* Re: [PATCH V6 16/21] soc/tegra: pmc: Add pmc wake support for tegra210
From: Dmitry Osipenko @ 2019-07-23 1:08 UTC (permalink / raw)
To: Sowjanya Komatineni, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland
Cc: pdeschrijver, pgaikwad, sboyd, linux-clk, linux-gpio, jckuo,
josephl, talho, linux-tegra, linux-kernel, mperttunen, spatra,
robh+dt, devicetree
In-Reply-To: <0b3d08ea-4633-8a54-ba66-c3f3146a1ece@gmail.com>
23.07.2019 3:58, Dmitry Osipenko пишет:
> 21.07.2019 22:40, Sowjanya Komatineni пишет:
>> This patch implements PMC wakeup sequence for Tegra210 and defines
>> common used RTC alarm wake event.
>>
>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>> ---
>> drivers/soc/tegra/pmc.c | 111 ++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 111 insertions(+)
>>
>> diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
>> index 91c84d0e66ae..c556f38874e1 100644
>> --- a/drivers/soc/tegra/pmc.c
>> +++ b/drivers/soc/tegra/pmc.c
>> @@ -57,6 +57,12 @@
>> #define PMC_CNTRL_SYSCLK_OE BIT(11) /* system clock enable */
>> #define PMC_CNTRL_SYSCLK_POLARITY BIT(10) /* sys clk polarity */
>> #define PMC_CNTRL_MAIN_RST BIT(4)
>> +#define PMC_CNTRL_LATCH_WAKEUPS BIT(5)
Please follow the TRM's bits naming.
PMC_CNTRL_LATCHWAKE_EN
>> +#define PMC_WAKE_MASK 0x0c
>> +#define PMC_WAKE_LEVEL 0x10
>> +#define PMC_WAKE_STATUS 0x14
>> +#define PMC_SW_WAKE_STATUS 0x18
>>
>> #define DPD_SAMPLE 0x020
>> #define DPD_SAMPLE_ENABLE BIT(0)
>> @@ -87,6 +93,11 @@
>>
>> #define PMC_SCRATCH41 0x140
>>
>> +#define PMC_WAKE2_MASK 0x160
>> +#define PMC_WAKE2_LEVEL 0x164
>> +#define PMC_WAKE2_STATUS 0x168
>> +#define PMC_SW_WAKE2_STATUS 0x16c
>> +
>> #define PMC_SENSOR_CTRL 0x1b0
>> #define PMC_SENSOR_CTRL_SCRATCH_WRITE BIT(2)
>> #define PMC_SENSOR_CTRL_ENABLE_RST BIT(1)
>> @@ -1922,6 +1933,55 @@ static const struct irq_domain_ops tegra_pmc_irq_domain_ops = {
>> .alloc = tegra_pmc_irq_alloc,
>> };
>>
>> +static int tegra210_pmc_irq_set_wake(struct irq_data *data, unsigned int on)
>> +{
>> + struct tegra_pmc *pmc = irq_data_get_irq_chip_data(data);
>> + unsigned int offset, bit;
>> + u32 value;
>> +
>> + if (data->hwirq == ULONG_MAX)
>> + return 0;
>> +
>> + offset = data->hwirq / 32;
>> + bit = data->hwirq % 32;
>> +
>> + /*
>> + * Latch wakeups to SW_WAKE_STATUS register to capture events
>> + * that would not make it into wakeup event register during LP0 exit.
>> + */
>> + value = tegra_pmc_readl(pmc, PMC_CNTRL);
>> + value |= PMC_CNTRL_LATCH_WAKEUPS;
>> + tegra_pmc_writel(pmc, value, PMC_CNTRL);
>> + udelay(120);
>
> Why it takes so much time to latch the values? Shouldn't some status-bit
> be polled for the completion of latching?
>
> Is this register-write really getting buffered in the PMC?
>
>> + value &= ~PMC_CNTRL_LATCH_WAKEUPS;
>> + tegra_pmc_writel(pmc, value, PMC_CNTRL);
>> + udelay(120);
>
> 120 usecs to remove latching, really?
>
>> + tegra_pmc_writel(pmc, 0, PMC_SW_WAKE_STATUS);
>> + tegra_pmc_writel(pmc, 0, PMC_SW_WAKE2_STATUS);
>> +
>> + tegra_pmc_writel(pmc, 0, PMC_WAKE_STATUS);
>> + tegra_pmc_writel(pmc, 0, PMC_WAKE2_STATUS);
>> +
>> + /* enable PMC wake */
>> + if (data->hwirq >= 32)
>> + offset = PMC_WAKE2_MASK;
>> + else
>> + offset = PMC_WAKE_MASK;
>> +
>> + value = tegra_pmc_readl(pmc, offset);
>> +
>> + if (on)
>> + value |= 1 << bit;
>> + else
>> + value &= ~(1 << bit);
>> +
>> + tegra_pmc_writel(pmc, value, offset);
>
> Why the latching is done *before* writing into the WAKE registers? What
> it is latching then?
I'm looking at the TRM doc and it says that latching should be done
*after* writing to the WAKE_MASK / LEVEL registers.
Secondly it says that it's enough to do:
value = tegra_pmc_readl(pmc, PMC_CNTRL);
value |= PMC_CNTRL_LATCH_WAKEUPS;
tegra_pmc_writel(pmc, value, PMC_CNTRL);
in order to latch. There is no need for the delay and to remove the
"LATCHWAKE_EN" bit, it should be a oneshot action.
>> + return 0;
>> +}
>> +
>> static int tegra186_pmc_irq_set_wake(struct irq_data *data, unsigned int on)
>> {
>> struct tegra_pmc *pmc = irq_data_get_irq_chip_data(data);
>> @@ -1954,6 +2014,49 @@ static int tegra186_pmc_irq_set_wake(struct irq_data *data, unsigned int on)
>> return 0;
>> }
>>
>> +static int tegra210_pmc_irq_set_type(struct irq_data *data, unsigned int type)
>> +{
>> + struct tegra_pmc *pmc = irq_data_get_irq_chip_data(data);
>> + unsigned int offset, bit;
>> + u32 value;
>> +
>> + if (data->hwirq == ULONG_MAX)
>> + return 0;
>> +
>> + offset = data->hwirq / 32;
>> + bit = data->hwirq % 32;
>> +
>> + if (data->hwirq >= 32)
>> + offset = PMC_WAKE2_LEVEL;
>> + else
>> + offset = PMC_WAKE_LEVEL;
>> +
>> + value = tegra_pmc_readl(pmc, offset);
>> +
>> + switch (type) {
>> + case IRQ_TYPE_EDGE_RISING:
>> + case IRQ_TYPE_LEVEL_HIGH:
>> + value |= 1 << bit;
>> + break;
>> +
>> + case IRQ_TYPE_EDGE_FALLING:
>> + case IRQ_TYPE_LEVEL_LOW:
>> + value &= ~(1 << bit);
>> + break;
>> +
>> + case IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING:
>> + value ^= 1 << bit;
>> + break;
>> +
>> + default:
>> + return -EINVAL;
>> + }
>> +
>> + tegra_pmc_writel(pmc, value, offset);
>
> Shouldn't the WAKE_LEVEL be latched as well?
>
>> + return 0;
>> +}
>> +
>> static int tegra186_pmc_irq_set_type(struct irq_data *data, unsigned int type)
>> {
>> struct tegra_pmc *pmc = irq_data_get_irq_chip_data(data);
>> @@ -2540,6 +2643,10 @@ static const struct pinctrl_pin_desc tegra210_pin_descs[] = {
>> TEGRA210_IO_PAD_TABLE(TEGRA_IO_PIN_DESC)
>> };
>>
>> +static const struct tegra_wake_event tegra210_wake_events[] = {
>> + TEGRA_WAKE_IRQ("rtc", 16, 2),
>> +};
>> +
>> static const struct tegra_pmc_soc tegra210_pmc_soc = {
>> .num_powergates = ARRAY_SIZE(tegra210_powergates),
>> .powergates = tegra210_powergates,
>> @@ -2557,10 +2664,14 @@ static const struct tegra_pmc_soc tegra210_pmc_soc = {
>> .regs = &tegra20_pmc_regs,
>> .init = tegra20_pmc_init,
>> .setup_irq_polarity = tegra20_pmc_setup_irq_polarity,
>> + .irq_set_wake = tegra210_pmc_irq_set_wake,
>> + .irq_set_type = tegra210_pmc_irq_set_type,
>> .reset_sources = tegra210_reset_sources,
>> .num_reset_sources = ARRAY_SIZE(tegra210_reset_sources),
>> .reset_levels = NULL,
>> .num_reset_levels = 0,
>> + .num_wake_events = ARRAY_SIZE(tegra210_wake_events),
>> + .wake_events = tegra210_wake_events,
>> };
>>
>> #define TEGRA186_IO_PAD_TABLE(_pad) \
>>
>
^ permalink raw reply
* Re: [PATCH V6 16/21] soc/tegra: pmc: Add pmc wake support for tegra210
From: Dmitry Osipenko @ 2019-07-23 0:58 UTC (permalink / raw)
To: Sowjanya Komatineni, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland
Cc: pdeschrijver, pgaikwad, sboyd, linux-clk, linux-gpio, jckuo,
josephl, talho, linux-tegra, linux-kernel, mperttunen, spatra,
robh+dt, devicetree
In-Reply-To: <1563738060-30213-17-git-send-email-skomatineni@nvidia.com>
21.07.2019 22:40, Sowjanya Komatineni пишет:
> This patch implements PMC wakeup sequence for Tegra210 and defines
> common used RTC alarm wake event.
>
> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
> ---
> drivers/soc/tegra/pmc.c | 111 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 111 insertions(+)
>
> diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
> index 91c84d0e66ae..c556f38874e1 100644
> --- a/drivers/soc/tegra/pmc.c
> +++ b/drivers/soc/tegra/pmc.c
> @@ -57,6 +57,12 @@
> #define PMC_CNTRL_SYSCLK_OE BIT(11) /* system clock enable */
> #define PMC_CNTRL_SYSCLK_POLARITY BIT(10) /* sys clk polarity */
> #define PMC_CNTRL_MAIN_RST BIT(4)
> +#define PMC_CNTRL_LATCH_WAKEUPS BIT(5)
> +
> +#define PMC_WAKE_MASK 0x0c
> +#define PMC_WAKE_LEVEL 0x10
> +#define PMC_WAKE_STATUS 0x14
> +#define PMC_SW_WAKE_STATUS 0x18
>
> #define DPD_SAMPLE 0x020
> #define DPD_SAMPLE_ENABLE BIT(0)
> @@ -87,6 +93,11 @@
>
> #define PMC_SCRATCH41 0x140
>
> +#define PMC_WAKE2_MASK 0x160
> +#define PMC_WAKE2_LEVEL 0x164
> +#define PMC_WAKE2_STATUS 0x168
> +#define PMC_SW_WAKE2_STATUS 0x16c
> +
> #define PMC_SENSOR_CTRL 0x1b0
> #define PMC_SENSOR_CTRL_SCRATCH_WRITE BIT(2)
> #define PMC_SENSOR_CTRL_ENABLE_RST BIT(1)
> @@ -1922,6 +1933,55 @@ static const struct irq_domain_ops tegra_pmc_irq_domain_ops = {
> .alloc = tegra_pmc_irq_alloc,
> };
>
> +static int tegra210_pmc_irq_set_wake(struct irq_data *data, unsigned int on)
> +{
> + struct tegra_pmc *pmc = irq_data_get_irq_chip_data(data);
> + unsigned int offset, bit;
> + u32 value;
> +
> + if (data->hwirq == ULONG_MAX)
> + return 0;
> +
> + offset = data->hwirq / 32;
> + bit = data->hwirq % 32;
> +
> + /*
> + * Latch wakeups to SW_WAKE_STATUS register to capture events
> + * that would not make it into wakeup event register during LP0 exit.
> + */
> + value = tegra_pmc_readl(pmc, PMC_CNTRL);
> + value |= PMC_CNTRL_LATCH_WAKEUPS;
> + tegra_pmc_writel(pmc, value, PMC_CNTRL);
> + udelay(120);
Why it takes so much time to latch the values? Shouldn't some status-bit
be polled for the completion of latching?
Is this register-write really getting buffered in the PMC?
> + value &= ~PMC_CNTRL_LATCH_WAKEUPS;
> + tegra_pmc_writel(pmc, value, PMC_CNTRL);
> + udelay(120);
120 usecs to remove latching, really?
> + tegra_pmc_writel(pmc, 0, PMC_SW_WAKE_STATUS);
> + tegra_pmc_writel(pmc, 0, PMC_SW_WAKE2_STATUS);
> +
> + tegra_pmc_writel(pmc, 0, PMC_WAKE_STATUS);
> + tegra_pmc_writel(pmc, 0, PMC_WAKE2_STATUS);
> +
> + /* enable PMC wake */
> + if (data->hwirq >= 32)
> + offset = PMC_WAKE2_MASK;
> + else
> + offset = PMC_WAKE_MASK;
> +
> + value = tegra_pmc_readl(pmc, offset);
> +
> + if (on)
> + value |= 1 << bit;
> + else
> + value &= ~(1 << bit);
> +
> + tegra_pmc_writel(pmc, value, offset);
Why the latching is done *before* writing into the WAKE registers? What
it is latching then?
> + return 0;
> +}
> +
> static int tegra186_pmc_irq_set_wake(struct irq_data *data, unsigned int on)
> {
> struct tegra_pmc *pmc = irq_data_get_irq_chip_data(data);
> @@ -1954,6 +2014,49 @@ static int tegra186_pmc_irq_set_wake(struct irq_data *data, unsigned int on)
> return 0;
> }
>
> +static int tegra210_pmc_irq_set_type(struct irq_data *data, unsigned int type)
> +{
> + struct tegra_pmc *pmc = irq_data_get_irq_chip_data(data);
> + unsigned int offset, bit;
> + u32 value;
> +
> + if (data->hwirq == ULONG_MAX)
> + return 0;
> +
> + offset = data->hwirq / 32;
> + bit = data->hwirq % 32;
> +
> + if (data->hwirq >= 32)
> + offset = PMC_WAKE2_LEVEL;
> + else
> + offset = PMC_WAKE_LEVEL;
> +
> + value = tegra_pmc_readl(pmc, offset);
> +
> + switch (type) {
> + case IRQ_TYPE_EDGE_RISING:
> + case IRQ_TYPE_LEVEL_HIGH:
> + value |= 1 << bit;
> + break;
> +
> + case IRQ_TYPE_EDGE_FALLING:
> + case IRQ_TYPE_LEVEL_LOW:
> + value &= ~(1 << bit);
> + break;
> +
> + case IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING:
> + value ^= 1 << bit;
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> +
> + tegra_pmc_writel(pmc, value, offset);
Shouldn't the WAKE_LEVEL be latched as well?
> + return 0;
> +}
> +
> static int tegra186_pmc_irq_set_type(struct irq_data *data, unsigned int type)
> {
> struct tegra_pmc *pmc = irq_data_get_irq_chip_data(data);
> @@ -2540,6 +2643,10 @@ static const struct pinctrl_pin_desc tegra210_pin_descs[] = {
> TEGRA210_IO_PAD_TABLE(TEGRA_IO_PIN_DESC)
> };
>
> +static const struct tegra_wake_event tegra210_wake_events[] = {
> + TEGRA_WAKE_IRQ("rtc", 16, 2),
> +};
> +
> static const struct tegra_pmc_soc tegra210_pmc_soc = {
> .num_powergates = ARRAY_SIZE(tegra210_powergates),
> .powergates = tegra210_powergates,
> @@ -2557,10 +2664,14 @@ static const struct tegra_pmc_soc tegra210_pmc_soc = {
> .regs = &tegra20_pmc_regs,
> .init = tegra20_pmc_init,
> .setup_irq_polarity = tegra20_pmc_setup_irq_polarity,
> + .irq_set_wake = tegra210_pmc_irq_set_wake,
> + .irq_set_type = tegra210_pmc_irq_set_type,
> .reset_sources = tegra210_reset_sources,
> .num_reset_sources = ARRAY_SIZE(tegra210_reset_sources),
> .reset_levels = NULL,
> .num_reset_levels = 0,
> + .num_wake_events = ARRAY_SIZE(tegra210_wake_events),
> + .wake_events = tegra210_wake_events,
> };
>
> #define TEGRA186_IO_PAD_TABLE(_pad) \
>
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: aspeed: tiogapass: Add VR devices
From: Andrew Jeffery @ 2019-07-23 0:41 UTC (permalink / raw)
To: Vijay Khemka, Rob Herring, Mark Rutland, Joel Stanley, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel
Cc: openbmc @ lists . ozlabs . org, Sai Dasari
In-Reply-To: <20190723003216.2910042-1-vijaykhemka@fb.com>
On Tue, 23 Jul 2019, at 10:04, Vijay Khemka wrote:
> Adds voltage regulators Infineon pxe1610 devices to Facebook
> tiogapass platform.
>
> Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
Acked-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> In v2: Renamed vr to regulator and fixed some typo in commit message.
>
> .../dts/aspeed-bmc-facebook-tiogapass.dts | 36 +++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
> b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
> index c4521eda787c..e722e9aef907 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
> @@ -144,6 +144,42 @@
> &i2c5 {
> status = "okay";
> // CPU Voltage regulators
> + regulator@48 {
> + compatible = "infineon,pxe1610";
> + reg = <0x48>;
> + };
> + regulator@4a {
> + compatible = "infineon,pxe1610";
> + reg = <0x4a>;
> + };
> + regulator@50 {
> + compatible = "infineon,pxe1610";
> + reg = <0x50>;
> + };
> + regulator@52 {
> + compatible = "infineon,pxe1610";
> + reg = <0x52>;
> + };
> + regulator@58 {
> + compatible = "infineon,pxe1610";
> + reg = <0x58>;
> + };
> + regulator@5a {
> + compatible = "infineon,pxe1610";
> + reg = <0x5a>;
> + };
> + regulator@68 {
> + compatible = "infineon,pxe1610";
> + reg = <0x68>;
> + };
> + regulator@70 {
> + compatible = "infineon,pxe1610";
> + reg = <0x70>;
> + };
> + regulator@72 {
> + compatible = "infineon,pxe1610";
> + reg = <0x72>;
> + };
> };
>
> &i2c6 {
> --
> 2.17.1
>
>
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: aspeed: tiogapass: Add VR devices
From: Vijay Khemka @ 2019-07-23 0:33 UTC (permalink / raw)
To: Andrew Jeffery, Jean Delvare, Guenter Roeck, Rob Herring,
Mark Rutland, Joel Stanley, linux-hwmon@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org
Cc: openbmc @ lists . ozlabs . org, Sai Dasari
In-Reply-To: <802c5419-08ec-4a0e-8a50-ad4a1bbf7f3a@www.fastmail.com>
On 7/22/19, 5:12 PM, "Andrew Jeffery" <andrew@aj.id.au> wrote:
Hi Vijay,
A few nitpicks.
On Tue, 23 Jul 2019, at 05:10, Vijay Khemka wrote:
> Addes
Typo: Adds
Ack
> Voltage
Unnecessary capitalisation.
Ack
> regulators Infineon pxe1610 devices to Facebook
> tiogapass platform.
>
> Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
> ---
> .../dts/aspeed-bmc-facebook-tiogapass.dts | 36 +++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
> b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
> index c4521eda787c..b7783833a58c 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
> @@ -144,6 +144,42 @@
> &i2c5 {
> status = "okay";
> // CPU Voltage regulators
> + vr@48 {
The recommended generic name is 'regulator', so e.g. regulator@48
Ack: Submitted v2 for this patch.
> + compatible = "infineon,pxe1610";
> + reg = <0x48>;
> + };
> + vr@4a {
> + compatible = "infineon,pxe1610";
> + reg = <0x4a>;
> + };
> + vr@50 {
> + compatible = "infineon,pxe1610";
> + reg = <0x50>;
> + };
> + vr@52 {
> + compatible = "infineon,pxe1610";
> + reg = <0x52>;
> + };
> + vr@58 {
> + compatible = "infineon,pxe1610";
> + reg = <0x58>;
> + };
> + vr@5a {
> + compatible = "infineon,pxe1610";
> + reg = <0x5a>;
> + };
> + vr@68 {
> + compatible = "infineon,pxe1610";
> + reg = <0x68>;
> + };
> + vr@70 {
> + compatible = "infineon,pxe1610";
> + reg = <0x70>;
> + };
> + vr@72 {
> + compatible = "infineon,pxe1610";
> + reg = <0x72>;
> + };
> };
>
> &i2c6 {
> --
> 2.17.1
>
>
_______________________________________________
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 v9 04/18] kunit: test: add kunit_stream a std::stream like logger
From: Brendan Higgins @ 2019-07-23 0:32 UTC (permalink / raw)
To: Stephen Boyd
Cc: Petr Mladek, open list:DOCUMENTATION, Peter Zijlstra,
Amir Goldstein, dri-devel, Sasha Levin, Masahiro Yamada,
Michael Ellerman, open list:KERNEL SELFTEST FRAMEWORK, shuah,
Rob Herring, linux-nvdimm, Frank Rowand, Knut Omang,
Kieran Bingham, wfg-VuQAYsv1563Yd54FQh9/CA, Joel Stanley,
David Rientjes, Jeff Dike, Dan Carpenter, devicetree,
linux-kbuild
In-Reply-To: <20190722235411.06C1320840-+nuXSHJNwjE76Z2rM5mHXA@public.gmane.org>
On Mon, Jul 22, 2019 at 4:54 PM Stephen Boyd <sboyd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
> Quoting Brendan Higgins (2019-07-22 15:30:49)
> > On Mon, Jul 22, 2019 at 1:03 PM Stephen Boyd <sboyd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > >
> > >
> > > What's the calling context of the assertions and expectations? I still
> > > don't like the fact that string stream needs to allocate buffers and
> > > throw them into a list somewhere because the calling context matters
> > > there.
> >
> > The calling context is the same as before, which is anywhere.
>
> Ok. That's concerning then.
Yeah. Luis suggested just not supporting the IRQ context until later.
See my later comment.
> > > I'd prefer we just wrote directly to the console/log via printk
> > > instead. That way things are simple because we use the existing
> > > buffering path of printk, but maybe there's some benefit to the string
> > > stream that I don't see? Right now it looks like it builds a string and
> > > then dumps it to printk so I'm sort of lost what the benefit is over
> > > just writing directly with printk.
> >
> > It's just buffering it so the whole string gets printed uninterrupted.
> > If we were to print out piecemeal to printk, couldn't we have another
> > call to printk come in causing it to garble the KUnit message we are
> > in the middle of printing?
>
> Yes, printing piecemeal by calling printk many times could lead to
> interleaving of messages if something else comes in such as an interrupt
> printing something. Printk has some support to hold "records" but I'm
> not sure how that would work here because KERN_CONT talks about only
> being used early on in boot code. I haven't looked at printk in detail
> though so maybe I'm all wrong and KERN_CONT just works?
It says KERN_CONT is not SMP safe, and it isn't supposed to contain
newlines, so it doesn't sound like it does any buffering for you. I
looked at it a while ago and those comments agreed with my
understanding of the code, but I could be wrong.
> Can printk be called once with whatever is in the struct?
Unfortunately, no. That is part of what I was trying to illustrate
with this patch. Most of the messages are deterministic, but
hardcoding all the possible message types would lead to a massive
number of hard coded strings. However, even this would break down for
the mocking formatters. All the different ways a function can be
called are just too complex to encode into a finite set of hard coded
fmt strings.
> Otherwise if
> this is about making printk into a structured log then maybe printk
> isn't the proper solution anyway. Maybe a dev interface should be used
> instead that can handle starting and stopping tests (via ioctl) in
> addition to reading test results, records, etc. with read() and a
> clearing of the records. Then the seqfile API works naturally. All of
Ehhh...I wouldn't mind providing such an interface, but I would really
like to be able to provide the results without having to depend on a
userland doing something to get test results. That has always been a
pretty important goal for me.
> this is a bit premature, but it looks like you're going down the path of
> making something akin to ftrace that stores binary formatted
> assertion/expectation records in a lockless ring buffer that then
> formats those records when the user asks for them.
Like you said, I think it is a bit premature to go that far.
In anycase, I don't see a way to get rid of string_stream, without
significantly sacrificing usability.
> I can imagine someone wanting to write unit tests that check conditions
> from a simulated hardirq context via irq works (a driver mock
> framework?), so this doesn't seem far off.
Yep, I actually presented the first pieces of that in the RFC v1 that
I linked to you earlier in this discussion. I have a more fleshed out
example here:
https://kunit.googlesource.com/linux/+/e10484ad2f9fc7926412ec84739fe105981b4771/drivers/i2c/busses/i2c-aspeed-test.c
I actually already have some people at Google playing around with it.
So yeah, not far off at all! However, in these cases we are not
actually running in the IRQ context (despite the fact that we are
testing IRQ code) because we provide a fake IRQ chip, or some other
fake mechanism that triggers the IRQ. Still, I could see someone
wanting to do it in a non-fake-IRQ context.
Luis' suggestion was just to hold off on the IRQ safe stuff at the
outset, since that is going to require a lot more effort to review. I
know that's kind of the future coding argument again, but maybe the
answer will be to just restrict what features an IRQ user has access
to (maybe just really simple expectations, for example). I mean, we
will probably have to restrict what they are allowed to use anyway.
Luis, do you have any ideas?
Cheers
^ permalink raw reply
* [PATCH v2] ARM: dts: aspeed: tiogapass: Add VR devices
From: Vijay Khemka @ 2019-07-23 0:32 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Joel Stanley, Andrew Jeffery,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
Cc: openbmc @ lists . ozlabs . org, sdasari, vijaykhemka
Adds voltage regulators Infineon pxe1610 devices to Facebook
tiogapass platform.
Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
---
In v2: Renamed vr to regulator and fixed some typo in commit message.
.../dts/aspeed-bmc-facebook-tiogapass.dts | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
index c4521eda787c..e722e9aef907 100644
--- a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
@@ -144,6 +144,42 @@
&i2c5 {
status = "okay";
// CPU Voltage regulators
+ regulator@48 {
+ compatible = "infineon,pxe1610";
+ reg = <0x48>;
+ };
+ regulator@4a {
+ compatible = "infineon,pxe1610";
+ reg = <0x4a>;
+ };
+ regulator@50 {
+ compatible = "infineon,pxe1610";
+ reg = <0x50>;
+ };
+ regulator@52 {
+ compatible = "infineon,pxe1610";
+ reg = <0x52>;
+ };
+ regulator@58 {
+ compatible = "infineon,pxe1610";
+ reg = <0x58>;
+ };
+ regulator@5a {
+ compatible = "infineon,pxe1610";
+ reg = <0x5a>;
+ };
+ regulator@68 {
+ compatible = "infineon,pxe1610";
+ reg = <0x68>;
+ };
+ regulator@70 {
+ compatible = "infineon,pxe1610";
+ reg = <0x70>;
+ };
+ regulator@72 {
+ compatible = "infineon,pxe1610";
+ reg = <0x72>;
+ };
};
&i2c6 {
--
2.17.1
^ permalink raw reply related
* [PATCH] dt-bindings: Add pxe1610 as a trivial device
From: Vijay Khemka @ 2019-07-23 0:20 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Jiri Kosina, Guenter Roeck, Herbert Xu,
Patrick Venture, Ard Biesheuvel, Vijay Khemka, Anson Huang,
Jeremy Gebben, devicetree, linux-kernel
Cc: openbmc @ lists . ozlabs . org, joel, linux-aspeed, sdasari
The pxe1610 is a voltage regulator from Infineon. It also supports
other VRs pxe1110 and pxm1310 from Infineon.
Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
---
Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
index 2e742d399e87..1be648828a31 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -99,6 +99,8 @@ properties:
# Infineon IR38064 Voltage Regulator
- infineon,ir38064
# Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz)
+ - infineon,pxe1610
+ # Infineon PXE1610, PXE1110 and PXM1310 Voltage Regulators
- infineon,slb9635tt
# Infineon SLB9645 I2C TPM (new protocol, max 400khz)
- infineon,slb9645tt
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] dt-bindings: hwmon: Add binding for pxe1610
From: Vijay Khemka @ 2019-07-23 0:12 UTC (permalink / raw)
To: Guenter Roeck
Cc: Mark Rutland, linux-hwmon@vger.kernel.org, Jean Delvare,
Sai Dasari, linux-aspeed@lists.ozlabs.org,
devicetree@vger.kernel.org, Andrew Jeffery,
openbmc @ lists . ozlabs . org, linux-kernel@vger.kernel.org,
Rob Herring, Joel Stanley, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190722200622.GA20435@roeck-us.net>
On 7/22/19, 1:06 PM, "Guenter Roeck" <groeck7@gmail.com on behalf of linux@roeck-us.net> wrote:
On Mon, Jul 22, 2019 at 12:24:48PM -0700, Vijay Khemka wrote:
> Added new DT binding document for Infineon PXE1610 devices.
>
> Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
> ---
> .../devicetree/bindings/hwmon/pxe1610.txt | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/pxe1610.txt
>
> diff --git a/Documentation/devicetree/bindings/hwmon/pxe1610.txt b/Documentation/devicetree/bindings/hwmon/pxe1610.txt
> new file mode 100644
> index 000000000000..635daf4955db
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/pxe1610.txt
> @@ -0,0 +1,15 @@
> +pxe1610 properties
> +
> +Required properties:
> +- compatible: Must be one of the following:
> + - "infineon,pxe1610" for pxe1610
> + - "infineon,pxe1110" for pxe1610
> + - "infineon,pxm1310" for pxm1310
> +- reg: I2C address
> +
> +Example:
> +
> +vr@48 {
> + compatible = "infineon,pxe1610";
> + reg = <0x48>;
> +};
Wouldn't it be better to add this to
./Documentation/devicetree/bindings/trivial-devices.txt ?
Sure, I didn't know about this file. I will add and send another patch. It is
Documentation/devicetree/bindings/trivial-devices.yaml. How do I abandon
this patch or just leave it.
Thanks,
Guenter
_______________________________________________
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] ARM: dts: aspeed: tiogapass: Add VR devices
From: Andrew Jeffery @ 2019-07-23 0:11 UTC (permalink / raw)
To: Vijay Khemka, Jean Delvare, Guenter Roeck, Rob Herring,
Mark Rutland, Joel Stanley, linux-hwmon, devicetree, linux-kernel,
linux-arm-kernel, linux-aspeed
Cc: openbmc @ lists . ozlabs . org, Sai Dasari
In-Reply-To: <20190722192451.1947348-1-vijaykhemka@fb.com>
Hi Vijay,
A few nitpicks.
On Tue, 23 Jul 2019, at 05:10, Vijay Khemka wrote:
> Addes
Typo: Adds
> Voltage
Unnecessary capitalisation.
> regulators Infineon pxe1610 devices to Facebook
> tiogapass platform.
>
> Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
> ---
> .../dts/aspeed-bmc-facebook-tiogapass.dts | 36 +++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
> b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
> index c4521eda787c..b7783833a58c 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
> @@ -144,6 +144,42 @@
> &i2c5 {
> status = "okay";
> // CPU Voltage regulators
> + vr@48 {
The recommended generic name is 'regulator', so e.g. regulator@48
> + compatible = "infineon,pxe1610";
> + reg = <0x48>;
> + };
> + vr@4a {
> + compatible = "infineon,pxe1610";
> + reg = <0x4a>;
> + };
> + vr@50 {
> + compatible = "infineon,pxe1610";
> + reg = <0x50>;
> + };
> + vr@52 {
> + compatible = "infineon,pxe1610";
> + reg = <0x52>;
> + };
> + vr@58 {
> + compatible = "infineon,pxe1610";
> + reg = <0x58>;
> + };
> + vr@5a {
> + compatible = "infineon,pxe1610";
> + reg = <0x5a>;
> + };
> + vr@68 {
> + compatible = "infineon,pxe1610";
> + reg = <0x68>;
> + };
> + vr@70 {
> + compatible = "infineon,pxe1610";
> + reg = <0x70>;
> + };
> + vr@72 {
> + compatible = "infineon,pxe1610";
> + reg = <0x72>;
> + };
> };
>
> &i2c6 {
> --
> 2.17.1
>
>
^ permalink raw reply
* Re: [PATCH] hwmon: Remove ads1015 driver
From: Guenter Roeck @ 2019-07-23 0:07 UTC (permalink / raw)
To: Rob Herring
Cc: Jonathan Cameron, devicetree, linux-hwmon, linux-kernel,
linux-iio, Dirk Eibach
In-Reply-To: <20190722223944.GA9166@bogus>
On Mon, Jul 22, 2019 at 04:39:44PM -0600, Rob Herring wrote:
> On Mon, Jul 01, 2019 at 11:12:38AM -0700, Guenter Roeck wrote:
> > A driver for ADS1015 with more functionality is available in the iio
> > subsystem.
> >
> > Remove the hwmon driver as duplicate. If the chip is used for hardware
> > monitoring, the iio->hwmon bridge should be used.
> >
> > Cc: Dirk Eibach <eibach@gdsys.de>
> > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> > ---
> > Current plan is to queue this removal for v5.4 (not v5.3) in the hwmon
> > tree.
> >
> > .../devicetree/bindings/hwmon/ads1015.txt | 73 -----
> > .../devicetree/bindings/iio/adc/ads1015.txt | 73 +++++
>
> I assume no change or I should review it again?
>
It is identical.
> Acked-by: Rob Herring <robh@kernel.org>
>
Thanks,
Guenter
> > Documentation/hwmon/ads1015.rst | 90 ------
> > Documentation/hwmon/index.rst | 1 -
> > MAINTAINERS | 8 -
> > drivers/hwmon/Kconfig | 10 -
> > drivers/hwmon/Makefile | 1 -
> > drivers/hwmon/ads1015.c | 324 ---------------------
> > drivers/iio/adc/Kconfig | 2 +-
> > 9 files changed, 74 insertions(+), 508 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/hwmon/ads1015.txt
> > create mode 100644 Documentation/devicetree/bindings/iio/adc/ads1015.txt
> > delete mode 100644 Documentation/hwmon/ads1015.rst
> > delete mode 100644 drivers/hwmon/ads1015.c
^ permalink raw reply
* Re: [PATCH 2/3] ath10k: Move regulator config to driver private data
From: Bjorn Andersson @ 2019-07-22 23:57 UTC (permalink / raw)
To: Govind Singh
Cc: ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20190703035711.25592-3-govinds-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Tue 02 Jul 20:57 PDT 2019, Govind Singh wrote:
> WCN3990 Regulator config is varying b/w different MSM platforms.
> In order to have scalable config, move regulator config to driver
> private data.
>
Regulators supplying clients with fixed voltage requirements should be
specified in the board devicetree with these required voltage values,
rather than in the driver. So the appropriate solution is not to add
and adjust these values but rather to drop this code from the driver.
I was about to send a patch that does this, because I have an SDM845
device where the voltage constraints specified on board level does not
meet the ranges specified here in the driver.
Regards,
Bjorn
> Signed-off-by: Govind Singh <govinds-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
> drivers/net/wireless/ath/ath10k/snoc.c | 38 +++++++++++++++++++++-----
> drivers/net/wireless/ath/ath10k/snoc.h | 23 +++++++++-------
> 2 files changed, 44 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
> index ca1186ec4129..bd7d97924fe0 100644
> --- a/drivers/net/wireless/ath/ath10k/snoc.c
> +++ b/drivers/net/wireless/ath/ath10k/snoc.c
> @@ -36,13 +36,20 @@ static char *const ce_name[] = {
> "WLAN_CE_11",
> };
>
> -static struct ath10k_vreg_info vreg_cfg[] = {
> +static struct ath10k_vreg_info sdm845_reg_cfg[] = {
> {NULL, "vdd-0.8-cx-mx", 800000, 850000, 0, 0, false},
> {NULL, "vdd-1.8-xo", 1800000, 1850000, 0, 0, false},
> {NULL, "vdd-1.3-rfa", 1300000, 1350000, 0, 0, false},
> {NULL, "vdd-3.3-ch0", 3300000, 3350000, 0, 0, false},
> };
>
> +static struct ath10k_vreg_info qcs40x_reg_cfg[] = {
> + {NULL, "vdd-0.8-cx-mx", 1224000, 1224000, 0, 0, false},
> + {NULL, "vdd-1.8-xo", 1800000, 1850000, 0, 0, false},
> + {NULL, "vdd-1.3-rfa", 1300000, 1350000, 0, 0, false},
> + {NULL, "vdd-3.3-ch0", 3300000, 3350000, 0, 0, false},
> +};
> +
> static struct ath10k_clk_info clk_cfg[] = {
> {NULL, "cxo_ref_clk_pin", 0, false},
> };
> @@ -54,10 +61,20 @@ static void ath10k_snoc_htt_rx_cb(struct ath10k_ce_pipe *ce_state);
> static void ath10k_snoc_htt_htc_rx_cb(struct ath10k_ce_pipe *ce_state);
> static void ath10k_snoc_pktlog_rx_cb(struct ath10k_ce_pipe *ce_state);
>
> -static const struct ath10k_snoc_drv_priv drv_priv = {
> +static const struct ath10k_snoc_drv_priv sdm845_wcn39xx_drv_priv = {
> + .hw_rev = ATH10K_HW_WCN3990,
> + .dma_mask = DMA_BIT_MASK(35),
> + .msa_size = 0x100000,
> + .vreg_cfg = sdm845_reg_cfg,
> + .vreg_count = ARRAY_SIZE(sdm845_reg_cfg),
> +};
> +
> +static const struct ath10k_snoc_drv_priv qcs40x_wcn39xx_drv_priv = {
> .hw_rev = ATH10K_HW_WCN3990,
> .dma_mask = DMA_BIT_MASK(35),
> .msa_size = 0x100000,
> + .vreg_cfg = qcs40x_reg_cfg,
> + .vreg_count = ARRAY_SIZE(qcs40x_reg_cfg),
> };
>
> #define WCN3990_SRC_WR_IDX_OFFSET 0x3C
> @@ -1465,7 +1482,7 @@ static int ath10k_snoc_vreg_on(struct ath10k *ar)
> int ret = 0;
> int i;
>
> - for (i = 0; i < ARRAY_SIZE(vreg_cfg); i++) {
> + for (i = 0; i < ar_snoc->vreg_count; i++) {
> vreg_info = &ar_snoc->vreg[i];
>
> if (!vreg_info->reg)
> @@ -1498,7 +1515,7 @@ static int ath10k_snoc_vreg_off(struct ath10k *ar)
> int ret = 0;
> int i;
>
> - for (i = ARRAY_SIZE(vreg_cfg) - 1; i >= 0; i--) {
> + for (i = ar_snoc->vreg_count - 1; i >= 0; i--) {
> vreg_info = &ar_snoc->vreg[i];
>
> if (!vreg_info->reg)
> @@ -1616,7 +1633,13 @@ static int ath10k_hw_power_off(struct ath10k *ar)
>
> static const struct of_device_id ath10k_snoc_dt_match[] = {
> { .compatible = "qcom,wcn3990-wifi",
> - .data = &drv_priv,
> + .data = &sdm845_wcn39xx_drv_priv,
> + },
> + { .compatible = "qcom,sdm845-wcn39xx-wifi",
> + .data = &sdm845_wcn39xx_drv_priv,
> + },
> + { .compatible = "qcom,qcs40x-wcn39xx-wifi",
> + .data = &qcs40x_wcn39xx_drv_priv,
> },
> { }
> };
> @@ -1680,8 +1703,9 @@ static int ath10k_snoc_probe(struct platform_device *pdev)
> goto err_release_resource;
> }
>
> - ar_snoc->vreg = vreg_cfg;
> - for (i = 0; i < ARRAY_SIZE(vreg_cfg); i++) {
> + ar_snoc->vreg = drv_data->vreg_cfg;
> + ar_snoc->vreg_count = drv_data->vreg_count;
> + for (i = 0; i < ar_snoc->vreg_count; i++) {
> ret = ath10k_get_vreg_info(ar, dev, &ar_snoc->vreg[i]);
> if (ret)
> goto err_free_irq;
> diff --git a/drivers/net/wireless/ath/ath10k/snoc.h b/drivers/net/wireless/ath/ath10k/snoc.h
> index d62f53501fbb..0bdada11985c 100644
> --- a/drivers/net/wireless/ath/ath10k/snoc.h
> +++ b/drivers/net/wireless/ath/ath10k/snoc.h
> @@ -10,10 +10,22 @@
> #include "ce.h"
> #include "qmi.h"
>
> +struct ath10k_vreg_info {
> + struct regulator *reg;
> + const char *name;
> + u32 min_v;
> + u32 max_v;
> + u32 load_ua;
> + unsigned long settle_delay;
> + bool required;
> +};
> +
> struct ath10k_snoc_drv_priv {
> enum ath10k_hw_rev hw_rev;
> u64 dma_mask;
> u32 msa_size;
> + struct ath10k_vreg_info *vreg_cfg;
> + u8 vreg_count;
> };
>
> struct snoc_state {
> @@ -42,16 +54,6 @@ struct ath10k_snoc_ce_irq {
> u32 irq_line;
> };
>
> -struct ath10k_vreg_info {
> - struct regulator *reg;
> - const char *name;
> - u32 min_v;
> - u32 max_v;
> - u32 load_ua;
> - unsigned long settle_delay;
> - bool required;
> -};
> -
> struct ath10k_clk_info {
> struct clk *handle;
> const char *name;
> @@ -77,6 +79,7 @@ struct ath10k_snoc {
> struct ath10k_ce ce;
> struct timer_list rx_post_retry;
> struct ath10k_vreg_info *vreg;
> + u8 vreg_count;
> struct ath10k_clk_info *clk;
> struct ath10k_qmi *qmi;
> unsigned long flags;
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply
* Re: [PATCH V4 1/2] dt-bindings: reset: imx7: Add support for i.MX8MM
From: Rob Herring @ 2019-07-22 23:56 UTC (permalink / raw)
To: Anson.Huang
Cc: p.zabel, robh+dt, mark.rutland, shawnguo, s.hauer, kernel,
festevam, leonard.crestez, viresh.kumar, daniel.baluta, ping.bai,
devicetree, linux-arm-kernel, linux-kernel, Linux-imx
In-Reply-To: <20190705085406.22483-1-Anson.Huang@nxp.com>
On Fri, 5 Jul 2019 16:54:05 +0800, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> i.MX8MM can reuse i.MX8MQ's reset driver, update the compatible
> property and related info to support i.MX8MM.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Changes since V3:
> - Add comments to those reset indices to indicate which are NOT supported on i.MX8MM.
> ---
> .../devicetree/bindings/reset/fsl,imx7-src.txt | 6 +++--
> include/dt-bindings/reset/imx8mq-reset.h | 28 +++++++++++-----------
> 2 files changed, 18 insertions(+), 16 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/6] dt-bindings: thermal: qoriq: Add optional clocks property
From: Rob Herring @ 2019-07-22 23:55 UTC (permalink / raw)
To: Anson.Huang
Cc: rui.zhang, edubezval, daniel.lezcano, robh+dt, mark.rutland,
shawnguo, s.hauer, kernel, festevam, mturquette, sboyd, l.stach,
abel.vesa, andrew.smirnov, angus, ccaione, agx, leonard.crestez,
linux-pm, devicetree, linux-kernel, linux-arm-kernel, linux-clk,
Linux-imx
In-Reply-To: <20190705045612.27665-3-Anson.Huang@nxp.com>
On Fri, 5 Jul 2019 12:56:09 +0800, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> Some platforms have clock control for TMU, add optional
> clocks property to the binding doc.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Documentation/devicetree/bindings/thermal/qoriq-thermal.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH RESEND 1/1] dt-bindings: serial: lpuart: add the clock requirement for imx8qxp
From: Rob Herring @ 2019-07-22 23:55 UTC (permalink / raw)
Cc: mark.rutland, devicetree, daniel.baluta, fugang.duan, gregkh,
linux-kernel, robh+dt, festevam, shawnguo, linux-arm-kernel
In-Reply-To: <20190704134355.2402-1-fugang.duan@nxp.com>
On Thu, 4 Jul 2019 21:43:55 +0800, fugang.duan@nxp.com wrote:
> From: Fugang Duan <fugang.duan@nxp.com>
>
> Add the baud clock requirement for imx8qxp.
>
> Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
> ---
> Documentation/devicetree/bindings/serial/fsl-lpuart.txt | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: thermal: imx8mm-thermal: Add binding doc for i.MX8MM
From: Rob Herring @ 2019-07-22 23:54 UTC (permalink / raw)
To: Anson.Huang
Cc: rui.zhang, edubezval, daniel.lezcano, robh+dt, mark.rutland,
shawnguo, s.hauer, kernel, festevam, catalin.marinas, will,
leonard.crestez, daniel.baluta, ping.bai, olof, maxime.ripard,
jagan, bjorn.andersson, dinguyen, enric.balletbo,
marcin.juszkiewicz, linux-pm, devicetree, linux-arm-kernel,
linux-kernel, Linux-imx
In-Reply-To: <20190704091313.9516-2-Anson.Huang@nxp.com>
On Thu, 4 Jul 2019 17:13:10 +0800, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> Add thermal binding doc for Freescale's i.MX8MM Thermal Monitoring Unit.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/thermal/imx8mm-thermal.txt | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/thermal/imx8mm-thermal.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger
From: Stephen Boyd @ 2019-07-22 23:54 UTC (permalink / raw)
To: Brendan Higgins
Cc: Frank Rowand, Greg KH, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Luis Chamberlain, Peter Zijlstra, Rob Herring, shuah,
Theodore Ts'o, Masahiro Yamada, devicetree, dri-devel,
kunit-dev, open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, KERNEL
In-Reply-To: <CAFd5g45hdCxEavSxirr0un_uLzo5Z-J4gHRA06qjzcQrTzmjVg@mail.gmail.com>
Quoting Brendan Higgins (2019-07-22 15:30:49)
> On Mon, Jul 22, 2019 at 1:03 PM Stephen Boyd <sboyd@kernel.org> wrote:
> >
> >
> > What's the calling context of the assertions and expectations? I still
> > don't like the fact that string stream needs to allocate buffers and
> > throw them into a list somewhere because the calling context matters
> > there.
>
> The calling context is the same as before, which is anywhere.
Ok. That's concerning then.
>
> > I'd prefer we just wrote directly to the console/log via printk
> > instead. That way things are simple because we use the existing
> > buffering path of printk, but maybe there's some benefit to the string
> > stream that I don't see? Right now it looks like it builds a string and
> > then dumps it to printk so I'm sort of lost what the benefit is over
> > just writing directly with printk.
>
> It's just buffering it so the whole string gets printed uninterrupted.
> If we were to print out piecemeal to printk, couldn't we have another
> call to printk come in causing it to garble the KUnit message we are
> in the middle of printing?
Yes, printing piecemeal by calling printk many times could lead to
interleaving of messages if something else comes in such as an interrupt
printing something. Printk has some support to hold "records" but I'm
not sure how that would work here because KERN_CONT talks about only
being used early on in boot code. I haven't looked at printk in detail
though so maybe I'm all wrong and KERN_CONT just works?
Can printk be called once with whatever is in the struct? Otherwise if
this is about making printk into a structured log then maybe printk
isn't the proper solution anyway. Maybe a dev interface should be used
instead that can handle starting and stopping tests (via ioctl) in
addition to reading test results, records, etc. with read() and a
clearing of the records. Then the seqfile API works naturally. All of
this is a bit premature, but it looks like you're going down the path of
making something akin to ftrace that stores binary formatted
assertion/expectation records in a lockless ring buffer that then
formats those records when the user asks for them.
I can imagine someone wanting to write unit tests that check conditions
from a simulated hardirq context via irq works (a driver mock
framework?), so this doesn't seem far off.
^ permalink raw reply
* Re: [PATCH v2] pinctrl: msm8998: Squash TSIF pins together
From: Rob Herring @ 2019-07-22 23:53 UTC (permalink / raw)
To: Marc Gonzalez
Cc: DT, Jeffrey Hugo, MSM, Linus Walleij, Jonathan Neuschäfer,
Bjorn Andersson, gpio, Linux ARM
In-Reply-To: <503b2ae8-ead6-70cd-7b21-ce5f5166a23a@free.fr>
On Thu, Jul 04, 2019 at 10:57:06AM +0200, Marc Gonzalez wrote:
> TSIF is the Transport Stream Interface.
> First, rename tsif1 to tsif0, and tsif2 to tsif1.
> Then squash all 5 tsif0 pins into a single function.
> Same for tsif1.
Doesn't this break backwards compatibility? If so, you should say so and
say why that's okay for this platform. In any case, whether it's a
problem or not is up to the platform maintainer(s).
>
> Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
> ---
> Changes from v1:
> - Reword commit message for clarity (hopefully)
> - Drop unrelated change in qcom,msm8998-pinctrl.txt
> - CC DT
> ---
> .../bindings/pinctrl/qcom,msm8998-pinctrl.txt | 5 +-
Acked-by: Rob Herring <robh@kernel.org>
> drivers/pinctrl/qcom/pinctrl-msm8998.c | 76 +++++--------------
> 2 files changed, 20 insertions(+), 61 deletions(-)
^ permalink raw reply
* Re: [RFC,V2,1/2] media: dt-bindings: media: i2c: Add bindings for OV02A10
From: Rob Herring @ 2019-07-22 23:49 UTC (permalink / raw)
To: dongchun.zhu-NuS5LvNUpcJWk0Htik3J/w
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
shengnan.wang-NuS5LvNUpcJWk0Htik3J/w,
--to=drinkcat-F7+t8E8rja9g9hUCZPvPmw,
tfiga-F7+t8E8rja9g9hUCZPvPmw, louis.kuo-NuS5LvNUpcJWk0Htik3J/w,
sj.huang-NuS5LvNUpcJWk0Htik3J/w,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
bingbu.cao-ral2JQCrhuEAvxtiuMwx3w, mchehab-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20190704084651.3105-2-dongchun.zhu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Thu, Jul 04, 2019 at 04:46:50PM +0800, dongchun.zhu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> From: Dongchun Zhu <dongchun.zhu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> Add device tree binding documentation for the OV02A10 camera sensor.
>
> Signed-off-by: Dongchun Zhu <dongchun.zhu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/media/i2c/ov02a10.txt | 43 ++++++++++++++++++++++
> MAINTAINERS | 7 ++++
> 2 files changed, 50 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov02a10.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov02a10.txt b/Documentation/devicetree/bindings/media/i2c/ov02a10.txt
> new file mode 100644
> index 0000000..d40aa87
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov02a10.txt
> @@ -0,0 +1,43 @@
> +* Omnivision OV02A10 MIPI CSI-2 sensor
> +
> +Required Properties:
> +- compatible: shall be "ovti,ov02a10"
> +- clocks: reference to the xvclk input clock
> +- clock-names: shall be "xvclk"
> +- avdd-supply: Analog voltage supply, 2.8 volts
> +- dovdd-supply: Digital I/O voltage supply, 1.8 volts
> +- dvdd-supply: Digital core voltage supply, 1.8 volts
> +- reset-gpios: Low active reset gpio
> +
> +The device node shall contain one 'port' child node with an
> +'endpoint' subnode for its digital output video port,
> +in accordance with the video interface bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> +The endpoint optional property 'data-lanes' shall be "<1>".
> +
> +Example:
> +&i2c4 {
> + ov02a10: camera-sensor@3d {
> + compatible = "ovti,ov02a10";
> + reg = <0x3d>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&camera_pins_cam1_mclk_on>;
> +
> + clocks = <&topckgen CLK_TOP_MUX_CAMTG2>,
> + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> + clock-names = "xvclk", "freq_mux";
> +
> + avdd-supply = <&mt6358_vcama1_reg>;
> + dvdd-supply = <&mt6358_vcn18_reg>;
> + dovdd-supply = <&mt6358_vcamio_reg>;
> + pwdn-gpios = <&pio 107 1>;
Not documented. If you need this, use 'powerdown-gpios' instead.
> + reset-gpios = <&pio 109 1>;
> +
> + port {
> + ov02a10_core: endpoint {
> + remote-endpoint = <&ov02a10_0>;
> + data-lanes = <1>;
> + };
> + };
> + };
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5cfbea4..62b81ff 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11571,6 +11571,13 @@ T: git git://linuxtv.org/media_tree.git
> S: Maintained
> F: drivers/media/i2c/ov13858.c
>
> +OMNIVISION OV02A10 SENSOR DRIVER
> +M: Dongchun Zhu <dongchun.zhu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> +L: linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +T: git git://linuxtv.org/media_tree.git
> +S: Maintained
> +F: Documentation/devicetree/bindings/media/i2c/ov02a10.txt
> +
> OMNIVISION OV2680 SENSOR DRIVER
> M: Rui Miguel Silva <rmfrfs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> L: linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> --
> 2.9.2
>
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: media: i2c: Add IMX290 CMOS sensor binding
From: Rob Herring @ 2019-07-22 23:48 UTC (permalink / raw)
Cc: mchehab, robh+dt, linux-media, linux-kernel, devicetree,
linux-arm-kernel, c.barrett, a.brela, Manivannan Sadhasivam
In-Reply-To: <20190703190230.12392-2-manivannan.sadhasivam@linaro.org>
On Thu, 4 Jul 2019 00:32:28 +0530, Manivannan Sadhasivam wrote:
> Add devicetree binding for IMX290 CMOS image sensor.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> .../devicetree/bindings/media/i2c/imx290.txt | 51 +++++++++++++++++++
> 1 file changed, 51 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/imx290.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v6 0/7] Solve postboot supplier cleanup and optimize probe ordering
From: Saravana Kannan @ 2019-07-22 23:47 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Rafael J. Wysocki,
Frank Rowand
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
David Collins, Android Kernel Team
In-Reply-To: <20190720061647.234852-1-saravanak@google.com>
On Fri, Jul 19, 2019 at 11:16 PM Saravana Kannan <saravanak@google.com> wrote:
>
> Add device-links to track functional dependencies between devices
> after they are created (but before they are probed) by looking at
> their common DT bindings like clocks, interconnects, etc.
>
> Having functional dependencies automatically added before the devices
> are probed, provides the following benefits:
>
> - Optimizes device probe order and avoids the useless work of
> attempting probes of devices that will not probe successfully
> (because their suppliers aren't present or haven't probed yet).
>
> For example, in a commonly available mobile SoC, registering just
> one consumer device's driver at an initcall level earlier than the
> supplier device's driver causes 11 failed probe attempts before the
> consumer device probes successfully. This was with a kernel with all
> the drivers statically compiled in. This problem gets a lot worse if
> all the drivers are loaded as modules without direct symbol
> dependencies.
>
> - Supplier devices like clock providers, interconnect providers, etc
> need to keep the resources they provide active and at a particular
> state(s) during boot up even if their current set of consumers don't
> request the resource to be active. This is because the rest of the
> consumers might not have probed yet and turning off the resource
> before all the consumers have probed could lead to a hang or
> undesired user experience.
>
> Some frameworks (Eg: regulator) handle this today by turning off
> "unused" resources at late_initcall_sync and hoping all the devices
> have probed by then. This is not a valid assumption for systems with
> loadable modules. Other frameworks (Eg: clock) just don't handle
> this due to the lack of a clear signal for when they can turn off
> resources. This leads to downstream hacks to handle cases like this
> that can easily be solved in the upstream kernel.
>
> By linking devices before they are probed, we give suppliers a clear
> count of the number of dependent consumers. Once all of the
> consumers are active, the suppliers can turn off the unused
> resources without making assumptions about the number of consumers.
>
> By default we just add device-links to track "driver presence" (probe
> succeeded) of the supplier device. If any other functionality provided
> by device-links are needed, it is left to the consumer/supplier
> devices to change the link when they probe.
>
> v1 -> v2:
> - Drop patch to speed up of_find_device_by_node()
> - Drop depends-on property and use existing bindings
>
> v2 -> v3:
> - Refactor the code to have driver core initiate the linking of devs
> - Have driver core link consumers to supplier before it's probed
> - Add support for drivers to edit the device links before probing
>
> v3 -> v4:
> - Tested edit_links() on system with cyclic dependency. Works.
> - Added some checks to make sure device link isn't attempted from
> parent device node to child device node.
> - Added way to pause/resume sync_state callbacks across
> of_platform_populate().
> - Recursively parse DT node to create device links from parent to
> suppliers of parent and all child nodes.
>
> v4 -> v5:
> - Fixed copy-pasta bugs with linked list handling
> - Walk up the phandle reference till I find an actual device (needed
> for regulators to work)
> - Added support for linking devices from regulator DT bindings
> - Tested the whole series again to make sure cyclic dependencies are
> broken with edit_links() and regulator links are created properly.
>
> v5 -> v6:
> - Split, squashed and reordered some of the patches.
> - Refactored the device linking code to follow the same code pattern for
> any property.
>
> I've also not updated this patch series to handle the new patch [1] from
> Rafael. Will do that once this patch series is close to being Acked.
>
> [1] - https://lore.kernel.org/lkml/3121545.4lOhFoIcdQ@kreacher/
>
> -Saravana
>
>
> Saravana Kannan (7):
> driver core: Add support for linking devices during device addition
> driver core: Add edit_links() callback for drivers
> of/platform: Add functional dependency link from DT bindings
> driver core: Add sync_state driver/bus callback
> of/platform: Pause/resume sync state during init and
> of_platform_populate()
> of/platform: Create device links for all child-supplier depencencies
> of/platform: Don't create device links for default busses
>
> .../admin-guide/kernel-parameters.txt | 5 +
> drivers/base/core.c | 168 ++++++++++++++++
> drivers/base/dd.c | 29 +++
> drivers/of/platform.c | 182 ++++++++++++++++++
> include/linux/device.h | 47 +++++
> 5 files changed, 431 insertions(+)
Update: Tested this refactor on hardware by backporting to a 4.14
kernel. Works just as it did before the refactor.
Also, nudge to make sure this series isn't lost over the weekend email snooze.
-Saravana
^ permalink raw reply
* Re: [PATCH v5 2/2] dt-bindings: mtd: Document Macronix raw NAND controller bindings
From: Rob Herring @ 2019-07-22 23:46 UTC (permalink / raw)
To: Mason Yang
Cc: miquel.raynal, marek.vasut, bbrezillon, dwmw2, computersforpeace,
vigneshr, richard, stefan, mark.rutland, linux-kernel, linux-mtd,
juliensu, paul.burton, liang.yang, lee.jones, anders.roxell,
christophe.kerello, paul, devicetree
In-Reply-To: <1562138144-2212-3-git-send-email-masonccyang@mxic.com.tw>
On Wed, Jul 03, 2019 at 03:15:44PM +0800, Mason Yang wrote:
> Document the bindings used by the Macronix raw NAND controller.
>
> Signed-off-by: Mason Yang <masonccyang@mxic.com.tw>
> ---
> Documentation/devicetree/bindings/mtd/mxic-nand.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/mxic-nand.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/mxic-nand.txt b/Documentation/devicetree/bindings/mtd/mxic-nand.txt
> new file mode 100644
> index 0000000..ddd7660
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/mxic-nand.txt
> @@ -0,0 +1,20 @@
> +Macronix Raw NAND Controller Device Tree Bindings
> +-------------------------------------------------
> +
> +Required properties:
> +- compatible: should be "macronix,nand-controller"
That's not very specific. There's only 1 version of this h/w?
> +- reg: should contain 1 entrie for the registers
s/entrie/entry/
> +- interrupts: interrupt line connected to this raw NAND controller
> +- clock-names: should contain "ps_clk", "send_clk" and "send_dly_clk"
> +- clocks: should contain 3 phandles for the "ps_clk", "send_clk" and
> + "send_dly_clk" clocks
You can drop '_clk' as that is redundant.
> +
> +Example:
> +
> + nand: mxic-nfc@43c30000 {
> + compatible = "macronix,nand-controller";
> + reg = <0x43c30000 0x10000>;
> + reg-names = "regs";
Not documented. You can drop as *-names is not generally useful when
there is only 1 entry.
> + clocks = <&clkwizard 0>, <&clkwizard 1>, <&clkc 15>;
> + clock-names = "send_clk", "send_dly_clk", "ps_clk";
> + };
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH v3 5/6] dt-bindings: interconnect: Add interconnect-opp-table property
From: Saravana Kannan @ 2019-07-22 23:43 UTC (permalink / raw)
To: Rob Herring
Cc: Georgi Djakov, Mark Rutland, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Rafael J. Wysocki, Vincent Guittot, Sweeney, Sean,
daidavid1, Rajendra Nayak, Sibi Sankar, Bjorn Andersson,
Evan Green, Android Kernel Team, Linux PM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML
In-Reply-To: <20190722233927.GA1353@bogus>
On Mon, Jul 22, 2019 at 4:39 PM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, Jul 02, 2019 at 06:10:19PM -0700, Saravana Kannan wrote:
> > Add support for listing bandwidth OPP tables for each interconnect path
> > listed using the interconnects property.
> >
> > Signed-off-by: Saravana Kannan <saravanak@google.com>
> > ---
> > .../devicetree/bindings/interconnect/interconnect.txt | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt b/Documentation/devicetree/bindings/interconnect/interconnect.txt
> > index 6f5d23a605b7..fc5b75b76a2c 100644
> > --- a/Documentation/devicetree/bindings/interconnect/interconnect.txt
> > +++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
> > @@ -55,10 +55,18 @@ interconnect-names : List of interconnect path name strings sorted in the same
> > * dma-mem: Path from the device to the main memory of
> > the system
> >
> > +interconnect-opp-table: List of phandles to OPP tables (bandwidth OPP tables)
> > + that specify the OPPs for the interconnect paths listed
> > + in the interconnects property. This property can only
> > + point to OPP tables that belong to the device and are
> > + listed in the device's operating-points-v2 property.
> > +
>
> IMO, there's no need for this property. Which OPP is which should be
> defined already as part of the device's binding. That's enough for the
> driver to know which OPP applies to the interconnect.
Sure, I don't mind dropping this.
-Saravana
^ permalink raw reply
* Re: [PATCH v3 1/6] dt-bindings: opp: Introduce opp-peak-KBps and opp-avg-KBps bindings
From: Saravana Kannan @ 2019-07-22 23:40 UTC (permalink / raw)
To: Rob Herring
Cc: Sibi Sankar, Georgi Djakov, Mark Rutland, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Rafael J. Wysocki, Vincent Guittot,
Sweeney, Sean, daidavid1, Rajendra Nayak, Bjorn Andersson,
Evan Green, Android Kernel Team, Linux PM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML
In-Reply-To: <20190722233501.GA19594@bogus>
On Mon, Jul 22, 2019 at 4:35 PM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, Jul 16, 2019 at 11:58:08AM -0700, Saravana Kannan wrote:
> > On Tue, Jul 16, 2019 at 10:25 AM Sibi Sankar <sibis@codeaurora.org> wrote:
> > >
> > > Hey Saravana,
> > >
> > > https://patchwork.kernel.org/patch/10850815/
> > > There was already a discussion ^^ on how bandwidth bindings were to be
> > > named.
> >
> > Yes, I'm aware of that series. That series is trying to define a BW
> > mapping for an existing frequency OPP table. This patch is NOT about
> > adding a mapping to an existing table. This patch is about adding the
> > notion of BW OPP tables where BW is the "key" instead of "frequency".
> >
> > So let's not mixed up these two series.
>
> Maybe different reasons, but in the end we'd end up with 2 bandwidth
> properties. We need to sort out how they'd overlap/coexist.
Oh, I totally agree! My point is that the other mapping isn't the
right approach because it doesn't handle a whole swath of use cases.
The one I'm proposing can act as a super set of the other (as in, can
handle that use case too).
> The same comment in that series about defining a standard unit suffix
> also applies to this one.
I thought I read that whole series and I don't remember reading about
the unit suffix. But I'll take a closer look. I've chosen to keep the
DT units at least as "high of a resolution" as what the APIs accept
today. The APIs take KB/s. So I make sure DT can capture KB/s
differences. If we all agree that KB/s is "too accurate" then I think
we should change everything to MB/s.
-Saravana
^ permalink raw reply
* Re: [PATCH 1/3] dt: bindings: update compatible dt properties for WCN3990 wifi node
From: Rob Herring @ 2019-07-22 23:40 UTC (permalink / raw)
Cc: ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Govind Singh
In-Reply-To: <20190703035711.25592-2-govinds-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Wed, 3 Jul 2019 09:27:09 +0530, Govind Singh wrote:
> update compatible dt properties for WCN3990 wifi node to be
> compatible across different MSM platforms.
>
> Signed-off-by: Govind Singh <govinds-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v3 5/6] dt-bindings: interconnect: Add interconnect-opp-table property
From: Rob Herring @ 2019-07-22 23:39 UTC (permalink / raw)
To: Saravana Kannan
Cc: Georgi Djakov, Mark Rutland, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Rafael J. Wysocki, vincent.guittot, seansw,
daidavid1, Rajendra Nayak, sibis, bjorn.andersson, evgreen,
kernel-team, linux-pm, devicetree, linux-kernel
In-Reply-To: <20190703011020.151615-6-saravanak@google.com>
On Tue, Jul 02, 2019 at 06:10:19PM -0700, Saravana Kannan wrote:
> Add support for listing bandwidth OPP tables for each interconnect path
> listed using the interconnects property.
>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
> ---
> .../devicetree/bindings/interconnect/interconnect.txt | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt b/Documentation/devicetree/bindings/interconnect/interconnect.txt
> index 6f5d23a605b7..fc5b75b76a2c 100644
> --- a/Documentation/devicetree/bindings/interconnect/interconnect.txt
> +++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
> @@ -55,10 +55,18 @@ interconnect-names : List of interconnect path name strings sorted in the same
> * dma-mem: Path from the device to the main memory of
> the system
>
> +interconnect-opp-table: List of phandles to OPP tables (bandwidth OPP tables)
> + that specify the OPPs for the interconnect paths listed
> + in the interconnects property. This property can only
> + point to OPP tables that belong to the device and are
> + listed in the device's operating-points-v2 property.
> +
IMO, there's no need for this property. Which OPP is which should be
defined already as part of the device's binding. That's enough for the
driver to know which OPP applies to the interconnect.
> Example:
>
> sdhci@7864000 {
> + operating-points-v2 = <&sdhc_opp_table>, <&sdhc_mem_opp_table>;
> ...
> interconnects = <&pnoc MASTER_SDCC_1 &bimc SLAVE_EBI_CH0>;
> interconnect-names = "sdhc-mem";
> + interconnect-opp-table = <&sdhc_mem_opp_table>;
> };
> --
> 2.22.0.410.gd8fdbe21b5-goog
>
^ 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