* Re: [PATCH v7 5/7] drivers/i2c: Add transfer implementation for FSI algorithm
From: Eddie James @ 2018-05-30 20:53 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-i2c, Linux Kernel Mailing List, devicetree, Wolfram Sang,
Rob Herring, Benjamin Herrenschmidt, Joel Stanley, Mark Rutland,
Greg Kroah-Hartman, Edward A. James
In-Reply-To: <CAHp75Vch1uEVvXadVR68tsDY-51=U+7FGr=5k0N5QtpcXpE_3A@mail.gmail.com>
On 05/29/2018 07:08 PM, Andy Shevchenko wrote:
> On Wed, May 30, 2018 at 1:24 AM, Eddie James <eajames@linux.vnet.ibm.com> wrote:
>> From: "Edward A. James" <eajames@us.ibm.com>
>>
>> Execute I2C transfers from the FSI-attached I2C master. Use polling
>> instead of interrupts as we have no hardware IRQ over FSI.
>> + if (msg->flags & I2C_M_RD)
>> + cmd |= I2C_CMD_READ;
> I think we have a helper for this, though not sure.
Didn't see any other I2C drivers using any helper for msg->flags.
>
>> +static int fsi_i2c_write_fifo(struct fsi_i2c_port *port, struct i2c_msg *msg,
>> + u8 fifo_count)
>> +{
>> + int write;
>> + int rc = 0;
> Redundant assignment.
>
>> + struct fsi_i2c_master *i2c = port->master;
>> + int bytes_to_write = i2c->fifo_size - fifo_count;
>> + int bytes_remaining = msg->len - port->xfrd;
>> + if (bytes_to_write > bytes_remaining)
>> + bytes_to_write = bytes_remaining;
> _write = min(_write, _remaining);
>
>> + while (bytes_to_write > 0) {
>> + write = bytes_to_write;
>> + /* fsi limited to max 4 byte aligned ops */
>> + if (bytes_to_write > 4)
>> + write = 4;
>> + else if (write == 3)
>> + write = 2;
> write = min_t(int, 4, rounddown_pow_of_two(bytes_to_write));
>
> Also check it carefully, it might be optimized even more, though I
> didn't think much.
I think it is more readable this way, and I'm not convinced the
min(rounddown()) is faster. I did however add a common function to do
this check since it's performed in both the read and write fifo
functions. Let me know what you think on v8.
Thanks,
Eddie
^ permalink raw reply
* Re: [PATCH v7 5/5] clk: renesas: Renesas R9A06G032 clock driver
From: Geert Uytterhoeven @ 2018-05-30 19:49 UTC (permalink / raw)
To: Michel Pollet
Cc: Linux-Renesas, Simon Horman, Phil Edworthy, Michel Pollet,
Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
Geert Uytterhoeven, linux-clk,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List
In-Reply-To: <1527154169-32380-6-git-send-email-michel.pollet@bp.renesas.com>
Hi Michel,
On Thu, May 24, 2018 at 11:28 AM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> This provides a clock driver for the Renesas R09A06G032.
> This uses a structure derived from both the RCAR gen2 driver as well as
> the renesas-cpg-mssr driver.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Thanks for your patch!
> --- /dev/null
> +++ b/drivers/clk/renesas/r9a06g032-clocks.c
> +/* register/bit pairs are encoded as an uint16_t */
> +static void clk_rdesc_set(
> + struct r9a06g032_priv *clocks,
> + uint16_t one, unsigned int on)
> +{
> + u32 __iomem *reg = ((u32 __iomem *)clocks->reg) + (one >> 5);
Do you need the cast? Gcc does support void pointer arithmetic, and treats
that like byte pointers.
> + u32 val = clk_readl(reg);
> +
> + val = (val & ~(1U << (one & 0x1f))) | ((!!on) << (one & 0x1f));
> + clk_writel(val, reg);
Hence
clk_writel(val, clocks->reg + 4 * (one >> 5));
Actually clk_{read,write}l() are deprecated, please use {read,write}l() instead.
> +static void r9a06g032_clk_gate_disable(struct clk_hw *hw)
> +{
> + struct r9a06g032_clk_gate *g = to_r9a06g032_gate(hw);
> +
> + if (!g->read_only)
> + r9a06g032_clk_gate_set(g->clocks, &g->gate, 0);
> + else
> + pr_debug("%s %s: disallowed\n", __func__,
> + __clk_get_name(hw->clk));
You can print the name of a clock using %pC:
pr_debug("%s %pC: disallowed\n", __func__, hw->clk);
But I don't think you need the check, cfr. below.
> +static struct clk *r9a06g032_register_gate(
> + struct r9a06g032_priv *clocks,
> + const char *parent_name,
> + const struct r9a06g032_clkdesc *desc)
> +{
> + struct clk *clk;
> + struct r9a06g032_clk_gate *g;
> + struct clk_init_data init;
> +
> + g = kzalloc(sizeof(struct r9a06g032_clk_gate), GFP_KERNEL);
> + if (!g)
> + return NULL;
> +
> + init.name = desc->name;
> + init.ops = &r9a06g032_clk_gate_ops;
> + init.flags = CLK_IS_BASIC | CLK_SET_RATE_PARENT;
> + init.parent_names = parent_name ? &parent_name : NULL;
> + init.num_parents = parent_name ? 1 : 0;
> +
> + g->clocks = clocks;
> + g->index = desc->index;
> + g->gate = desc->gate;
> + g->hw.init = &init;
> + g->read_only = 0;
> +
> + clk = clk_register(NULL, &g->hw);
> + if (IS_ERR(clk)) {
> + kfree(g);
> + return NULL;
> + }
> + /*
> + * important here, some clocks are already in use by the CM3, we
> + * have to assume they are not Linux's to play with and try to disable
> + * at the end of the boot!
> + * Therefore we increase the clock usage count by arbitrarily enabling
> + * the clock, allowing it to stay untouched at the end of the boot.
> + */
> + g->read_only = r9a06g032_clk_gate_is_enabled(&g->hw);
Is checking if the clock is enabled the recommended way to find out if a
clock is used by the Cortex M3? No need for a table?
> + if (g->read_only)
> + pr_debug("%s was enabled, making read-only\n", desc->name);
You can set init.flags |= CLK_IS_CRITICAL instead of using your own flag.
> +static unsigned long r9a06g032_divider_recalc_rate(
> + struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct r9a06g032_clk_div *clk = to_r9a06g032_divider(hw);
> + u32 *reg = ((u32 *)clk->clocks->reg) + clk->reg;
Fishy operations on __iomem pointers
> + long div = clk_readl(reg);
u32 div?
> +
> + if (div < clk->min)
> + div = clk->min;
> + else if (div > clk->max)
> + div = clk->max;
> + return DIV_ROUND_UP(parent_rate, div);
> +}
> +
> +/*
> + * Attempts to find a value that is in range of min,max,
> + * and if a table of set dividers was specified for this
> + * register, try to find the fixed divider that is the closest
> + * to the target frequency
> + */
> +static long r9a06g032_divider_clamp_div(
> + struct r9a06g032_clk_div *clk,
> + unsigned long rate, unsigned long prate)
> +{
> + /* + 1 to cope with rates that have the remainder dropped */
> + long div = DIV_ROUND_UP(prate, rate + 1);
> + int i;
unsigned int i
> +
> + if (div <= clk->min)
> + return clk->min;
> + if (div >= clk->max)
> + return clk->max;
> +
> + for (i = 0; clk->table_size && i < clk->table_size - 1; i++) {
> +static long r9a06g032_divider_round_rate(
> + struct clk_hw *hw, unsigned long rate,
> + unsigned long *prate)
> +{
> + struct r9a06g032_clk_div *clk = to_r9a06g032_divider(hw);
> + long div = DIV_ROUND_UP(*prate, rate);
> +
> + pr_devel("%s %pC %ld (prate %ld) (wanted div %ld)\n", __func__,
Ah, you do know about %pC ;-)
> + hw->clk, rate, *prate, div);
> + pr_devel(" min %d (%ld) max %d (%ld)\n",
> + clk->min, DIV_ROUND_UP(*prate, clk->min),
> + clk->max, DIV_ROUND_UP(*prate, clk->max));
> +
> + div = r9a06g032_divider_clamp_div(clk, rate, *prate);
> + /*
> + * this is a hack. Currently the serial driver asks for a clock rate
> + * that is 16 times the baud rate -- and that is wildly outside the
> + * range of the UART divider, somehow there is no provision for that
> + * case of 'let the divider as is if outside range'.
> + * The serial driver *shouldn't* play with these clocks anyway, there's
> + * several uarts attached to this divider, and changing this impacts
> + * everyone.
Huh?
> + */
> + if (clk->index == R9A06G032_DIV_UART) {
> + pr_devel("%s div uart hack!\n", __func__);
> + return clk_get_rate(hw->clk);
> + }
> + pr_devel("%s %pC %ld / %ld = %ld\n", __func__, hw->clk,
> + *prate, div, DIV_ROUND_UP(*prate, div));
> + return DIV_ROUND_UP(*prate, div);
> +}
> +
> +static int r9a06g032_divider_set_rate(
> + struct clk_hw *hw, unsigned long rate,
> + unsigned long parent_rate)
> +{
> + struct r9a06g032_clk_div *clk = to_r9a06g032_divider(hw);
> + /* + 1 to cope with rates that have the remainder dropped */
> + u32 div = DIV_ROUND_UP(parent_rate, rate + 1);
> + u32 *reg = ((u32 *)clk->clocks->reg) + clk->reg;
> +
> + pr_devel("%s %pC rate %ld parent %ld div %d\n", __func__, hw->clk,
> + rate, parent_rate, div);
> +
> + /*
> + * Need to write the bit 31 with the divider value to
> + * latch it. Technically we should wait until it has been
> + * cleared too.
> + * TODO: Find whether this callback is sleepable, in case
> + * the hardware /does/ require some sort of spinloop here.
> + */
> + clk_writel(div | (1U << 31), reg);
BIT(31)?
> +
> + return 0;
> +}
> +static struct clk *r9a06g032_register_divider(
> + struct r9a06g032_priv *clocks,
> + const char *parent_name,
> + const struct r9a06g032_clkdesc *desc)
> +{
> + struct r9a06g032_clk_div *div;
> + struct clk *clk;
> + struct clk_init_data init;
> + int i;
unsigned int i;
> +static void __init r9a06g032_clocks_init(struct device_node *np)
> +{
> + struct r9a06g032_priv *clocks;
> + struct clk **clks;
> + unsigned int i;
> + uint16_t uart_group_sel[2];
> +
> + clocks = kzalloc(sizeof(*clocks), GFP_KERNEL);
> + clks = kzalloc(R9A06G032_CLOCK_COUNT * sizeof(struct clk *),
> + GFP_KERNEL);
kcalloc()?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2] ASoC: simple-card: set cpu dai clk in hw_params
From: Daniel Mack @ 2018-05-30 19:45 UTC (permalink / raw)
To: lgirdwood, broonie, kuninori.morimoto.gx
Cc: devicetree, alsa-devel, robert.jarzmik, Daniel Mack
The simple-card driver currently accepts a clock node in the cpu dai
sub-node and only uses it as an alternative to the
'system-clock-frequency' property to get the current frequency.
This patch adds another use of the passed clock node. If mclk-fs is
specified, the clocks in cpu and codec dai sub-nodes will be set to
the calculated rate (stream rate * mclk_fs) in hw_params.
This allows platforms to pass tuneable clocks as phandle that will
automatically be set to the right rates.
Signed-off-by: Daniel Mack <daniel@zonque.org>
---
This is the only patch that's left from the series of three that I
posted earlier.
v1 → v2:
* Apply the setting to both the codec and the cpu dai
* Check for errors from clk_set_rate() and avoid unnecessary rate
changes.
.../devicetree/bindings/sound/simple-card.txt | 5 +++++
sound/soc/generic/simple-card.c | 21 +++++++++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt
index 17c13e74667d..a4c72d09cd45 100644
--- a/Documentation/devicetree/bindings/sound/simple-card.txt
+++ b/Documentation/devicetree/bindings/sound/simple-card.txt
@@ -86,6 +86,11 @@ Optional CPU/CODEC subnodes properties:
in dai startup() and disabled with
clk_disable_unprepare() in dai
shutdown().
+ If a clock is specified and a
+ multiplication factor is given with
+ mclk-fs, the clock will be set to the
+ calculated mclk frequency when the
+ stream starts.
- system-clock-direction-out : specifies clock direction as 'out' on
initialization. It is useful for some aCPUs with
fixed clocks.
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 6959a74a6f49..4a516c428b3d 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -135,6 +135,18 @@ static void asoc_simple_card_shutdown(struct snd_pcm_substream *substream)
asoc_simple_card_clk_disable(&dai_props->codec_dai);
}
+static int asoc_simple_set_clk_rate(struct asoc_simple_dai *simple_dai,
+ unsigned long rate)
+{
+ if (!simple_dai->clk)
+ return 0;
+
+ if (clk_get_rate(simple_dai->clk) == rate)
+ return 0;
+
+ return clk_set_rate(simple_dai->clk, rate);
+}
+
static int asoc_simple_card_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
{
@@ -154,6 +166,15 @@ static int asoc_simple_card_hw_params(struct snd_pcm_substream *substream,
if (mclk_fs) {
mclk = params_rate(params) * mclk_fs;
+
+ ret = asoc_simple_set_clk_rate(&dai_props->codec_dai, mclk);
+ if (ret < 0)
+ return ret;
+
+ ret = asoc_simple_set_clk_rate(&dai_props->cpu_dai, mclk);
+ if (ret < 0)
+ return ret;
+
ret = snd_soc_dai_set_sysclk(codec_dai, 0, mclk,
SND_SOC_CLOCK_IN);
if (ret && ret != -ENOTSUPP)
--
2.14.3
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply related
* Re: [PATCH 00/12] introduce support for early platform drivers
From: Michael Turquette @ 2018-05-30 19:40 UTC (permalink / raw)
To: Bartosz Golaszewski, Rob Herring
Cc: Sekhar Nori, Kevin Hilman, David Lechner, Stephen Boyd,
Arnd Bergmann, Greg Kroah-Hartman, Mark Rutland, Yoshinori Sato,
Rich Felker, Andy Shevchenko, Marc Zyngier, Rafael J . Wysocki,
Peter Rosin, Jiri Slaby, Thomas Gleixner, Daniel Lezcano,
Geert Uytterhoeven, Magnus Damm, Johan Hovold, Frank Rowand, mo
In-Reply-To: <CAL_JsqJ=DdkDR3LtnTMHPUpwaUbjPEBgkaCV8ja+p-mTvWZuYA@mail.gmail.com>
Hi Rob,
Quoting Rob Herring (2018-05-14 06:20:57)
> On Mon, May 14, 2018 at 6:38 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > 2018-05-11 22:13 GMT+02:00 Rob Herring <robh+dt@kernel.org>:
> >> On Fri, May 11, 2018 at 11:20 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >>> This series is a follow-up to the RFC[1] posted a couple days ago.
> >>>
> >>> NOTE: this series applies on top of my recent patches[2] that move the previous
> >>> implementation of early platform devices to arch/sh.
> >>>
> >>> Problem:
> >>>
> >>> Certain class of devices, such as timers, certain clock drivers and irq chip
> >>> drivers need to be probed early in the boot sequence. The currently preferred
> >>> approach is using one of the OF_DECLARE() macros. This however does not create
> >>> a platform device which has many drawbacks - such as not being able to use
> >>> devres routines, dev_ log functions or no way of deferring the init OF function
> >>> if some other resources are missing.
> >>
> >> I skimmed though this and it doesn't look horrible (how's that for
> >> positive feedback? ;) ). But before going into the details, I think
> >> first there needs to be agreement this is the right direction.
> >>
> >> The question does remain though as to whether this class of devices
> >> should be platform drivers. They can't be modules. They can't be
> >> hotplugged. Can they be runtime-pm enabled? So the advantage is ...
> >>
> >
> > The main (but not the only) advantage for drivers that can both be
> > platform drivers and OF_DECLARE drivers is that we get a single entry
> > point and can reuse code without resorting to checking if (!dev). It
> > results in more consistent code base. Another big advantage is
> > consolidation of device tree and machine code for SoC drivers used in
> > different boards of which some are still using board files and others
> > are defined in DT (see: DaVinci).
> >
> >> I assume that the clock maintainers had some reason to move clocks to
> >> be platform drivers. It's just not clear to me what that was.
> >>
> >>> For drivers that use both platform drivers and OF_DECLARE the situation is even
> >>> more complicated as the code needs to take into account that there can possibly
> >>> be no struct device present. For a specific use case that we're having problems
> >>> with, please refer to the recent DaVinci common-clock conversion patches and
> >>> the nasty workaround that this problem implies[3].
> >>
> >> So devm_kzalloc will work with this solution? Why did we need
> >> devm_kzalloc in the first place? The clocks can never be removed and
> >> cleaning up on error paths is kind of pointless. The system would be
> >> hosed, right?
> >>
> >
> > It depends - not all clocks are necessary for system to boot.
>
> That doesn't matter. You have a single driver for all/most of the
> clocks, so the driver can't be removed.
-ECANOFWORMS
A couple of quick rebuttals, but I imagine we're going to disagree on
the platform_driver thing as a matter of taste no matter what...
1) There should be multiple clk drivers in a properly modeled system.
Some folks still incorrectly put all clocks in a system into a single
driver because That's How We Used To Do It, and some systems (simpler
ones) really only have a single clock generator IP block.
Excepting those two reasons above, we really should have separate
drivers for clocks controlled by the PMIC, for the (one or more) clock
generator blocks inside of the AP/SoC, and then even more for the
drivers that map to IP blocks that have their own clock gens.
Good examples of the latter are display controllers that generate their
own PLL and pixel clock. Or MMC controllers that have a
runtime-programmable clock divider. Examples of these are merged into
mainline.
2) Stephen and I wanted clock drivers to actually be represented in the
driver model. There were these gigantic clock drivers that exclusively
used CLK_OF_DECLARE and they just sort of floated out there in the
ether... no representation in sysfs, no struct device to map onto a
clock controller struct, etc.
I'd be happy to hear why you think that platform_driver is a bad fit for
a device driver that generally manages memory-mapped system resources
that are part of the system glue and not really tied to a specific bus.
Sounds like a good fit to me.
If platform_driver doesn't handle the early boot thing well, that tells
me that we have a problem to solve in platform_driver, not in the clk
subsystem or drivers.
3) Lots of clock controllers should be loadable modules. E.g. i2c clock
expanders, potentially external PMIC-related drivers, external audio
codecs, etc.
Again, repeating my point #1 above, just because many platforms have a
monolithic clock driver does not mean that this is the Right Way to do
it.
Best regards,
Mike
>
> >>> We also used to have an early platform drivers implementation but they were not
> >>> integrated with the linux device model at all - they merely used the same data
> >>> structures. The users could not use devres, defer probe and the early devices
> >>> never became actual platform devices later on.
> >>>
> >>> Proposed solution:
> >>>
> >>> This series aims at solving this problem by (re-)introducing the concept of
> >>> early platform drivers and devices - this time however in a way that seamlessly
> >>> integrates with the existing platform drivers and also offers device-tree
> >>> support.
> >>>
> >>> The idea is to provide a way for users to probe devices early, while already
> >>> being able to use devres, devices resources and properties and also deferred
> >>> probing.
> >>>
> >>> New structures are introduced: the early platform driver contains the
> >>> early_probe callback which has the same signature as regular platform_device
> >>> probe. This callback is called early on. The user can have both the early and
> >>> regular probe speficied or only one of them and they both receive the same
> >>> platform device object as argument. Any device data allocated early will be
> >>> carried over to the normal probe.
> >>>
> >>> The architecture code is responsible for calling early_platform_start() in
> >>> which the early drivers will be registered and devices populated from DT.
> >>
> >> Can we really do this in one spot for different devices (clk, timers,
> >> irq). The sequence is all very carefully crafted. Platform specific
> >> hooks is another thing to consider.
> >>
> >
> > This is why I added support for early probe deferral - so that we can
> > stop caring for the order as long as the drivers are aware of other
> > resources they need and we call early_platform_start() the moment the
> > earliest of the early devices is needed.
>
> Deferred probe helps for inter-device dependencies, but I am more
> concerned about timing of trying to register clocksources, irqchips,
> etc. What happens if we probe drivers before the infrastructure is
> initialized?
>
> Rob
^ permalink raw reply
* Re: [PATCH RFC] ARM: dts: add Raspberry Pi Compute Module and IO board
From: Eric Anholt @ 2018-05-30 19:38 UTC (permalink / raw)
To: Stefan Wahren, Rob Herring, Mark Rutland
Cc: devicetree, Florian Fainelli, Scott Branden, Ray Jui, Phil Elwell,
bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel
In-Reply-To: <1670815145.72020.1526930907735@email.1und1.de>
[-- Attachment #1.1: Type: text/plain, Size: 6021 bytes --]
Stefan Wahren <stefan.wahren@i2se.com> writes:
>> Eric Anholt <eric@anholt.net> hat am 21. Mai 2018 um 20:26 geschrieben:
>>
>>
>> Stefan Wahren <stefan.wahren@i2se.com> writes:
>>
>> > The Raspberry Pi Compute Module (CM1) is a SoM which contains a
>> > BCM2835 processor, 512 MB RAM and a 4 GB eMMC. There is also a carrier
>> > board which is called Compute Module IO Board.
>> >
>> > Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>> > ---
>> > arch/arm/boot/dts/Makefile | 1 +
>> > arch/arm/boot/dts/bcm2835-rpi-cm1-io1.dts | 92 +++++++++++++++++++++++++++++++
>> > arch/arm/boot/dts/bcm2835-rpi-cm1.dtsi | 34 ++++++++++++
>> > 3 files changed, 127 insertions(+)
>> > create mode 100644 arch/arm/boot/dts/bcm2835-rpi-cm1-io1.dts
>> > create mode 100644 arch/arm/boot/dts/bcm2835-rpi-cm1.dtsi
>> >
>> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> > index ec2024e..a9883e8 100644
>> > --- a/arch/arm/boot/dts/Makefile
>> > +++ b/arch/arm/boot/dts/Makefile
>> > @@ -73,6 +73,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
>> > bcm2835-rpi-b-rev2.dtb \
>> > bcm2835-rpi-b-plus.dtb \
>> > bcm2835-rpi-a-plus.dtb \
>> > + bcm2835-rpi-cm1-io1.dtb \
>> > bcm2836-rpi-2-b.dtb \
>> > bcm2837-rpi-3-b.dtb \
>> > bcm2837-rpi-3-b-plus.dtb \
>> > diff --git a/arch/arm/boot/dts/bcm2835-rpi-cm1-io1.dts b/arch/arm/boot/dts/bcm2835-rpi-cm1-io1.dts
>> > new file mode 100644
>> > index 0000000..4d9aa22
>> > --- /dev/null
>> > +++ b/arch/arm/boot/dts/bcm2835-rpi-cm1-io1.dts
>> > @@ -0,0 +1,92 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +/dts-v1/;
>> > +#include "bcm2835-rpi-cm1.dtsi"
>> > +#include "bcm283x-rpi-usb-host.dtsi"
>> > +
>> > +/ {
>> > + compatible = "raspberrypi,compute-module", "brcm,bcm2835";
>> > + model = "Raspberry Pi Compute Module IO board rev1";
>> > +};
>> > +
>> > +&dsi1 {
>> > + status = "okay";
>> > +};
>> > +
>> > +&gpio {
>> > + /*
>> > + * This is based on the official GPU firmware DT blob.
>> > + *
>> > + * Legend:
>> > + * "NC" = not connected (no rail from the SoC)
>> > + * "FOO" = GPIO line named "FOO" on the schematic
>> > + * "FOO_N" = GPIO line named "FOO" on schematic, active low
>> > + */
>> > + gpio-line-names = "GPIO0",
>> > + "GPIO1",
>> > + "GPIO2",
>> > + "GPIO3",
>> > + "GPIO4",
>> > + "GPIO5",
>> > + "GPIO6",
>> > + "GPIO7",
>> > + "GPIO8",
>> > + "GPIO9",
>> > + "GPIO10",
>> > + "GPIO11",
>> > + "GPIO12",
>> > + "GPIO13",
>> > + "GPIO14",
>> > + "GPIO15",
>> > + "GPIO16",
>> > + "GPIO17",
>> > + "GPIO18",
>> > + "GPIO19",
>> > + "GPIO20",
>> > + "GPIO21",
>> > + "GPIO22",
>> > + "GPIO23",
>> > + "GPIO24",
>> > + "GPIO25",
>> > + "GPIO26",
>> > + "GPIO27",
>> > + "GPIO28",
>> > + "GPIO29",
>> > + "GPIO30",
>> > + "GPIO31",
>> > + "GPIO32",
>> > + "GPIO33",
>> > + "GPIO34",
>> > + "GPIO35",
>> > + "GPIO36",
>> > + "GPIO37",
>> > + "GPIO38",
>> > + "GPIO39",
>> > + "GPIO40",
>> > + "GPIO41",
>> > + "GPIO42",
>> > + "GPIO43",
>> > + "GPIO44",
>> > + "GPIO45",
>> > + "HDMI_HPD_N",
>> > + /* Also used as ACT LED */
>> > + "EMMC_EN_N",
>> > + /* Used by eMMC */
>> > + "SD_CLK_R",
>> > + "SD_CMD_R",
>> > + "SD_DATA0_R",
>> > + "SD_DATA1_R",
>> > + "SD_DATA2_R",
>> > + "SD_DATA3_R";
>> > +
>> > + pinctrl-0 = <&gpioout &alt0>;
>> > +};
>> > +
>> > +&hdmi {
>> > + hpd-gpios = <&gpio 46 GPIO_ACTIVE_HIGH>;
>> > +};
>>
>> I think this should be ACTIVE_LOW, since it's "HDMI_HPD_N_1V8", right?
>
> I just copy & paste from the rpi-4.14/bcm2708-rpi-cm.dts. I thought
> the HDMI interface on my IO board is broken, but maybe this is a
> downstream issue.
Downstream gets HDMI wrong pretty frequently, so it's not surprising.
Watching xrandr -q with X11 running and plugging and unplugging HDMI can
help figure out whether we got the polarity right. I think you can also
do this with libdrm's modetest, if you don't have X11 up.
>> > +
>> > +&uart0 {
>> > + pinctrl-names = "default";
>> > + pinctrl-0 = <&uart0_gpio14>;
>> > + status = "okay";
>> > +};
>> > diff --git a/arch/arm/boot/dts/bcm2835-rpi-cm1.dtsi b/arch/arm/boot/dts/bcm2835-rpi-cm1.dtsi
>> > new file mode 100644
>> > index 0000000..ef22c2d
>> > --- /dev/null
>> > +++ b/arch/arm/boot/dts/bcm2835-rpi-cm1.dtsi
>> > @@ -0,0 +1,34 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +/dts-v1/;
>> > +#include "bcm2835.dtsi"
>> > +#include "bcm2835-rpi.dtsi"
>> > +
>> > +/ {
>> > + leds {
>> > + act {
>> > + gpios = <&gpio 47 GPIO_ACTIVE_LOW>;
>> > + };
>> > + };
>> > +
>> > + reg_3v3: fixed-regulator {
>> > + compatible = "regulator-fixed";
>> > + regulator-name = "3V3";
>> > + regulator-min-microvolt = <3300000>;
>> > + regulator-max-microvolt = <3300000>;
>> > + regulator-always-on;
>> > + };
>> > +
>> > + reg_1v8: fixed-regulator {
>> > + compatible = "regulator-fixed";
>> > + regulator-name = "1V8";
>> > + regulator-min-microvolt = <1800000>;
>> > + regulator-max-microvolt = <1800000>;
>> > + regulator-always-on;
>> > + };
>> > +};
>> > +
>> > +&sdhost {
>> > + non-removable;
>> > + vmmc-supply = <®_3v3>;
>> > + vqmmc-supply = <®_1v8>;
>> > +};
>>
>> Also, looking at some datasheets I have laying around, it says "eMMC I/O
>> Voltage fixed at 1V8" -- is this regulator setup right, in that case?
>
> Usually an eMMC has 2 different voltage sources:
> vqmmc-supply -> supply node for IO line power (usually switchable, but fixed on Compute Module)
> vmmc-supply -> supply node for card's power (usually fixed)
>
> Do you have a specific concern (voltage, naming)?
It was just "I was reviewing, and this stood out." That explanation
there seems sufficient to me. Thanks!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: 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: [v5 2/6] dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs
From: Li Yang @ 2018-05-30 18:51 UTC (permalink / raw)
To: Wen He
Cc: vkoul, dmaengine, Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
jiafei.pan, jiaheng.fan
In-Reply-To: <20180525111920.24498-2-wen.he_1@nxp.com>
On Fri, May 25, 2018 at 6:19 AM, Wen He <wen.he_1@nxp.com> wrote:
> NXP Queue DMA controller(qDMA) on Layerscape SoCs supports channel
> virtuallization by allowing DMA jobs to be enqueued into different
> command queues.
>
> Note that this module depends on NXP DPAA.
>
> Signed-off-by: Wen He <wen.he_1@nxp.com>
> Signed-off-by: Jiaheng Fan <jiaheng.fan@nxp.com>
> ---
> change in v5:
> - Fixed the issues includes:
> * add error handler which every function
> * replace word to bit definition
> * move global variable to struct definition
> * add some comments to context
>
> change in v4:
> - Fixed the issues that Vinod point out in the mail list.
>
> change in v3:
> - Add 'depends on ARM || ARM64' in file 'drivers/dma/Kconfig'
>
> change in v2:
> - Replace GPL V2 License details by SPDX tags
> - Replace Freescale by NXP
> - Reduce and optimize header file references
> - Replace big_endian by feature in struct fsl_qdma_engine
> - Replace struct fsl_qdma_format by struct fsl_qdma_ccdf
> and struct fsl_qdma_csgf
> - Remove empty line
> - Replace 'if..else' by macro 'FSL_QDMA_IN/OUT' in function
> qdma_readl() and qdma_writel()
> - Remove function fsl_qdma_alloc_chan_resources()
> - Replace 'prei' by 'pre'
> - Replace '-1' by '-ENOMEM' in function fsl_qdma_pre_request_enqueue_desc()
> - Fix dma pool allocation need to rolled back in function
> fsl_qdma_request_enqueue_desc()
> - Replace function of_property_read_u32_array() by device_property_read_u32_array()
> - Add functions fsl_qdma_cleanup_vchan() and fsl_qdma_irq_exit() to ensure
> irq and tasklets stopped
> - Replace dts node element 'channels' by 'dma-channels'
> - Replace function platform_driver_register() by module_platform_driver()
>
> drivers/dma/Kconfig | 13 +
> drivers/dma/Makefile | 1 +
> drivers/dma/fsl-qdma.c | 1101 ++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 1115 insertions(+), 0 deletions(-)
> create mode 100644 drivers/dma/fsl-qdma.c
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 6d61cd0..99aff33 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -225,6 +225,19 @@ config FSL_EDMA
> multiplexing capability for DMA request sources(slot).
> This module can be found on Freescale Vybrid and LS-1 SoCs.
>
> +config FSL_QDMA
> + tristate "NXP Layerscape qDMA engine support"
> + depends on ARM || ARM64
> + select DMA_ENGINE
> + select DMA_VIRTUAL_CHANNELS
> + select DMA_ENGINE_RAID
> + select ASYNC_TX_ENABLE_CHANNEL_SWITCH
> + help
> + Support the NXP Layerscape qDMA engine with command queue and legacy mode.
> + Channel virtualization is supported through enqueuing of DMA jobs to,
> + or dequeuing DMA jobs from, different work queues.
> + This module can be found on NXP Layerscape SoCs.
> +
> config FSL_RAID
> tristate "Freescale RAID engine Support"
> depends on FSL_SOC && !ASYNC_TX_ENABLE_CHANNEL_SWITCH
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index 0f62a4d..93db0fc 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_DW_DMAC_CORE) += dw/
> obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o
> obj-$(CONFIG_FSL_DMA) += fsldma.o
> obj-$(CONFIG_FSL_EDMA) += fsl-edma.o
> +obj-$(CONFIG_FSL_QDMA) += fsl-qdma.o
> obj-$(CONFIG_FSL_RAID) += fsl_raid.o
> obj-$(CONFIG_HSU_DMA) += hsu/
> obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o
> diff --git a/drivers/dma/fsl-qdma.c b/drivers/dma/fsl-qdma.c
> new file mode 100644
> index 0000000..81df812
> --- /dev/null
> +++ b/drivers/dma/fsl-qdma.c
> @@ -0,0 +1,1101 @@
Not a critical issue, but the format of the file header looks a little
bit weird to me. Would you mind clean it up?
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright 2018 NXP
I know the SPDX tag is recommended to be the 1st line, but copyright
normally goes below the file description not above.
> +
No newline needed.
> +/*
> + * Driver for NXP Layerscape Queue Direct Memory Access Controller
> + *
> + * Author:
> + * Wen He <wen.he_1@nxp.com>
> + * Jiaheng Fan <jiaheng.fan@nxp.com>
> + *
No newline needed.
> + */
> +
Regards,
Leo
^ permalink raw reply
* Re: [PATCH v2 1/6] soc: qcom: rpmpd: Add a powerdomain driver to model corners
From: David Collins @ 2018-05-30 18:27 UTC (permalink / raw)
To: Rajendra Nayak, Ulf Hansson
Cc: Viresh Kumar, Stephen Boyd, Andy Gross, devicetree, linux-arm-msm,
Linux Kernel Mailing List
In-Reply-To: <0e07d577-9728-e97a-2da0-dd7dd324f058@codeaurora.org>
Hello Rajendra,
On 05/30/2018 03:14 AM, Rajendra Nayak wrote:
> On 05/30/2018 02:47 PM, Ulf Hansson wrote:
>> On 25 May 2018 at 12:01, Rajendra Nayak <rnayak@codeaurora.org> wrote:
...
>>> + pm_genpd_init(&rpmpds[i]->pd, NULL, true);
>>
>> Question: Is there no hierarchical topology of the PM domains. No
>> genpd subdomains?
>
> The hierarchy if any is all handled by the remote core (RPM in this case).
> For Linux its just a flat view.
There is one special case that we'll need to handle somehow. The APPS
vlvl request for VDD_MX needs to be greater than or equal to the vlvl
request for VDD_CX. Can you please add the necessary code to achieve
this? RPMh hardware doesn't handle this hardware requirement due to
concerns about modem use case latency.
Please note that this is handled in a somewhat hacky manner [1] with the
downstream rpmh-regulator driver by specifying VDD_MX as the parent of
VDD_CX and VDD_MX_AO as the parent of VDD_CX_AO with a dropout voltage of
-1. That way, enabling CX causes MX to be enabled and voltage level
requests are propagated from CX to MX (the -1 is ignored because it is
rounded up within the sparse vlvl numbering space).
Thanks,
David
[1]:
https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/arch/arm64/boot/dts/qcom/sdm845-regulator.dtsi?h=msm-4.9#n135
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 09/13] Bluetooth: hci_serdev: Fix HCI_UART_INIT_PENDING not working
From: Hans de Goede @ 2018-05-30 17:31 UTC (permalink / raw)
To: Rob Herring
Cc: Marcel Holtmann, Johan Hedberg, Martin Blumenstingl, Jeremy Cline,
open list:BLUETOOTH DRIVERS, open list:SERIAL DRIVERS, linux-acpi,
devicetree
In-Reply-To: <CAL_JsqKBc4_bsaqNd3t5=LPBYgv32Jw3pzUq-=25V7JBbRhF7A@mail.gmail.com>
Hi,
On 30-05-18 15:25, Rob Herring wrote:
> On Sun, May 27, 2018 at 2:04 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Init hci_uart->init_ready so that hci_uart_init_ready() works properly.
>
> Why do you need to init in a wq? For serdev devices, probe is async
> already. So my thought was this wouldn't be needed.
The H5 protocol needs to exchange a number of messages to
sync the 2 sides before it can accept any HCI commands, so
it uses the delayed-registration feature of the hci_ldisc code by
setting the HCI_UART_INIT_PENDING. When doing serdev based enumeration
we could do something different but that would require significant
changes to the hci_h5.c code.
Regards,
Hans
^ permalink raw reply
* Re: [v2] MAINTAINERS: add myself as maintainer for QorIQ PTP clock driver
From: David Miller @ 2018-05-30 17:27 UTC (permalink / raw)
To: yangbo.lu
Cc: netdev, devicetree, linux-kernel, richardcochran, claudiu.manoil,
robh+dt
In-Reply-To: <20180529034744.44590-1-yangbo.lu@nxp.com>
From: Yangbo Lu <yangbo.lu@nxp.com>
Date: Tue, 29 May 2018 11:47:44 +0800
> Added myself as maintainer for QorIQ PTP clock driver.
> Since gianfar_ptp.c was renamed to ptp_qoriq.c, let's
> maintain it under QorIQ PTP clock driver.
>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> ---
> Changes for v2:
> - Dropped dpaa2/rtc part.
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH 2/6] PCI: iproc: Add INTx support with better modeling
From: Ray Jui @ 2018-05-30 17:27 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Mark Rutland,
Linux Kernel Mailing List, bcm-kernel-feedback-list, linux-pci,
devicetree, linux-arm Mailing List
In-Reply-To: <CAHp75VfwfKbikfat3tTbMzSfNgt4v9nFpExyDvhOdX9ko1Z4Fw@mail.gmail.com>
Hi Andy,
On 5/29/2018 5:59 PM, Andy Shevchenko wrote:
> On Wed, May 30, 2018 at 12:58 AM, Ray Jui <ray.jui@broadcom.com> wrote:
>> Add PCIe legacy interrupt INTx support to the iProc PCIe driver by
>> modeling it with its own IRQ domain. All 4 interrupts INTA, INTB, INTC,
>> INTD share the same interrupt line connected to the GIC in the system,
>> while the status of each INTx can be obtained through the INTX CSR
>> register
>
>> + while ((status = iproc_pcie_read_reg(pcie, IPROC_PCIE_INTX_CSR) &
>> + SYS_RC_INTX_MASK) != 0) {
>> + for_each_set_bit(bit, &status, PCI_NUM_INTX) {
>> + virq = irq_find_mapping(pcie->irq_domain, bit + 1);
>> + if (virq)
>> + generic_handle_irq(virq);
>> + else
>> + dev_err(dev, "unexpected INTx%u\n", bit);
>> + }
>> + }
>
> do {
> status = ...;
> for_each_set_bit() {
> ...
> }
> } while (status);
>
> would look slightly better for my opinion.
>
Indeed. I agree with you. I'll wait for comments before sending out v2
which will include this improvement.
Thanks,
Ray
^ permalink raw reply
* Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Mark Brown @ 2018-05-30 16:59 UTC (permalink / raw)
To: Doug Anderson
Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland,
linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak,
Stephen Boyd
In-Reply-To: <CAD=FV=V1gGccKr1mHM0zx_-FFdLU1vrzUChwx6KTUyTGzj39Tw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]
On Wed, May 30, 2018 at 09:41:55AM -0700, Doug Anderson wrote:
> On Wed, May 30, 2018 at 9:36 AM, Mark Brown <broonie@kernel.org> wrote:
> > Yeah, and I don't think that's unreasonable for the core to do - just
> > drop the voltage to the constraint minimum after it has turned off the
> > regulator, then recheck and raise if needed before it enables again.
> Would it do this for all regulators, though? Most regulators are
> hooked up over a slow i2c bus, so that means that every regulator
> disable would now do an extra i2c transfer even though for all
> regulators (other than RPMh) the voltage of a regulator doesn't matter
> when it's been "disabled' (from Linux's point of view).
It'd only affect regulators that can vary in voltage and actually get
disabled which is a pretty small subset. Most regulators are either
fixed voltage or always on.
> Hrmmm, I suppose maybe it'd be OK though because for most regulators
> we'd use "regcache" and most regulators that we enabled/disable a lot
> are not expected to change voltage in Linux (so the regcache write
> would hopefully be a noop), so maybe it wouldn't be _that_
> inefficient...
Even if the regulator lacks a cache we'd at least skip out on the write
when we're not changing voltage as we'd do a read/modify/update cycle
and stop at the modify.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] ARM: dts: exynos: Add missing CPU clocks to secondary CPUs on Exynos542x
From: Krzysztof Kozlowski @ 2018-05-30 16:49 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kukjin Kim, Krzysztof Kozlowski,
Marek Szyprowski, Viresh Kumar, devicetree, linux-arm-kernel,
linux-samsung-soc, linux-kernel
Secondary CPUs should have the same information in DeviceTree as booting
CPU from both correctness point of view and for possible hotplug
scenarios.
Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm/boot/dts/exynos5420-cpus.dtsi | 6 ++++++
arch/arm/boot/dts/exynos5422-cpus.dtsi | 8 +++++++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi b/arch/arm/boot/dts/exynos5420-cpus.dtsi
index a8e449471304..0ee6e92a3c29 100644
--- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
@@ -38,6 +38,7 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
@@ -49,6 +50,7 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x2>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
@@ -60,6 +62,7 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x3>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
@@ -83,6 +86,7 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
operating-points-v2 = <&cluster_a7_opp_table>;
@@ -94,6 +98,7 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x102>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
operating-points-v2 = <&cluster_a7_opp_table>;
@@ -105,6 +110,7 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x103>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
operating-points-v2 = <&cluster_a7_opp_table>;
diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi b/arch/arm/boot/dts/exynos5422-cpus.dtsi
index 7c130a00d1a8..e4a5857c135f 100644
--- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
@@ -37,6 +37,7 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
operating-points-v2 = <&cluster_a7_opp_table>;
@@ -48,6 +49,7 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x102>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
operating-points-v2 = <&cluster_a7_opp_table>;
@@ -59,6 +61,7 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x103>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
operating-points-v2 = <&cluster_a7_opp_table>;
@@ -69,8 +72,8 @@
cpu4: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
- clocks = <&clock CLK_ARM_CLK>;
reg = <0x0>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
@@ -82,6 +85,7 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
@@ -93,6 +97,7 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x2>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
@@ -104,6 +109,7 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x3>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
--
2.14.1
^ permalink raw reply related
* Re: [PATCH v1 2/2] hwmon: npcm-pwm: add NPCM7xx PWM driver
From: Guenter Roeck @ 2018-05-30 16:46 UTC (permalink / raw)
To: Tomer Maimon
Cc: Rob Herring, Mark Rutland, jdelvare, Avi Fishman, Nancy Yuen,
Brendan Higgins, Patrick Venture, Joel Stanley, devicetree,
Linux Kernel Mailing List, linux-hwmon, OpenBMC Maillist,
linux-pwm, Thierry Reding
In-Reply-To: <CAP6Zq1h8_n8R=dqmBxC_bK_YstLt1kkE6UCp2OVsNpKp=RK8og@mail.gmail.com>
On Wed, May 30, 2018 at 06:44:58PM +0300, Tomer Maimon wrote:
> Hi Guenter,
>
> Thanks for your prompt reply!
>
>
> On 29 May 2018 at 19:56, Guenter Roeck <linux@roeck-us.net> wrote:
>
> > On Tue, May 29, 2018 at 01:02:21PM +0300, Tomer Maimon wrote:
> > > Add Nuvoton BMC NPCM7xx Pulse Width Modulation (PWM) driver.
> > >
> > > The Nuvoton BMC NPCM7xx has two identical PWM controller modules,
> > > each module has four PWM controller outputs.
> > >
> >
> > I don't see it guaranteed that all future NPCM7xx devices will be PWM
> > controllers, much less that they will be compatible to the chip really
> >
>
> Actually all NPCM7xx family have PWM and FAN modules support,
>
>
> > supported here. NPCM750, I presume ? I would suggest name the driver
> > accordingly.
> >
>
> The compatible name can not be a family name like nuvoton,npcm7xx-pwm, only
> a specific chip name. (in our case the NPCM750 is the full modules SOC)
> still you think i should change the driver name? (note: all of our NPCM7xx
> unique modules drivers are named npcm7xx-*.c or *-npcm7xx.c)
>
drivers/watchdog/npcm_wdt.c contradicts that statement.
Please discuss with the pwm maintainer. In hwmon, wildcards in driver file
names are discouraged and will not be accepted. Our recommendation is to pick
one chip from the family and use it as part of the file name.
>
> > As a generic pwm driver, not specifically tied to a fan controller,
> > this driver does not belong into hwmon. It should be added to the pwm
> > subsystem. Copying the maintainer and mailing list.
> >
> > In the NPCM7xx we have PWM and FAN controller modules, usually in the
> aspect of our BMC clients the two module
> are used together to control the fans.
>
> But because in the NPCM7xx the PWM and the FAN controller are separate
> modules we
> thought to do two separate drivers in the hwmon
> is it possible? or you think it is better to do one hwmon driver for the
> PWM and the FAN controller.
>
That depends on how closely the two modules are intertwined. If the pwm module
is generic, it belongs into the pwm subsystem. It only belongs into hwmon
if it can _only_ be used for fan control, eg if the data reported by the fan
module is used by the hardware to control the pwm output based on some
fan speed <-> pw value mapping which is programmed into the chip, and/or
if the pwm output can only connect to a fan and nothing else, and if the
relationship between pwm output and fan input is well defined.
If both end up in hwmon, I don't see the benefit of having two separate
drivers. That means two hwmon devices for the same fan or set of fans,
one being all but useless in respect to output from the 'sensors'
command. You'll have to convince me why that would make sense; I just
don't see the point. In that case, I would also not see the point of
having two separate devicetree nodes; to me, that would be similar
to having two interfaces for a single serial line, one for receive
and one for transmit.
> note that we were going to submit soon also the FAN controller driver under
> hwmon.
>
No problem with that as long as there are no wildcards in the file name.
Guenter
^ permalink raw reply
* Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 16:41 UTC (permalink / raw)
To: Mark Brown
Cc: Mark Rutland, devicetree, Rajendra Nayak, David Collins,
Stephen Boyd, linux-arm-msm, Liam Girdwood, LKML, Rob Herring,
Linux ARM
In-Reply-To: <20180530163644.GW6920@sirena.org.uk>
Hi,
On Wed, May 30, 2018 at 9:36 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 30, 2018 at 09:31:55AM -0700, Doug Anderson wrote:
>> On Wed, May 30, 2018 at 9:13 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > If we're just going to use the most recently set voltage then hopefully
>> > the hardware already knew that, and it might not be the lowest available
>> > voltage if the last consumer to get turned off was holding the voltage
>> > higher.
>
>> To circle back to the original point: the problem is that (IMHO) the
>> hardware is doing the wrong thing by still counting Linux's vote for a
>> voltage even though Linux also voted that the regulator should be
>> disabled. So basically we're working around the hardware by
>> pretending to vote for a dummy lower voltage whenever Linux wants the
>> regulator disabled. From Linux's point of view everything works as
>> normal--we just tell the hardware a falsehood so it doesn't count our
>> vote for a voltage while the regulator is disabled.
>
> Yeah, and I don't think that's unreasonable for the core to do - just
> drop the voltage to the constraint minimum after it has turned off the
> regulator, then recheck and raise if needed before it enables again.
Would it do this for all regulators, though? Most regulators are
hooked up over a slow i2c bus, so that means that every regulator
disable would now do an extra i2c transfer even though for all
regulators (other than RPMh) the voltage of a regulator doesn't matter
when it's been "disabled' (from Linux's point of view).
Hrmmm, I suppose maybe it'd be OK though because for most regulators
we'd use "regcache" and most regulators that we enabled/disable a lot
are not expected to change voltage in Linux (so the regcache write
would hopefully be a noop), so maybe it wouldn't be _that_
inefficient...
-Doug
^ permalink raw reply
* Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Mark Brown @ 2018-05-30 16:36 UTC (permalink / raw)
To: Doug Anderson
Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland,
linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak,
Stephen Boyd
In-Reply-To: <CAD=FV=UpWEMSPUYOHmLQ0g_mF990kwn4_zm=ZCNttLKZiz7i=Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]
On Wed, May 30, 2018 at 09:31:55AM -0700, Doug Anderson wrote:
> On Wed, May 30, 2018 at 9:13 AM, Mark Brown <broonie@kernel.org> wrote:
> > If we're just going to use the most recently set voltage then hopefully
> > the hardware already knew that, and it might not be the lowest available
> > voltage if the last consumer to get turned off was holding the voltage
> > higher.
> To circle back to the original point: the problem is that (IMHO) the
> hardware is doing the wrong thing by still counting Linux's vote for a
> voltage even though Linux also voted that the regulator should be
> disabled. So basically we're working around the hardware by
> pretending to vote for a dummy lower voltage whenever Linux wants the
> regulator disabled. From Linux's point of view everything works as
> normal--we just tell the hardware a falsehood so it doesn't count our
> vote for a voltage while the regulator is disabled.
Yeah, and I don't think that's unreasonable for the core to do - just
drop the voltage to the constraint minimum after it has turned off the
regulator, then recheck and raise if needed before it enables again.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/2] regulator: add QCOM RPMh regulator driver
From: Mark Brown @ 2018-05-30 16:33 UTC (permalink / raw)
To: David Collins
Cc: lgirdwood, robh+dt, mark.rutland, linux-arm-msm, linux-arm-kernel,
devicetree, linux-kernel, rnayak, sboyd, dianders
In-Reply-To: <cover.1527040878.git.collinsd@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]
On Tue, May 22, 2018 at 07:43:16PM -0700, David Collins wrote:
> This patch series adds a driver and device tree binding documentation for
> PMIC regulator control via Resource Power Manager-hardened (RPMh) on some
> Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block
So, this is a very big driver and obviously it being RPM based it
doesn't look like other regulators which is causing problems, especially
when coupled with the desire to implement a bunch of more exotic
features like the mode setting. I think this review is going to go a
lot more smoothly if you split this up into a base driver with just
normal, standard stuff that doesn't add too many custom properties or
unusual ways of working and then a series of patches on top of that
adding things like the mode adjustment and interaction with other RPM
clients.
We've got other RPM based regulators in tree already so the baseline bit
shouldn't be too hard, that'll make the rest of the patches much smaller
and easier to review and mean that the bits that are simpler and easier
to cope with don't need to be reposted.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 16:31 UTC (permalink / raw)
To: Mark Brown
Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland,
linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak,
Stephen Boyd
In-Reply-To: <20180530161311.GT6920@sirena.org.uk>
Hi,
On Wed, May 30, 2018 at 9:13 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 30, 2018 at 09:09:02AM -0700, Doug Anderson wrote:
>> On Wed, May 30, 2018 at 9:07 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > It needs something to tell it what the new voltage to set is.
>
>> The regulator driver has its own cache of what voltage was most
>> recently requested by Linux. It can use that, can't it?
>
> If we're just going to use the most recently set voltage then hopefully
> the hardware already knew that, and it might not be the lowest available
> voltage if the last consumer to get turned off was holding the voltage
> higher.
To circle back to the original point: the problem is that (IMHO) the
hardware is doing the wrong thing by still counting Linux's vote for a
voltage even though Linux also voted that the regulator should be
disabled. So basically we're working around the hardware by
pretending to vote for a dummy lower voltage whenever Linux wants the
regulator disabled. From Linux's point of view everything works as
normal--we just tell the hardware a falsehood so it doesn't count our
vote for a voltage while the regulator is disabled.
-Doug
^ permalink raw reply
* Re: [DPU PATCH 10/11] drm/msm/dpu: correct dpu_io_util.h include path
From: Jordan Crouse @ 2018-05-30 16:30 UTC (permalink / raw)
To: Rajesh Yadav
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
robdclark-Re5JQEeQqe8AvxtiuMwx3w, seanpaul-F7+t8E8rja9g9hUCZPvPmw,
hoegsberg-F7+t8E8rja9g9hUCZPvPmw,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <1527691788-9350-11-git-send-email-ryadav-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Wed, May 30, 2018 at 08:19:47PM +0530, Rajesh Yadav wrote:
> dpu_io_util.h is moved from standard include path
> to driver folder, correct the include path in code.
>
> Signed-off-by: Rajesh Yadav <ryadav@codeaurora.org>
If the previous patch doesn't compile without this fix you should squash them.
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 1 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 2 +-
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
> index 24c3274..f997bd9 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
> @@ -20,7 +20,6 @@
> #include <linux/slab.h>
> #include <linux/mutex.h>
> #include <linux/of_platform.h>
> -#include <linux/dpu_io_util.h>
>
> #include "dpu_power_handle.h"
> #include "dpu_trace.h"
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
> index 9a6d4b9..193f468 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
> @@ -21,7 +21,7 @@
> #define DPU_POWER_HANDLE_ENABLE_BUS_IB_QUOTA 1600000000
> #define DPU_POWER_HANDLE_DISABLE_BUS_IB_QUOTA 0
>
> -#include <linux/dpu_io_util.h>
> +#include "dpu_io_util.h"
>
> /* event will be triggered before power handler disable */
> #define DPU_POWER_EVENT_PRE_DISABLE 0x1
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply
* Re: [PATCH v2 0/5] crypto: ccree: cleanup, fixes and R-Car enabling
From: Herbert Xu @ 2018-05-30 16:28 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Geert Uytterhoeven,
Michael Turquette, Stephen Boyd, David S. Miller, Ofir Drang,
linux-renesas-soc, devicetree, linux-arm-kernel, linux-kernel,
linux-clk, linux-crypto
In-Reply-To: <1527171551-21979-1-git-send-email-gilad@benyossef.com>
On Thu, May 24, 2018 at 03:19:05PM +0100, Gilad Ben-Yossef wrote:
> The patch set enables the use of CryptoCell found in some Renesas R-Car
> Salvator-X boards and fixes some driver issues uncovered that prevented
> to work properly.
>
> Changes from v1:
> - Properly fix the bug that caused us to read a bad signature register
> rather than dropping the check
> - Proper DT fields as indicated by Geert Uytterhoeven.
> - Better clock enabling as suggested by Geert Uytterhoeven.
>
> Note! the last two patches in the set depend on the
> "clk: renesas: r8a7795: Add CR clock" patch from Geert Uytterhoeven.
Patches 1-3 applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 16:24 UTC (permalink / raw)
To: Mark Brown
Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland,
linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak,
Stephen Boyd
In-Reply-To: <20180530162007.GU6920@sirena.org.uk>
Hi,
On Wed, May 30, 2018 at 9:20 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 30, 2018 at 09:12:25AM -0700, Doug Anderson wrote:
>> On Wed, May 30, 2018 at 8:50 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > No, I'm saying that I don't know why that property exists at all. This
>> > sounds like it's intended to be the amount of current the regulator can
>> > deliver in each mode which is normally a design property of the silicon.
>
>> Ah, got it. So the whole point here is to be able to implement either
>> the function "set_load" or the function "get_optimum_mode". We need
>> some sort of table to convert from current to mode. That's what this
>> table does.
>
> We do need that table, my expectation would be that this table would be
> in the driver as it's not something I'd expect to vary between different
> systems but rather be a property of the silicon design. No sense in
> every single board having to copy it in.
Ah, got it! I'd be OK with it being hardcoded in the driver.
At one point I think David was making the argument that some boards
have different noise needs for the rails and thus you might want to
change modes at different currents. I don't know if this is realistic
but I believe it was part of his original argument for why this needed
to be specified. If we can hardcode this in the driver I'm fine with
it... That would actually solve many of my objections too...
-Doug
^ permalink raw reply
* Re: [PATCH v1 0/3] USB host: Add USB ehci support for nuvoton npcm7xx
From: Avi Fishman @ 2018-05-30 16:22 UTC (permalink / raw)
To: Greg Kroah-Hartman, stern
Cc: Avi Fishman, Tomer Maimon, Patrick Venture, Nancy Yuen,
Brendan Higgins, mathias.nyman, bjorn.andersson, jhogan, albeu,
chunfeng.yun, tony, baolu.lu, elder, digetx, kstewart, hdegoede,
Linux Kernel Mailing List, linux-usb, OpenBMC Maillist,
Rob Herring, Mark Rutland, devicetree, davem, akpm, rdunlap
In-Reply-To: <CAKKbWA5zu2ty-OapQMiYXWg6wk0UisPq56gow7_1Tti_fg7fkw@mail.gmail.com>
From: Avi Fishman <AviFishman70@gmail.com>
This patch adds support for ehci controller for the Nuvoton npcm7xx platform.
Most of the code was taken from ehci-spear.c + specific initialization code
Avi Fishman (3):
USB host: Add USB ehci support for nuvoton npcm7xx platform
USB: DT probing support to ehci-npcm7xx
MAINTAINERS: add subfolders for nuvoton *npcm*
.../devicetree/bindings/usb/npcm7xx-usb.txt | 18 ++
MAINTAINERS | 3 +
drivers/usb/host/Kconfig | 8 +
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-npcm7xx.c | 212 +++++++++++++++++++++
5 files changed, 242 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/npcm7xx-usb.txt
create mode 100644 drivers/usb/host/ehci-npcm7xx.c
--
2.14.1
^ permalink raw reply
* Re: [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Mark Brown @ 2018-05-30 16:20 UTC (permalink / raw)
To: Doug Anderson
Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland,
linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak,
Stephen Boyd
In-Reply-To: <CAD=FV=WVUmvPPd5BxXv9Sa_2CRPrrjQvYFyqroY-3fRr4f0Bzg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 854 bytes --]
On Wed, May 30, 2018 at 09:12:25AM -0700, Doug Anderson wrote:
> On Wed, May 30, 2018 at 8:50 AM, Mark Brown <broonie@kernel.org> wrote:
> > No, I'm saying that I don't know why that property exists at all. This
> > sounds like it's intended to be the amount of current the regulator can
> > deliver in each mode which is normally a design property of the silicon.
> Ah, got it. So the whole point here is to be able to implement either
> the function "set_load" or the function "get_optimum_mode". We need
> some sort of table to convert from current to mode. That's what this
> table does.
We do need that table, my expectation would be that this table would be
in the driver as it's not something I'd expect to vary between different
systems but rather be a property of the silicon design. No sense in
every single board having to copy it in.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Mark Brown @ 2018-05-30 16:13 UTC (permalink / raw)
To: Doug Anderson
Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland,
linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak,
Stephen Boyd
In-Reply-To: <CAD=FV=WVGu0f+=q-C9kiEmaLEUJqGY+Jbns83h72uF-9iasrUw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
On Wed, May 30, 2018 at 09:09:02AM -0700, Doug Anderson wrote:
> On Wed, May 30, 2018 at 9:07 AM, Mark Brown <broonie@kernel.org> wrote:
> > It needs something to tell it what the new voltage to set is.
> The regulator driver has its own cache of what voltage was most
> recently requested by Linux. It can use that, can't it?
If we're just going to use the most recently set voltage then hopefully
the hardware already knew that, and it might not be the lowest available
voltage if the last consumer to get turned off was holding the voltage
higher.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 16:12 UTC (permalink / raw)
To: Mark Brown
Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland,
linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak,
Stephen Boyd
In-Reply-To: <20180530155044.GR6920@sirena.org.uk>
Hi,
On Wed, May 30, 2018 at 8:50 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 30, 2018 at 07:54:47AM -0700, Doug Anderson wrote:
>> On Wed, May 30, 2018 at 3:37 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > I'm confused as to why we are specifying the maximum current the device
>> > can deliver in a given mode in the DT - surely that's a fixed property
>> > of the hardware?
>
>> Said another way: you're saying that you'd expect the "max-microamps"
>> table to have one fewer element than the listed modes? So in the
>> above example you'd have:
>
> No, I'm saying that I don't know why that property exists at all. This
> sounds like it's intended to be the amount of current the regulator can
> deliver in each mode which is normally a design property of the silicon.
Ah, got it. So the whole point here is to be able to implement either
the function "set_load" or the function "get_optimum_mode". We need
some sort of table to convert from current to mode. That's what this
table does.
My argument to David was that since set_load / get_optimum_mode were
features of the regulator core these should actually be standard
properties and not Qualcomm-specific ones.
-Doug
^ permalink raw reply
* Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 16:09 UTC (permalink / raw)
To: Mark Brown
Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland,
linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak,
Stephen Boyd
In-Reply-To: <20180530160744.GS6920@sirena.org.uk>
Hi,
On Wed, May 30, 2018 at 9:07 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 30, 2018 at 09:06:16AM -0700, Doug Anderson wrote:
>> On Wed, May 30, 2018 at 8:48 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > Without the core doing something the regulator isn't going to get told
>> > that anything updated voltages anyway...
>
>> I was just suggesting that when the core tells the regulator driver to
>> disable itself that the regulator driver tell RPMh to not only disable
>> itself but also (temporarily) vote for a lower voltage. When the core
>> tells the regulator to re-enable itself then the regulator driver
>> restores the original voltage vote (or applies any vote that might
>> have been attempted while the regulator was disabled). That wouldn't
>> require any regulator core changes.
>
> It needs something to tell it what the new voltage to set is.
The regulator driver has its own cache of what voltage was most
recently requested by Linux. It can use that, can't it?
-Doug
^ 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