* Re: [PATCH 0/3] pwm: bcm2835: Minor fixes
From: Uwe Kleine-König @ 2019-08-24 9:25 UTC (permalink / raw)
To: Stefan Wahren
Cc: linux-pwm, Florian Fainelli, Scott Branden, Ray Jui, Eric Anholt,
Thierry Reding, linux-arm-kernel
In-Reply-To: <1566630445-4599-1-git-send-email-wahrenst@gmx.net>
Hello Stefan,
On Sat, Aug 24, 2019 at 09:07:22AM +0200, Stefan Wahren wrote:
> This small patch series contains minor fixes for clock handling and the
> period range check.
I'd like to understand the various different usecases of PWMs. The
in-kernel consumers are kind of obvious, but sysfs users are not. It
seems you are one of the latter.
Would you mind sharing what you control using the PWM? Does it bother
you that the sysfs interface doesn't allow atomic configuration?
Assuming you have some interest in this driver: It still uses the legacy
stuff implementing .config, .enable, .disable, .set_polarity. Are you
willing to test (or even implement) a switch to .apply instead?
Just from a quick lock into the driver I wonder a few things, maybe you
can shed some light here. If there is publicly available documenation
for this piece of hardware, feel free to point this out, then I might be
able to work out some of the answers myself.
The overall (and common) design of the PWM is an input clk, a counter, a
duty and a period register.
The slightly simplified logic in .config is:
scaler = DIV_ROUND_CLOSEST(NSEC_PER_SEC, rate);
writel(DIV_ROUND_CLOSEST(duty_ns, scaler), PWM_DUTY);
writel(DIV_ROUND_CLOSEST(period_ns, scaler), PWM_PERIOD);
This is loosing precision while the calculation could be cheaper (in CPU
cycles) and more exact when using:
writel(DIV_ROUND_CLOSEST(duty_ns * rate, NSEC_PER_SEC), PWM_DUTY);
writel(DIV_ROUND_CLOSEST(period_ns * rate, NSEC_PER_SEC), PWM_PERIOD);
This is only two divisions instead of three. And assuming a rate of 9.2
MHz and a request of duty_ns = 499945, period_ns = 999891 the original
calculation yields
DUTY = 4587
PERIOD = 9173
real_duty_ns = 498586.95652173914
real_period_ns = 997065.2173913043
error_duty_ns = 1358.0434782608645
error_period_ns = 2825.7826086956775
With my suggestion you'd get
DUTY = 4599
PERIOD = 9199
real_duty_ns = 499891.3043478261
real_period_ns = 999891.304347826
error_duty_ns = 53.69565217389027
error_period_ns = -0.30434782605152577
(But having said this, I'd prefer to use rounding down instead of
rounding closest).
Also I wonder if reprogramming the hardware completes the currently
running period and how the hardware behaves on disable. (In the latter
case I'm interested in "Does it complete the running period?" and "Which
state does the output stop in?")
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] pwm: bcm2835: suppress error message for invalid period_ns
From: Uwe Kleine-König @ 2019-08-24 9:26 UTC (permalink / raw)
To: Stefan Wahren
Cc: linux-pwm, Florian Fainelli, Scott Branden, Ray Jui, Eric Anholt,
Thierry Reding, linux-arm-kernel
In-Reply-To: <1566630445-4599-2-git-send-email-wahrenst@gmx.net>
On Sat, Aug 24, 2019 at 09:07:23AM +0200, Stefan Wahren wrote:
> The PWM config can be triggered via sysfs, so we better suppress the
> error message in case of an invalid period to avoid kernel log spamming.
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] pwm: bcm2835: fix period_ns range check
From: Uwe Kleine-König @ 2019-08-24 9:26 UTC (permalink / raw)
To: Stefan Wahren
Cc: linux-pwm, Florian Fainelli, Scott Branden, Ray Jui, Eric Anholt,
Thierry Reding, linux-arm-kernel
In-Reply-To: <1566630445-4599-3-git-send-email-wahrenst@gmx.net>
On Sat, Aug 24, 2019 at 09:07:24AM +0200, Stefan Wahren wrote:
> The range check for period_ns was written under assumption of a fixed
> PWM clock. With clk-bcm2835 driver the PWM clock is a dynamic one.
> So fix this by doing the range check on the period register value.
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] pwm: bcm2835: suppress error message during deferred probe
From: Uwe Kleine-König @ 2019-08-24 9:30 UTC (permalink / raw)
To: Stefan Wahren
Cc: linux-pwm, Florian Fainelli, Scott Branden, Ray Jui, Eric Anholt,
Thierry Reding, linux-arm-kernel
In-Reply-To: <1566630445-4599-4-git-send-email-wahrenst@gmx.net>
On Sat, Aug 24, 2019 at 09:07:25AM +0200, Stefan Wahren wrote:
> This suppresses error messages in case the PWM clock isn't ready yet.
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> ---
> drivers/pwm/pwm-bcm2835.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
> index 2c82386..ce362be 100644
> --- a/drivers/pwm/pwm-bcm2835.c
> +++ b/drivers/pwm/pwm-bcm2835.c
> @@ -153,7 +153,10 @@ static int bcm2835_pwm_probe(struct platform_device *pdev)
>
> pc->clk = devm_clk_get(&pdev->dev, NULL);
> if (IS_ERR(pc->clk)) {
> - dev_err(&pdev->dev, "clock not found: %ld\n", PTR_ERR(pc->clk));
> + if (PTR_ERR(pc->clk) != -EPROBE_DEFER) {
> + dev_err(&pdev->dev, "clock not found: %ld\n",
> + PTR_ERR(pc->clk));
> + }
> return PTR_ERR(pc->clk);
> }
I would have used:
if (IS_ERR(pc->clk)) {
int err = PTR_ERR(pc->clk);
if (err != -EPROBE_DEFER)
dev_err(&pdev->dev, "clock not found: %d\n", err);
return err;
}
This calculates the error code only once and make the dev_err line short
enough to not make it necessary to add a line break.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] pwm: bcm2835: suppress error message during deferred probe
From: Stefan Wahren @ 2019-08-24 9:44 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-pwm, Florian Fainelli, Scott Branden, Ray Jui, Eric Anholt,
Thierry Reding, linux-arm-kernel
In-Reply-To: <20190824093032.cunkmukx73vl4hy3@pengutronix.de>
Am 24.08.19 um 11:30 schrieb Uwe Kleine-König:
> On Sat, Aug 24, 2019 at 09:07:25AM +0200, Stefan Wahren wrote:
>> This suppresses error messages in case the PWM clock isn't ready yet.
>>
>> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
>> ---
>> drivers/pwm/pwm-bcm2835.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
>> index 2c82386..ce362be 100644
>> --- a/drivers/pwm/pwm-bcm2835.c
>> +++ b/drivers/pwm/pwm-bcm2835.c
>> @@ -153,7 +153,10 @@ static int bcm2835_pwm_probe(struct platform_device *pdev)
>>
>> pc->clk = devm_clk_get(&pdev->dev, NULL);
>> if (IS_ERR(pc->clk)) {
>> - dev_err(&pdev->dev, "clock not found: %ld\n", PTR_ERR(pc->clk));
>> + if (PTR_ERR(pc->clk) != -EPROBE_DEFER) {
>> + dev_err(&pdev->dev, "clock not found: %ld\n",
>> + PTR_ERR(pc->clk));
>> + }
>> return PTR_ERR(pc->clk);
>> }
> I would have used:
>
> if (IS_ERR(pc->clk)) {
> int err = PTR_ERR(pc->clk);
> if (err != -EPROBE_DEFER)
> dev_err(&pdev->dev, "clock not found: %d\n", err);
>
> return err;
> }
>
> This calculates the error code only once and make the dev_err line short
> enough to not make it necessary to add a line break.
Sure that's better. Will send V2 soon
>
> Best regards
> Uwe
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/3] pwm: bcm2835: Minor fixes
From: Stefan Wahren @ 2019-08-24 10:05 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-pwm, Florian Fainelli, Scott Branden, Ray Jui, Eric Anholt,
Thierry Reding, linux-arm-kernel
In-Reply-To: <20190824092553.j4rjpzaz4m6yaa5t@pengutronix.de>
Hi Uwe,
Am 24.08.19 um 11:25 schrieb Uwe Kleine-König:
> Hello Stefan,
>
> On Sat, Aug 24, 2019 at 09:07:22AM +0200, Stefan Wahren wrote:
>> This small patch series contains minor fixes for clock handling and the
>> period range check.
> I'd like to understand the various different usecases of PWMs. The
> in-kernel consumers are kind of obvious, but sysfs users are not. It
> seems you are one of the latter.
>
> Would you mind sharing what you control using the PWM?
not really a PWM user with BCM2835. It's more the motivation as a
platform maintainer to keep the drivers in shape. At work we are using
sysfs interface for user applications to control ventilation (via hwmon
interface) and EV charging (IEC 61851) with a different SoC.
> Does it bother
> you that the sysfs interface doesn't allow atomic configuration?
To be honest not really, but i think a lot of user could benefit and
might stop using hacky Python scripts which manipulate the registers
directly.
>
> Assuming you have some interest in this driver: It still uses the legacy
> stuff implementing .config, .enable, .disable, .set_polarity. Are you
> willing to test (or even implement) a switch to .apply instead?
Yes, definitely. This is one of my never ending TODO list [1]. But i
would be suprised that you wont have access to a Raspberry Pi.
>
> Just from a quick lock into the driver I wonder a few things, maybe you
> can shed some light here. If there is publicly available documenation
> for this piece of hardware, feel free to point this out, then I might be
> able to work out some of the answers myself.
Fortunately yes [2]
>
> The overall (and common) design of the PWM is an input clk, a counter, a
> duty and a period register.
>
> The slightly simplified logic in .config is:
>
> scaler = DIV_ROUND_CLOSEST(NSEC_PER_SEC, rate);
> writel(DIV_ROUND_CLOSEST(duty_ns, scaler), PWM_DUTY);
> writel(DIV_ROUND_CLOSEST(period_ns, scaler), PWM_PERIOD);
>
> This is loosing precision while the calculation could be cheaper (in CPU
> cycles) and more exact when using:
>
> writel(DIV_ROUND_CLOSEST(duty_ns * rate, NSEC_PER_SEC), PWM_DUTY);
> writel(DIV_ROUND_CLOSEST(period_ns * rate, NSEC_PER_SEC), PWM_PERIOD);
>
> This is only two divisions instead of three. And assuming a rate of 9.2
> MHz and a request of duty_ns = 499945, period_ns = 999891 the original
> calculation yields
>
> DUTY = 4587
> PERIOD = 9173
>
> real_duty_ns = 498586.95652173914
> real_period_ns = 997065.2173913043
>
> error_duty_ns = 1358.0434782608645
> error_period_ns = 2825.7826086956775
>
> With my suggestion you'd get
>
> DUTY = 4599
> PERIOD = 9199
>
> real_duty_ns = 499891.3043478261
> real_period_ns = 999891.304347826
>
> error_duty_ns = 53.69565217389027
> error_period_ns = -0.30434782605152577
>
> (But having said this, I'd prefer to use rounding down instead of
> rounding closest).
>
> Also I wonder if reprogramming the hardware completes the currently
> running period and how the hardware behaves on disable. (In the latter
> case I'm interested in "Does it complete the running period?" and "Which
> state does the output stop in?")
I need to make logic analyzer traces to make any statement.
Thanks
[1] - https://github.com/lategoodbye/rpi-zero/issues/16
[2] -
https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
>
> Best regards
> Uwe
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH 1/1] rtc: sun6i: Allow using as wakeup source from suspend
From: Alejandro González @ 2019-08-24 10:10 UTC (permalink / raw)
To: a.zummo, alexandre.belloni, maxime.ripard, wens, linux-rtc,
linux-arm-kernel, linux-kernel
Cc: linux-sunxi
In-Reply-To: <20190821210056.11995-1-alejandro.gonzalez.correo@gmail.com>
Alejandro González wrote:
> This patch allows userspace to set up wakeup alarms on any RTC handled by the
> sun6i driver, and adds the necessary PM operations to allow resuming from
> suspend when the configured wakeup alarm fires a IRQ. Of course, that the
> device actually resumes depends on the suspend state and how a particular
> hardware reacts to it, but that is out of scope for this patch.
>
> I've tested these changes on a Pine H64 model B, which contains a
> Allwinner H6 SoC, with the help of CONFIG_PM_TEST_SUSPEND kernel option.
> These are the interesting outputs from the kernel and commands which
> show that it works. As every RTC handled by this driver is largely the
> same, I think that it shouldn't introduce any regression on other SoCs,
> but I may be wrong.
>
> [ 1.092705] PM: test RTC wakeup from 'freeze' suspend
> [ 1.098230] PM: suspend entry (s2idle)
> [ 1.212907] PM: suspend devices took 0.080 seconds
> (The SoC freezes for some seconds)
> [ 3.197604] PM: resume devices took 0.104 seconds
> [ 3.215937] PM: suspend exit
>
> [ 1.092812] PM: test RTC wakeup from 'mem' suspend
> [ 1.098089] PM: suspend entry (deep)
> [ 1.102033] PM: suspend exit
> [ 1.105205] PM: suspend test failed, error -22
>
> In any case, the RTC alarm interrupt gets fired as exptected:
>
> $ echo +5 > /sys/class/rtc/rtc0/wakealarm && sleep 5 && grep rtc /proc/interrupts
> 29: 1 0 0 0 GICv2 133 Level 7000000.rtc
>
> Signed-off-by: Alejandro González <alejandro.gonzalez.correo@gmail.com>
> ---
> drivers/rtc/rtc-sun6i.c | 30 ++++++++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> index c0e75c373605..b7611e5dea3f 100644
> --- a/drivers/rtc/rtc-sun6i.c
> +++ b/drivers/rtc/rtc-sun6i.c
> @@ -598,6 +598,33 @@ static const struct rtc_class_ops sun6i_rtc_ops = {
> .alarm_irq_enable = sun6i_rtc_alarm_irq_enable
> };
>
> +#ifdef CONFIG_PM_SLEEP
> +/* Enable IRQ wake on suspend, to wake up from RTC. */
> +static int sun6i_rtc_suspend(struct device *dev)
> +{
> + struct sun6i_rtc_dev *chip = dev_get_drvdata(dev);
> +
> + if (device_may_wakeup(dev))
> + enable_irq_wake(chip->irq);
> +
> + return 0;
> +}
> +
> +/* Disable IRQ wake on resume. */
> +static int sun6i_rtc_resume(struct device *dev)
> +{
> + struct sun6i_rtc_dev *chip = dev_get_drvdata(dev);
> +
> + if (device_may_wakeup(dev))
> + disable_irq_wake(chip->irq);
> +
> + return 0;
> +}
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(sun6i_rtc_pm_ops,
> + sun6i_rtc_suspend, sun6i_rtc_resume);
> +
> static int sun6i_rtc_probe(struct platform_device *pdev)
> {
> struct sun6i_rtc_dev *chip = sun6i_rtc;
> @@ -650,6 +677,8 @@ static int sun6i_rtc_probe(struct platform_device *pdev)
>
> clk_prepare_enable(chip->losc);
>
> + device_init_wakeup(&pdev->dev, 1);
> +
> chip->rtc = devm_rtc_device_register(&pdev->dev, "rtc-sun6i",
> &sun6i_rtc_ops, THIS_MODULE);
> if (IS_ERR(chip->rtc)) {
> @@ -684,6 +713,7 @@ static struct platform_driver sun6i_rtc_driver = {
> .driver = {
> .name = "sun6i-rtc",
> .of_match_table = sun6i_rtc_dt_ids,
> + .pm = &sun6i_rtc_pm_ops,
> },
> };
> builtin_platform_driver(sun6i_rtc_driver);
>
I'd be grateful if someone can test this patch on different boards to the Pine H64 model B. I'm afraid that board is the only one I have to test this.
Regards.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 14/19] dt-bindings: pci: add PHY properties to Armada 7K/8K controller bindings
From: Miquel Raynal @ 2019-08-24 10:15 UTC (permalink / raw)
To: Rob Herring
Cc: Andrew Lunn, Jason Cooper, devicetree, Antoine Tenart,
Grzegorz Jaszczyk, Gregory Clement, Russell King,
Kishon Vijay Abraham I, Nadav Haklai, Thomas Petazzoni,
Maxime Chevallier, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20190821182857.GA9660@bogus>
Hi Rob,
Rob Herring <robh@kernel.org> wrote on Wed, 21 Aug 2019 13:28:57 -0500:
> On Wed, Jul 31, 2019 at 02:21:21PM +0200, Miquel Raynal wrote:
> > Armada CP110 PCIe controller can have from one to four PHYs for
> > configuring SERDES lanes (PCIe x1, PCIe x2 or PCIe x4). Describe the
> > phys and phy-names properties in the bindings.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> > Documentation/devicetree/bindings/pci/pci-armada8k.txt | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/pci-armada8k.txt b/Documentation/devicetree/bindings/pci/pci-armada8k.txt
> > index 9e3fc15e1af8..7cf12162aa4e 100644
> > --- a/Documentation/devicetree/bindings/pci/pci-armada8k.txt
> > +++ b/Documentation/devicetree/bindings/pci/pci-armada8k.txt
> > @@ -17,6 +17,12 @@ Required properties:
> > name must be "core" for the first clock and "reg" for the second
> > one
> >
> > +Optional properties:
> > +- phys: phandle(s) to PHY node(s) following the generic PHY bindings.
> > + Either 1, 2 or 4 PHYs might be needed depending on the number of
> > + PCIe lanes.
> > +- phy-names: names of the PHYs.
>
> You need to enumerate what the names are. Based on your example in v2, I
> don't think the names are really valuable unless you can skip lanes.
I don't know any setup doing it but yes, I suppose you could skip lanes.
Kishon asked me to rebase on phy-next, I'll enumerate the names when
resending.
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 1/4] clk: core: link consumer with clock driver
From: Miquel Raynal @ 2019-08-24 10:35 UTC (permalink / raw)
To: Stephen Boyd
Cc: Gregory Clement, Antoine Tenart, Michael Turquette, linux-kernel,
Russell King, Nadav Haklai, Thomas Petazzoni, Maxime Chevallier,
linux-clk, linux-arm-kernel
In-Reply-To: <20190815000301.3ABAF2086C@mail.kernel.org>
Hi Stephen,
Stephen Boyd <sboyd@kernel.org> wrote on Wed, 14 Aug 2019 17:03:00
-0700:
> Quoting Miquel Raynal (2019-05-21 05:51:10)
> > One major concern when, for instance, suspending/resuming a platform
> > is to never access registers before the underlying clock has been
> > resumed, otherwise most of the time the kernel will just crash. One
> > solution is to use syscore operations when registering clock drivers
> > suspend/resume callbacks. One problem of using syscore_ops is that the
> > suspend/resume scheduling will depend on the order of the
> > registrations, which brings (unacceptable) randomness in the process.
> >
> > A feature called device links has been introduced to handle such
> > situation. It creates dependencies between consumers and providers,
> > enforcing e.g. the suspend/resume order when needed. Such feature is
> > already in use for regulators.
> >
> > Add device links support in the clock subsystem by creating/deleting
> > the links at get/put time.
> >
> > Example of a boot (ESPRESSObin, A3700 SoC) with devices linked to clocks:
> >
> > marvell-armada-3700-tbg-clock d0013200.tbg: Linked as a consumer to d0013800.pinctrl:xtal-clk
> > marvell-armada-3700-tbg-clock d0013200.tbg: Dropping the link to d0013800.pinctrl:xtal-clk
> > marvell-armada-3700-tbg-clock d0013200.tbg: Linked as a consumer to d0013800.pinctrl:xtal-clk
> > marvell-armada-3700-periph-clock d0013000.nb-periph-clk: Linked as a consumer to d0013200.tbg
> > marvell-armada-3700-periph-clock d0013000.nb-periph-clk: Linked as a consumer to d0013800.pinctrl:xtal-clk
> > marvell-armada-3700-periph-clock d0018000.sb-periph-clk: Linked as a consumer to d0013200.tbg
> > mvneta d0030000.ethernet: Linked as a consumer to d0018000.sb-periph-clk
> > xhci-hcd d0058000.usb: Linked as a consumer to d0018000.sb-periph-clk
> > xenon-sdhci d00d0000.sdhci: Linked as a consumer to d0013000.nb-periph-clk
> > xenon-sdhci d00d0000.sdhci: Dropping the link to d0013000.nb-periph-clk
> > mvebu-uart d0012000.serial: Linked as a consumer to d0013800.pinctrl:xtal-clk
> > advk-pcie d0070000.pcie: Linked as a consumer to d0018000.sb-periph-clk
> > xenon-sdhci d00d0000.sdhci: Linked as a consumer to d0013000.nb-periph-clk
> > xenon-sdhci d00d0000.sdhci: Linked as a consumer to regulator.1
> > cpu cpu0: Linked as a consumer to d0013000.nb-periph-clk
> > cpu cpu0: Dropping the link to d0013000.nb-periph-clk
> > cpu cpu0: Linked as a consumer to d0013000.nb-periph-clk
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
>
> This patch doesn't apply. Things have changed upstream.
>
> >
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index ec6f04dcf5e6..e6b84ab43f9f 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -1676,6 +1710,8 @@ static void clk_reparent(struct clk_core *core, struct clk_core *new_parent)
> >
> > if (was_orphan != becomes_orphan)
> > clk_core_update_orphan_status(core, becomes_orphan);
> > +
> > + clk_link_hierarchy(core, new_parent);
>
> This isn't going to work.
Strange, I didn't had that problem (on Marvell platforms).
>
> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:909
> in_atomic(): 1, irqs_disabled(): 128, pid: 1, name: swapper/0
> 3 locks held by swapper/0/1:
> #0: (____ptrval____) (&dev->mutex){....}, at: __device_driver_lock+0x40/0x4c
> #1: (____ptrval____) (prepare_lock){+.+.}, at: clk_prepare_lock+0x18/0x94
> #2: (____ptrval____) (enable_lock){....}, at: clk_enable_lock+0x34/0xdc
> irq event stamp: 311516
> hardirqs last enabled at (311515): [<ffffff901fce5c90>] _raw_spin_unlock_irqrestore+0x54/0x90
> hardirqs last disabled at (311516): [<ffffff901f73d468>] clk_enable_lock+0x28/0xdc
> softirqs last enabled at (311348): [<ffffff901f28188c>] __do_softirq+0x4cc/0x514
> softirqs last disabled at (311341): [<ffffff901f2f89ac>] irq_exit+0xd8/0xf8
> CPU: 4 PID: 1 Comm: swapper/0 Tainted: G W 5.3.0-rc4-00005-g6be06bbec80ef #10
> Hardware name: Google Cheza (rev3+) (DT)
> Call trace:
> dump_backtrace+0x0/0x13c
> show_stack+0x20/0x2c
> dump_stack+0xc4/0x12c
> ___might_sleep+0x1b4/0x1c4
> __might_sleep+0x50/0x88
> __mutex_lock_common+0x5c/0xbfc
> mutex_lock_nested+0x40/0x50
> device_link_add+0x88/0x3ac
> clk_reparent+0xc4/0x114
> __clk_set_parent_before+0x74/0x90
> clk_change_rate+0x98/0x854
> clk_core_set_rate_nolock+0x1b0/0x21c
> clk_set_rate+0x3c/0x6c
> of_clk_set_defaults+0x29c/0x364
> platform_drv_probe+0x28/0xb0
> really_probe+0x130/0x2b4
> driver_probe_device+0x64/0xfc
> device_driver_attach+0x4c/0x6c
> __driver_attach+0xb0/0xc4
> bus_for_each_dev+0x84/0xcc
> driver_attach+0x2c/0x38
> bus_add_driver+0xfc/0x1d0
> driver_register+0x64/0xf0
> __platform_driver_register+0x4c/0x58
> msm_drm_register+0x5c/0x60
> do_one_initcall+0x1e0/0x478
> do_initcall_level+0x21c/0x25c
> do_basic_setup+0x60/0x78
> kernel_init_freeable+0x128/0x1b0
> kernel_init+0x14/0x100
> ret_from_fork+0x10/0x18
>
> > } else {
> > hlist_add_head(&core->child_node, &clk_orphan_list);
> > if (!was_orphan)
> > @@ -2402,6 +2438,8 @@ __clk_init_parent(struct clk_core *core, bool update_orphan)
> > if (!parent_hw)
> > return NULL;
> >
> > + clk_link_hierarchy(core, parent_hw->core);
> > +
>
> This is the hunk that doesn't apply anymore.
>
> > return parent_hw->core;
> > }
> >
>
> The general thought is that it would be good to _not_ call the device
> link APIs from deep within the clk parent changing code or even parent
> initialization code. It would be better to make device links based on
> the possible parents of a clk controller when the clk is registered and
> after the clk prepare lock (i.e. the registration lock) is dropped. Is
> this possible? The problem is that we're deeply nested in locks that are
> already hard to reason about and get out from underneath. I don't want
> to get into some sort of ABBA deadlock scenario with the PM core. The
> usage of runtime PM in the clk framework is probably busted right now
> because it is used under the prepare lock. Ugh.
I understand.
>
> Is it necessary to add the device links between different clk
> controllers either? I mean, is it necessary to create links between clks
> and their parents right now? Maybe we can take the easy way out and
> just make links between devices that call clk_get() and the devices that
> provide those clks (the consumer side). I suppose you may want to order
> suspend/resume of a device with the parent clks of some clk that is
> acquired from clk_get(). I hope it isn't required though, because this
> is a problem to do with ordering suspend/resume of the clk tree itself,
> which isn't really solved at all.
What you propose is, IIRC what I sent in the early version. Here is
what Maxime Ripard pointed with this early implementation:
I think this doesn't address all the cases. In your case, where you
have one consumer that is not a clock, and one provider that is a
clock, it works just fine.
However, if you have clocks providers chained, for example with one
oscillator, a clock controller, and a device, the link will be created
between the device and the controller, but there will be no link
between the controller and the oscillator.
>
> We probably need to solve that by doing something clk provider specific
> in the clk framework to figure out a way for device drivers that provide
> clks to get callbacks to suspend/resume clks in the clk tree in some
> sort of topo-sorted order. That way we can traverse the clk tree and
> call down into provider drivers for each clk it registered to do things
> like restore the clk frequency or clk enable/prepare state, etc. It
> needs to be done in a certain order and it's not possible to flatten
> that order into a sequential list of providers (that correspond 1:1 with
> devices) given that there are loops between providers.
Ok so this would be a clocks internal mechanism to handle clock
dependencies within the clock tree, with device links to handle
dependencies with external consumers and dependencies.
>
> But from the perspective of a consumer driver like PCI, I don't see why
> it needs to care about the clk tree suspend/resume ordering details. It
> really only cares that the clk it's consuming, at the edge of the tree,
> is resumed before the consumer itself, PCI, is resumed. However the
> dependencies of that clk it's consuming is managed, be it with device
> links or something clk framework specific, doesn't matter to the PCI
> driver. And other clks that are parents or grandparents of the clk
> consumed by PCI could have device link dependencies themselves, on
> something like an i2c controller or such. Even then, we don't need to
> use device links in the clk tree to describe ordering between clks. We
> can do it without device links and break the device link chain when it
> crosses the clk tree.
>
> PCI -[device link]-> PCI leaf clk provider -[clk framework ordering black box]-> parent of leaf clk -[device link]-> i2c controller
>
I get your point. Well, too bad that Lorenzo refused the PCI series
because of this one because PCIe S2RAM won't be supported at all even if
someday someone contributes the "framework ordering black box" you are
talking about, anyway I will not have the time to work on it I am sorry.
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/3] pwm: bcm2835: Minor fixes
From: Uwe Kleine-König @ 2019-08-24 10:56 UTC (permalink / raw)
To: Stefan Wahren
Cc: linux-pwm, Florian Fainelli, Scott Branden, Ray Jui, Eric Anholt,
Thierry Reding, linux-arm-kernel
In-Reply-To: <22f8e65b-2d65-84e7-de50-ba6538a84292@gmx.net>
Hello Stefan,
On Sat, Aug 24, 2019 at 12:05:00PM +0200, Stefan Wahren wrote:
> Am 24.08.19 um 11:25 schrieb Uwe Kleine-König:
> > Hello Stefan,
> >
> > On Sat, Aug 24, 2019 at 09:07:22AM +0200, Stefan Wahren wrote:
> >> This small patch series contains minor fixes for clock handling and the
> >> period range check.
> >
> > I'd like to understand the various different usecases of PWMs. The
> > in-kernel consumers are kind of obvious, but sysfs users are not. It
> > seems you are one of the latter.
> >
> > Would you mind sharing what you control using the PWM?
>
> not really a PWM user with BCM2835. It's more the motivation as a
> platform maintainer to keep the drivers in shape. At work we are using
> sysfs interface for user applications to control ventilation (via hwmon
> interface) and EV charging (IEC 61851) with a different SoC.
I don't understand how you use the sysfs interface and still interact
with the hwmon interface. Other than that, thanks for sharing.
> > Assuming you have some interest in this driver: It still uses the legacy
> > stuff implementing .config, .enable, .disable, .set_polarity. Are you
> > willing to test (or even implement) a switch to .apply instead?
>
> Yes, definitely. This is one of my never ending TODO list [1]. But i
> would be suprised that you wont have access to a Raspberry Pi.
So be surprised :-)
> > Just from a quick lock into the driver I wonder a few things, maybe you
> > can shed some light here. If there is publicly available documenation
> > for this piece of hardware, feel free to point this out, then I might be
> > able to work out some of the answers myself.
>
> Fortunately yes [2]
Care to add a link to this document in the driver for others to easily
find it?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 12/16] arm64: prefer __section from compiler_attributes.h
From: Will Deacon @ 2019-08-24 11:25 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Song Liu, Catalin Marinas, Alexei Starovoitov, Daniel Borkmann,
clang-built-linux, Allison Randal, Yonghong Song,
Masayoshi Mizuma, Suzuki K Poulose, Andrey Konovalov,
Shaokun Zhang, Alexios Zavras, Josh Poimboeuf, Sedat Dilek,
Thomas Gleixner, bpf, Linux ARM, Greg Kroah-Hartman,
Nick Desaulniers, linux-kernel, Network Development,
Andrew Morton, Enrico Weigelt, Martin KaFai Lau
In-Reply-To: <CANiq72nfn4zxAO63GEEoUjumC6Jwi5_jdcD_5Xzt1vZRgh52fg@mail.gmail.com>
On Fri, Aug 23, 2019 at 09:35:08PM +0200, Miguel Ojeda wrote:
> On Thu, Aug 15, 2019 at 11:12 AM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > Btw, I guess that is the Oops you were mentioning in the cover letter?
>
> Pinging about this...
Which bit are you pinging about? This patch (12/16) has been in -next for a
while and is queued in the arm64 tree for 5.4. The Oops/boot issue is
addressed in patch 14 which probably needs to be sent as a separate patch
(with a commit message) if it's targetting 5.3 and, I assume, routed via
somebody like akpm.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] media: imx: Move capture device init to registered
From: kbuild test robot @ 2019-08-24 11:25 UTC (permalink / raw)
To: Steve Longerbeam
Cc: open list:STAGING SUBSYSTEM, Philipp Zabel, Greg Kroah-Hartman,
Sascha Hauer, open list, kbuild-all, Pengutronix Kernel Team,
Steve Longerbeam, NXP Linux Team, Mauro Carvalho Chehab,
Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-media
In-Reply-To: <20190824002750.5860-2-slongerbeam@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3499 bytes --]
Hi Steve,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[cannot apply to v5.3-rc5 next-20190823]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Steve-Longerbeam/media-imx-Move-capture-device-init-to-registered/20190824-182241
base: git://linuxtv.org/media_tree.git master
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sparc64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
Note: the linux-review/Steve-Longerbeam/media-imx-Move-capture-device-init-to-registered/20190824-182241 HEAD 7c4284abbf1ba252792db5645a7004bd033dd3b0 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/staging/media/imx/imx-ic-prpencvf.c: In function 'prp_registered':
>> drivers/staging/media/imx/imx-ic-prpencvf.c:1274:45: error: 'ic_priv' undeclared (first use in this function); did you mean 'priv'?
priv->vdev = imx_media_capture_device_init(ic_priv->ipu_dev,
^~~~~~~
priv
drivers/staging/media/imx/imx-ic-prpencvf.c:1274:45: note: each undeclared identifier is reported only once for each function it appears in
vim +1274 drivers/staging/media/imx/imx-ic-prpencvf.c
1242
1243 /*
1244 * retrieve our pads parsed from the OF graph by the media device
1245 */
1246 static int prp_registered(struct v4l2_subdev *sd)
1247 {
1248 struct prp_priv *priv = sd_to_priv(sd);
1249 int i, ret;
1250 u32 code;
1251
1252 for (i = 0; i < PRPENCVF_NUM_PADS; i++) {
1253 priv->pad[i].flags = (i == PRPENCVF_SINK_PAD) ?
1254 MEDIA_PAD_FL_SINK : MEDIA_PAD_FL_SOURCE;
1255
1256 /* set a default mbus format */
1257 imx_media_enum_ipu_format(&code, 0, CS_SEL_YUV);
1258 ret = imx_media_init_mbus_fmt(&priv->format_mbus[i],
1259 640, 480, code, V4L2_FIELD_NONE,
1260 &priv->cc[i]);
1261 if (ret)
1262 return ret;
1263 }
1264
1265 /* init default frame interval */
1266 priv->frame_interval.numerator = 1;
1267 priv->frame_interval.denominator = 30;
1268
1269 ret = media_entity_pads_init(&sd->entity, PRPENCVF_NUM_PADS,
1270 priv->pad);
1271 if (ret)
1272 return ret;
1273
> 1274 priv->vdev = imx_media_capture_device_init(ic_priv->ipu_dev,
1275 &ic_priv->sd,
1276 PRPENCVF_SRC_PAD);
1277 if (IS_ERR(priv->vdev))
1278 return PTR_ERR(priv->vdev);
1279
1280 ret = imx_media_capture_device_register(priv->vdev);
1281 if (ret)
1282 goto remove_vdev;
1283
1284 ret = prp_init_controls(priv);
1285 if (ret)
1286 goto unreg_vdev;
1287
1288 return 0;
1289
1290 unreg_vdev:
1291 imx_media_capture_device_unregister(priv->vdev);
1292 remove_vdev:
1293 imx_media_capture_device_remove(priv->vdev);
1294 return ret;
1295 }
1296
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 58651 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 16/20] dt-bindings: marvell: Declare the CN913x SoC compatibles
From: Miquel Raynal @ 2019-08-24 11:30 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Yan Markman, Antoine Tenart,
Grzegorz Jaszczyk, Gregory Clement, Maxime Chevallier,
Nadav Haklai, Thomas Petazzoni, Stefan Chulski, Marcin Wojtas,
linux-arm-kernel
In-Reply-To: <20190821193726.GA32220@bogus>
Hi Rob,
Rob Herring <robh@kernel.org> wrote on Wed, 21 Aug 2019 14:37:26 -0500:
> On Tue, Aug 06, 2019 at 04:54:56PM +0200, Miquel Raynal wrote:
> > From: Grzegorz Jaszczyk <jaz@semihalf.com>
> >
> > Describe the compatible properties for the new Marvell SoCs:
> > * CN9130: 1x AP807-quad + 1x CP115 (1x embedded)
> > * CN9131: 1x AP807-quad + 2x CP115 (1x embedded + 1x modular)
> > * CN9132: 1x AP807-quad + 3x CP115 (1x embedded + 2x modular)
> >
> > CP115 are similar to CP110 in terms of features.
> >
> > There are three development boards based on these SoCs:
> > * CN9130-DB: comes as a single mother board (with the CP115 bundled)
> > * CN9131-DB: same as CN9130-DB with one additional modular CP115
> > * CN9132-DB: same as CN9130-DB with two additional modular CP115
> >
> > Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> > .../bindings/arm/marvell/armada-7k-8k.txt | 13 ++++++++++++-
> > 1 file changed, 12 insertions(+), 1 deletion(-)
>
> Please convert this to DT schema first.
As you wish.
>
> >
> > diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
> > index df98a9c82a8c..8eb34ca4c4f0 100644
> > --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
> > +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
> > @@ -1,7 +1,7 @@
> > Marvell Armada 7K/8K Platforms Device Tree Bindings
> > ---------------------------------------------------
> >
> > -Boards using a SoC of the Marvell Armada 7K or 8K families must carry
> > +Boards using a SoC of the Marvell Armada 7K/8K or CN913x families must carry
> > the following root node property:
> >
> > - compatible, with one of the following values:
> > @@ -18,6 +18,17 @@ the following root node property:
> > - "marvell,armada8040", "marvell,armada-ap806-quad", "marvell,armada-ap806"
> > when the SoC being used is the Armada 8040
> >
> > + - "marvell,cn9130", "marvell,armada-ap807-quad", "marvell,armada-ap807"
> > + when the SoC being used is the Armada CN9130 with no external CP.
> > +
> > + - "marvell,cn9131", "marvell,cn9130",
> > + "marvell,armada-ap807-quad", "marvell,armada-ap807"
> > + when the SoC being used is the Armada CN9130 with one external CP.
> > +
> > + - "marvell,cn9132", "marvell,cn9131", "marvell,cn9130",
> > + "marvell,armada-ap807-quad", "marvell,armada-ap807"
>
> It's generally not all that useful to have all these compatibles.
>
> > + when the SoC being used is the Armada CN9130 with two external CPs.
>
> Is the number of external CPs not discoverable somewhere else in the DT?
I don't think so.
What do you suggest? Keep only the marvell,cn9130 compatible? I am not
sure having the three compatibles is actually useful but for the reader
I find it more friendly. Of course the model name will reflect the
number of external CP but from a computational point of view that's
hard to parse if needed.
>
> > +
> > Example:
> >
> > compatible = "marvell,armada7040-db", "marvell,armada7040",
> > --
> > 2.20.1
> >
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/3] CP115 pinctrl support
From: Miquel Raynal @ 2019-08-24 11:33 UTC (permalink / raw)
To: Linus Walleij, Yan Markman
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Antoine Tenart, Grzegorz Jaszczyk, Gregory Clement,
Maxime Chevallier, Nadav Haklai, open list:GPIO SUBSYSTEM,
Rob Herring, Thomas Petazzoni, Stefan Chulski, Marcin Wojtas,
Linux ARM
In-Reply-To: <CACRpkdY-AtaS67u4s58PifFtP5C7xp4P15J+hW_Dba=Gb4rhSQ@mail.gmail.com>
Hi Linus,
Linus Walleij <linus.walleij@linaro.org> wrote on Thu, 15 Aug 2019
10:10:46 +0200:
> On Wed, Aug 14, 2019 at 2:35 PM Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
> > On Wed, 14 Aug 2019 10:12:36 +0200
> > Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > > On Wed, Aug 7, 2019 at 2:47 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> > > > On Mon, Aug 5, 2019 at 12:16 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > > This is the second batch of changes (out of three) to support the brand
> > > > > new Marvell CN9130 SoCs which are made of one AP807 and one CP115.
> > > > >
> > > > > We add a new compatible (and the relevant support in the pinctrl
> > > > > driver) before the addition in batch 3/3 of CN9130 SoCs DT using it.
> > > >
> > > > Waiting for review from the Mvebu maintainers.
> > > >
> > > > If it takes too long just nudge me, it looks good to me.
> > >
> > > So if the other MVEBU maintainers don't really look much at MVEBU
> > > patches anymore while Miquel is working a lot on the platform,
> > > what about listing Miquel as maintainer under the SoC entry, hm?
> >
> > Miquel sent his series on August 5, i.e 9 days ago. We're in August, in
> > the middle of the summer vacations for many people. While it is nice to
> > see subsystem maintainers who want to get code merged in a timely
> > fashion, I think it is probably wise to give it some more time for
> > review in this period of the year.
>
> OK then maybe I am a bit impatient.
Actually Gregory is on vacation until September, so if we still are in
time for this merge window I suppose you can take it.
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 00/19] Enhance CP110 COMPHY support
From: Miquel Raynal @ 2019-08-24 11:54 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Andrew Lunn, Jason Cooper, devicetree, Antoine Tenart,
Grzegorz Jaszczyk, Gregory Clement, Russell King,
Maxime Chevallier, Nadav Haklai, Matt Pelland, Rob Herring,
Thomas Petazzoni, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <4e1c4d27-3676-5efa-1126-8149a8635eb5@ti.com>
Hi Kishon,
+ Matt Pelland
Kishon Vijay Abraham I <kishon@ti.com> wrote on Fri, 23 Aug 2019
08:46:14 +0530:
> On 31/07/19 5:51 PM, Miquel Raynal wrote:
> > Armada CP110 have a COMPHY IP which supports configuring SERDES lanes
> > in one mode, either:
> > - SATA
> > - USB3 host
> > - PCIe (several width)
> > - Ethernet (several modes)
> >
> > As of today, only a few Ethernet modes are supported and the code is
> > embedded in the Linux driver. A more complete COMPHY driver that can
> > be used by both Linux and U-Boot is embedded in the firmware and can
> > be run through SMC calls.
> >
> > First the current COMPHY driver is updated to use SMC calls but
> > fallbacks to the already existing functions if the firmware is not
> > up-to-date. Then, more Ethernet modes are added (through SMC calls
> > only). SATA, USB3H and PCIe modes are also supported one by one.
> >
> > There is one subtle difference with the PCIe functions: we must tell
> > the firmware the number of lanes to configure (x1, x2 or x4). This
> > parameter depends on the number of entries in the 'phys' property
> > describing the PCIe PHY. We use the "submode" parameter of the generic
> > PHY API to carry this value. The Armada-8k PCIe driver has been
> > updated to follow this idea and this change has been merged already:
> > http://patchwork.ozlabs.org/patch/1072763/
>
> Some of the patches are not applying cleanly. Care to resend the series after
> rebasing to phy -next?
Besides two conflicts that I can fix very easily about missing
of_node_put() calls, you just merged in phy-next this patch:
phy: marvell: phy-mvebu-cp110-comphy: implement RXAUI support
Which totally conflicts with my series while I also add RXAUI support
in patch 5. Please note that even the third version of my series
was contributed before this patch.
There is one difference to note though: in the patch from Matt Peland,
RXAUI support is embedded in the driver while I do SMC calls.
Anyway, would it be possible to change the order of application if
you want both methods in the driver because it will be much easier
to add Matt's patch on top of my series than the opposite. I can
even do it myself if you wish.
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v11 00/23] MT8183 IOMMU SUPPORT
From: Will Deacon @ 2019-08-24 11:57 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang,
srv_heupstream, Tomasz Figa, Joerg Roedel, linux-kernel,
Evan Green, chao.hao, iommu, Rob Herring, linux-mediatek,
Matthias Brugger, ming-fan.chen, anan.sun, Robin Murphy,
Matthias Kaehlcke, linux-arm-kernel
In-Reply-To: <1566615728-26388-1-git-send-email-yong.wu@mediatek.com>
On Sat, Aug 24, 2019 at 11:01:45AM +0800, Yong Wu wrote:
> This patchset mainly adds support for mt8183 IOMMU and SMI.
Thanks for persevering with this, and sorry it took me so long to get
to grips with the io-pgtable changes.
Joerg -- this is good for you to pick up from my side now, but if you run
into any fiddly conflicts with any of my other changes then I'm happy to
resolve them on a separate branch for you to pull.
Just let me know.
Cheers,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] arm64: Fixes for -rc6
From: Will Deacon @ 2019-08-24 12:12 UTC (permalink / raw)
To: torvalds
Cc: kvm, rkrcmar, marc.zyngier, catalin.marinas, linux-kernel,
pbonzini, kvmarm, linux-arm-kernel
Hi Linus,
Please pull these two KVM/arm fixes for -rc6. Unusually, we're routing them
via the arm64 tree as per Paolo's request on the list:
https://lore.kernel.org/kvm/21ae69a2-2546-29d0-bff6-2ea825e3d968@redhat.com/
We don't actually have any other arm64 fixes pending at the moment (touch
wood), so I've pulled from Marc, written a merge commit, tagged the
result and run it through my build/boot/bisect scripts.
Cheers,
Will
--->8
The following changes since commit d1abaeb3be7b5fa6d7a1fbbd2e14e3310005c4c1:
Linux 5.3-rc5 (2019-08-18 14:31:08 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes
for you to fetch changes up to 087eeea9adcbaef55ae8d68335dcd3820c5b344b:
Merge tag 'kvmarm-fixes-for-5.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into kvm/fixes (2019-08-24 12:46:30 +0100)
----------------------------------------------------------------
arm64 fixes for -rc6
- Two KVM fixes for MMIO emulation and UBSAN
----------------------------------------------------------------
Andre Przywara (1):
KVM: arm/arm64: VGIC: Properly initialise private IRQ affinity
Andrew Jones (1):
KVM: arm/arm64: Only skip MMIO insn once
Will Deacon (1):
Merge tag 'kvmarm-fixes-for-5.3-3' of git://git.kernel.org/.../kvmarm/kvmarm into kvm/fixes
virt/kvm/arm/mmio.c | 7 +++++++
virt/kvm/arm/vgic/vgic-init.c | 30 ++++++++++++++++++++----------
2 files changed, 27 insertions(+), 10 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
From: Jernej Škrabec @ 2019-08-24 12:32 UTC (permalink / raw)
To: linux-sunxi, megous
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, devicetree,
Maxime Ripard, linux-kernel, Chen-Yu Tsai, Rob Herring,
linux-arm-kernel, linux-rtc
In-Reply-To: <20190820151934.3860-3-megous@megous.com>
Hi!
Dne torek, 20. avgust 2019 ob 17:19:33 CEST je megous@megous.com napisal(a):
> From: Ondrej Jirman <megous@megous.com>
>
> RTC on H6 is mostly the same as on H5 and H3. It has slight differences
> mostly in features that are not yet supported by this driver.
>
> Some differences are already stated in the comments in existing code.
> One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
> EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
>
> It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
> external low speed oscillator is working correctly.
>
> This patch adds support for enabling LOSC when necessary:
>
> - during reparenting
> - when probing the clock
>
> H6 also has capacbility to automatically reparent RTC clock from
> external crystal oscillator, to internal RC oscillator, if external
> oscillator fails. This is enabled by default. Disable it during
> probe.
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> Reviewed-by: Chen-Yu Tsai <wens@csie.org>
> ---
> drivers/rtc/rtc-sun6i.c | 40 ++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> index d50ee023b559..b0c3752bed3f 100644
> --- a/drivers/rtc/rtc-sun6i.c
> +++ b/drivers/rtc/rtc-sun6i.c
> @@ -32,9 +32,11 @@
> /* Control register */
> #define SUN6I_LOSC_CTRL 0x0000
> #define SUN6I_LOSC_CTRL_KEY (0x16aa << 16)
> +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15)
User manual says that above field is bit 14.
Best regards,
Jernej
> #define SUN6I_LOSC_CTRL_ALM_DHMS_ACC BIT(9)
> #define SUN6I_LOSC_CTRL_RTC_HMS_ACC BIT(8)
> #define SUN6I_LOSC_CTRL_RTC_YMD_ACC BIT(7)
> +#define SUN6I_LOSC_CTRL_EXT_LOSC_EN BIT(4)
> #define SUN6I_LOSC_CTRL_EXT_OSC BIT(0)
> #define SUN6I_LOSC_CTRL_ACC_MASK GENMASK(9, 7)
>
> @@ -128,6 +130,8 @@ struct sun6i_rtc_clk_data {
> unsigned int has_prescaler : 1;
> unsigned int has_out_clk : 1;
> unsigned int export_iosc : 1;
> + unsigned int has_losc_en : 1;
> + unsigned int has_auto_swt : 1;
> };
>
> struct sun6i_rtc_dev {
> @@ -190,6 +194,10 @@ static int sun6i_rtc_osc_set_parent(struct clk_hw *hw,
> u8 index) val &= ~SUN6I_LOSC_CTRL_EXT_OSC;
> val |= SUN6I_LOSC_CTRL_KEY;
> val |= index ? SUN6I_LOSC_CTRL_EXT_OSC : 0;
> + if (rtc->data->has_losc_en) {
> + val &= ~SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> + val |= index ? SUN6I_LOSC_CTRL_EXT_LOSC_EN : 0;
> + }
> writel(val, rtc->base + SUN6I_LOSC_CTRL);
> spin_unlock_irqrestore(&rtc->lock, flags);
>
> @@ -215,6 +223,7 @@ static void __init sun6i_rtc_clk_init(struct device_node
> *node, const char *iosc_name = "rtc-int-osc";
> const char *clkout_name = "osc32k-out";
> const char *parents[2];
> + u32 reg;
>
> rtc = kzalloc(sizeof(*rtc), GFP_KERNEL);
> if (!rtc)
> @@ -235,9 +244,18 @@ static void __init sun6i_rtc_clk_init(struct
> device_node *node, goto err;
> }
>
> + reg = SUN6I_LOSC_CTRL_KEY;
> + if (rtc->data->has_auto_swt) {
> + /* Bypass auto-switch to int osc, on ext losc failure */
> + reg |= SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS;
> + writel(reg, rtc->base + SUN6I_LOSC_CTRL);
> + }
> +
> /* Switch to the external, more precise, oscillator */
> - writel(SUN6I_LOSC_CTRL_KEY | SUN6I_LOSC_CTRL_EXT_OSC,
> - rtc->base + SUN6I_LOSC_CTRL);
> + reg |= SUN6I_LOSC_CTRL_EXT_OSC;
> + if (rtc->data->has_losc_en)
> + reg |= SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> + writel(reg, rtc->base + SUN6I_LOSC_CTRL);
>
> /* Yes, I know, this is ugly. */
> sun6i_rtc = rtc;
> @@ -345,6 +363,23 @@ CLK_OF_DECLARE_DRIVER(sun8i_h3_rtc_clk,
> "allwinner,sun8i-h3-rtc", CLK_OF_DECLARE_DRIVER(sun50i_h5_rtc_clk,
> "allwinner,sun50i-h5-rtc", sun8i_h3_rtc_clk_init);
>
> +static const struct sun6i_rtc_clk_data sun50i_h6_rtc_data = {
> + .rc_osc_rate = 16000000,
> + .fixed_prescaler = 32,
> + .has_prescaler = 1,
> + .has_out_clk = 1,
> + .export_iosc = 1,
> + .has_losc_en = 1,
> + .has_auto_swt = 1,
> +};
> +
> +static void __init sun50i_h6_rtc_clk_init(struct device_node *node)
> +{
> + sun6i_rtc_clk_init(node, &sun50i_h6_rtc_data);
> +}
> +CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
> + sun50i_h6_rtc_clk_init);
> +
> static const struct sun6i_rtc_clk_data sun8i_v3_rtc_data = {
> .rc_osc_rate = 32000,
> .has_out_clk = 1,
> @@ -675,6 +710,7 @@ static const struct of_device_id sun6i_rtc_dt_ids[] = {
> { .compatible = "allwinner,sun8i-r40-rtc" },
> { .compatible = "allwinner,sun8i-v3-rtc" },
> { .compatible = "allwinner,sun50i-h5-rtc" },
> + { .compatible = "allwinner,sun50i-h6-rtc" },
> { /* sentinel */ },
> };
> MODULE_DEVICE_TABLE(of, sun6i_rtc_dt_ids);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next v3 1/3] net: ethernet: mediatek: Add basic PHYLINK support
From: René van Dorst @ 2019-08-24 12:33 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Nelson Chang, Frank Wunderlich, netdev, Sean Wang, linux-mips,
linux-mediatek, John Crispin, Matthias Brugger, Stefan Roese,
David S . Miller, linux-arm-kernel
In-Reply-To: <20190824091106.GC13294@shell.armlinux.org.uk>
Hi Russell,
Quoting Russell King - ARM Linux admin <linux@armlinux.org.uk>:
> On Fri, Aug 23, 2019 at 03:45:14PM +0200, René van Dorst wrote:
>> This convert the basics to PHYLINK API.
>> SGMII support is not in this patch.
>>
>> Signed-off-by: René van Dorst <opensource@vdorst.com>
>> --
>> v2->v3:
>> * Make link_down() similar as link_up() suggested by Russell King
>
> Yep, almost there, but...
>
>> +static void mtk_mac_link_down(struct phylink_config *config,
>> unsigned int mode,
>> + phy_interface_t interface)
>> +{
>> + struct mtk_mac *mac = container_of(config, struct mtk_mac,
>> + phylink_config);
>> + u32 mcr = mtk_r32(mac->hw, MTK_MAC_MCR(mac->id));
>>
>> + mcr &= (MAC_MCR_TX_EN | MAC_MCR_RX_EN);
>
> ... this clears all bits _except_ for the tx and rx enable (which will
> remain set) - you probably wanted a ~ before the (.
Yes that is what it should be.
I only want to clear the TX_EN en RX_EN bits.
Greats,
René
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
From: Ondřej Jirman @ 2019-08-24 12:46 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, devicetree,
Maxime Ripard, linux-kernel, linux-sunxi, Rob Herring,
Chen-Yu Tsai, linux-arm-kernel, linux-rtc
In-Reply-To: <10586215.O0B29uHg7A@jernej-laptop>
Hi,
On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote:
> Hi!
>
> Dne torek, 20. avgust 2019 ob 17:19:33 CEST je megous@megous.com napisal(a):
> > From: Ondrej Jirman <megous@megous.com>
> >
> > RTC on H6 is mostly the same as on H5 and H3. It has slight differences
> > mostly in features that are not yet supported by this driver.
> >
> > Some differences are already stated in the comments in existing code.
> > One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
> > EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
> >
> > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
> > external low speed oscillator is working correctly.
> >
> > This patch adds support for enabling LOSC when necessary:
> >
> > - during reparenting
> > - when probing the clock
> >
> > H6 also has capacbility to automatically reparent RTC clock from
> > external crystal oscillator, to internal RC oscillator, if external
> > oscillator fails. This is enabled by default. Disable it during
> > probe.
> >
> > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > Reviewed-by: Chen-Yu Tsai <wens@csie.org>
> > ---
> > drivers/rtc/rtc-sun6i.c | 40 ++++++++++++++++++++++++++++++++++++++--
> > 1 file changed, 38 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > index d50ee023b559..b0c3752bed3f 100644
> > --- a/drivers/rtc/rtc-sun6i.c
> > +++ b/drivers/rtc/rtc-sun6i.c
> > @@ -32,9 +32,11 @@
> > /* Control register */
> > #define SUN6I_LOSC_CTRL 0x0000
> > #define SUN6I_LOSC_CTRL_KEY (0x16aa << 16)
> > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15)
>
> User manual says that above field is bit 14.
See the previous discussion, this is from BSP.
regards,
o.
> Best regards,
> Jernej
>
> > #define SUN6I_LOSC_CTRL_ALM_DHMS_ACC BIT(9)
> > #define SUN6I_LOSC_CTRL_RTC_HMS_ACC BIT(8)
> > #define SUN6I_LOSC_CTRL_RTC_YMD_ACC BIT(7)
> > +#define SUN6I_LOSC_CTRL_EXT_LOSC_EN BIT(4)
> > #define SUN6I_LOSC_CTRL_EXT_OSC BIT(0)
> > #define SUN6I_LOSC_CTRL_ACC_MASK GENMASK(9, 7)
> >
> > @@ -128,6 +130,8 @@ struct sun6i_rtc_clk_data {
> > unsigned int has_prescaler : 1;
> > unsigned int has_out_clk : 1;
> > unsigned int export_iosc : 1;
> > + unsigned int has_losc_en : 1;
> > + unsigned int has_auto_swt : 1;
> > };
> >
> > struct sun6i_rtc_dev {
> > @@ -190,6 +194,10 @@ static int sun6i_rtc_osc_set_parent(struct clk_hw *hw,
> > u8 index) val &= ~SUN6I_LOSC_CTRL_EXT_OSC;
> > val |= SUN6I_LOSC_CTRL_KEY;
> > val |= index ? SUN6I_LOSC_CTRL_EXT_OSC : 0;
> > + if (rtc->data->has_losc_en) {
> > + val &= ~SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> > + val |= index ? SUN6I_LOSC_CTRL_EXT_LOSC_EN : 0;
> > + }
> > writel(val, rtc->base + SUN6I_LOSC_CTRL);
> > spin_unlock_irqrestore(&rtc->lock, flags);
> >
> > @@ -215,6 +223,7 @@ static void __init sun6i_rtc_clk_init(struct device_node
> > *node, const char *iosc_name = "rtc-int-osc";
> > const char *clkout_name = "osc32k-out";
> > const char *parents[2];
> > + u32 reg;
> >
> > rtc = kzalloc(sizeof(*rtc), GFP_KERNEL);
> > if (!rtc)
> > @@ -235,9 +244,18 @@ static void __init sun6i_rtc_clk_init(struct
> > device_node *node, goto err;
> > }
> >
> > + reg = SUN6I_LOSC_CTRL_KEY;
> > + if (rtc->data->has_auto_swt) {
> > + /* Bypass auto-switch to int osc, on ext losc failure */
> > + reg |= SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS;
> > + writel(reg, rtc->base + SUN6I_LOSC_CTRL);
> > + }
> > +
> > /* Switch to the external, more precise, oscillator */
> > - writel(SUN6I_LOSC_CTRL_KEY | SUN6I_LOSC_CTRL_EXT_OSC,
> > - rtc->base + SUN6I_LOSC_CTRL);
> > + reg |= SUN6I_LOSC_CTRL_EXT_OSC;
> > + if (rtc->data->has_losc_en)
> > + reg |= SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> > + writel(reg, rtc->base + SUN6I_LOSC_CTRL);
> >
> > /* Yes, I know, this is ugly. */
> > sun6i_rtc = rtc;
> > @@ -345,6 +363,23 @@ CLK_OF_DECLARE_DRIVER(sun8i_h3_rtc_clk,
> > "allwinner,sun8i-h3-rtc", CLK_OF_DECLARE_DRIVER(sun50i_h5_rtc_clk,
> > "allwinner,sun50i-h5-rtc", sun8i_h3_rtc_clk_init);
> >
> > +static const struct sun6i_rtc_clk_data sun50i_h6_rtc_data = {
> > + .rc_osc_rate = 16000000,
> > + .fixed_prescaler = 32,
> > + .has_prescaler = 1,
> > + .has_out_clk = 1,
> > + .export_iosc = 1,
> > + .has_losc_en = 1,
> > + .has_auto_swt = 1,
> > +};
> > +
> > +static void __init sun50i_h6_rtc_clk_init(struct device_node *node)
> > +{
> > + sun6i_rtc_clk_init(node, &sun50i_h6_rtc_data);
> > +}
> > +CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
> > + sun50i_h6_rtc_clk_init);
> > +
> > static const struct sun6i_rtc_clk_data sun8i_v3_rtc_data = {
> > .rc_osc_rate = 32000,
> > .has_out_clk = 1,
> > @@ -675,6 +710,7 @@ static const struct of_device_id sun6i_rtc_dt_ids[] = {
> > { .compatible = "allwinner,sun8i-r40-rtc" },
> > { .compatible = "allwinner,sun8i-v3-rtc" },
> > { .compatible = "allwinner,sun50i-h5-rtc" },
> > + { .compatible = "allwinner,sun50i-h6-rtc" },
> > { /* sentinel */ },
> > };
> > MODULE_DEVICE_TABLE(of, sun6i_rtc_dt_ids);
>
>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 12/16] arm64: prefer __section from compiler_attributes.h
From: Miguel Ojeda @ 2019-08-24 12:48 UTC (permalink / raw)
To: Will Deacon
Cc: Song Liu, Catalin Marinas, Alexei Starovoitov, Daniel Borkmann,
clang-built-linux, Allison Randal, Yonghong Song,
Masayoshi Mizuma, Suzuki K Poulose, Andrey Konovalov,
Shaokun Zhang, Alexios Zavras, Josh Poimboeuf, Sedat Dilek,
Thomas Gleixner, bpf, Linux ARM, Greg Kroah-Hartman,
Nick Desaulniers, linux-kernel, Network Development,
Andrew Morton, Enrico Weigelt, Martin KaFai Lau
In-Reply-To: <20190824112542.7guulvdenm35ihs7@willie-the-truck>
On Sat, Aug 24, 2019 at 1:25 PM Will Deacon <will@kernel.org> wrote:
>
> Which bit are you pinging about? This patch (12/16) has been in -next for a
> while and is queued in the arm64 tree for 5.4. The Oops/boot issue is
> addressed in patch 14 which probably needs to be sent as a separate patch
> (with a commit message) if it's targetting 5.3 and, I assume, routed via
> somebody like akpm.
I was pinging about the bit I was quoting, i.e. whether the Oops in
the cover letter was #14 indeed. Also, since Nick said he wanted to
get this ASAP through compiler-attributes, I assumed he wanted it to
be in 5.3, but I have not seen the independent patch.
Since he seems busy, I will write a better commit message myself and
send it to Linus next week.
Cheers,
Miguel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
From: Jernej Škrabec @ 2019-08-24 12:51 UTC (permalink / raw)
To: linux-sunxi, megous
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, devicetree,
Maxime Ripard, linux-kernel, Chen-Yu Tsai, Rob Herring,
linux-arm-kernel, linux-rtc
In-Reply-To: <20190824124654.nqtlkam2gsaqsj77@core.my.home>
Dne sobota, 24. avgust 2019 ob 14:46:54 CEST je Ondřej Jirman napisal(a):
> Hi,
>
> On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote:
> > Hi!
> >
> > Dne torek, 20. avgust 2019 ob 17:19:33 CEST je megous@megous.com
napisal(a):
> > > From: Ondrej Jirman <megous@megous.com>
> > >
> > > RTC on H6 is mostly the same as on H5 and H3. It has slight differences
> > > mostly in features that are not yet supported by this driver.
> > >
> > > Some differences are already stated in the comments in existing code.
> > > One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
> > > EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
> > >
> > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
> > > external low speed oscillator is working correctly.
> > >
> > > This patch adds support for enabling LOSC when necessary:
> > >
> > > - during reparenting
> > > - when probing the clock
> > >
> > > H6 also has capacbility to automatically reparent RTC clock from
> > > external crystal oscillator, to internal RC oscillator, if external
> > > oscillator fails. This is enabled by default. Disable it during
> > > probe.
> > >
> > > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > > Reviewed-by: Chen-Yu Tsai <wens@csie.org>
> > > ---
> > >
> > > drivers/rtc/rtc-sun6i.c | 40 ++++++++++++++++++++++++++++++++++++++--
> > > 1 file changed, 38 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > > index d50ee023b559..b0c3752bed3f 100644
> > > --- a/drivers/rtc/rtc-sun6i.c
> > > +++ b/drivers/rtc/rtc-sun6i.c
> > > @@ -32,9 +32,11 @@
> > >
> > > /* Control register */
> > > #define SUN6I_LOSC_CTRL 0x0000
> > > #define SUN6I_LOSC_CTRL_KEY (0x16aa << 16)
> > >
> > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15)
> >
> > User manual says that above field is bit 14.
>
> See the previous discussion, this is from BSP.
I have two versions of BSP (don't ask me which) which have this set as bit 14
and changing this to 14 actually solves all my problems with LOSC (no more
issues with setting RTC and HDMI-CEC works now - it uses LOSC as parent) on
Tanix TX6 box.
Best regards,
Jernej
>
> regards,
> o.
>
> > Best regards,
> > Jernej
> >
> > > #define SUN6I_LOSC_CTRL_ALM_DHMS_ACC BIT(9)
> > > #define SUN6I_LOSC_CTRL_RTC_HMS_ACC BIT(8)
> > > #define SUN6I_LOSC_CTRL_RTC_YMD_ACC BIT(7)
> > >
> > > +#define SUN6I_LOSC_CTRL_EXT_LOSC_EN BIT(4)
> > >
> > > #define SUN6I_LOSC_CTRL_EXT_OSC BIT(0)
> > > #define SUN6I_LOSC_CTRL_ACC_MASK GENMASK(9, 7)
> > >
> > > @@ -128,6 +130,8 @@ struct sun6i_rtc_clk_data {
> > >
> > > unsigned int has_prescaler : 1;
> > > unsigned int has_out_clk : 1;
> > > unsigned int export_iosc : 1;
> > >
> > > + unsigned int has_losc_en : 1;
> > > + unsigned int has_auto_swt : 1;
> > >
> > > };
> > >
> > > struct sun6i_rtc_dev {
> > >
> > > @@ -190,6 +194,10 @@ static int sun6i_rtc_osc_set_parent(struct clk_hw
> > > *hw,
> > > u8 index) val &= ~SUN6I_LOSC_CTRL_EXT_OSC;
> > >
> > > val |= SUN6I_LOSC_CTRL_KEY;
> > > val |= index ? SUN6I_LOSC_CTRL_EXT_OSC : 0;
> > >
> > > + if (rtc->data->has_losc_en) {
> > > + val &= ~SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> > > + val |= index ? SUN6I_LOSC_CTRL_EXT_LOSC_EN : 0;
> > > + }
> > >
> > > writel(val, rtc->base + SUN6I_LOSC_CTRL);
> > > spin_unlock_irqrestore(&rtc->lock, flags);
> > >
> > > @@ -215,6 +223,7 @@ static void __init sun6i_rtc_clk_init(struct
> > > device_node *node, const char *iosc_name = "rtc-int-osc";
> > >
> > > const char *clkout_name = "osc32k-out";
> > > const char *parents[2];
> > >
> > > + u32 reg;
> > >
> > > rtc = kzalloc(sizeof(*rtc), GFP_KERNEL);
> > > if (!rtc)
> > >
> > > @@ -235,9 +244,18 @@ static void __init sun6i_rtc_clk_init(struct
> > > device_node *node, goto err;
> > >
> > > }
> > >
> > > + reg = SUN6I_LOSC_CTRL_KEY;
> > > + if (rtc->data->has_auto_swt) {
> > > + /* Bypass auto-switch to int osc, on ext losc failure
*/
> > > + reg |= SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS;
> > > + writel(reg, rtc->base + SUN6I_LOSC_CTRL);
> > > + }
> > > +
> > >
> > > /* Switch to the external, more precise, oscillator */
> > >
> > > - writel(SUN6I_LOSC_CTRL_KEY | SUN6I_LOSC_CTRL_EXT_OSC,
> > > - rtc->base + SUN6I_LOSC_CTRL);
> > > + reg |= SUN6I_LOSC_CTRL_EXT_OSC;
> > > + if (rtc->data->has_losc_en)
> > > + reg |= SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> > > + writel(reg, rtc->base + SUN6I_LOSC_CTRL);
> > >
> > > /* Yes, I know, this is ugly. */
> > > sun6i_rtc = rtc;
> > >
> > > @@ -345,6 +363,23 @@ CLK_OF_DECLARE_DRIVER(sun8i_h3_rtc_clk,
> > > "allwinner,sun8i-h3-rtc", CLK_OF_DECLARE_DRIVER(sun50i_h5_rtc_clk,
> > > "allwinner,sun50i-h5-rtc", sun8i_h3_rtc_clk_init);
> > >
> > > +static const struct sun6i_rtc_clk_data sun50i_h6_rtc_data = {
> > > + .rc_osc_rate = 16000000,
> > > + .fixed_prescaler = 32,
> > > + .has_prescaler = 1,
> > > + .has_out_clk = 1,
> > > + .export_iosc = 1,
> > > + .has_losc_en = 1,
> > > + .has_auto_swt = 1,
> > > +};
> > > +
> > > +static void __init sun50i_h6_rtc_clk_init(struct device_node *node)
> > > +{
> > > + sun6i_rtc_clk_init(node, &sun50i_h6_rtc_data);
> > > +}
> > > +CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
> > > + sun50i_h6_rtc_clk_init);
> > > +
> > >
> > > static const struct sun6i_rtc_clk_data sun8i_v3_rtc_data = {
> > >
> > > .rc_osc_rate = 32000,
> > > .has_out_clk = 1,
> > >
> > > @@ -675,6 +710,7 @@ static const struct of_device_id sun6i_rtc_dt_ids[]
> > > = {
> > >
> > > { .compatible = "allwinner,sun8i-r40-rtc" },
> > > { .compatible = "allwinner,sun8i-v3-rtc" },
> > > { .compatible = "allwinner,sun50i-h5-rtc" },
> > >
> > > + { .compatible = "allwinner,sun50i-h6-rtc" },
> > >
> > > { /* sentinel */ },
> > >
> > > };
> > > MODULE_DEVICE_TABLE(of, sun6i_rtc_dt_ids);
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v2 0/3] Add basic support for RTC on Allwinner H6 SoC
From: Ondřej Jirman @ 2019-08-24 12:56 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, devicetree,
Maxime Ripard, linux-kernel, linux-sunxi, Rob Herring,
Chen-Yu Tsai, linux-arm-kernel, linux-rtc
In-Reply-To: <5421621.t8Lore9UF7@jernej-laptop>
Hi,
On Sat, Aug 24, 2019 at 10:06:14AM +0200, Jernej Škrabec wrote:
> Dne sobota, 24. avgust 2019 ob 10:04:24 CEST je Jernej Škrabec napisal(a):
> > Hi!
> >
> > Dne torek, 20. avgust 2019 ob 17:19:31 CEST je megous@megous.com napisal(a):
> > > From: Ondrej Jirman <megous@megous.com>
> > >
> > > I went through the datasheets for H6 and H5, and compared the differences.
> > > RTCs are largely similar, but not entirely compatible. Incompatibilities
> > > are in details not yet implemented by the rtc driver though.
> > >
> > > I also corrected the clock tree in H6 DTSI.
> > >
> > > This patchset is necessary for implementing the WiFi/Bluetooth support
> > > on boards using H6 SoC.
> > >
> > > There was some discussion previously of describing HOSC, DCXO and XO
> > > oscillators and clocks as part of RTC in DT, but I decided against it
> > > because it's not necessary, becuse information that would be provided
> > > as a part of DT can already be determined at runtime from RTC registers,
> > > so this woudn't add any value and would only introduce complications
> > > to the driver. See: https://patchwork.kernel.org/cover/10898083/
> > >
> > > Please take a look.
> > >
> > >
> > > Thank you and regards,
> > >
> > > Ondrej Jirman
> >
> > Sorry for a bit late test, but with your patches on Tanix TX6 box I get this
> > in dmesg:
> >
> > [ 17.431742] sun6i-rtc 7000000.rtc: Failed to set rtc time.
> > [ 20.439742] sun6i-rtc 7000000.rtc: rtc is still busy.
> > [ 21.435744] sun6i-rtc 7000000.rtc: rtc is still busy.
> > [ 24.055741] sun6i-rtc 7000000.rtc: rtc is still busy.
> > [ 24.439752] sun6i-rtc 7000000.rtc: rtc is still busy.
> >
> > Last line is repeated non-stop.
> >
> > Any idea what could be wrong?
>
> Additional info - this is on kernel 5.2.6 with your patches applied.
Do you have schematics, or a FEX file for the board or any other info on how the
RTC is set up on that board?
Can you dump the RTC register range?
regards,
o.
> Best regards,
> Jernej
>
>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v2 0/3] Add basic support for RTC on Allwinner H6 SoC
From: Jernej Škrabec @ 2019-08-24 12:58 UTC (permalink / raw)
To: linux-sunxi, megous
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, devicetree,
Maxime Ripard, linux-kernel, Chen-Yu Tsai, Rob Herring,
linux-arm-kernel, linux-rtc
In-Reply-To: <20190824125612.zq5qsay2wv62wykt@core.my.home>
Dne sobota, 24. avgust 2019 ob 14:56:12 CEST je Ondřej Jirman napisal(a):
> Hi,
>
> On Sat, Aug 24, 2019 at 10:06:14AM +0200, Jernej Škrabec wrote:
> > Dne sobota, 24. avgust 2019 ob 10:04:24 CEST je Jernej Škrabec napisal(a):
> > > Hi!
> > >
> > > Dne torek, 20. avgust 2019 ob 17:19:31 CEST je megous@megous.com
napisal(a):
> > > > From: Ondrej Jirman <megous@megous.com>
> > > >
> > > > I went through the datasheets for H6 and H5, and compared the
> > > > differences.
> > > > RTCs are largely similar, but not entirely compatible.
> > > > Incompatibilities
> > > > are in details not yet implemented by the rtc driver though.
> > > >
> > > > I also corrected the clock tree in H6 DTSI.
> > > >
> > > > This patchset is necessary for implementing the WiFi/Bluetooth support
> > > > on boards using H6 SoC.
> > > >
> > > > There was some discussion previously of describing HOSC, DCXO and XO
> > > > oscillators and clocks as part of RTC in DT, but I decided against it
> > > > because it's not necessary, becuse information that would be provided
> > > > as a part of DT can already be determined at runtime from RTC
> > > > registers,
> > > > so this woudn't add any value and would only introduce complications
> > > > to the driver. See: https://patchwork.kernel.org/cover/10898083/
> > > >
> > > > Please take a look.
> > > >
> > > >
> > > > Thank you and regards,
> > > >
> > > > Ondrej Jirman
> > >
> > > Sorry for a bit late test, but with your patches on Tanix TX6 box I get
> > > this in dmesg:
> > >
> > > [ 17.431742] sun6i-rtc 7000000.rtc: Failed to set rtc time.
> > > [ 20.439742] sun6i-rtc 7000000.rtc: rtc is still busy.
> > > [ 21.435744] sun6i-rtc 7000000.rtc: rtc is still busy.
> > > [ 24.055741] sun6i-rtc 7000000.rtc: rtc is still busy.
> > > [ 24.439752] sun6i-rtc 7000000.rtc: rtc is still busy.
> > >
> > > Last line is repeated non-stop.
> > >
> > > Any idea what could be wrong?
> >
> > Additional info - this is on kernel 5.2.6 with your patches applied.
>
> Do you have schematics, or a FEX file for the board or any other info on how
> the RTC is set up on that board?
>
> Can you dump the RTC register range?
I have only Android DT, but as I already said in latest reply to patch 2,
changing switch bypass to bit 14 instead of 15 solved all issues.
Best regards,
Jernej
>
> regards,
> o.
>
> > Best regards,
> > Jernej
> >
> >
> >
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
From: Ondřej Jirman @ 2019-08-24 13:05 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, devicetree,
Maxime Ripard, linux-kernel, linux-sunxi, Rob Herring,
Chen-Yu Tsai, linux-arm-kernel, linux-rtc
In-Reply-To: <2544007.NTLiB2pbcT@jernej-laptop>
On Sat, Aug 24, 2019 at 02:51:54PM +0200, Jernej Škrabec wrote:
> Dne sobota, 24. avgust 2019 ob 14:46:54 CEST je Ondřej Jirman napisal(a):
> > Hi,
> >
> > On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote:
> > > Hi!
> > >
> > > Dne torek, 20. avgust 2019 ob 17:19:33 CEST je megous@megous.com
> napisal(a):
> > > > From: Ondrej Jirman <megous@megous.com>
> > > >
> > > > RTC on H6 is mostly the same as on H5 and H3. It has slight differences
> > > > mostly in features that are not yet supported by this driver.
> > > >
> > > > Some differences are already stated in the comments in existing code.
> > > > One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
> > > > EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
> > > >
> > > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
> > > > external low speed oscillator is working correctly.
> > > >
> > > > This patch adds support for enabling LOSC when necessary:
> > > >
> > > > - during reparenting
> > > > - when probing the clock
> > > >
> > > > H6 also has capacbility to automatically reparent RTC clock from
> > > > external crystal oscillator, to internal RC oscillator, if external
> > > > oscillator fails. This is enabled by default. Disable it during
> > > > probe.
> > > >
> > > > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > > > Reviewed-by: Chen-Yu Tsai <wens@csie.org>
> > > > ---
> > > >
> > > > drivers/rtc/rtc-sun6i.c | 40 ++++++++++++++++++++++++++++++++++++++--
> > > > 1 file changed, 38 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > > > index d50ee023b559..b0c3752bed3f 100644
> > > > --- a/drivers/rtc/rtc-sun6i.c
> > > > +++ b/drivers/rtc/rtc-sun6i.c
> > > > @@ -32,9 +32,11 @@
> > > >
> > > > /* Control register */
> > > > #define SUN6I_LOSC_CTRL 0x0000
> > > > #define SUN6I_LOSC_CTRL_KEY (0x16aa << 16)
> > > >
> > > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15)
> > >
> > > User manual says that above field is bit 14.
> >
> > See the previous discussion, this is from BSP.
>
> I have two versions of BSP (don't ask me which) which have this set as bit 14
> and changing this to 14 actually solves all my problems with LOSC (no more
> issues with setting RTC and HDMI-CEC works now - it uses LOSC as parent) on
> Tanix TX6 box.
Interesting. Is LOSC fed externally generated clock, or is it setup as a crystal
oscillator on your board?
Anyway, see here:
https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.h?h=h6-4.9-bsp#n649
https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n652
It would be nice to know what's really happening.
My output is:
[ 0.832252] sun6i-rtc 7000000.rtc: registered as rtc0
[ 0.832257] sun6i-rtc 7000000.rtc: RTC enabled
[ 1.728968] sun6i-rtc 7000000.rtc: setting system clock to 1970-01-01T00:00:07 UTC (7)
I think, you may have just enabled the auto switch feature, and running the
clock from low precision RC oscillator with your patch.
The real issue probably is that the mainline driver is missing this:
https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n650
regards,
o.
> Best regards,
> Jernej
>
> >
> > regards,
> > o.
> >
> > > Best regards,
> > > Jernej
> > >
> > > > #define SUN6I_LOSC_CTRL_ALM_DHMS_ACC BIT(9)
> > > > #define SUN6I_LOSC_CTRL_RTC_HMS_ACC BIT(8)
> > > > #define SUN6I_LOSC_CTRL_RTC_YMD_ACC BIT(7)
> > > >
> > > > +#define SUN6I_LOSC_CTRL_EXT_LOSC_EN BIT(4)
> > > >
> > > > #define SUN6I_LOSC_CTRL_EXT_OSC BIT(0)
> > > > #define SUN6I_LOSC_CTRL_ACC_MASK GENMASK(9, 7)
> > > >
> > > > @@ -128,6 +130,8 @@ struct sun6i_rtc_clk_data {
> > > >
> > > > unsigned int has_prescaler : 1;
> > > > unsigned int has_out_clk : 1;
> > > > unsigned int export_iosc : 1;
> > > >
> > > > + unsigned int has_losc_en : 1;
> > > > + unsigned int has_auto_swt : 1;
> > > >
> > > > };
> > > >
> > > > struct sun6i_rtc_dev {
> > > >
> > > > @@ -190,6 +194,10 @@ static int sun6i_rtc_osc_set_parent(struct clk_hw
> > > > *hw,
> > > > u8 index) val &= ~SUN6I_LOSC_CTRL_EXT_OSC;
> > > >
> > > > val |= SUN6I_LOSC_CTRL_KEY;
> > > > val |= index ? SUN6I_LOSC_CTRL_EXT_OSC : 0;
> > > >
> > > > + if (rtc->data->has_losc_en) {
> > > > + val &= ~SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> > > > + val |= index ? SUN6I_LOSC_CTRL_EXT_LOSC_EN : 0;
> > > > + }
> > > >
> > > > writel(val, rtc->base + SUN6I_LOSC_CTRL);
> > > > spin_unlock_irqrestore(&rtc->lock, flags);
> > > >
> > > > @@ -215,6 +223,7 @@ static void __init sun6i_rtc_clk_init(struct
> > > > device_node *node, const char *iosc_name = "rtc-int-osc";
> > > >
> > > > const char *clkout_name = "osc32k-out";
> > > > const char *parents[2];
> > > >
> > > > + u32 reg;
> > > >
> > > > rtc = kzalloc(sizeof(*rtc), GFP_KERNEL);
> > > > if (!rtc)
> > > >
> > > > @@ -235,9 +244,18 @@ static void __init sun6i_rtc_clk_init(struct
> > > > device_node *node, goto err;
> > > >
> > > > }
> > > >
> > > > + reg = SUN6I_LOSC_CTRL_KEY;
> > > > + if (rtc->data->has_auto_swt) {
> > > > + /* Bypass auto-switch to int osc, on ext losc failure
> */
> > > > + reg |= SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS;
> > > > + writel(reg, rtc->base + SUN6I_LOSC_CTRL);
> > > > + }
> > > > +
> > > >
> > > > /* Switch to the external, more precise, oscillator */
> > > >
> > > > - writel(SUN6I_LOSC_CTRL_KEY | SUN6I_LOSC_CTRL_EXT_OSC,
> > > > - rtc->base + SUN6I_LOSC_CTRL);
> > > > + reg |= SUN6I_LOSC_CTRL_EXT_OSC;
> > > > + if (rtc->data->has_losc_en)
> > > > + reg |= SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> > > > + writel(reg, rtc->base + SUN6I_LOSC_CTRL);
> > > >
> > > > /* Yes, I know, this is ugly. */
> > > > sun6i_rtc = rtc;
> > > >
> > > > @@ -345,6 +363,23 @@ CLK_OF_DECLARE_DRIVER(sun8i_h3_rtc_clk,
> > > > "allwinner,sun8i-h3-rtc", CLK_OF_DECLARE_DRIVER(sun50i_h5_rtc_clk,
> > > > "allwinner,sun50i-h5-rtc", sun8i_h3_rtc_clk_init);
> > > >
> > > > +static const struct sun6i_rtc_clk_data sun50i_h6_rtc_data = {
> > > > + .rc_osc_rate = 16000000,
> > > > + .fixed_prescaler = 32,
> > > > + .has_prescaler = 1,
> > > > + .has_out_clk = 1,
> > > > + .export_iosc = 1,
> > > > + .has_losc_en = 1,
> > > > + .has_auto_swt = 1,
> > > > +};
> > > > +
> > > > +static void __init sun50i_h6_rtc_clk_init(struct device_node *node)
> > > > +{
> > > > + sun6i_rtc_clk_init(node, &sun50i_h6_rtc_data);
> > > > +}
> > > > +CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
> > > > + sun50i_h6_rtc_clk_init);
> > > > +
> > > >
> > > > static const struct sun6i_rtc_clk_data sun8i_v3_rtc_data = {
> > > >
> > > > .rc_osc_rate = 32000,
> > > > .has_out_clk = 1,
> > > >
> > > > @@ -675,6 +710,7 @@ static const struct of_device_id sun6i_rtc_dt_ids[]
> > > > = {
> > > >
> > > > { .compatible = "allwinner,sun8i-r40-rtc" },
> > > > { .compatible = "allwinner,sun8i-v3-rtc" },
> > > > { .compatible = "allwinner,sun50i-h5-rtc" },
> > > >
> > > > + { .compatible = "allwinner,sun50i-h6-rtc" },
> > > >
> > > > { /* sentinel */ },
> > > >
> > > > };
> > > > MODULE_DEVICE_TABLE(of, sun6i_rtc_dt_ids);
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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