* [PATCH 1/2] clk: imx6ul: add GPIO clock gates
From: Michael Nazzareno Trimarchi @ 2018-06-02 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5DfpwEDrBrMaTCt1_2Kkkm_tuVLE2WMy5z2=iO_rRFVEg@mail.gmail.com>
Hi Fabio
On Sat, Jun 2, 2018 at 4:07 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Michael,
>
> On Sat, Jun 2, 2018 at 11:04 AM, Michael Nazzareno Trimarchi
> <michael@amarulasolutions.com> wrote:
>
>> ull is a preatty new platform so one board was listed. Are you sure
>> that we need?
>
> There are several imx6ul based dts in mainline and it is better if we
> can avoid dtb breakage when possible.
>
> In this case we can avoid the dtb breakage by adding the new clock
> definitions at the end of the file, just like we do for all the other
> imx devices.
Yes, when I add new ul clock I move down ull (that is new), but agree
that this is not possible in general.
Michael
^ permalink raw reply
* [PATCH 1/2] clk: imx6ul: add GPIO clock gates
From: Fabio Estevam @ 2018-06-02 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOf5uwneWyjNpD-tGGL7CgL2_jJFvDtzbi+NBg7wqGMGR4qGCw@mail.gmail.com>
Hi Michael,
On Sat, Jun 2, 2018 at 11:04 AM, Michael Nazzareno Trimarchi
<michael@amarulasolutions.com> wrote:
> ull is a preatty new platform so one board was listed. Are you sure
> that we need?
There are several imx6ul based dts in mainline and it is better if we
can avoid dtb breakage when possible.
In this case we can avoid the dtb breakage by adding the new clock
definitions at the end of the file, just like we do for all the other
imx devices.
^ permalink raw reply
* [PATCH 1/2] clk: imx6ul: add GPIO clock gates
From: Michael Nazzareno Trimarchi @ 2018-06-02 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BVhjwGpJ22qBihKcjWyvBkzNPU0cNtNY9HToLLEkYByA@mail.gmail.com>
Hi
On Sat, Jun 2, 2018 at 3:48 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Stefan,
>
> On Tue, May 22, 2018 at 9:25 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>
>>> --- a/include/dt-bindings/clock/imx6ul-clock.h
>>> +++ b/include/dt-bindings/clock/imx6ul-clock.h
>>> @@ -242,20 +242,25 @@
>>> #define IMX6UL_CLK_CKO2_PODF 229
>>> #define IMX6UL_CLK_CKO2 230
>>> #define IMX6UL_CLK_CKO 231
>>> +#define IMX6UL_CLK_GPIO1 232
>>> +#define IMX6UL_CLK_GPIO2 233
>>> +#define IMX6UL_CLK_GPIO3 234
>>> +#define IMX6UL_CLK_GPIO4 235
>>> +#define IMX6UL_CLK_GPIO5 236
>>
>> this change looks like a breakage of devicetree ABI. You are changing the mean of the existing clock IDs on i.MX6ULL, which probably regress the combination of older DTBs with newer kernel.
>
> Good point! I will send a fix for f5a4670de96678 ("clk: imx: Add new
> clo01 and clo2 controlled
> by CCOSR") which did the same reordering.
>
ull is a preatty new platform so one board was listed. Are you sure
that we need?
Michael
> Thanks
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
^ permalink raw reply
* [clk:clk-qcom-sdm845 12/13] ERROR: "clk_fabia_pll_configure" [drivers/clk/qcom/videocc-sdm845.ko] undefined!
From: kbuild test robot @ 2018-06-02 13:53 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-qcom-sdm845
head: a3dcdc7e5417a369f59214f67cd642c95017cf3b
commit: c646b347669587790db6c703d0786bb5a2639bdd [12/13] clk: qcom: Add video clock controller driver for SDM845
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout c646b347669587790db6c703d0786bb5a2639bdd
# save the attached .config to linux build tree
make ARCH=i386
Note: the clk/clk-qcom-sdm845 HEAD a3dcdc7e5417a369f59214f67cd642c95017cf3b builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
>> ERROR: "clk_fabia_pll_configure" [drivers/clk/qcom/videocc-sdm845.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 62909 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180602/93f1a1e9/attachment-0001.gz>
^ permalink raw reply
* [PATCH 1/2] clk: imx6ul: add GPIO clock gates
From: Fabio Estevam @ 2018-06-02 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1439344955.9677.1526991935718@email.1und1.de>
Hi Stefan,
On Tue, May 22, 2018 at 9:25 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>> --- a/include/dt-bindings/clock/imx6ul-clock.h
>> +++ b/include/dt-bindings/clock/imx6ul-clock.h
>> @@ -242,20 +242,25 @@
>> #define IMX6UL_CLK_CKO2_PODF 229
>> #define IMX6UL_CLK_CKO2 230
>> #define IMX6UL_CLK_CKO 231
>> +#define IMX6UL_CLK_GPIO1 232
>> +#define IMX6UL_CLK_GPIO2 233
>> +#define IMX6UL_CLK_GPIO3 234
>> +#define IMX6UL_CLK_GPIO4 235
>> +#define IMX6UL_CLK_GPIO5 236
>
> this change looks like a breakage of devicetree ABI. You are changing the mean of the existing clock IDs on i.MX6ULL, which probably regress the combination of older DTBs with newer kernel.
Good point! I will send a fix for f5a4670de96678 ("clk: imx: Add new
clo01 and clo2 controlled
by CCOSR") which did the same reordering.
Thanks
^ permalink raw reply
* [PATCH v2 5/5] arm64: dts: renesas: r8a7795: add ccree binding
From: Simon Horman @ 2018-06-02 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUX874g6pAz-Ze-yA3S+6aOhzUkfGN9wmQUhy-y0f7dMw@mail.gmail.com>
On Fri, Jun 01, 2018 at 10:12:24AM +0200, Geert Uytterhoeven wrote:
> Hi Gilad,
>
> On Thu, May 31, 2018 at 1:55 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> > On Tue, May 29, 2018 at 7:19 PM, Simon Horman <horms@verge.net.au> wrote:
> >> On Thu, May 24, 2018 at 03:19:10PM +0100, Gilad Ben-Yossef wrote:
> >>> Add bindings for CryptoCell instance in the SoC.
> >>>
> >>> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
> >>
> >> In so far as I can review the details of this (which is not much) this
> >> looks fine to me. I am, however, a little unclear in when it should be
> >> accepted.
> >
> > Since Herbert Xu ACKed the driver changes, I would say the only gating
> > commit is Geert's CR clock patch.
>
> These are queued for v4.19.
>
> > If that one is in, than I would say this one should go in as well.
>
> As the device node now has a power-domains property, the genpd code will
> try to attach it to the CPG/MSSR PM Domain, which is a clock domain.
> In the absence of the clock patch, the device's module clock cannot be
> found, and dev_pm_domain_attach() and thus platform_drv_probe() will fail,
> before calling the device driver's .probe() function.
>
> So there is no longer a dependency on the clock patch, and the DT patch can
> go in in parallel (although I prefer its subject to be changed
> s/binding/device device/).
Thanks, I have applied the following (but may not push until next week).
From: Gilad Ben-Yossef <gilad@benyossef.com>
Subject: [PATCH] arm64: dts: renesas: r8a7795: add ccree to device tree
Add bindings for CryptoCell instance in the SoC.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index d842940b2f43..3ac75dbf2d93 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -528,6 +528,15 @@
status = "disabled";
};
+ arm_cc630p: crypto at e6601000 {
+ compatible = "arm,cryptocell-630p-ree";
+ interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0x0 0xe6601000 0 0x1000>;
+ clocks = <&cpg CPG_MOD 229>;
+ resets = <&cpg 229>;
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ };
+
i2c3: i2c at e66d0000 {
#address-cells = <1>;
#size-cells = <0>;
--
2.11.0
^ permalink raw reply related
* [PATCH 8/8] media: uniphier: add LD20 adapter driver for ISDB
From: Masahiro Yamada @ 2018-06-02 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530090946.1635-9-suzuki.katsuhiro@socionext.com>
2018-05-30 18:09 GMT+09:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>:
> This patch adds UniPhier LD20 DVB adapter driver for ISDB-S/T
> that equipments SONY SUT-PJ series using CXD2858 tuner and Socionext
> MN884434 demodulator.
>
> Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
> ---
> drivers/media/platform/uniphier/Kconfig | 10 +
> drivers/media/platform/uniphier/Makefile | 1 +
> .../platform/uniphier/ld20-mn884434-helene.c | 274 ++++++++++++++++++
> 3 files changed, 285 insertions(+)
> create mode 100644 drivers/media/platform/uniphier/ld20-mn884434-helene.c
>
> +
> +static const struct of_device_id uniphier_hsc_adapter_of_match[] = {
> + {
> + .compatible = "socionext,uniphier-ld20-mn884434-helene",
> + .data = &ld20_mn884434_helene_spec,
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, uniphier_hsc_adapter_of_match);
> +
> +static struct platform_driver uniphier_hsc_adapter_driver = {
> + .driver = {
> + .name = "uniphier-ld20-isdb",
> + .of_match_table = of_match_ptr(uniphier_hsc_adapter_of_match),
> + },
> + .probe = uniphier_adapter_probe,
> + .remove = uniphier_adapter_remove,
> +};
> +module_platform_driver(uniphier_hsc_adapter_driver);
> +
> +MODULE_AUTHOR("Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>");
> +MODULE_DESCRIPTION("UniPhier LD20 adapter driver for ISDB.");
> +MODULE_LICENSE("GPL v2");
This is weird.
>From drivers/media/platform/uniphier/Makefile,
obviously you link all the objects into the single module, uniphier-dvb.ko
It contains zero, one, or two sets of MODULE_* depending on CONFIG options.
- Zero MODULE_LICENSE / MODULE_AUTHOR / MODULE_DESCRIPTION
if CONFIG_DVB_UNIPHIER_LD11_ISDB=n &&
CONFIG_DVB_UNIPHIER_LD20_ISDB=n
- Two sets of MODULE_LICENSE / MODULE_AUTHOR / MODULE_DESCRIPTION
if CONFIG_DVB_UNIPHIER_LD11_ISDB=y &&
CONFIG_DVB_UNIPHIER_LD20_ISDB=y
What you can do is:
- Split the module into core, ld11, ld20
or
- Move the module tags and entry to hsc-core.c
and leave only the data arrays in ld11, ld20.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH 7/8] media: uniphier: add LD11 adapter driver for ISDB
From: Masahiro Yamada @ 2018-06-02 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530090946.1635-8-suzuki.katsuhiro@socionext.com>
2018-05-30 18:09 GMT+09:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>:
> diff --git a/drivers/media/platform/uniphier/ld11-mn884433-helene.c b/drivers/media/platform/uniphier/ld11-mn884433-helene.c
> new file mode 100644
> index 000000000000..f4f48b6a0211
> --- /dev/null
> +++ b/drivers/media/platform/uniphier/ld11-mn884433-helene.c
> @@ -0,0 +1,265 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Socionext UniPhier LD11 adapter driver for ISDB.
> +// Using Socionext MN884433 ISDB-S/ISDB-T demodulator and
> +// SONY HELENE tuner.
> +//
> +// Copyright (c) 2018 Socionext Inc.
> +
> +#include <linux/clk.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/reset.h>
> +
> +#include "sc1501a.h"
"sc1501a.h" is not included in this patch series.
It took some time to notice that
this series actually depends on the following:
https://patchwork.kernel.org/patch/10434159/
Otherwise, this cause a build error.
scripts/kconfig/conf --syncconfig Kconfig
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK scripts/mod/devicetable-offsets.h
CHK include/generated/utsrelease.h
CHK include/generated/bounds.h
CHK include/generated/timeconst.h
CHK include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
CC [M] drivers/media/platform/uniphier/ld11-mn884433-helene.o
drivers/media/platform/uniphier/ld11-mn884433-helene.c:16:10: fatal
error: sc1501a.h: No such file or directory
#include "sc1501a.h"
^~~~~~~~~~~
compilation terminated.
make[2]: *** [scripts/Makefile.build:313:
drivers/media/platform/uniphier/ld11-mn884433-helene.o] Error 1
make[1]: *** [scripts/Makefile.build:559:
drivers/media/platform/uniphier] Error 2
make: *** [Makefile:1746: drivers/media/platform/] Error 2
I applied that patch, but still fail to build this series.
CC [M] drivers/media/platform/uniphier/hsc-core.o
CC [M] drivers/media/platform/uniphier/hsc-ucode.o
CC [M] drivers/media/platform/uniphier/hsc-css.o
CC [M] drivers/media/platform/uniphier/hsc-ts.o
CC [M] drivers/media/platform/uniphier/hsc-dma.o
CC [M] drivers/media/platform/uniphier/hsc-ld11.o
CC [M] drivers/media/platform/uniphier/uniphier-adapter.o
CC [M] drivers/media/platform/uniphier/ld11-mn884433-helene.o
drivers/media/platform/uniphier/ld11-mn884433-helene.c:17:10: fatal
error: cxd2858.h: No such file or directory
#include "cxd2858.h"
^~~~~~~~~~~
compilation terminated.
make[1]: *** [scripts/Makefile.build:312:
drivers/media/platform/uniphier/ld11-mn884433-helene.o] Error 1
make: *** [Makefile:1665: drivers/media/platform/uniphier/] Error 2
I give up searching pre-requisite patches.
You need to describe this information under '---'
if your series needs pre-requisite patches that have not been applied yet.
> +#include "cxd2858.h"
> +#include "helene.h"
> +#include "hsc.h"
> +#include "uniphier-adapter.h"
> +
> +static struct sc1501a_config mn884433_conf[] = {
> + { .if_freq = LOW_IF_4MHZ, },
> +};
> +
> +static int uniphier_adapter_demod_probe(struct uniphier_adapter_priv *priv)
> +{
> + const struct uniphier_adapter_spec *spec = priv->spec;
> + struct device *dev = &priv->pdev->dev;
> + struct device_node *node;
> + int ret, i;
> +
> + priv->demod_mclk = devm_clk_get(dev, "demod-mclk");
> + if (IS_ERR(priv->demod_mclk)) {
> + dev_err(dev, "Failed to request demod-mclk: %ld\n",
> + PTR_ERR(priv->demod_mclk));
> + return PTR_ERR(priv->demod_mclk);
> + }
> +
> + priv->demod_gpio = devm_gpiod_get_optional(dev, "reset-demod",
> + GPIOD_OUT_HIGH);
> + if (IS_ERR(priv->demod_gpio)) {
> + dev_err(dev, "Failed to request demod_gpio: %ld\n",
> + PTR_ERR(priv->demod_gpio));
> + return PTR_ERR(priv->demod_gpio);
> + }
> +
> + node = of_parse_phandle(dev->of_node, "demod-i2c-bus", 0);
> + if (!node) {
> + dev_err(dev, "Failed to parse demod-i2c-bus\n");
> + return -ENODEV;
> + }
> +
> + priv->demod_i2c_adapter = of_find_i2c_adapter_by_node(node);
> + if (!priv->demod_i2c_adapter) {
> + dev_err(dev, "Failed to find demod i2c adapter\n");
> + of_node_put(node);
> + return -ENODEV;
> + }
> + of_node_put(node);
> +
> + mn884433_conf[0].reset_gpio = priv->demod_gpio;
> + for (i = 0; i < spec->adapters; i++) {
> + struct i2c_client *c;
> +
> + mn884433_conf[i].mclk = priv->demod_mclk;
> + mn884433_conf[i].fe = &priv->fe[i].fe;
> +
> + c = dvb_module_probe(spec->demod_i2c_info[i].type, NULL,
> + priv->demod_i2c_adapter,
> + spec->demod_i2c_info[i].addr,
> + &mn884433_conf[i]);
> + if (!c) {
> + dev_err(dev, "Failed to probe demod\n");
> + ret = -ENODEV;
> + goto err_out;
> + }
> + priv->fe[i].demod_i2c = c;
> + }
> +
> + return 0;
> +
> +err_out:
> + for (i = 0; i < spec->adapters; i++)
> + dvb_module_release(priv->fe[i].demod_i2c);
> +
> + return ret;
> +}
> +
> +static struct helene_config helene_conf[] = {
> + { .xtal = SONY_HELENE_XTAL_16000, },
> + { .xtal = SONY_HELENE_XTAL_16000, },
> +};
> +
> +static int uniphier_adapter_tuner_probe(struct uniphier_adapter_priv *priv)
> +{
> + const struct uniphier_adapter_spec *spec = priv->spec;
> + struct device *dev = &priv->pdev->dev;
> + struct device_node *node;
> + int ret, i;
> +
> + priv->tuner_gpio = devm_gpiod_get_optional(dev, "reset-tuner",
> + GPIOD_OUT_HIGH);
> + if (IS_ERR(priv->tuner_gpio)) {
> + dev_err(dev, "Failed to request tuner_gpio: %ld\n",
> + PTR_ERR(priv->tuner_gpio));
> + return PTR_ERR(priv->tuner_gpio);
> + }
> + gpiod_set_value_cansleep(priv->tuner_gpio, 0);
> +
> + node = of_parse_phandle(dev->of_node, "tuner-i2c-bus", 0);
> + if (!node) {
> + dev_err(dev, "Failed to parse tuner-i2c-bus\n");
> + return -ENODEV;
> + }
> +
> + priv->tuner_i2c_adapter = of_find_i2c_adapter_by_node(node);
> + if (!priv->tuner_i2c_adapter) {
> + dev_err(dev, "Failed to find tuner i2c adapter\n");
> + of_node_put(node);
> + return -ENODEV;
> + }
> + of_node_put(node);
> +
> + for (i = 0; i < priv->spec->adapters; i++) {
> + struct i2c_client *c;
> +
> + helene_conf[i].fe = priv->fe[i].fe;
> +
> + c = dvb_module_probe(spec->tuner_i2c_info[i].type, NULL,
> + priv->tuner_i2c_adapter,
> + spec->tuner_i2c_info[i].addr,
> + &helene_conf[i]);
> + if (!c) {
> + dev_err(dev, "Failed to probe tuner\n");
> + ret = -ENODEV;
> + goto err_out;
> + }
> + priv->fe[i].tuner_i2c = c;
> + }
> +
> + return 0;
> +
> +err_out:
> + for (i = 0; i < spec->adapters; i++)
> + dvb_module_release(priv->fe[i].tuner_i2c);
> +
> + return ret;
> +}
> +
> +static int uniphier_adapter_probe(struct platform_device *pdev)
> +{
> + struct uniphier_adapter_priv *priv;
> + struct device *dev = &pdev->dev;
> + int i, ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> + priv->pdev = pdev;
> +
> + priv->spec = of_device_get_match_data(dev);
> + if (!priv->spec)
> + return -EINVAL;
> +
> + priv->fe = devm_kzalloc(dev, sizeof(*priv->fe) * priv->spec->adapters,
> + GFP_KERNEL);
> + if (!priv->fe)
> + return -ENOMEM;
> +
> + ret = uniphier_adapter_demux_probe(priv);
> + if (ret)
> + return ret;
> +
> + ret = uniphier_adapter_demod_probe(priv);
> + if (ret)
> + return ret;
> +
> + ret = uniphier_adapter_tuner_probe(priv);
> + if (ret)
> + return ret;
> +
> + platform_set_drvdata(pdev, priv);
> +
> + for (i = 0; i < priv->spec->adapters; i++) {
> + priv->chip->tsif[i].fe = priv->fe[i].fe;
> +
> + ret = hsc_register_dvb(&priv->chip->tsif[i]);
> + if (ret) {
> + dev_err(dev, "Failed to register adapter\n");
> + goto err_out_if;
> + }
> + }
> +
> + return 0;
> +
> +err_out_if:
> + for (i = 0; i < priv->spec->adapters; i++)
> + hsc_unregister_dvb(&priv->chip->tsif[i]);
> +
> + return ret;
> +}
> +
> +static int uniphier_adapter_remove(struct platform_device *pdev)
> +{
> + struct uniphier_adapter_priv *priv = platform_get_drvdata(pdev);
> + int i;
> +
> + for (i = 0; i < priv->spec->adapters; i++) {
> + hsc_dmaif_release(&priv->chip->dmaif[i]);
> + hsc_tsif_release(&priv->chip->tsif[i]);
> + hsc_unregister_dvb(&priv->chip->tsif[i]);
> + dvb_module_release(priv->fe[i].tuner_i2c);
> + dvb_module_release(priv->fe[i].demod_i2c);
> + }
> +
> + return 0;
> +}
> +
> +static const struct hsc_conf ld11_hsc_conf[] = {
> + {
> + .css_in = HSC_CSS_IN_SRLTS0,
> + .css_out = HSC_CSS_OUT_TSI0,
> + .dpll = HSC_DPLL0,
> + .dma_out = HSC_DMA_OUT0,
> + },
> +};
> +
> +static const struct i2c_board_info mn884433_i2c_info[] = {
> + { .type = "mn884433", .addr = 0x68, },
> +};
> +
> +static const struct i2c_board_info helene_i2c_info[] = {
> + { .type = "helene", .addr = 0x61, },
> +};
> +
> +static const struct uniphier_adapter_spec ld11_mn884433_helene_spec = {
> + .adapters = 1,
> + .hsc_conf = ld11_hsc_conf,
> + .demod_i2c_info = mn884433_i2c_info,
> + .tuner_i2c_info = helene_i2c_info,
> +};
> +
> +static const struct of_device_id uniphier_hsc_adapter_of_match[] = {
> + {
> + .compatible = "socionext,uniphier-ld11-mn884433-helene",
> + .data = &ld11_mn884433_helene_spec,
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, uniphier_hsc_adapter_of_match);
> +
> +static struct platform_driver uniphier_hsc_adapter_driver = {
> + .driver = {
> + .name = "uniphier-ld11-isdb",
> + .of_match_table = of_match_ptr(uniphier_hsc_adapter_of_match),
> + },
> + .probe = uniphier_adapter_probe,
> + .remove = uniphier_adapter_remove,
> +};
> +module_platform_driver(uniphier_hsc_adapter_driver);
> +
> +MODULE_AUTHOR("Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>");
> +MODULE_DESCRIPTION("UniPhier LD11 adapter driver for ISDB.");
> +MODULE_LICENSE("GPL v2");
> --
> 2.17.0
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH 6/8] media: uniphier: add common module of DVB adapter drivers
From: Masahiro Yamada @ 2018-06-02 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530090946.1635-7-suzuki.katsuhiro@socionext.com>
2018-05-30 18:09 GMT+09:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>:
> This patch adds common module for UniPhier DVB adapter drivers
> that equipments tuners and demod that connected by I2C and
> UniPhier demux.
>
> Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
> ---
> drivers/media/platform/uniphier/Makefile | 5 ++
> drivers/media/platform/uniphier/hsc-core.c | 8 ---
> .../platform/uniphier/uniphier-adapter.c | 54 +++++++++++++++++++
> .../platform/uniphier/uniphier-adapter.h | 42 +++++++++++++++
> 4 files changed, 101 insertions(+), 8 deletions(-)
> create mode 100644 drivers/media/platform/uniphier/uniphier-adapter.c
> create mode 100644 drivers/media/platform/uniphier/uniphier-adapter.h
>
> diff --git a/drivers/media/platform/uniphier/Makefile b/drivers/media/platform/uniphier/Makefile
> index 0622f04d9e68..9e75ad081b77 100644
> --- a/drivers/media/platform/uniphier/Makefile
> +++ b/drivers/media/platform/uniphier/Makefile
> @@ -3,3 +3,8 @@ uniphier-dvb-y += hsc-core.o hsc-ucode.o hsc-css.o hsc-ts.o hsc-dma.o
> uniphier-dvb-$(CONFIG_DVB_UNIPHIER_LD11) += hsc-ld11.o
>
> obj-$(CONFIG_DVB_UNIPHIER) += uniphier-dvb.o
> +
> +ccflags-y += -Idrivers/media/dvb-frontends/
> +ccflags-y += -Idrivers/media/tuners/
Please add $(srctree)/ like
ccflags-y += -I$(srctree)/drivers/media/dvb-frontends/
ccflags-y += -I$(srctree)/drivers/media/tuners/
Currently, it works $(srctree)/,
but I really want to rip off the build system hack.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH 3/8] media: uniphier: add submodules of HSC MPEG2-TS I/O driver
From: Masahiro Yamada @ 2018-06-02 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530090946.1635-4-suzuki.katsuhiro@socionext.com>
2018-05-30 18:09 GMT+09:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>:
> This patch adds submodules of HSC for UniPhier SoCs.
> These work as follows:
> ucode: Load uCode and start subsystems
> css : Switch stream path
> ts : Receive MPEG2-TS clock and signal
> dma : Transfer MPEG2-TS data bytes to main memory
>
> Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
> ---
> drivers/media/platform/uniphier/Makefile | 3 +
> drivers/media/platform/uniphier/hsc-css.c | 258 ++++++++++++
> drivers/media/platform/uniphier/hsc-dma.c | 302 ++++++++++++++
> drivers/media/platform/uniphier/hsc-ts.c | 99 +++++
> drivers/media/platform/uniphier/hsc-ucode.c | 436 ++++++++++++++++++++
> 5 files changed, 1098 insertions(+)
> create mode 100644 drivers/media/platform/uniphier/hsc-css.c
> create mode 100644 drivers/media/platform/uniphier/hsc-dma.c
> create mode 100644 drivers/media/platform/uniphier/hsc-ts.c
> create mode 100644 drivers/media/platform/uniphier/hsc-ucode.c
>
> diff --git a/drivers/media/platform/uniphier/Makefile b/drivers/media/platform/uniphier/Makefile
> index f66554cd5c45..92536bc56b31 100644
> --- a/drivers/media/platform/uniphier/Makefile
> +++ b/drivers/media/platform/uniphier/Makefile
> @@ -1 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
> +uniphier-dvb-y += hsc-ucode.o hsc-css.o hsc-ts.o hsc-dma.o
> +
> +obj-$(CONFIG_DVB_UNIPHIER) += uniphier-dvb.o
If you claim this driver is tristate,
you need to do compile-test with =m.
I see the following warning for allmodconfig.
CC [M] drivers/media/platform/uniphier/hsc-ucode.o
CC [M] drivers/media/platform/uniphier/hsc-css.o
CC [M] drivers/media/platform/uniphier/hsc-ts.o
CC [M] drivers/media/platform/uniphier/hsc-dma.o
LD [M] drivers/media/platform/uniphier/uniphier-dvb.o
WARNING: modpost: missing MODULE_LICENSE() in
drivers/media/platform/uniphier/uniphier-dvb.o
see include/linux/module.h for more information
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH 2/8] media: uniphier: add headers of HSC MPEG2-TS I/O driver
From: Masahiro Yamada @ 2018-06-02 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530090946.1635-3-suzuki.katsuhiro@socionext.com>
2018-05-30 18:09 GMT+09:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>:
> This patch adds register definitions of HSC (High speed Stream
> Controller) driver for Socionext UniPhier SoCs. The HSC enables to
> input and output MPEG2-TS stream from/to outer world of SoC.
>
> Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
> ---
> drivers/media/platform/Kconfig | 1 +
> drivers/media/platform/Makefile | 2 +
> drivers/media/platform/uniphier/Kconfig | 9 +
> drivers/media/platform/uniphier/Makefile | 1 +
> drivers/media/platform/uniphier/hsc-reg.h | 491 ++++++++++++++++++++++
> drivers/media/platform/uniphier/hsc.h | 480 +++++++++++++++++++++
> 6 files changed, 984 insertions(+)
> create mode 100644 drivers/media/platform/uniphier/Kconfig
> create mode 100644 drivers/media/platform/uniphier/Makefile
> create mode 100644 drivers/media/platform/uniphier/hsc-reg.h
> create mode 100644 drivers/media/platform/uniphier/hsc.h
What's the point of adding an empty Makefile,
and header files in a separate commit?
Anyway, ...
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 2728376b04b5..289ab4dfd30e 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -525,6 +525,7 @@ menuconfig DVB_PLATFORM_DRIVERS
>
> if DVB_PLATFORM_DRIVERS
> source "drivers/media/platform/sti/c8sectpfe/Kconfig"
> +source "drivers/media/platform/uniphier/Kconfig"
> endif #DVB_PLATFORM_DRIVERS
>
> menuconfig CEC_PLATFORM_DRIVERS
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 04bc1502a30e..08d5052119ef 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -93,3 +93,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS) += qcom/camss-8x16/
> obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
>
> obj-y += meson/
> +
> +obj-$(CONFIG_DVB_UNIPHIER) += uniphier/
> diff --git a/drivers/media/platform/uniphier/Kconfig b/drivers/media/platform/uniphier/Kconfig
> new file mode 100644
> index 000000000000..1b4543ec1e3c
> --- /dev/null
> +++ b/drivers/media/platform/uniphier/Kconfig
> @@ -0,0 +1,9 @@
> +# SPDX-License-Identifier: GPL-2.0
> +config DVB_UNIPHIER
> + tristate "Socionext UniPhier Frontend"
> + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
> + depends on ARCH_UNIPHIER
depends on ARCH_UNIPHIER || COMPILE_TEST
Not so sure if regmap is useful here.
Anyway this driver uses regmap_{read,write},
but 'select REGMAP_MMIO' is missing.
> + help
> + Driver for UniPhier frontend for MPEG2-TS input/output,
> + demux and descramble.
> + Say Y when you want to support this frontend.
> diff --git a/drivers/media/platform/uniphier/Makefile b/drivers/media/platform/uniphier/Makefile
> new file mode 100644
> index 000000000000..f66554cd5c45
> --- /dev/null
> +++ b/drivers/media/platform/uniphier/Makefile
> @@ -0,0 +1 @@
> +# SPDX-License-Identifier: GPL-2.0
> diff --git a/drivers/media/platform/uniphier/hsc-reg.h b/drivers/media/platform/uniphier/hsc-reg.h
> new file mode 100644
> index 000000000000..5f0a9b86cf49
> --- /dev/null
> +++ b/drivers/media/platform/uniphier/hsc-reg.h
> @@ -0,0 +1,491 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Socionext UniPhier DVB driver for High-speed Stream Controller (HSC).
> + *
> + * Copyright (c) 2018 Socionext Inc.
> + */
> +
> +#ifndef DVB_UNIPHIER_HSC_REG_H__
> +#define DVB_UNIPHIER_HSC_REG_H__
> +
> +/*
> + * CH_0 : CIP-R8, W9
> + * CH_1 : CIP-R10,W11
> + * CH_2 : CIP-R12,W13
> + * CH_3 : CIP-R14,W15
> + * CH_4 : CIP-R16,W17
> + */
> +enum HSC_CIP_FILE_NO {
Please use lower cases for enum.
> + HSC_CIP_FILE_NO_0 = 0x0,
> + HSC_CIP_FILE_NO_1,
> + HSC_CIP_FILE_NO_2,
> + HSC_CIP_FILE_NO_3,
> + HSC_CIP_FILE_NO_4,
> + HSC_CIP_FILE_NO_END,
> + HSC_CIP_FILE_NO_DISABLE,
> +};
This is OK.
The members of enum should be capitalized.
[ snip ]
> +
> +/* MBC
> + * i: channel number
> + * 1- 3: Record0,1,2
> + * 19-21: Record3,4,5
> + */
Why is this block comment sylte?
Documentation/process/coding-style.rst says
this style is used only files under net/ and drivers/net.
> +#define CDMBC_CHTDCTRLH(i) (((i) < 19) ? \
> + (0x23a4 + ((i) - 1) * 0x20) : \
> + (0x23b4 + ((i) - 19) * 0x20))
> +#define CDMBC_CHTDCTRLH_STREM_MASK GENMASK(20, 16)
> +#define CDMBC_CHTDCTRLH_NOT_FLT BIT(7)
> +#define CDMBC_CHTDCTRLH_ALL_EN BIT(6)
> +#define CDMBC_CHTDCTRLU(i) (((i) < 19) ? \
> + (0x23a8 + ((i) - 1) * 0x20) : \
> + (0x23b8 + ((i) - 19) * 0x20))
Hmm, OK this is macro...
> +#define CDMBC_TDSTAT 0x23f8
> +#define CDMBC_TDIR 0x23fc
> +#define CDMBC_REPRATECTRL 0x2400
> +#define CDMBC_ATRIBUTE0 0x24e8
> +#define CDMBC_ATRIBUTE1 0x24ec
> +#define CDMBC_ATRIBUTE2 0x24f0
> +#define CDMBC_ATRIBUTE3 0x24f4
> +#define CDMBC_ATRIBUTE4 0x24f8
> +#define CDMBC_CIPMODE(i) (0x24fc + (i) * 0x4)
> +#define CDMBC_CIPMODE_PUSH BIT(0)
> +#define CDMBC_CIPPRIORITY(i) (0x2510 + (i) * 0x4)
> +#define CDMBC_CIPPRIORITY_PRIOR_MASK GENMASK(1, 0)
> +#define CDMBC_CH18ATTRIBUTE (0x2524)
> +
> +/* MBC Channel
> + * i: channel number
> + * 0 : Section
> + * 1- 3: Record0,1,2
> + * 4 : Partial
> + * 5- 7: Replay0,1,2
> + * 8-17: Even: CIP-Read
> + * Odd : CIP-Write
> + * 18 : AM32
> + * 19-21: Record3,4,5
> + * 22-24: Replay3,4,5
> + */
> +#define CDMBC_CHCTRL1(i) (0x2540 + (i) * 0x50)
> +#define CDMBC_CHCTRL1_LINKCH1_MASK GENMASK(12, 10)
> +#define CDMBC_CHCTRL1_STATSEL_MASK GENMASK(9, 7)
> +#define CDMBC_CHCTRL1_TYPE_INTERMIT BIT(1)
> +#define CDMBC_CHCTRL1_IND_SIZE_UND BIT(0)
> +#define CDMBC_CHCTRL2(i) (0x2544 + (i) * 0x50)
> +#define CDMBC_CHDDR(i) (0x2548 + (i) * 0x50)
> +#define CDMBC_CHDDR_REG_LOAD_ON BIT(4)
> +#define CDMBC_CHDDR_AT_CHEN_ON BIT(3)
> +#define CDMBC_CHDDR_SET_MCB_MASK GENMASK(2, 1)
> +#define CDMBC_CHDDR_SET_MCB_WR (0x0 << 1)
> +#define CDMBC_CHDDR_SET_MCB_RD (0x3 << 1)
> +#define CDMBC_CHDDR_SET_DDR_1 BIT(0)
> +#define CDMBC_CHCAUSECTRL(i) (0x254c + (i) * 0x50)
> +#define CDMBC_CHCAUSECTRL_MODE_MASK BIT(31)
> +#define CDMBC_CHCAUSECTRL_CSEL2_MASK GENMASK(20, 12)
> +#define CDMBC_CHCAUSECTRL_CSEL1_MASK GENMASK(8, 0)
> +#define CDMBC_CHSTAT(i) (0x2550 + (i) * 0x50)
> +#define CDMBC_CHIR(i) (0x2554 + (i) * 0x50)
> +#define CDMBC_CHIE(i) (0x2558 + (i) * 0x50)
> +#define CDMBC_CHID(i) (0x255c + (i) * 0x50)
> +#define CDMBC_CHI_STOPPED BIT(13)
> +#define CDMBC_CHI_TRANSIT BIT(6)
> +#define CDMBC_CHI_STARTING BIT(1)
> +#define CDMBC_CHSRCAMODE(i) (0x2560 + (i) * 0x50)
> +#define CDMBC_CHDSTAMODE(i) (0x2564 + (i) * 0x50)
> +#define CDMBC_CHAMODE_TUNIT_MASK GENMASK(29, 28)
> +#define CDMBC_CHAMODE_ENDIAN_MASK GENMASK(17, 16)
> +#define CDMBC_CHAMODE_AUPDT_MASK GENMASK(5, 4)
> +#define CDMBC_CHAMODE_TYPE_RB BIT(2)
> +#define CDMBC_CHSRCSTRTADRSD(i) (0x2568 + (i) * 0x50)
> +#define CDMBC_CHSRCSTRTADRSU(i) (0x256c + (i) * 0x50)
> +#define CDMBC_CHDSTSTRTADRSD(i) (0x2570 + (i) * 0x50)
> +#define CDMBC_CHDSTSTRTADRSU(i) (0x2574 + (i) * 0x50)
> +#define CDMBC_CHDSTSTRTADRS_TID_MASK GENMASK(31, 28)
> +#define CDMBC_CHDSTSTRTADRS_ID1_EN_MASK BIT(15)
> +#define CDMBC_CHDSTSTRTADRS_KEY_ID1_MASK GENMASK(12, 8)
> +#define CDMBC_CHDSTSTRTADRS_KEY_ID0_MASK GENMASK(4, 0)
> +#define CDMBC_CHSIZE(i) (0x2578 + (i) * 0x50)
> +#define CDMBC_CHIRADRSD(i) (0x2580 + (i) * 0x50)
> +#define CDMBC_CHIRADRSU(i) (0x2584 + (i) * 0x50)
> +#define CDMBC_CHDST1STUSIZE(i) (0x258C + (i) * 0x50)
> +
> +/* MBC DMA
> + * i: channel number
> + * 5- 7: Replay0,1,2
> + * 8-17: Even: CIP-Read
> + * Odd : CIP-Write
> + * 22-24: Replay3-5
> + */
> +static inline int HSC_IT_INT(int i)
> +{
> + if (i > 21)
> + return i - 9;
> +
> + return i - 5;
> +}
> +
> +#define CDMBC_ITCTRL(i) (0x3000 + HSC_IT_INT(i) * 0x20)
> +#define CDMBC_ITSTEPS(i) (0x3018 + HSC_IT_INT(i) * 0x20)
> +
> +/* MBC Ring buffer
> + * i: channel number
> + * 0 : Section (RB0)
> + * 1- 3: Record0,1,2 (RB1-3)
> + * 5- 7: Replay0,1,2 (RB4-6)
> + * 8-17: Even: CIP-Read
> + * Odd : CIP-Write (RB7-16)
> + * 19-21: Record3-4 (RB17-19)
> + * 22-24: Replay3-4 (RB20-22)
> + */
> +static inline int HSC_INT(int i)
> +{
> + if (i > 18)
> + return i - 2;
> + if (i > 4)
> + return i - 1;
> +
> + return i;
> +}
CDMBC_CHTDCTRLH(i) was a macro,
but HSC_INT() is a static inline function inconsistently,
then used from the lots of macros below...
Wow.
This is already enough crap.
Is there any other way instead of
putting all the mess into registers?
> +#define CDMBC_RBBGNADRS(i) (0x3200 + HSC_INT(i) * 0x40)
> +#define CDMBC_RBBGNADRSD(i) (0x3200 + HSC_INT(i) * 0x40)
> +#define CDMBC_RBBGNADRSU(i) (0x3204 + HSC_INT(i) * 0x40)
> +#define CDMBC_RBENDADRS(i) (0x3208 + HSC_INT(i) * 0x40)
> +#define CDMBC_RBENDADRSD(i) (0x3208 + HSC_INT(i) * 0x40)
> +#define CDMBC_RBENDADRSU(i) (0x320C + HSC_INT(i) * 0x40)
> +#define CDMBC_RBIR(i) (0x3214 + HSC_INT(i) * 0x40)
> +#define CDMBC_RBIE(i) (0x3218 + HSC_INT(i) * 0x40)
> +#define CDMBC_RBID(i) (0x321c + HSC_INT(i) * 0x40)
> +#define CDMBC_RBRDPTR(i) (0x3220 + HSC_INT(i) * 0x40)
> +#define CDMBC_RBRDPTRD(i) (0x3220 + HSC_INT(i) * 0x40)
> +#define CDMBC_RBRDPTRU(i) (0x3224 + HSC_INT(i) * 0x40)
> +#define CDMBC_RBWRPTR(i) (0x3228 + HSC_INT(i) * 0x40)
> +#define CDMBC_RBWRPTRD(i) (0x3228 + HSC_INT(i) * 0x40)
> +#define CDMBC_RBWRPTRU(i) (0x322C + HSC_INT(i) * 0x40)
> +#define CDMBC_RBERRCNFG(i) (0x3238 + HSC_INT(i) * 0x40)
> +
> +/* MBC Rate */
> +#define CDMBC_RCNMSKCYC(i) (MBC6_TOP_ADDR + 0x000 + (i) * 0x04)
> +
> +/* MBC Address Transfer */
> +#define CDMBC_CHPSIZE(i) (0x3c00 + ((i) - 1) * 0x48)
> +#define CDMBC_CHATCTRL(i) (0x3c04 + ((i) - 1) * 0x48)
> +#define CDMBC_CHBTPAGE(i, j) (0x3c08 + ((i) - 1) * 0x48 + (j) * 0x10)
> +#define CDMBC_CHBTPAGED(i, j) (0x3c08 + ((i) - 1) * 0x48 + (j) * 0x10)
> +#define CDMBC_CHBTPAGEU(i, j) (0x3c0C + ((i) - 1) * 0x48 + (j) * 0x10)
> +#define CDMBC_CHATPAGE(i, j) (0x3c10 + ((i) - 1) * 0x48 + (j) * 0x10)
> +#define CDMBC_CHATPAGED(i, j) (0x3c10 + ((i) - 1) * 0x48 + (j) * 0x10)
> +#define CDMBC_CHATPAGEU(i, j) (0x3c14 + ((i) - 1) * 0x48 + (j) * 0x10)
> +
> +/* CSS */
> +#define CSS_PTSOCONFIG 0x1c00
> +#define CSS_PTSISIGNALPOL 0x1c04
> +#define CSS_SIGNALPOLCH(i) (0x1c08 + (i) * 0x4)
> +#define CSS_OUTPUTENABLE 0x1c10
> +#define CSS_OUTPUTCTRL(i) (0x1c14 + (i) * 0x4)
> +#define CSS_STSOCONFIG 0x1c2c
> +#define CSS_STSOSIGNALPOL 0x1c30
> +#define CSS_DMDSIGNALPOL 0x1c34
> +#define CSS_PTSOSIGNALPOL 0x1c38
> +#define CSS_PF0CONFIG 0x1c3c
> +#define CSS_PF1CONFIG 0x1c40
> +#define CSS_PFINTENABLE 0x1c44
> +#define CSS_PFINTSTATUS 0x1c48
> +#define CSS_AVOUTPUTCTRL(i) (0x1c4c + (i) * 0x4)
> +#define CSS_DPCTRL(i) (0x1c54 + (i) * 0x4)
> +#define CSS_DPCTRL_DPSEL_MASK GENMASK(22, 0)
> +#define CSS_DPCTRL_DPSEL_PLAY5 BIT(15)
> +#define CSS_DPCTRL_DPSEL_PLAY4 BIT(14)
> +#define CSS_DPCTRL_DPSEL_PLAY3 BIT(13)
> +#define CSS_DPCTRL_DPSEL_PLAY2 BIT(12)
> +#define CSS_DPCTRL_DPSEL_PLAY1 BIT(11)
> +#define CSS_DPCTRL_DPSEL_PLAY0 BIT(10)
> +#define CSS_DPCTRL_DPSEL_TSI4 BIT(4)
> +#define CSS_DPCTRL_DPSEL_TSI3 BIT(3)
> +#define CSS_DPCTRL_DPSEL_TSI2 BIT(2)
> +#define CSS_DPCTRL_DPSEL_TSI1 BIT(1)
> +#define CSS_DPCTRL_DPSEL_TSI0 BIT(0)
> +
> +/* TSI */
> +#define TSI_SYNCCNTROL(i) (0x7100 + (i) * 0x70)
> +#define TSI_SYNCCNTROL_FRAME_MASK GENMASK(18, 16)
> +#define TSI_SYNCCNTROL_FRAME_EXTSYNC1 (0x0 << 16)
> +#define TSI_SYNCCNTROL_FRAME_EXTSYNC2 (0x1 << 16)
> +#define TSI_CONFIG(i) (0x7104 + (i) * 0x70)
> +#define TSI_CONFIG_ATSMD_MASK GENMASK(22, 21)
> +#define TSI_CONFIG_ATSMD_PCRPLL0 (0x0 << 21)
> +#define TSI_CONFIG_ATSMD_PCRPLL1 (0x1 << 21)
> +#define TSI_CONFIG_ATSMD_DPLL (0x3 << 21)
> +#define TSI_CONFIG_ATSADD_ON BIT(20)
> +#define TSI_CONFIG_STCMD_MASK GENMASK(7, 6)
> +#define TSI_CONFIG_STCMD_PCRPLL0 (0x0 << 6)
> +#define TSI_CONFIG_STCMD_PCRPLL1 (0x1 << 6)
> +#define TSI_CONFIG_STCMD_DPLL (0x3 << 6)
> +#define TSI_CONFIG_CHEN_START BIT(0)
> +#define TSI_RATEUPLMT(i) (0x7108 + (i) * 0x70)
> +#define TSI_RATELOWLMT(i) (0x710c + (i) * 0x70)
> +#define TSI_CNTINTR(i) (0x7110 + (i) * 0x70)
> +#define TSI_INTREN(i) (0x7114 + (i) * 0x70)
> +#define TSI_INTR_NTP BIT(13)
> +#define TSI_INTR_NTPCNT BIT(12)
> +#define TSI_INTR_PKTEND BIT(11)
> +#define TSI_INTR_PCR BIT(9)
> +#define TSI_INTR_LOAD BIT(8)
> +#define TSI_INTR_SERR BIT(7)
> +#define TSI_INTR_SOF BIT(6)
> +#define TSI_INTR_TOF BIT(5)
> +#define TSI_INTR_UL BIT(4)
> +#define TSI_INTR_LL BIT(3)
> +#define TSI_INTR_CNT BIT(2)
> +#define TSI_INTR_LOST BIT(1)
> +#define TSI_INTR_LOCK BIT(0)
> +#define TSI_SYNCSTATUS(i) (0x7118 + (i) * 0x70)
> +#define TSI_STAT_PKTST_ERR BIT(21)
> +#define TSI_STAT_LARGE_ERR BIT(20)
> +#define TSI_STAT_SMALL_ERR BIT(19)
> +#define TSI_STAT_LOCK BIT(18)
> +#define TSI_STAT_SYNC BIT(17)
> +#define TSI_STAT_SEARCH BIT(16)
> +#define TSI_PCRPID(i) (0x711c + (i) * 0x70)
> +#define TSI_PCRCTRL(i) (0x7120 + (i) * 0x70)
> +#define TSI_STCBASE(i) (0x7124 + (i) * 0x70)
> +#define TSI_STCEXT(i) (0x7128 + (i) * 0x70)
> +#define TSI_CURSTC1(i) (0x712c + (i) * 0x70)
> +#define TSI_CURSTCBASE(i) (0x712c + (i) * 0x70)
> +#define TSI_CURSTC2(i) (0x7130 + (i) * 0x70)
> +#define TSI_CURSTCEXT(i) (0x7130 + (i) * 0x70)
> +#define TSI_STC2BASE(i) (0x7134 + (i) * 0x70)
> +#define TSI_STC2EXT(i) (0x7138 + (i) * 0x70)
> +#define TSI_PCRBASE(i) (0x713c + (i) * 0x70)
> +#define TSI_PCREXT(i) (0x7140 + (i) * 0x70)
> +#define TSI_TIMESTAMP(i) (0x7144 + (i) * 0x70)
> +#define TSI_CNTCTRL0(i) (0x7148 + (i) * 0x70)
> +#define TSI_CNTCTRL1(i) (0x714c + (i) * 0x70)
> +#define TSI_DEBUG(i) (0x7150 + (i) * 0x70)
> +
> +#define TSI_STCCMPCTRL 0x7000
> +#define VCXOSTCBASE(i) (0x7010 + (i) * 0x18)
> +#define VCXOSTCEXT(i) (0x7014 + (i) * 0x18)
> +#define VCXOCURSTC1(i) (0x7018 + (i) * 0x18)
> +#define VCXOCURSTC2(i) (0x701c + (i) * 0x18)
> +#define VCXOSTC2BASE(i) (0x7020 + (i) * 0x18)
> +#define VCXOSTC2EXT(i) (0x7024 + (i) * 0x18)
> +
> +/* UCODE DL */
> +#define UCODE_REVISION_AM 0x10fd0
> +#define CIP_UCODEADDR_AM1 0x10fd4
> +#define CIP_UCODEADDR_AM0 0x10fd8
> +#define CORRECTATS_CTRL 0x10fdc
> +#define UCODE_REVISION 0x10fe0
> +#define AM_UCODE_IGPGCTRL 0x10fe4
> +#define REPDPLLCTRLEN 0x10fe8
> +#define UCODE_DLADDR1 0x10fec
> +#define UCODE_DLADDR0 0x10ff0
> +#define UCODE_ERRLOGCTRL 0x10ff4
> +
> +#endif /* DVB_UNIPHIER_HSC_REG_H__ */
> diff --git a/drivers/media/platform/uniphier/hsc.h b/drivers/media/platform/uniphier/hsc.h
> new file mode 100644
> index 000000000000..ad57fea58675
> --- /dev/null
> +++ b/drivers/media/platform/uniphier/hsc.h
> @@ -0,0 +1,480 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Socionext UniPhier DVB driver for High-speed Stream Controller (HSC).
> + *
> + * Copyright (c) 2018 Socionext Inc.
> + */
> +
> +#ifndef DVB_UNIPHIER_HSC_H__
> +#define DVB_UNIPHIER_HSC_H__
> +
> +#include <linux/gpio/consumer.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/types.h>
> +
> +#include <media/dmxdev.h>
> +#include <media/dvbdev.h>
> +#include <media/dvb_demux.h>
> +#include <media/dvb_frontend.h>
> +
> +enum HSC_CORE {
> + HSC_CORE_0,
> + HSC_CORE_1,
> + HSC_CORE_2,
> +};
> +
> +enum HSC_UCODE {
> + HSC_UCODE_SPU_0,
> + HSC_UCODE_SPU_1,
> + HSC_UCODE_ACE,
> +};
> +
> +enum HSC_INTR_IOB {
> + HSC_INTR_IOB_0,
> + HSC_INTR_IOB_0_1,
> + HSC_INTR_IOB_0_2,
> + HSC_INTR_IOB_1,
> + HSC_INTR_IOB_1_1,
> + HSC_INTR_IOB_2,
> + HSC_INTR_IOB_3,
> + HSC_INTR_IOB_4,
> + HSC_INTR_IOB_5,
> + HSC_INTR_IOB_5_1,
> + HSC_INTR_IOB_5_2,
> + HSC_INTR_IOB_6,
> + HSC_INTR_IOB_6_1,
> + HSC_INTR_IOB_7,
> + HSC_INTR_IOB_8,
> + HSC_INTR_IOB_9,
> +
> + HSC_INTR_IOB_NUM,
> +};
> +
> +enum HSC_DPLL {
> + HSC_DPLL0,
> + HSC_DPLL1,
> + HSC_DPLL2,
> + HSC_DPLL3,
> +
> + HSC_DPLL_NUM,
> +};
> +
> +enum HSC_DPLL_SRC {
> + HSC_DPLL_SRC_NONE = -1,
> + HSC_DPLL_SRC_TSI0 = 0x00,
> + HSC_DPLL_SRC_TSI1,
> + HSC_DPLL_SRC_TSI2,
> + HSC_DPLL_SRC_TSI3,
> + HSC_DPLL_SRC_TSI4,
> + HSC_DPLL_SRC_TSI5,
> + HSC_DPLL_SRC_TSI6,
> + HSC_DPLL_SRC_TSI7,
> + HSC_DPLL_SRC_TSI8,
> + HSC_DPLL_SRC_TSI9,
> + HSC_DPLL_SRC_REP0 = 0x0a,
> + HSC_DPLL_SRC_REP1,
> + HSC_DPLL_SRC_REP2,
> + HSC_DPLL_SRC_REP3,
> + HSC_DPLL_SRC_REP4,
> + HSC_DPLL_SRC_REP5,
> +
> + HSC_DPLL_SRC_NUM,
> +};
> +
> +/* Port to send to CSS */
> +enum HSC_CSS_IN {
> + HSC_CSS_IN_1394_0 = 0x00,
> + HSC_CSS_IN_1394_1,
> + HSC_CSS_IN_1394_2,
> + HSC_CSS_IN_1394_3,
> + HSC_CSS_IN_DMD0 = 0x04,
> + HSC_CSS_IN_DMD1,
> + HSC_CSS_IN_SRLTS0 = 0x06,
> + HSC_CSS_IN_SRLTS1,
> + HSC_CSS_IN_SRLTS2,
> + HSC_CSS_IN_SRLTS3,
> + HSC_CSS_IN_SRLTS4,
> + HSC_CSS_IN_SRLTS5,
> + HSC_CSS_IN_SRLTS6,
> + HSC_CSS_IN_SRLTS7,
> + HSC_CSS_IN_PARTS0 = 0x10,
> + HSC_CSS_IN_PARTS1,
> + HSC_CSS_IN_PARTS2,
> + HSC_CSS_IN_PARTS3,
> + HSC_CSS_IN_TSO0 = 0x18,
Look like each must have a particular value.
Is it important to HSC_CSS_IN_TSO0 == 0x18 ?
If so, it might be better to do
#define HSC_CSS_IN_TSO0 0x18
> + HSC_CSS_IN_TSO1,
> + HSC_CSS_IN_TSO2,
> + HSC_CSS_IN_TSO3,
> + HSC_CSS_IN_ENCORDER0_IN = 0x1c,
> + HSC_CSS_IN_ENCORDER1_IN,
> +
> + HSC_CSS_IN_NUM,
> +};
[snip]
> +struct hsc_spec_dma {
> + int dma_ch;
> + struct hsc_dma_en en;
> + struct hsc_cmn_intr intr;
> +};
> +
> +struct hsc_spec {
> + const struct hsc_spec_ucode ucode_spu;
Suspicious usage of 'const'
since ucode_spu is not a pointer.
Look like you constified the whole hsc_spec,
so this 'const' should be here.
> + const struct hsc_spec_ucode ucode_ace;
Ditto.
> + const struct hsc_spec_init_ram *init_rams;
OK, this 'const' is legitimate since init-rams a pointer.
> + size_t num_init_rams;
> + const struct hsc_spec_css_in *css_in;
> + size_t num_css_in;
> + const struct hsc_spec_css_out *css_out;
> + size_t num_css_out;
> + const struct hsc_spec_ts *ts_in;
> + size_t num_ts_in;
> + const struct hsc_spec_dma *dma_in;
> + size_t num_dma_in;
> + const struct hsc_spec_dma *dma_out;
> + size_t num_dma_out;
> +};
> +
> +struct hsc_tsif {
> + struct hsc_chip *chip;
> +
> + struct dvb_adapter adapter;
> + struct dvb_demux demux;
> + struct dmxdev dmxdev;
> + struct dvb_frontend *fe;
> + int valid_adapter;
> + int valid_demux;
> + int valid_dmxdev;
> + int valid_fe;
> +
> + enum HSC_CSS_IN css_in;
> + enum HSC_CSS_OUT css_out;
> + enum HSC_TS_IN tsi;
> + enum HSC_DPLL dpll;
> + enum HSC_DPLL_SRC dpll_src;
> + struct hsc_dmaif *dmaif;
> +
> + int running;
> + struct delayed_work recover_work;
> + unsigned long recover_delay;
> +};
> +
> +struct hsc_dma_in {
> + struct hsc_chip *chip;
> +
> + enum HSC_DMA_IN id;
> + const struct hsc_spec_dma *spec;
> + struct hsc_dma_buf *buf;
> +};
> +
> +struct hsc_dma_out {
> + struct hsc_chip *chip;
> +
> + enum HSC_DMA_OUT id;
> + const struct hsc_spec_dma *spec;
> + struct hsc_dma_buf *buf;
> +};
> +
> +struct hsc_dma_buf {
> + void *virt;
> + dma_addr_t phys;
> + u64 size;
> + u64 size_chk;
> + u64 rd_offs;
> + u64 wr_offs;
> + u64 chk_offs;
> +};
> +
> +struct hsc_dmaif {
> + struct hsc_chip *chip;
> +
> + struct hsc_dma_buf buf_out;
> + struct hsc_dma_out dma_out;
> +
> + struct hsc_tsif *tsif;
> +
> + /* guard read/write pointer of DMA buffer from interrupt handler */
> + spinlock_t lock;
> + int running;
> + struct work_struct feed_work;
> +};
> +
> +struct hsc_chip {
> + const struct hsc_spec *spec;
> + short *adapter_nums;
> +
> + struct platform_device *pdev;
> + struct regmap *regmap;
> + struct clk *clk_stdmac;
> + struct clk *clk_hsc;
> + struct reset_control *rst_stdmac;
> + struct reset_control *rst_hsc;
> +
> + struct hsc_dmaif dmaif[HSC_STREAM_IF_NUM];
> + struct hsc_tsif tsif[HSC_STREAM_IF_NUM];
> +
> + struct hsc_ucode_buf ucode_spu;
> + struct hsc_ucode_buf ucode_am;
> +};
> +
> +struct hsc_conf {
> + enum HSC_CSS_IN css_in;
> + enum HSC_CSS_OUT css_out;
> + enum HSC_DPLL dpll;
> + enum HSC_DMA_OUT dma_out;
> +};
> +
> +static inline u32 field_prep(u32 mask, u32 v)
> +{
> + int sft = ffs(mask) - 1;
> +
> + return (v << sft) & mask;
> +}
> +
> +static inline u32 field_get(u32 mask, u32 v)
> +{
> + int sft = ffs(mask) - 1;
> +
> + return (v & mask) >> sft;
> +}
A good thing of <linux/bitfield.h> is, it is compile-time computable,
but this is not.
It might be better to re-consider the hsc_spec_css_out data arrangement.
For example, shift & width pair instead of shifted-mask.
> +/* CSS */
> +enum HSC_TS_IN hsc_css_out_to_ts_in(enum HSC_CSS_OUT out);
> +enum HSC_DPLL_SRC hsc_css_out_to_dpll_src(enum HSC_CSS_OUT out);
> +
> +int hsc_dpll_get_src(struct hsc_chip *chip, enum HSC_DPLL dpll,
> + enum HSC_DPLL_SRC *src);
> +int hsc_dpll_set_src(struct hsc_chip *chip, enum HSC_DPLL dpll,
> + enum HSC_DPLL_SRC src);
> +int hsc_css_in_get_polarity(struct hsc_chip *chip, enum HSC_CSS_IN in,
> + bool *sync_bit, bool *val_bit, bool *clk_fall);
> +int hsc_css_in_set_polarity(struct hsc_chip *chip, enum HSC_CSS_IN in,
> + bool sync_bit, bool val_bit, bool clk_fall);
> +int hsc_css_out_get_polarity(struct hsc_chip *chip, enum HSC_CSS_OUT out,
> + bool *sync_bit, bool *val_bit, bool *clk_fall);
> +int hsc_css_out_set_polarity(struct hsc_chip *chip, enum HSC_CSS_OUT out,
> + bool sync_bit, bool val_bit, bool clk_fall);
> +int hsc_css_out_get_src(struct hsc_chip *chip, enum HSC_CSS_IN *in,
> + enum HSC_CSS_OUT out, bool *en);
> +int hsc_css_out_set_src(struct hsc_chip *chip, enum HSC_CSS_IN in,
> + enum HSC_CSS_OUT out, bool en);
> +
> +/* TSI */
> +const struct hsc_spec_tsi *hsc_ts_in_get_spec(struct hsc_chip *chip,
> + enum HSC_TS_IN in);
> +int hsc_ts_in_set_enable(struct hsc_chip *chip, enum HSC_TS_IN in, bool en);
> +int hsc_ts_in_set_dmaparam(struct hsc_chip *chip, enum HSC_TS_IN in,
> + enum HSC_TSIF_FMT ifmt);
> +
> +/* DMA */
> +u64 hsc_rb_cnt(struct hsc_dma_buf *buf);
> +u64 hsc_rb_cnt_to_end(struct hsc_dma_buf *buf);
> +u64 hsc_rb_space(struct hsc_dma_buf *buf);
> +u64 hsc_rb_space_to_end(struct hsc_dma_buf *buf);
> +int hsc_dma_in_init(struct hsc_dma_in *dma_in, struct hsc_chip *chip,
> + enum HSC_DMA_IN in, struct hsc_dma_buf *buf);
> +void hsc_dma_in_start(struct hsc_dma_in *dma_in, bool en);
> +void hsc_dma_in_sync(struct hsc_dma_in *dma_in);
> +int hsc_dma_in_get_intr(struct hsc_dma_in *dma_in, u32 *stat);
> +void hsc_dma_in_clear_intr(struct hsc_dma_in *dma_in, u32 clear);
> +int hsc_dma_out_init(struct hsc_dma_out *dma_out, struct hsc_chip *chip,
> + enum HSC_DMA_OUT out, struct hsc_dma_buf *buf);
> +void hsc_dma_out_set_src_ts_in(struct hsc_dma_out *dma_out,
> + enum HSC_TS_IN ts_in);
> +void hsc_dma_out_start(struct hsc_dma_out *dma_out, bool en);
> +void hsc_dma_out_sync(struct hsc_dma_out *dma_out);
> +int hsc_dma_out_get_intr(struct hsc_dma_out *dma_out, u32 *stat);
> +void hsc_dma_out_clear_intr(struct hsc_dma_out *dma_out, u32 clear);
> +
> +/* UCODE DL */
> +int hsc_ucode_load_all(struct hsc_chip *chip);
> +int hsc_ucode_unload_all(struct hsc_chip *chip);
> +
> +/* For Adapter */
> +int hsc_register_dvb(struct hsc_tsif *tsif);
> +void hsc_unregister_dvb(struct hsc_tsif *tsif);
> +int hsc_tsif_init(struct hsc_tsif *tsif, const struct hsc_conf *conf);
> +void hsc_tsif_release(struct hsc_tsif *tsif);
> +int hsc_dmaif_init(struct hsc_dmaif *dmaif, const struct hsc_conf *conf);
> +void hsc_dmaif_release(struct hsc_dmaif *dmaif);
> +extern const struct hsc_spec uniphier_hsc_ld11_spec;
> +extern const struct hsc_spec uniphier_hsc_ld20_spec;
> +
> +#endif /* DVB_UNIPHIER_HSC_H__ */
> --
> 2.17.0
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [GIT PULL] pxa for v4.18
From: Robert Jarzmik @ 2018-06-02 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180602082018.t4tnffy2plqqntcr@localhost>
Olof Johansson <olof@lixom.net> writes:
> On Mon, May 28, 2018 at 10:03:17PM +0200, Robert Jarzmik wrote:
>> This is is the pxa changes for v4.18 cycle :
>> - change to phase out at24 eeprom platform data
>> - add a missing wakeup pin on pxa320 SoCs
>
> Hi,
>
> This is coming in very late, but it's also a pretty small pull request so I've
> merged it for v4.18. If you can, please try to get your staged patches set
> around rc5/rc6 timeframe.
Hi Olof,
Sorry for that, I got overwhelmed by my work. I usually request pull in -rc5,
I'll try to be more available next time.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH 1/8] media: uniphier: add DT bindings documentation for UniPhier HSC
From: Masahiro Yamada @ 2018-06-02 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530090946.1635-2-suzuki.katsuhiro@socionext.com>
2018-05-30 18:09 GMT+09:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>:
> This patch adds DT binding documentation for UniPhier HSC which is
> MPEG2-TS input/output and demux subsystem.
>
> Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
> ---
> .../bindings/media/uniphier,hsc.txt | 38 +++++++++++++++++++
> 1 file changed, 38 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/uniphier,hsc.txt
>
> diff --git a/Documentation/devicetree/bindings/media/uniphier,hsc.txt b/Documentation/devicetree/bindings/media/uniphier,hsc.txt
> new file mode 100644
> index 000000000000..4242483b2ecc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/uniphier,hsc.txt
> @@ -0,0 +1,38 @@
> +Socionext UniPhier HSC (High-speed Stream Controller)
> +
> +The Socionext UniPhier HSC subsystem consists of MPEG2-TS input/output and
> +demultiplexer cores in the same register space.
> +
> +This interface is support TS serial signals (clock, valid, sync, data) from
> +external demodulators.
> +
> +Required properties:
> +- compatible : should be one of the following:
> + "socionext,uniphier-ld11-hsc"
> + "socionext,uniphier-ld20-hsc"
> +- reg : offset and length of the register set for the device.
> +- interrupts : should contain DMA and TSI error interrupt.
> +- pinctrl-names : should be "default".
> +- pinctrl-0 : defined TS serial signal pins for external demodulators.
> +- clock-names : should include following entries:
"the following entries:"
> + "hsc", "stdmac"
> +- clocks : a list of phandle, should contain an entry for each
> + entry in clock-names.
> +- reset-names : should include following entries:
Ditto.
> + "hsc", "stdmac"
> +- resets : a list of phandle, should contain an entry for each
> + entry in reset-names.
> +
> +Example:
> + hsc {
> + compatible = "socionext,uniphier-ld20-hsc";
> + reg = <0x5c000000 0x100000>;
> + interrupts = <0 100 4>, <0 101 4>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hscin2_s>,
> + <&pinctrl_hscin3_s>;
> + clock-names = "stdmac", "hsc";
> + clocks = <&sys_clk 8>, <&sys_clk 9>;
> + reset-names = "stdmac", "hsc";
> + resets = <&sys_rst 8>, <&sys_rst 9>;
> + };
> --
> 2.17.0
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH] clkdev: Remove duplicated negative index check from __of_clk_get()
From: Geert Uytterhoeven @ 2018-06-02 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152791486506.225090.5983323218999937025@swboyd.mtv.corp.google.com>
Hi Stephen,
On Sat, Jun 2, 2018 at 6:47 AM, Stephen Boyd <sboyd@kernel.org> wrote:
> Quoting Geert Uytterhoeven (2018-06-01 12:22:33)
>> On Fri, Jun 1, 2018 at 9:20 PM, Stephen Boyd <sboyd@kernel.org> wrote:
>> > Quoting Geert Uytterhoeven (2018-05-18 03:58:40)
>> >> __of_clk_get() calls of_parse_phandle_with_args(), which rejects
>> >> negative indices since commit bd69f73f2c81eed9 ("of: Create function for
>> >> counting number of phandles in a property").
>> >>
>> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> >> ---
>> >> Commit bd69f73f2c81eed9 is in v3.9.
>> >
>> > Did you send this to Russell's patch tracker? Otherwise I can pick it up
>>
>> Not yet. The patch tracker is for reviewed patches, AFAIK.
>>
>> > to clk-next.
>>
>> Thanks!
>>
>
> Ok. If you need my reviewed-by to add it to the tracker feel free to
> have:
>
> Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Thanks, but it's much easier if you would take it, and I can avoid looking
up again how to submit it properly to the patch tracker.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
* [PATCH V2 3/3] arm64: tegra: Configure DWC EQOS TxPBL for multi-queue
From: Bhadram Varka @ 2018-06-02 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527931251-4809-1-git-send-email-vbhadram@nvidia.com>
PBL should be limited to half of the Queue size.
For multi-queue: Total MTL queue size 4KB.
PBL = 16, PBLx8 = 1 -> This setting would lead
to an effective burst = 8*16 = 128, which would
mean 128*16B = 2KB (half of queue size)
Signed-off-by: Bhadram Varka <vbhadram@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 48c6caf..c4d70c5 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -101,7 +101,7 @@
snps,write-requests = <1>;
snps,read-requests = <3>;
snps,burst-map = <0x7>;
- snps,txpbl = <32>;
+ snps,txpbl = <16>;
snps,rxpbl = <8>;
snps,mtl-rx-config = <&mtl_rx_setup>;
snps,mtl-tx-config = <&mtl_tx_setup>;
--
2.7.4
^ permalink raw reply related
* [PATCH V2 2/3] arm64: tegra: Enable multi-queue for DWC EQOS
From: Bhadram Varka @ 2018-06-02 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527931251-4809-1-git-send-email-vbhadram@nvidia.com>
DWC EQOS supports four MTL queues for Tx and Rx
separately.
Signed-off-by: Bhadram Varka <vbhadram@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 48 ++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 252133b..48c6caf 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -37,6 +37,52 @@
gpio-controller;
};
+ mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <4>;
+ snps,rx-sched-sp;
+ queue0 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x0>;
+ snps,priority = <0x0>;
+ };
+ queue1 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x1>;
+ snps,priority = <0x1>;
+ };
+ queue2 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x2>;
+ snps,priority = <0x2>;
+ };
+ queue3 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x2>;
+ snps,priority = <0x3>;
+ };
+ };
+
+ mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <4>;
+ snps,tx-sched-sp;
+ queue0 {
+ snps,dcb-algorithm;
+ snps,priority = <0x0>;
+ };
+ queue1 {
+ snps,dcb-algorithm;
+ snps,priority = <0x1>;
+ };
+ queue2 {
+ snps,dcb-algorithm;
+ snps,priority = <0x2>;
+ };
+ queue3 {
+ snps,dcb-algorithm;
+ snps,priority = <0x3>;
+ };
+ };
+
ethernet at 2490000 {
compatible = "nvidia,tegra186-eqos",
"snps,dwc-qos-ethernet-4.10";
@@ -57,6 +103,8 @@
snps,burst-map = <0x7>;
snps,txpbl = <32>;
snps,rxpbl = <8>;
+ snps,mtl-rx-config = <&mtl_rx_setup>;
+ snps,mtl-tx-config = <&mtl_tx_setup>;
};
memory-controller at 2c00000 {
--
2.7.4
^ permalink raw reply related
* [PATCH V2 1/3] arm64: tegra: Remove unused interrupt properties
From: Bhadram Varka @ 2018-06-02 9:20 UTC (permalink / raw)
To: linux-arm-kernel
DWC EQOS on Tegra handles all interrupts through
common interrupt line. So lets remove unused power
and per-channel interrupt properties.
Signed-off-by: Bhadram Varka <vbhadram@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index b762227..252133b 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -41,16 +41,7 @@
compatible = "nvidia,tegra186-eqos",
"snps,dwc-qos-ethernet-4.10";
reg = <0x0 0x02490000 0x0 0x10000>;
- interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>, /* common */
- <GIC_SPI 195 IRQ_TYPE_LEVEL_HIGH>, /* power */
- <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>, /* rx0 */
- <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>, /* tx0 */
- <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>, /* rx1 */
- <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>, /* tx1 */
- <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>, /* rx2 */
- <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>, /* tx2 */
- <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>, /* rx3 */
- <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>; /* tx3 */
+ interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>; /* common */
clocks = <&bpmp TEGRA186_CLK_AXI_CBB>,
<&bpmp TEGRA186_CLK_EQOS_AXI>,
<&bpmp TEGRA186_CLK_EQOS_RX>,
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] arm64: tegra: Configure DWC EQOS TxPBL for multi-queue
From: Bhadram Varka @ 2018-06-02 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527930713-4479-1-git-send-email-vbhadram@nvidia.com>
PBL should be limited to half of the Queue size.
For multi-queue: Total MTL queue size 4KB.
PBL = 16, PBLx8 = 1 -> This setting would lead
to an effective burst = 8*16 = 128, which would
mean 128*16B = 2KB (half of queue size)
Signed-off-by: Bhadram Varka <vbhadram@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index f27730d..630cb81 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -101,7 +101,7 @@
snps,write-requests = <1>;
snps,read-requests = <3>;
snps,burst-map = <0x7>;
- snps,txpbl = <32>;
+ snps,txpbl = <16>;
snps,rxpbl = <8>;
snps,mtl-rx-config = <&mtl_rx_setup>;
snps,mtl-tx-config = <&mtl_tx_setup>;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] arm64: tegra: Enable multi-queue for DWC EQOS
From: Bhadram Varka @ 2018-06-02 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527930713-4479-1-git-send-email-vbhadram@nvidia.com>
DWC EQOS supports four MTL queues for Tx and Rx
separately.
Signed-off-by: Bhadram Varka <vbhadram@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 48 ++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 0f4bed8..f27730d 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -37,6 +37,52 @@
gpio-controller;
};
+ mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <4>;
+ snps,rx-sched-sp;
+ queue0 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x0>;
+ snps,priority = <0x0>;
+ };
+ queue1 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x1>;
+ snps,priority = <0x1>;
+ };
+ queue2 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x2>;
+ snps,priority = <0x2>;
+ };
+ queue3 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x2>;
+ snps,priority = <0x3>;
+ };
+ };
+
+ mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <4>;
+ snps,tx-sched-sp;
+ queue0 {
+ snps,dcb-algorithm;
+ snps,priority = <0x0>;
+ };
+ queue1 {
+ snps,dcb-algorithm;
+ snps,priority = <0x1>;
+ };
+ queue2 {
+ snps,dcb-algorithm;
+ snps,priority = <0x2>;
+ };
+ queue3 {
+ snps,dcb-algorithm;
+ snps,priority = <0x3>;
+ };
+ };
+
ethernet at 2490000 {
compatible = "nvidia,tegra186-eqos",
"snps,dwc-qos-ethernet-4.10";
@@ -57,6 +103,8 @@
snps,burst-map = <0x7>;
snps,txpbl = <32>;
snps,rxpbl = <8>;
+ snps,mtl-rx-config = <&mtl_rx_setup>;
+ snps,mtl-tx-config = <&mtl_tx_setup>;
};
memory-controller at 2c00000 {
--
2.7.4
^ permalink raw reply related
* [PATCH] arm64: tegra: Remove unused interrupt properties
From: Bhadram Varka @ 2018-06-02 9:11 UTC (permalink / raw)
To: linux-arm-kernel
DWC EQOS on Tegra handles all interrupts through
common interrupt line. So lets remove unused power
and per-channel interrupt properties.
Signed-off-by: Bhadram Varka <vbhadram@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index b762227..252133b 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -41,16 +41,7 @@
compatible = "nvidia,tegra186-eqos",
"snps,dwc-qos-ethernet-4.10";
reg = <0x0 0x02490000 0x0 0x10000>;
- interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>, /* common */
- <GIC_SPI 195 IRQ_TYPE_LEVEL_HIGH>, /* power */
- <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>, /* rx0 */
- <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>, /* tx0 */
- <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>, /* rx1 */
- <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>, /* tx1 */
- <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>, /* rx2 */
- <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>, /* tx2 */
- <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>, /* rx3 */
- <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>; /* tx3 */
+ interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>; /* common */
clocks = <&bpmp TEGRA186_CLK_AXI_CBB>,
<&bpmp TEGRA186_CLK_EQOS_AXI>,
<&bpmp TEGRA186_CLK_EQOS_RX>,
--
2.7.4
^ permalink raw reply related
* [clk:clk-bcm-stingray 1/2] drivers/clk/bcm/clk-sr.c:217:3: error: 'BCM_SR_LCPLL0_SATA_REF_CLK' undeclared here (not in a function); did you mean 'BCM_SR_LCPLL0_SATA_REFN_CLK'?
From: kbuild test robot @ 2018-06-02 9:01 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-bcm-stingray
head: 5afa881c6635427e68c73861a2c22d8cac00b984
commit: 48bf9a522c14449cc7c214c6062668ac54e4e88f [1/2] dt-bindings: clk: Update Stingray binding doc
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 48bf9a522c14449cc7c214c6062668ac54e4e88f
# save the attached .config to linux build tree
make.cross ARCH=sh
Note: the clk/clk-bcm-stingray HEAD 5afa881c6635427e68c73861a2c22d8cac00b984 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/clk/bcm/clk-sr.c:59:3: error: 'BCM_SR_GENPLL0_SATA_CLK' undeclared here (not in a function); did you mean 'BCM_SR_GENPLL0_SCR_CLK'?
[BCM_SR_GENPLL0_SATA_CLK] = {
^~~~~~~~~~~~~~~~~~~~~~~
BCM_SR_GENPLL0_SCR_CLK
drivers/clk/bcm/clk-sr.c:59:3: error: array index in initializer not of integer type
drivers/clk/bcm/clk-sr.c:59:3: note: (near initialization for 'sr_genpll0_clk')
drivers/clk/bcm/clk-sr.c:184:3: error: 'BCM_SR_GENPLL5_FS_CLK' undeclared here (not in a function); did you mean 'BCM_SR_GENPLL2_FS4_CLK'?
[BCM_SR_GENPLL5_FS_CLK] = {
^~~~~~~~~~~~~~~~~~~~~
BCM_SR_GENPLL2_FS4_CLK
drivers/clk/bcm/clk-sr.c:184:3: error: array index in initializer not of integer type
drivers/clk/bcm/clk-sr.c:184:3: note: (near initialization for 'sr_genpll5_clk')
drivers/clk/bcm/clk-sr.c:185:14: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
.channel = BCM_SR_GENPLL5_FS_CLK,
^~~~~~~~~~~~~~~~~~~~~
drivers/clk/bcm/clk-sr.c:185:14: note: (near initialization for 'sr_genpll5_clk[0].channel')
drivers/clk/bcm/clk-sr.c:185:14: error: initializer element is not constant
drivers/clk/bcm/clk-sr.c:185:14: note: (near initialization for 'sr_genpll5_clk[0].channel')
drivers/clk/bcm/clk-sr.c:190:3: error: 'BCM_SR_GENPLL5_SPU_CLK' undeclared here (not in a function); did you mean 'BCM_SR_GENPLL5_FS_CLK'?
[BCM_SR_GENPLL5_SPU_CLK] = {
^~~~~~~~~~~~~~~~~~~~~~
BCM_SR_GENPLL5_FS_CLK
drivers/clk/bcm/clk-sr.c:190:3: error: array index in initializer not of integer type
drivers/clk/bcm/clk-sr.c:190:3: note: (near initialization for 'sr_genpll5_clk')
drivers/clk/bcm/clk-sr.c:191:14: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
.channel = BCM_SR_GENPLL5_SPU_CLK,
^~~~~~~~~~~~~~~~~~~~~~
drivers/clk/bcm/clk-sr.c:191:14: note: (near initialization for 'sr_genpll5_clk[1].channel')
drivers/clk/bcm/clk-sr.c:191:14: error: initializer element is not constant
drivers/clk/bcm/clk-sr.c:191:14: note: (near initialization for 'sr_genpll5_clk[1].channel')
>> drivers/clk/bcm/clk-sr.c:217:3: error: 'BCM_SR_LCPLL0_SATA_REF_CLK' undeclared here (not in a function); did you mean 'BCM_SR_LCPLL0_SATA_REFN_CLK'?
[BCM_SR_LCPLL0_SATA_REF_CLK] = {
^~~~~~~~~~~~~~~~~~~~~~~~~~
BCM_SR_LCPLL0_SATA_REFN_CLK
drivers/clk/bcm/clk-sr.c:217:3: error: array index in initializer not of integer type
drivers/clk/bcm/clk-sr.c:217:3: note: (near initialization for 'sr_lcpll0_clk')
drivers/clk/bcm/clk-sr.c:218:14: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
.channel = BCM_SR_LCPLL0_SATA_REF_CLK,
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/clk/bcm/clk-sr.c:218:14: note: (near initialization for 'sr_lcpll0_clk[0].channel')
drivers/clk/bcm/clk-sr.c:218:14: error: initializer element is not constant
drivers/clk/bcm/clk-sr.c:218:14: note: (near initialization for 'sr_lcpll0_clk[0].channel')
drivers/clk/bcm/clk-sr.c:223:3: error: 'BCM_SR_LCPLL0_USB_REF_CLK' undeclared here (not in a function); did you mean 'BCM_SR_LCPLL1_USB_REF_CLK'?
[BCM_SR_LCPLL0_USB_REF_CLK] = {
^~~~~~~~~~~~~~~~~~~~~~~~~
BCM_SR_LCPLL1_USB_REF_CLK
drivers/clk/bcm/clk-sr.c:223:3: error: array index in initializer not of integer type
drivers/clk/bcm/clk-sr.c:223:3: note: (near initialization for 'sr_lcpll0_clk')
drivers/clk/bcm/clk-sr.c:224:14: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
.channel = BCM_SR_LCPLL0_USB_REF_CLK,
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/clk/bcm/clk-sr.c:224:14: note: (near initialization for 'sr_lcpll0_clk[1].channel')
drivers/clk/bcm/clk-sr.c:224:14: error: initializer element is not constant
drivers/clk/bcm/clk-sr.c:224:14: note: (near initialization for 'sr_lcpll0_clk[1].channel')
>> drivers/clk/bcm/clk-sr.c:229:3: error: 'BCM_SR_LCPLL0_SATA_REFPN_CLK' undeclared here (not in a function); did you mean 'BCM_SR_LCPLL0_SATA_REFN_CLK'?
[BCM_SR_LCPLL0_SATA_REFPN_CLK] = {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
BCM_SR_LCPLL0_SATA_REFN_CLK
drivers/clk/bcm/clk-sr.c:229:3: error: array index in initializer not of integer type
drivers/clk/bcm/clk-sr.c:229:3: note: (near initialization for 'sr_lcpll0_clk')
drivers/clk/bcm/clk-sr.c:230:14: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
.channel = BCM_SR_LCPLL0_SATA_REFPN_CLK,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/clk/bcm/clk-sr.c:230:14: note: (near initialization for 'sr_lcpll0_clk[2].channel')
drivers/clk/bcm/clk-sr.c:230:14: error: initializer element is not constant
drivers/clk/bcm/clk-sr.c:230:14: note: (near initialization for 'sr_lcpll0_clk[2].channel')
vim +217 drivers/clk/bcm/clk-sr.c
654cdd32 Sandeep Tripathy 2017-06-06 182
654cdd32 Sandeep Tripathy 2017-06-06 183 static const struct iproc_clk_ctrl sr_genpll5_clk[] = {
654cdd32 Sandeep Tripathy 2017-06-06 184 [BCM_SR_GENPLL5_FS_CLK] = {
654cdd32 Sandeep Tripathy 2017-06-06 185 .channel = BCM_SR_GENPLL5_FS_CLK,
654cdd32 Sandeep Tripathy 2017-06-06 186 .flags = IPROC_CLK_AON,
654cdd32 Sandeep Tripathy 2017-06-06 187 .enable = ENABLE_VAL(0x4, 6, 0, 12),
654cdd32 Sandeep Tripathy 2017-06-06 188 .mdiv = REG_VAL(0x18, 0, 9),
654cdd32 Sandeep Tripathy 2017-06-06 189 },
654cdd32 Sandeep Tripathy 2017-06-06 @190 [BCM_SR_GENPLL5_SPU_CLK] = {
654cdd32 Sandeep Tripathy 2017-06-06 191 .channel = BCM_SR_GENPLL5_SPU_CLK,
654cdd32 Sandeep Tripathy 2017-06-06 192 .flags = IPROC_CLK_AON,
654cdd32 Sandeep Tripathy 2017-06-06 193 .enable = ENABLE_VAL(0x4, 6, 0, 12),
654cdd32 Sandeep Tripathy 2017-06-06 194 .mdiv = REG_VAL(0x18, 10, 9),
654cdd32 Sandeep Tripathy 2017-06-06 195 },
654cdd32 Sandeep Tripathy 2017-06-06 196 };
654cdd32 Sandeep Tripathy 2017-06-06 197
654cdd32 Sandeep Tripathy 2017-06-06 198 static int sr_genpll5_clk_init(struct platform_device *pdev)
654cdd32 Sandeep Tripathy 2017-06-06 199 {
654cdd32 Sandeep Tripathy 2017-06-06 200 iproc_pll_clk_setup(pdev->dev.of_node,
654cdd32 Sandeep Tripathy 2017-06-06 201 &sr_genpll5, NULL, 0, sr_genpll5_clk,
654cdd32 Sandeep Tripathy 2017-06-06 202 ARRAY_SIZE(sr_genpll5_clk));
654cdd32 Sandeep Tripathy 2017-06-06 203 return 0;
654cdd32 Sandeep Tripathy 2017-06-06 204 }
654cdd32 Sandeep Tripathy 2017-06-06 205
654cdd32 Sandeep Tripathy 2017-06-06 206 static const struct iproc_pll_ctrl sr_lcpll0 = {
654cdd32 Sandeep Tripathy 2017-06-06 207 .flags = IPROC_CLK_AON | IPROC_CLK_PLL_NEEDS_SW_CFG,
654cdd32 Sandeep Tripathy 2017-06-06 208 .aon = AON_VAL(0x0, 2, 19, 18),
654cdd32 Sandeep Tripathy 2017-06-06 209 .reset = RESET_VAL(0x0, 31, 30),
654cdd32 Sandeep Tripathy 2017-06-06 210 .sw_ctrl = SW_CTRL_VAL(0x4, 31),
654cdd32 Sandeep Tripathy 2017-06-06 211 .ndiv_int = REG_VAL(0x4, 16, 10),
654cdd32 Sandeep Tripathy 2017-06-06 212 .pdiv = REG_VAL(0x4, 26, 4),
654cdd32 Sandeep Tripathy 2017-06-06 213 .status = REG_VAL(0x38, 12, 1),
654cdd32 Sandeep Tripathy 2017-06-06 214 };
654cdd32 Sandeep Tripathy 2017-06-06 215
654cdd32 Sandeep Tripathy 2017-06-06 216 static const struct iproc_clk_ctrl sr_lcpll0_clk[] = {
654cdd32 Sandeep Tripathy 2017-06-06 @217 [BCM_SR_LCPLL0_SATA_REF_CLK] = {
654cdd32 Sandeep Tripathy 2017-06-06 218 .channel = BCM_SR_LCPLL0_SATA_REF_CLK,
654cdd32 Sandeep Tripathy 2017-06-06 219 .flags = IPROC_CLK_AON,
654cdd32 Sandeep Tripathy 2017-06-06 220 .enable = ENABLE_VAL(0x0, 7, 1, 13),
654cdd32 Sandeep Tripathy 2017-06-06 221 .mdiv = REG_VAL(0x14, 0, 9),
654cdd32 Sandeep Tripathy 2017-06-06 222 },
654cdd32 Sandeep Tripathy 2017-06-06 @223 [BCM_SR_LCPLL0_USB_REF_CLK] = {
654cdd32 Sandeep Tripathy 2017-06-06 224 .channel = BCM_SR_LCPLL0_USB_REF_CLK,
654cdd32 Sandeep Tripathy 2017-06-06 225 .flags = IPROC_CLK_AON,
654cdd32 Sandeep Tripathy 2017-06-06 226 .enable = ENABLE_VAL(0x0, 8, 2, 14),
654cdd32 Sandeep Tripathy 2017-06-06 227 .mdiv = REG_VAL(0x14, 10, 9),
654cdd32 Sandeep Tripathy 2017-06-06 228 },
654cdd32 Sandeep Tripathy 2017-06-06 @229 [BCM_SR_LCPLL0_SATA_REFPN_CLK] = {
654cdd32 Sandeep Tripathy 2017-06-06 230 .channel = BCM_SR_LCPLL0_SATA_REFPN_CLK,
654cdd32 Sandeep Tripathy 2017-06-06 231 .flags = IPROC_CLK_AON,
654cdd32 Sandeep Tripathy 2017-06-06 232 .enable = ENABLE_VAL(0x0, 9, 3, 15),
654cdd32 Sandeep Tripathy 2017-06-06 233 .mdiv = REG_VAL(0x14, 20, 9),
654cdd32 Sandeep Tripathy 2017-06-06 234 },
654cdd32 Sandeep Tripathy 2017-06-06 235 };
654cdd32 Sandeep Tripathy 2017-06-06 236
:::::: The code at line 217 was first introduced by commit
:::::: 654cdd3229cd1d3f2bfb9df57baf88ba382a52be clk: bcm: Add clocks for Stingray SOC
:::::: TO: Sandeep Tripathy <sandeep.tripathy@broadcom.com>
:::::: CC: Stephen Boyd <sboyd@codeaurora.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 47758 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180602/d7e73bfe/attachment-0001.gz>
^ permalink raw reply
* [PATCH v3 2/5] gpio: syscon: rockchip: add GPIO_MUTE support for rk3328
From: Levin Du @ 2018-06-02 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKSy4q5dfVfXbRMLa7koTWufpAt3yNdE-9mwyJ-VzVQRQ@mail.gmail.com>
Rob Herring <robh+dt@kernel.org> writes:
> On Thu, May 31, 2018 at 9:05 PM, Levin <djw@t-chip.com.cn>
> wrote:
>> Hi Rob,
>>
>>
>> On 2018-05-31 10:45 PM, Rob Herring wrote:
>>>
>>> On Wed, May 30, 2018 at 10:27 PM, <djw@t-chip.com.cn> wrote:
>>>>
>>>> From: Levin Du <djw@t-chip.com.cn>
>>>>
>>>> In Rockchip RK3328, the output only GPIO_MUTE pin, originally
>>>> for codec
>>>> mute control, can also be used for general purpose. It is
>>>> manipulated by
>>>> the GRF_SOC_CON10 register.
>>>>
>>>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>>>>
>>>> ---
>>>>
>>>> Changes in v3:
>>>> - Change from general gpio-syscon to specific
>>>> rk3328-gpio-mute
>>>>
>>>> Changes in v2:
>>>> - Rename gpio_syscon10 to gpio_mute in doc
>>>>
>>>> Changes in v1:
>>>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
>>>> - Add doc rockchip,gpio-syscon.txt
>>>>
>>>> .../bindings/gpio/rockchip,rk3328-gpio-mute.txt | 28
>>>> +++++++++++++++++++
>>>> drivers/gpio/gpio-syscon.c | 31
>>>> ++++++++++++++++++++++
>>>> 2 files changed, 59 insertions(+)
>>>> create mode 100644
>>>> Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>>> b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>>> new file mode 100644
>>>> index 0000000..10bc632
>>>> --- /dev/null
>>>> +++
>>>> b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>>> @@ -0,0 +1,28 @@
>>>> +Rockchip RK3328 GPIO controller dedicated for the GPIO_MUTE
>>>> pin.
>>>> +
>>>> +In Rockchip RK3328, the output only GPIO_MUTE pin,
>>>> originally for codec
>>>> mute
>>>> +control, can also be used for general purpose. It is
>>>> manipulated by the
>>>> +GRF_SOC_CON10 register.
>>>> +
>>>> +Required properties:
>>>> +- compatible: Should contain "rockchip,rk3328-gpio-mute".
>>>> +- gpio-controller: Marks the device node as a gpio
>>>> controller.
>>>> +- #gpio-cells: Should be 2. The first cell is the pin number
>>>> and
>>>> + the second cell is used to specify the gpio polarity:
>>>> + 0 = Active high,
>>>> + 1 = Active low.
>>>> +
>>>> +Example:
>>>> +
>>>> + grf: syscon at ff100000 {
>>>> + compatible = "rockchip,rk3328-grf", "syscon",
>>>> "simple-mfd";
>>>> +
>>>> + gpio_mute: gpio-mute {
>>>
>>> Node names should be generic:
>>>
>>> gpio {
>>>
>>> This also means you can't add another GPIO node in the future
>>> and
>>> you'll have to live with "rockchip,rk3328-gpio-mute" covering
>>> more
>>> than 1 GPIO if you do need to add more GPIOs.
>>
>>
>> As the first line describes, this GPIO controller is dedicated
>> for the
>> GPIO_MUTE pin.
>> There's only one GPIO pin in the GRF_SOC_CON10 register.
>> Therefore the
>> gpio_mute
>> name is proper IMHO.
>
> It's how many GPIOs in the GRF, not this register. What I'm
> saying is
> when you come along later to add another GPIO in the GRF, you
> had
> better just add it to this same node. I'm not going to accept
> another
> GPIO controller node within the GRF. You have the cells to
> support
> more than 1, so it would only be a driver change. The compatible
> string would then not be ideally named at that point. But
> compatible
> strings are just unique identifiers, so it doesn't really matter
> what
> the string is.
>
I'll try my best to introduce the situation here. The GRF,
GPIO0~GPIO3
are register blocks in the RK3328 Soc. The GPIO0~GPIO3 contain
registers
for GPIO operations like reading/writing data, setting direction,
interruption etc, which corresponds to the GPIO banks
(gpio0~gpio3)
defined in rk3328.dtsi:
pinctrl: pinctrl {
compatible = "rockchip,rk3328-pinctrl";
rockchip,grf = <&grf>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
gpio0: gpio0 at ff210000 {
compatible = "rockchip,gpio-bank";
reg = <0x0 0xff210000 0x0 0x100>;
interrupts = <GIC_SPI 51
IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru PCLK_GPIO0>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
gpio1: gpio1 at ff220000 {
//...
};
gpio2: gpio2 at ff230000 {
//...
};
gpio3: gpio3 at ff240000 {
//...
};
}
However, these general GPIO pins has multiplexed functions and
their
pull up/down and driving strength can also be configured. These
settings
are manipulated by the GRF registers in pinctrl driver. Quoted
from the
TRM, the GRF has the following function:
- IOMUX control
- Control the state of GPIO in power-down mode
- GPIO PAD pull down and pull up control
- Used for common system control
- Used to record the system state
Therefore the functions of the GRF are messy and scattered in
different
nodes. The so-called GPIO_MUTE does not belong to GPIO0~GPIO3. It
is
manipulated by the GRF_SOC_CON10 register in the GRF block.
> I'm being told both "this is the only GPIO" and "the GRF has too
> many
> different functions for us to tell you what they all are". So
> which is
> it?
>
> Rob
They are both true, but lack of context. See the above
description.
Thanks,
Levin
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC DT Updates for v4.18
From: Olof Johansson @ 2018-06-02 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1526641667.git.horms+renesas@verge.net.au>
On Fri, May 18, 2018 at 01:17:37PM +0200, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these Renesas ARM based SoC DT updates for v4.18.
>
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt-for-v4.18
>
> for you to fetch changes up to 7fad92d05887319998b8d2bb40082b8b224d5ef5:
>
> ARM: dts: r8a7740: Add CEU1 (2018-05-16 10:54:50 +0200)
Per the other subthread, I have queued this up in next/late now. Thanks.
-Olof
^ permalink raw reply
* [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.18
From: Olof Johansson @ 2018-06-02 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528074436.rctyzocv4qfmdfzy@verge.net.au>
On Mon, May 28, 2018 at 09:44:41AM +0200, Simon Horman wrote:
> Hi Olof,
>
> On Sat, May 26, 2018 at 02:14:20PM -0700, Olof Johansson wrote:
> > Hi Simon,
> >
> > On Fri, May 18, 2018 at 01:16:00PM +0200, Simon Horman wrote:
> > > Hi Olof, Hi Kevin, Hi Arnd,
> > >
> > > Please consider these Renesas ARM64 based SoC DT updates for v4.18.
> > >
> > >
> > > The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
> > >
> > > Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
> > >
> > > are available in the git repository at:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm64-dt-for-v4.18
> > >
> > > for you to fetch changes up to 908001d778eba06ee1d832863d4e9a1e2cfd4746:
> > >
> > > arm64: dts: renesas: salvator-common: Add ADV7482 support (2018-05-18 11:52:03 +0200)
> >
> > This pull request is really, really hard for us to digest. The tag
> > description is very large, and it repeats several SoCs several times,
> > making it hard to get an overview of what is in it. The verbosity of "<x>
> > says.." makes it harder on this size of a pull request as well.
>
> I appologise that this pull-request has turned out to be hard to digest.
>
> I think that one reason for this is that there are an unusally large number
> of commits. It seems that the team has been a little more productive than
> usual and I might have been better to send a smaller pull-request earlier
> in the development cycle and then follow-up with a second batch. I'll try
> to pay more attention to this aspect of things going forwards.
>
> Regarding your specific comments:
>
> * Repetition of SoCs. I do try to group things in a logical manner,
> but clearly I failed in this case. I'll try to make that a bit clearer
> in future.
I don't think you're helped by the fact that Renesas product names seem
to have little rhyme or reason to them, and mumbles families and product
names and numbers seemingly random. :(
> * Verbosity: There as a request a few development cycles for me
> to include more information in the commit logs. It seems that
> I may have gone a bit too far. I'll try to find a better balance next
> time around.
There's a balance to be found here. You chose to describe some very small
changes with 3 lines of description, and as a result it's hard to get an
overview of what's in the pull request.
As a maintainer, you should strive to be the editor that makes sure that things
are easy to understand, and arranged in a manner that makes sense for both your
developers and the rest of the community (and the upstream maintainers).
> * Patches for the same change split up for different SoCs/boards.
> Featurs broken out into incremental patches. And so on.
>
> This has been a long-standing practice for Renesas SoC development.
> We find that in general it aids review. It also works well
> with the way we develop patches. But I do see your point that
> it may be a little excessive - f.e. multiple patches for the same
> whitespace fixes. Again, we'll try to find a better balance.
I can understand where the policy comes from, but it seems to me that at least
in this case it's one that's no longer scaling to the number of SoCs you're
supporting, and the number of (each small) additions that you're doing.
Grouping in some of the simpler dtsi additions into one per SoC, or one per IP
block across all SoCs, seems like something to attempt here.
> > For example:
> >
> > > * Condor board with R-Car V3H (r8a77980) SoC
> > > - Enable eMMC
> > >
> > > Sergei Shtylyov says "We're adding the R8A77980 MMC (SDHI)
> > > device nodes and then enable eMMC support on the Condor board."
> >
> > The "Enable eMMC" line is just fine here.
> >
> > > ----------------------------------------------------------------
> > > Geert Uytterhoeven (11):
> > > arm64: dts: renesas: draak: Rename EtherAVB "mdc" pin group to "mdio"
> > > arm64: dts: renesas: salvator-common: Rename EtherAVB "mdc" pin group to "mdio"
> > > arm64: dts: renesas: ulcb: Rename EtherAVB "mdc" pin group to "mdio"
> >
> > Why can't these be done in one commit?
> >
> > > arm64: dts: renesas: r8a7795: Correct whitespace
> > > arm64: dts: renesas: r8a7796: Correct whitespace
> > > arm64: dts: renesas: r8a77965: Correct whitespace
> >
> > Do these really need to be three commits to fix some whitespace?
> >
> > > arm64: dts: renesas: ulcb: Add BD9571 PMIC
> > > arm64: dts: renesas: salvator-common: Add PMIC DDR Backup Power config
> > > arm64: dts: renesas: ulcb: Add PMIC DDR Backup Power config
> > > arm64: dts: renesas: r8a77970: Add secondary CA53 CPU core
> > > arm64: dts: renesas: r8a77970: Add Cortex-A53 PMU node
> >
> > Why can't these be done in the same commit?
> >
> > > Kieran Bingham (7):
> > > arm64: dts: renesas: r8a77965: Add FCPF and FCPV instances
> > > arm64: dts: renesas: r8a77965: Add VSP instances
> > > arm64: dts: renesas: r8a77965: Populate the DU instance placeholder
> > > arm64: dts: renesas: r8a77965: Add HDMI encoder instance
> > > arm64: dts: renesas: r8a77965-salvator-x: Enable DU external clocks and HDMI
> > > arm64: dts: renesas: r8a77965-salvator-xs: Enable DU external clocks and HDMI
> >
> > These two can probably be in one commit as well.
> >
> > > arm64: dts: renesas: salvator-common: Add ADV7482 support
> > >
> > > Kuninori Morimoto (8):
> > > arm64: dts: renesas: r8a7795: add HDMI sound support
> > > arm64: dts: renesas: r8a7796: add HDMI sound support
> >
> > ... starting to see a trend?
> >
> > > arm64: dts: renesas: salvator-common: use audio-graph-card for Sound
> > > arm64: dts: renesas: r8a7795-es1-salvator-x: enable HDMI sound
> > > arm64: dts: renesas: r8a7795-salvator-xs: enable HDMI sound
> > > arm64: dts: renesas: r8a7796-salvator-xs: enable HDMI sound
> > > arm64: dts: renesas: r8a7795-salvator-x: enable HDMI sound
> > > arm64: dts: renesas: r8a7796-salvator-x: enable HDMI sound
> >
> > ... and more.
> >
> > >
> > > Magnus Damm (5):
> > > arm64: dts: renesas: r8a77970: Update IPMMU DS1 bit number
> > > arm64: dts: renesas: r8a7795: Enable IPMMU devices
> > > arm64: dts: renesas: r8a7796: Enable IPMMU devices
> > > arm64: dts: renesas: r8a77970: Enable IPMMU devices
> > > arm64: dts: renesas: r8a77995: Enable IPMMU devices
> >
> > I think these 4 could be in one commit too.
> >
> > >
> > > Niklas S?derlund (11):
> > > arm64: dts: renesas: r8a7795: decrease temperature hysteresis
> > > arm64: dts: renesas: r8a7796: decrease temperature hysteresis
> > > arm64: dts: renesas: r8a77965: use r8a77965-sysc binding definitions
> > > arm64: dts: renesas: r8a77965: Add R-Car Gen3 thermal support
> > > arm64: dts: renesas: r8a77965: add I2C support
> > > arm64: dts: renesas: r8a7795: add VIN and CSI-2 nodes
> > > arm64: dts: renesas: r8a7795-es1: add CSI-2 node
> > > arm64: dts: renesas: r8a7796: add VIN and CSI-2 nodes
> > > arm64: dts: renesas: r8a77965: add VIN and CSI-2 nodes
> > > arm64: dts: renesas: r8a77970: add VIN and CSI-2 nodes
> >
> >
> > .... etc, etc. I'll stop here.
> >
> >
> > I haven't merged this branch yet, will need to set aside more time to review
> > the contents. I can't guarantee that it'll make v4.18 but I'll try.
>
> Please let me know if there is anything I can do to help make this happen.
> This work is very important to Renesas.
I've queued this and the SoC branch up in a next/late branch now. I'm planning
on sending it in unless it's a messy or hard merge window for some reason.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: mvebu: fixes for v4.17 (#2)
From: Olof Johansson @ 2018-06-02 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <871sdvyfxj.fsf@bootlin.com>
On Mon, May 28, 2018 at 05:10:16PM +0200, Gregory CLEMENT wrote:
> Hi,
>
> Here is the second pull request for fixes for mvebu for v4.17.
> Nothing really critical but it needs to be fixed.
>
> Gregory
>
> The following changes since commit f43194c1447c9536efb0859c2f3f46f6bf2b9154:
>
> ARM64: dts: marvell: armada-cp110: Add mg_core_clk for ethernet node (2018-04-27 17:47:24 +0200)
>
> are available in the Git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-fixes-4.17-2
>
> for you to fetch changes up to ac62cc9d9cd6fa4c79e171c13dc8d58c3862b678:
>
> arm: dts: armada: Fix "#cooling-cells" property's name (2018-05-28 16:54:44 +0200)
>
> ----------------------------------------------------------------
> mvebu fixes for 4.17 (part 2)
>
> - Use correct size for ICU nodes (irq controller) on Armada 7K/8K
> - Fix "#cooling-cells" property's name on Synology DS116 (Armada 385)
>
> ----------------------------------------------------------------
> Miquel Raynal (1):
> arm64: dts: marvell: fix CP110 ICU node size
>
> Viresh Kumar (1):
> arm: dts: armada: Fix "#cooling-cells" property's name
Subject here should be 'ARM: dts: ...'
The latter is definitely not 4.17 material by now. It's unclear on the ICU
patch whether it's causing a real problem in reality, i.e. if it's an urgent
regression fix or if it's just fixing up the register range to be correct per
documentation. Let me know if it's a real issue and I can either cherry-pick
it or send a separate pull request with just that fix.
-Olof
^ 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