* Re: [PATCH v2 3/6] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver
From: Stefan Agner @ 2018-05-31 9:55 UTC (permalink / raw)
To: boris.brezillon, dwmw2, computersforpeace, marek.vasut, robh+dt,
mark.rutland, thierry.reding, mturquette, sboyd
Cc: dev, miquel.raynal, richard, marcel, krzk, digetx,
benjamin.lindqvist, jonathanh, pdeschrijver, pgaikwad, mirza.krak,
linux-mtd, linux-tegra, devicetree, linux-kernel, linux-clk
In-Reply-To: <80eb6a514e96cdbd460c6a0937a9dff9@agner.ch>
On 31.05.2018 11:37, Stefan Agner wrote:
> On 27.05.2018 23:54, Stefan Agner wrote:
>> Add support for the NAND flash controller found on NVIDIA
>> Tegra 2 SoCs. This implementation does not make use of the
>> command queue feature. Regular operations/data transfers are
>> done in PIO mode. Page read/writes with hardware ECC make
>> use of the DMA for data transfer.
>>
>> Signed-off-by: Lucas Stach <dev@lynxeye.de>
>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>> ---
>> MAINTAINERS | 7 +
>> drivers/mtd/nand/raw/Kconfig | 6 +
>> drivers/mtd/nand/raw/Makefile | 1 +
>> drivers/mtd/nand/raw/tegra_nand.c | 999 ++++++++++++++++++++++++++++++
>> 4 files changed, 1013 insertions(+)
>> create mode 100644 drivers/mtd/nand/raw/tegra_nand.c
>>
> [...]
>> +
>> + chip->ecc.read_page = tegra_nand_read_page_hwecc;
>> + chip->ecc.write_page = tegra_nand_write_page_hwecc;
>> + /* Not functional for unknown reason...
>> + chip->ecc.read_page_raw = tegra_nand_read_page;
>> + chip->ecc.write_page_raw = tegra_nand_write_page;
>> + */
>
> I am giving up on these raw read/write_page functions. Using DMA without
> HW ECC just seems not to work.
>
> I do not get the CMD_DONE interrupt as I do when using DMA with HW ECC.
> I tried with the same settings, just not enabling DMA (HW_ECC not set,
> HW_ERR_CORRECTION not set, and also with/without PIPELINE_EN).
s/not enabling DMA/not enabling HW ECC/
>
> A register dump after a successful read with HW ECC looks like this:
> [ 196.935199] CMD: 0x66890104
> [ 196.938003] STATUS: 0x00000101
> [ 196.941049] ISR: 0x00000000
> [ 196.943865] CONFIG: 0x0084000b
> [ 196.946914] DMA_MST_CTRL: 0x15000004
> [ 196.950481] DMA_CFG_A: 0x00000fff
> [ 196.954361] DMA_CFG_B: 0x00000000
> [ 196.957670] FIFO: 0x0000aa00
>
> Whereas without HW ECC completion times out (using
> wait_for_completion_timeout already):
> [ 226.128618] tegra-nand 70008000.nand: CMD timeout, last CMD:
> 0xe6890104
> [ 226.135375] CMD: 0xe6890104
> [ 226.138201] STATUS: 0x00000100
> [ 226.141280] ISR: 0x00000100
> [ 226.153372] CONFIG: 0x0084000b
> [ 226.156423] DMA_MST_CTRL: 0x95000004
> [ 226.159989] DMA_CFG_A: 0x00000fff
> [ 226.164084] DMA_CFG_B: 0x00000000
> [ 226.167393] FIFO: 0x0000aa00
>
> It looks to me as if the DMA just does not start the data cycle. The
> NAND seems to have read the page (RBSY0 is set).
>
>
> Note that it is never explicitly stated whether DMA without HW ECC is
> supported. There is some indication that it should: There are separated
> bits to enable HW ECC/DMA, the reference manual states "If HW ECC is
> enabled... " and a block diagram shows separate blocks for the ECC
> Engine and NAND DMA control.
>
> There is also indication that it does not: The chapter Restrictions
> reads: "HW_ERR_CORRECTION = 0/1, doesn’t alter controller hardware
> behavior. Software error correction scheme with HW_ERR_CORRECTION = 0,
> is deprecated in Tegra 2 Processor."
>
> Note that the default implementations nand_(read|write)_page_raw which
> use exec_op do work fine! Unfortunately, the PIO mode only allows 4
> bytes in a read cycle, hence raw read/write is slow...
>
> --
> Stefan
>
>
>> + config = readl(ctrl->regs + CFG);
>> + config |= CFG_PIPE_EN | CFG_SKIP_SPARE | CFG_SKIP_SPARE_SIZE_4;
>> +
>> + if (chip->options & NAND_BUSWIDTH_16)
>> + config |= CFG_BUS_WIDTH_16;
>> +
>> + switch (chip->ecc.algo) {
>> + case NAND_ECC_RS:
>> + bits_per_step = BITS_PER_STEP_RS * chip->ecc.strength;
>> + mtd_set_ooblayout(mtd, &tegra_nand_oob_rs_ops);
>> + switch (chip->ecc.strength) {
>> + case 4:
>> + config |= CFG_ECC_SEL | CFG_TVAL_4;
>> + break;
>> + case 6:
>> + config |= CFG_ECC_SEL | CFG_TVAL_6;
>> + break;
>> + case 8:
>> + config |= CFG_ECC_SEL | CFG_TVAL_8;
>> + break;
>> + default:
>> + dev_err(dev, "ECC strength %d not supported\n",
>> + chip->ecc.strength);
>> + return -EINVAL;
>> + }
>> + break;
>> + case NAND_ECC_BCH:
>> + bits_per_step = BITS_PER_STEP_BCH * chip->ecc.strength;
>> + mtd_set_ooblayout(mtd, &tegra_nand_oob_bch_ops);
>> + switch (chip->ecc.strength) {
>> + case 4:
>> + bch_config = BCH_TVAL_4;
>> + break;
>> + case 8:
>> + bch_config = BCH_TVAL_8;
>> + break;
>> + case 14:
>> + bch_config = BCH_TVAL_14;
>> + break;
>> + case 16:
>> + bch_config = BCH_TVAL_16;
>> + break;
>> + default:
>> + dev_err(dev, "ECC strength %d not supported\n",
>> + chip->ecc.strength);
>> + return -EINVAL;
>> + }
>> + break;
>> + default:
>> + dev_err(dev, "ECC algorithm not supported\n");
>> + return -EINVAL;
>> + }
>> +
>> + chip->ecc.bytes = DIV_ROUND_UP(bits_per_step, 8);
>> +
>> + switch (mtd->writesize) {
>> + case 256:
>> + config |= CFG_PS_256;
>> + break;
>> + case 512:
>> + config |= CFG_PS_512;
>> + break;
>> + case 1024:
>> + config |= CFG_PS_1024;
>> + break;
>> + case 2048:
>> + config |= CFG_PS_2048;
>> + break;
>> + case 4096:
>> + config |= CFG_PS_4096;
>> + break;
>> + default:
>> + dev_err(dev, "unhandled writesize %d\n", mtd->writesize);
>> + return -ENODEV;
>> + }
>> +
>> + writel(config, ctrl->regs + CFG);
>> + writel(bch_config, ctrl->regs + BCH_CONFIG);
>> +
>> + err = nand_scan_tail(mtd);
>> + if (err)
>> + return err;
>> +
>> + config |= CFG_TAG_BYTE_SIZE(mtd_ooblayout_count_freebytes(mtd) - 1);
>> + writel(config, ctrl->regs + CFG);
>> +
>> + err = mtd_device_register(mtd, NULL, 0);
>> + if (err)
>> + return err;
>> +
>> + return 0;
>> +}
>> +
>> +static int tegra_nand_probe(struct platform_device *pdev)
>> +{
>> + struct reset_control *rst;
>> + struct tegra_nand_controller *ctrl;
>> + struct resource *res;
>> + unsigned long value;
>> + int irq, err = 0;
>> +
>> + ctrl = devm_kzalloc(&pdev->dev, sizeof(*ctrl), GFP_KERNEL);
>> + if (!ctrl)
>> + return -ENOMEM;
>> +
>> + ctrl->dev = &pdev->dev;
>> + nand_hw_control_init(&ctrl->controller);
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + ctrl->regs = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(ctrl->regs))
>> + return PTR_ERR(ctrl->regs);
>> +
>> + rst = devm_reset_control_get(&pdev->dev, "nand");
>> + if (IS_ERR(rst))
>> + return PTR_ERR(rst);
>> +
>> + ctrl->clk = devm_clk_get(&pdev->dev, "nand");
>> + if (IS_ERR(ctrl->clk))
>> + return PTR_ERR(ctrl->clk);
>> +
>> + err = clk_prepare_enable(ctrl->clk);
>> + if (err)
>> + return err;
>> +
>> + reset_control_reset(rst);
>> +
>> + value = HWSTATUS_RDSTATUS_MASK(1) | HWSTATUS_RDSTATUS_VALUE(0) |
>> + HWSTATUS_RBSY_MASK(NAND_STATUS_READY) |
>> + HWSTATUS_RBSY_VALUE(NAND_STATUS_READY);
>> + writel(NAND_CMD_STATUS, ctrl->regs + HWSTATUS_CMD);
>> + writel(value, ctrl->regs + HWSTATUS_MASK);
>> +
>> + init_completion(&ctrl->command_complete);
>> + init_completion(&ctrl->dma_complete);
>> +
>> + /* clear interrupts */
>> + value = readl(ctrl->regs + ISR);
>> + writel(value, ctrl->regs + ISR);
>> +
>> + irq = platform_get_irq(pdev, 0);
>> + err = devm_request_irq(&pdev->dev, irq, tegra_nand_irq, 0,
>> + dev_name(&pdev->dev), ctrl);
>> + if (err)
>> + goto err_disable_clk;
>> +
>> + writel(DMA_CTRL_IS_DONE, ctrl->regs + DMA_CTRL);
>> +
>> + /* enable interrupts */
>> + value = IER_UND | IER_OVR | IER_CMD_DONE | IER_ECC_ERR | IER_GIE;
>> + writel(value, ctrl->regs + IER);
>> +
>> + /* reset config */
>> + writel(0, ctrl->regs + CFG);
>> +
>> + err = tegra_nand_chips_init(ctrl->dev, ctrl);
>> + if (err)
>> + goto err_disable_clk;
>> +
>> + platform_set_drvdata(pdev, ctrl);
>> +
>> + return 0;
>> +
>> +err_disable_clk:
>> + clk_disable_unprepare(ctrl->clk);
>> + return err;
>> +}
>> +
>> +static int tegra_nand_remove(struct platform_device *pdev)
>> +{
>> + struct tegra_nand_controller *ctrl = platform_get_drvdata(pdev);
>> +
>> + nand_release(nand_to_mtd(ctrl->chip));
>> +
>> + clk_disable_unprepare(ctrl->clk);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id tegra_nand_of_match[] = {
>> + { .compatible = "nvidia,tegra20-nand" },
>> + { /* sentinel */ }
>> +};
>> +
>> +static struct platform_driver tegra_nand_driver = {
>> + .driver = {
>> + .name = "tegra-nand",
>> + .of_match_table = tegra_nand_of_match,
>> + },
>> + .probe = tegra_nand_probe,
>> + .remove = tegra_nand_remove,
>> +};
>> +module_platform_driver(tegra_nand_driver);
>> +
>> +MODULE_DESCRIPTION("NVIDIA Tegra NAND driver");
>> +MODULE_AUTHOR("Thierry Reding <thierry.reding@nvidia.com>");
>> +MODULE_AUTHOR("Lucas Stach <dev@lynxeye.de>");
>> +MODULE_AUTHOR("Stefan Agner <stefan@agner.ch>");
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DEVICE_TABLE(of, tegra_nand_of_match);
^ permalink raw reply
* Re: [PATCH v7 1/5] dt-bindings: Add the r9a06g032-sysctrl.h file
From: M P @ 2018-05-31 10:01 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: michel.pollet, linux-renesas-soc, Simon Horman, Phil Edworthy,
buserror+upstream, Michael Turquette, sboyd, robh+dt,
mark.rutland, geert+renesas, linux-clk, devicetree, linux-kernel
In-Reply-To: <CAMuHMdXQWSVh37HqrvFWeLNHZ5zNh0=9+hV0_nsQ9mi1HQSCaQ@mail.gmail.com>
Hi Geert,
On Thu, 31 May 2018 at 10:32, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Michel,
>
> On Thu, May 31, 2018 at 11:11 AM, M P <buserror@gmail.com> wrote:
> > On Fri, 25 May 2018 at 11:31, Geert Uytterhoeven <geert@linux-m68k.org>
> > wrote:
> >> On Thu, May 24, 2018 at 11:28 AM, Michel Pollet
> >> <michel.pollet@bp.renesas.com> wrote:
> >> > This adds the constants necessary to use the renesas,r9a06g032-sysctrl
> > node.
>
> >> > @@ -0,0 +1,187 @@
> >> > +/* SPDX-License-Identifier: GPL-2.0 */
> >> > +/*
> >> > + * R9A06G032 sysctrl IDs
> >> > + *
> >> > + * Copyright (C) 2018 Renesas Electronics Europe Limited
> >> > + *
> >> > + * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
> >> > + * Derived from zx-reboot.c
> >> > + */
> >> > +
> >> > +#ifndef __DT_BINDINGS_R9A06G032_SYSCTRL_H__
> >> > +#define __DT_BINDINGS_R9A06G032_SYSCTRL_H__
> >> > +
> >> > +#define R9A06G032_CLKOUT 0
> >> > +#define R9A06G032_CLK_PLL_USB 1
> >> > +#define R9A06G032_CLK_48 1 /* AKA CLK_PLL_USB */
> >> > +#define R9A06G032_CLKOUT_D10 2
> >> > +#define R9A06G032_CLKOUT_D16 3
> >> > +#define R9A06G032_MSEBIS_CLK 3 /* AKA CLKOUT_D16 */
> >> > +#define R9A06G032_MSEBIM_CLK 3 /* AKA CLKOUT_D16 */
> >> > +#define R9A06G032_CLKOUT_D160 4
> >> > +#define R9A06G032_CLKOUT_D1OR2 5
> >> > +#define R9A06G032_CLK_DDRPHY_PLLCLK 5 /* AKA CLKOUT_D1OR2 */
> >
> >> [...]
> >
> >> I have 3 comments:
> >
> >> 1. I had expected this list to match (both name- and order-wise)
> > Appendix
> >> C ("Clock Tree Structure") in the RZ/N1[DSL] User’s Manual: System
> >> Introduction, Multiplexing, Electrical and Mechanical Information.
> >> That would make it easier to review.
> >
> > Well, that document was made a *long* time after the internal documentation
> > we used to generate the clock lists. There are a few things we had to do:
> >
> > * Renumber peripherals. We decided a long time ago that u-boot and linux
> > would stick to zero based peripherals, and not one based numbers. It's next
> > to impossible to keep mixing number based across software base, so we use
> > UART0 while the hardware manual mentions UART1 -- It *is* documented
> > extensively with out SDK, and makes life using linux a lot easier. It's
> > across all our SDK, u-boot, webapps readmes, howtos etc.
> >
> > * Rename some peripherals. Plenty of peripherals names made little sense
> > and had zero consistency, in fact, many names were different depending on
> > the place they were used! -- "flashnand"+"nand_flash"+"FNAND" etc,
> > "QUADSPI"+"QSPI" etc etc so we also re-normalized the names to match linux
> > conventions.
> >
> > * Other internal reasons I can't document here
> >
> > Also, the value here are made up anyway -- so I've decided to sort them to
> > make sure any clock that has a parent is numbered *after* the parent...
>
> Well, all of that combines makes it very hard for us to review the list.
I understand -- the previous format was a lot more readable, here I had to
work to make the table as small as I could, and quite a few bits of readability
were lost in the process. It's already a huge file.
I'm not sure if that would help, but here is the link to the old table
format I used
https://github.com/renesas-rz/rzn1_linux/blob/rzn1-stable/drivers/clk/rzn1/rzn1-clkctrl-tables.h
I had to throw that away to make up the new composite table that now contains
what was in the device tree file before. However the names are the same.
Perhaps I could change how I encode the register/bit pairs to use 8+8 bits to
make the hex constants more readable?
>
> >> 2. These definitions seems to be a mix of:
> >> 1. Internal core clocks,
> >> 2. Other core clocks,
> >> 3. Module clocks.
> >
> >> The internal clocks do not need to be referenced from DT, so I would
> >> not make them part of the DT bindings.
> >
> > Why? I'm told that "Bindings aren't for linux" -- why can't I imagine
> > 'something' needing them? Why would I decide NOT to include them,
> > as they are there? I 'factored' a few of them to the same number when
>
> Just general safety w.r.t. unchangeable DT definitions: anything that is
> not listed here cannot be declared wrong later.
Well, I need these #define *somewhere* as I use them in my driver. So what
do you want me to do?
+ Remove the header, move the constants into the driver?
+ Use hard coded numbers in the DT and remove the header entirely?
+ Duplicate the header, keep the full one with the driver, and only list
the CA7+UART0 one in the dt-binding and duplicate the ones I need as
I go along?
>
> > applicable.
>
> You're 100% sure they're the same?
Yes, the script logic hasn't changed in 2 years, and we've been using that
hierarchy extensively since.
Basically the logic is that if a clock doesn't have a gate and isn't a divisor
of some sort, it's factored with it's parent clock... it used to be
done with a DT
alias of the same name.
>
> > This is all done automatically BTW -- a script takes the original clocking
> > spreadsheet, and converts it into a table, correcting 'human input' as it
> > goes along.
>
> So the internal spreadsheet doesn't match the public documentation neither?
Nope, as usual, people who wrote the documentation went their own way at
some point, and didn't backport any changes they made.
> Gr{oetje,eeting}s,
>
> Geert
Cheers,
Michel
^ permalink raw reply
* Re: [PATCH v2 3/6] clk: ti: dra7: Add clkctrl clock data for the mcan clocks
From: Faiz Abbas @ 2018-05-31 10:14 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel, devicetree, linux-omap, linux-arm-kernel, linux-clk,
bcousson, tony, paul, t-kristo
In-Reply-To: <20180531040350.GA25132@rob-hp-laptop>
Hi,
On Thursday 31 May 2018 09:33 AM, Rob Herring wrote:
> On Wed, May 30, 2018 at 07:41:30PM +0530, Faiz Abbas wrote:
>> Add clkctrl data for the m_can clocks and register it within the
...
>>
>> diff --git a/include/dt-bindings/clock/dra7.h b/include/dt-bindings/clock/dra7.h
>> index 5e1061b15aed..d7549c57cac3 100644
>> --- a/include/dt-bindings/clock/dra7.h
>> +++ b/include/dt-bindings/clock/dra7.h
>> @@ -168,5 +168,6 @@
>> #define DRA7_COUNTER_32K_CLKCTRL DRA7_CLKCTRL_INDEX(0x50)
>> #define DRA7_UART10_CLKCTRL DRA7_CLKCTRL_INDEX(0x80)
>> #define DRA7_DCAN1_CLKCTRL DRA7_CLKCTRL_INDEX(0x88)
>> +#define DRA7_ADC_CLKCTRL DRA7_CLKCTRL_INDEX(0xa0)
>
> ADC and mcan are the same thing?
>
The register to control MCAN clocks is called ADC_CLKCTRL, Yes.
Thanks,
Faiz
^ permalink raw reply
* Re: [PATCH v2 4/6] bus: ti-sysc: Add support for using ti-sysc for MCAN on dra76x
From: Faiz Abbas @ 2018-05-31 10:16 UTC (permalink / raw)
To: Tony Lindgren
Cc: devicetree, paul, linux-kernel, t-kristo, robh+dt, bcousson,
linux-omap, linux-clk, linux-arm-kernel
In-Reply-To: <20180530145726.GD5705@atomide.com>
Hi,
On Wednesday 30 May 2018 08:27 PM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180530 14:12]:
>> The dra76x MCAN generic interconnect module has a its own
>> format for the bits in the control registers.
...
>> static int sysc_init_pdata(struct sysc *ddata)
>> {
>> struct ti_sysc_platform_data *pdata = dev_get_platdata(ddata->dev);
>> @@ -1441,6 +1457,7 @@ static const struct of_device_id sysc_match[] = {
>> { .compatible = "ti,sysc-mcasp", .data = &sysc_omap4_mcasp, },
>> { .compatible = "ti,sysc-usb-host-fs",
>> .data = &sysc_omap4_usb_host_fs, },
>> + { .compatible = "ti,sysc-dra7-mcan", .data = &sysc_dra7_mcan, },
>> { },
>> };
>
> Looks good to me. And presumably you checked that no other dra7 modules
> use sysconfig register bit layout like this?
>
As far as I could see, Yes.
Thanks,
Faiz
^ permalink raw reply
* Re: [PATCH v7 2/5] dt-bindings: clock: renesas,r9a06g032-sysctrl: documentation
From: M P @ 2018-05-31 10:16 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: michel.pollet, linux-renesas-soc, Simon Horman, Phil Edworthy,
buserror+upstream, Michael Turquette, sboyd, robh+dt,
mark.rutland, geert+renesas, linux-clk, devicetree, linux-kernel
In-Reply-To: <CAMuHMdUb4fWFB9oP41ejO0_FDxmgBPL0GxQnkFv18Zfb5=1-fw@mail.gmail.com>
Hi Geert,
On Fri, 25 May 2018 at 10:23, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Michel,
>
> On Thu, May 24, 2018 at 11:28 AM, Michel Pollet
> <michel.pollet@bp.renesas.com> wrote:
> > The Renesas R9A06G032 SYSCTRL node description.
> >
> > Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>
> Thanks for your patch!
>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.txt
> > @@ -0,0 +1,32 @@
> > +* Renesas R9A06G032 SYSCTRL
> > +
> > +Required Properties:
> > +
> > + - compatible: Must be:
> > + - "renesas,r9a06g032-sysctrl"
> > + - reg: Base address and length of the SYSCTRL IO block.
> > + - #clock-cells: Must be 1
>
> No clocks/clock-names for the external clock inputs?
>
> "RZ/N1 has 3 clock sources, 1 reference clock inputs for RGMII, and 2
> reference clock outputs for RMII/MII."
>
> Given the documentation explicitly mentions the module clocks are to be
> used for power-management, you may want to add #power-domain-cells as well,
> and let the driver register clock domain. But that can be added later
> (although it will break backwards compatibility with old DTBs).
>
> As PWRCTRL_* registers allow to reset individual modules, #reset-cells is
> another thing to add later. It's good to start thinking early about how to
> reference resets, though.
> E.g. on other Renesas-SoCs, module resets uses the same numerical
> references as module clocks.
As you said, could we add all that later, as appropriate? Here I tried
to trim it
down to the the bare minimum -- my previous version of the driver had
separate reset descriptors, but this one has been all compacted to do just
what it's supposed to do: clocks.
Or, so you want to add another DT index to refer to other reset indexes etc?
ie not use the of_clk_src_onecell_get provider? That COULD work and yes, the
indexes would stay the same, I'd just have to get the reset descriptor from the
clock object. We haven't had a use for individual resets so far.
> Gr{oetje,eeting}s,
>
> Geert
Cheers,
Michel
^ permalink raw reply
* Re: [PATCH v2 5/6] ARM: dts: Add generic interconnect target module node for MCAN
From: Faiz Abbas @ 2018-05-31 10:21 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-kernel, devicetree, linux-omap, linux-arm-kernel, linux-clk,
robh+dt, bcousson, paul, t-kristo
In-Reply-To: <20180530150402.GE5705@atomide.com>
Hi,
On Wednesday 30 May 2018 08:34 PM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180530 14:12]:
>> The ti-sysc driver provides support for manipulating the idlemodes
>> and interconnect level resets.
> ...
>> --- a/arch/arm/boot/dts/dra76x.dtsi
>> +++ b/arch/arm/boot/dts/dra76x.dtsi
>> @@ -11,6 +11,25 @@
>> / {
>> compatible = "ti,dra762", "ti,dra7";
>>
>> + ocp {
>> +
>> + target-module@0x42c00000 {
>> + compatible = "ti,sysc-dra7-mcan";
>> + ranges = <0x0 0x42c00000 0x2000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + reg = <0x42c01900 0x4>,
>> + <0x42c01904 0x4>,
>> + <0x42c01908 0x4>;
>> + reg-names = "rev", "sysc", "syss";
>> + ti,sysc-mask = <(SYSC_OMAP4_SOFTRESET |
>> + SYSC_DRA7_MCAN_ENAWAKEUP)>;
>> + ti,syss-mask = <1>;
>> + clocks = <&wkupaon_clkctrl DRA7_ADC_CLKCTRL 0>;
>> + clock-names = "fck";
>> + };
>> + };
>> +
>> };
>
> Looks good to me except I think the reset won't do anything currently
> with ti-sysc.c unless you specfify also "ti,hwmods" for the module?
>
> Can you please check? It might be worth adding the reset function to
> ti-sysc.c for non "ti,hwmods" case and that just might remove the
> need for any hwmod code for this module.
>
If I understand correctly, this involves adding a (*reset_module) in
ti_sysc_platform_data and defining a ti_sysc_reset_module() in ti-sysc.c
similar to ti_sysc_idle_module(). Right?
Thanks,
Faiz
^ permalink raw reply
* Re: [PATCH v4 2/6] mfd: bd71837: Devicetree bindings for ROHM BD71837 PMIC
From: Matti Vaittinen @ 2018-05-31 10:23 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Rob Herring, Matti Vaittinen, mturquette, sboyd, mark.rutland,
lee.jones, lgirdwood, broonie, linux-clk, devicetree,
linux-kernel, mikko.mutanen, heikki.haikola
In-Reply-To: <20180531071717.GG13528@localhost.localdomain>
On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote:
> Hello Rob,
>
> Thanks for the review!
>
> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote:
> > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote:
> > > Document devicetree bindings for ROHM BD71837 PMIC MFD.
> > > + - interrupts : The interrupt line the device is connected to.
> > > + - interrupt-controller : Marks the device node as an interrupt controller.
> >
> > What sub blocks have interrupts?
>
> The PMIC can generate interrupts from events which cause it to reset.
> Eg, irq from watchdog line change, power button pushes, reset request
> via register interface etc. I don't know any generic handling for these
> interrupts. In "normal" use-case this PMIC is powering the processor
> where driver is running and I do not see reasonable handling because
> power-reset is going to follow the irq.
>
Oh, but when reading this I understand that the interrupt-controller
property should at least be optional.
Br,
Matti Vaittinen
^ permalink raw reply
* Re: [PATCH v4 1/7] dt-bindings: clk: at91: add an I2S mux clock
From: Codrin Ciubotariu @ 2018-05-31 10:25 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, alsa-devel, alexandre.belloni, nicolas.ferre,
linux-kernel, boris.brezillon, broonie, Cristian.Birsan,
linux-clk, linux-arm-kernel
In-Reply-To: <20180531005827.GA17203@rob-hp-laptop>
On 31.05.2018 03:58, Rob Herring wrote:
> On Fri, May 25, 2018 at 03:34:22PM +0300, Codrin Ciubotariu wrote:
>> The I2S mux clock can be used to select the I2S input clock. The
>> available parents are the peripheral and the generated clocks.
>>
>> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
>> ---
>> .../devicetree/bindings/clock/at91-clock.txt | 34 ++++++++++++++++++++++
>> 1 file changed, 34 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt b/Documentation/devicetree/bindings/clock/at91-clock.txt
>> index 51c259a..1c46b3c 100644
>> --- a/Documentation/devicetree/bindings/clock/at91-clock.txt
>> +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
>> @@ -90,6 +90,8 @@ Required properties:
>> "atmel,sama5d2-clk-audio-pll-pmc"
>> at91 audio pll output on AUDIOPLLCLK that feeds the PMC
>> and can be used by peripheral clock or generic clock
>> + "atmel,sama5d2-clk-i2s-mux":
>> + at91 I2S clock source selection
>
> Is this boolean or takes some values. If latter, what are valid values?
This is the compatible string of the clock driver.
>
>>
>> Required properties for SCKC node:
>> - reg : defines the IO memory reserved for the SCKC.
>> @@ -507,3 +509,35 @@ For example:
>> atmel,clk-output-range = <0 83000000>;
>> };
>> };
>> +
>> +Required properties for I2S mux clocks:
>> +- #size-cells : shall be 0 (reg is used to encode I2S bus id).
>> +- #address-cells : shall be 1 (reg is used to encode I2S bus id).
>> +- name: device tree node describing a specific mux clock.
>> + * #clock-cells : from common clock binding; shall be set to 0.
>> + * clocks : shall be the mux clock parent phandles; shall be 2 phandles:
>> + peripheral and generated clock; the first phandle shall belong to the
>> + peripheral clock and the second one shall belong to the generated
>> + clock; "clock-indices" property can be user to specify
>> + the correct order.
>> + * reg: I2S bus id of the corresponding mux clock.
>> + e.g. reg = <0>; for i2s0, reg = <1>; for i2s1
>> +
>> +For example:
>> + i2s_clkmux {
>
> What is this a child of?
It is a child of PMC node, since both parent clocks are generated by PMC.
>
>> + compatible = "atmel,sama5d2-clk-i2s-mux";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>
> How do you address this block? My guess is you don't because it is just
> part of some other block and you are just creating this node to
> instantiate a driver. Just make the node for the actual h/w block a
> clock provider and define the clock ids (0 and 1).
This block is not addressed, but its children are. The register we
access in this driver is not part of other block. It's a SFR register,
accessed through syscon and it has nothing to do with the I2S IP (see
SAMA5D2 DS, page 1256, fig. 44-1: I2SC Block Diagram) that is the
consumer of this clock. Adding a clock-id property in the I2S node would
be just like v3 of this series, with the difference that we use clock-id
instead of alias id to set the clock parent, which is not how you
suggested back then.
Thank you for your review.
Best regards,
Codrin
[...]
^ permalink raw reply
* Re: [PATCH v2 6/6] clk: meson: axg: add the audio clock controller driver
From: kbuild test robot @ 2018-05-31 10:30 UTC (permalink / raw)
Cc: kbuild-all, Neil Armstrong, Carlo Caione, Kevin Hilman,
Jerome Brunet, Michael Turquette, Stephen Boyd, linux-amlogic,
linux-clk, devicetree, linux-kernel
In-Reply-To: <20180522163457.13834-7-jbrunet@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 4330 bytes --]
Hi Jerome,
I love your patch! Yet something to improve:
[auto build test ERROR on clk/clk-next]
[also build test ERROR on next-20180530]
[cannot apply to v4.17-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Jerome-Brunet/clk-meson-axg-add-audio-clock-controller-support/20180524-053349
base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
In file included from drivers/clk/meson/clk-triphase.c:8:0:
>> drivers/clk/meson/clkc-audio.h:22:18: error: field 'cached_duty' has incomplete type
struct clk_duty cached_duty;
^~~~~~~~~~~
--
In file included from drivers/clk/meson/sclk-div.c:19:0:
>> drivers/clk/meson/clkc-audio.h:22:18: error: field 'cached_duty' has incomplete type
struct clk_duty cached_duty;
^~~~~~~~~~~
drivers/clk/meson/sclk-div.c: In function 'sclk_div_set_duty_cycle':
>> drivers/clk/meson/sclk-div.c:127:43: error: dereferencing pointer to incomplete type 'struct clk_duty'
memcpy(&sclk->cached_duty, duty, sizeof(*duty));
^~~~~
drivers/clk/meson/sclk-div.c: At top level:
>> drivers/clk/meson/sclk-div.c:239:3: error: 'const struct clk_ops' has no member named 'get_duty_cycle'
.get_duty_cycle = sclk_div_get_duty_cycle,
^~~~~~~~~~~~~~
>> drivers/clk/meson/sclk-div.c:239:20: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.get_duty_cycle = sclk_div_get_duty_cycle,
^~~~~~~~~~~~~~~~~~~~~~~
drivers/clk/meson/sclk-div.c:239:20: note: (near initialization for 'meson_sclk_div_ops.disable_unused')
>> drivers/clk/meson/sclk-div.c:240:3: error: 'const struct clk_ops' has no member named 'set_duty_cycle'
.set_duty_cycle = sclk_div_set_duty_cycle,
^~~~~~~~~~~~~~
drivers/clk/meson/sclk-div.c:240:20: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.set_duty_cycle = sclk_div_set_duty_cycle,
^~~~~~~~~~~~~~~~~~~~~~~
drivers/clk/meson/sclk-div.c:240:20: note: (near initialization for 'meson_sclk_div_ops.recalc_rate')
cc1: some warnings being treated as errors
--
In file included from drivers/clk/meson/axg-audio.c:17:0:
>> drivers/clk/meson/clkc-audio.h:22:18: error: field 'cached_duty' has incomplete type
struct clk_duty cached_duty;
^~~~~~~~~~~
>> drivers/clk/meson/axg-audio.c:35:12: error: 'CLK_DUTY_CYCLE_PARENT' undeclared here (not in a function); did you mean 'CLK_SET_RATE_PARENT'?
.flags = CLK_DUTY_CYCLE_PARENT | (_iflags), \
^
drivers/clk/meson/axg-audio.c:74:2: note: in expansion of macro 'AXG_AUD_GATE'
AXG_AUD_GATE(_name, AUDIO_CLK_GATE_EN, _bit, "axg_audio_pclk", 0)
^~~~~~~~~~~~
drivers/clk/meson/axg-audio.c:77:8: note: in expansion of macro 'AXG_PCLK_GATE'
static AXG_PCLK_GATE(ddr_arb, 0);
^~~~~~~~~~~~~
vim +/cached_duty +22 drivers/clk/meson/clkc-audio.h
1917a00b Jerome Brunet 2018-05-22 17
77ad1f34 Jerome Brunet 2018-05-22 18 struct meson_sclk_div_data {
77ad1f34 Jerome Brunet 2018-05-22 19 struct parm div;
77ad1f34 Jerome Brunet 2018-05-22 20 struct parm hi;
77ad1f34 Jerome Brunet 2018-05-22 21 unsigned int cached_div;
77ad1f34 Jerome Brunet 2018-05-22 @22 struct clk_duty cached_duty;
77ad1f34 Jerome Brunet 2018-05-22 23 };
77ad1f34 Jerome Brunet 2018-05-22 24
:::::: The code at line 22 was first introduced by commit
:::::: 77ad1f347931a823d715bbcf7d0bf02ba016abc7 clk: meson: add axg audio sclk divider driver
:::::: TO: Jerome Brunet <jbrunet@baylibre.com>
:::::: CC: 0day robot <lkp@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 59077 bytes --]
^ permalink raw reply
* [RESEND PATCH v4 1/2] dt-bindings: input: Add Add Spreadtrum SC27xx vibrator documentation
From: Baolin Wang @ 2018-05-31 10:34 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, mark.rutland
Cc: linux-input, devicetree, linux-kernel, baolin.wang, xiaotong.lu
From: Xiaotong Lu <xiaotong.lu@spreadtrum.com>
This patch adds the binding documentation for Spreadtrum SC27xx series
vibrator device.
Signed-off-by: Xiaotong Lu <xiaotong.lu@spreadtrum.com>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes since v3:
- Change compatible string to explicit Soc name.
- Add parent MFD node.
Changes since v2:
- No updates.
Changes since v1:
- No updates.
---
.../bindings/input/sprd,sc27xx-vibra.txt | 23 ++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt
diff --git a/Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt b/Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt
new file mode 100644
index 0000000..f2ec0d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt
@@ -0,0 +1,23 @@
+Spreadtrum SC27xx PMIC Vibrator
+
+Required properties:
+- compatible: should be "sprd,sc2731-vibrator".
+- reg: address of vibrator control register.
+
+Example :
+
+ sc2731_pmic: pmic@0 {
+ compatible = "sprd,sc2731";
+ reg = <0>;
+ spi-max-frequency = <26000000>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vibrator@eb4 {
+ compatible = "sprd,sc2731-vibrator";
+ reg = <0xeb4>;
+ };
+ };
--
1.7.9.5
^ permalink raw reply related
* [RESEND PATCH v4 2/2] input: misc: Add Spreadtrum vibrator driver
From: Baolin Wang @ 2018-05-31 10:34 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, mark.rutland
Cc: linux-input, devicetree, linux-kernel, baolin.wang, xiaotong.lu
In-Reply-To: <c315312e53fe50ab8da95bc00037a8f8b92f8d78.1527762429.git.baolin.wang@linaro.org>
From: Xiaotong Lu <xiaotong.lu@spreadtrum.com>
This patch adds the Spreadtrum vibrator driver, which embedded in the
Spreadtrum SC27xx series PMICs.
Signed-off-by: Xiaotong Lu <xiaotong.lu@spreadtrum.com>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
Changes since v3:
- No updates.
Changes since v2:
- Fix the condition when disabling the vibrator.
- Change of_property_read_u32() to device_property_read_u32().
- Correct the device parent relationship.
- Call sc27xx_vibra_hw_init() before calling input_register_device().
- Remove platform_set_drvdata().
Changes since v1:
- Remove input_ff_destroy() and input_unregister_device()
---
drivers/input/misc/Kconfig | 10 +++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/sc27xx-vibra.c | 154 +++++++++++++++++++++++++++++++++++++
3 files changed, 165 insertions(+)
create mode 100644 drivers/input/misc/sc27xx-vibra.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 572b15f..c761c0c 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -841,4 +841,14 @@ config INPUT_RAVE_SP_PWRBUTTON
To compile this driver as a module, choose M here: the
module will be called rave-sp-pwrbutton.
+config INPUT_SC27XX_VIBRA
+ tristate "Spreadtrum sc27xx vibrator support"
+ depends on MFD_SC27XX_PMIC || COMPILE_TEST
+ select INPUT_FF_MEMLESS
+ help
+ This option enables support for Spreadtrum sc27xx vibrator driver.
+
+ To compile this driver as a module, choose M here. The module will
+ be called sc27xx_vibra.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 72cde28..9d0f9d1 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
obj-$(CONFIG_INPUT_AXP20X_PEK) += axp20x-pek.o
obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER) += rotary_encoder.o
obj-$(CONFIG_INPUT_RK805_PWRKEY) += rk805-pwrkey.o
+obj-$(CONFIG_INPUT_SC27XX_VIBRA) += sc27xx-vibra.o
obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
obj-$(CONFIG_INPUT_SIRFSOC_ONKEY) += sirfsoc-onkey.o
obj-$(CONFIG_INPUT_SOC_BUTTON_ARRAY) += soc_button_array.o
diff --git a/drivers/input/misc/sc27xx-vibra.c b/drivers/input/misc/sc27xx-vibra.c
new file mode 100644
index 0000000..295251a
--- /dev/null
+++ b/drivers/input/misc/sc27xx-vibra.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Spreadtrum Communications Inc.
+ */
+
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/input.h>
+#include <linux/workqueue.h>
+
+#define CUR_DRV_CAL_SEL GENMASK(13, 12)
+#define SLP_LDOVIBR_PD_EN BIT(9)
+#define LDO_VIBR_PD BIT(8)
+
+struct vibra_info {
+ struct input_dev *input_dev;
+ struct work_struct play_work;
+ struct regmap *regmap;
+ u32 base;
+ u32 strength;
+ bool enabled;
+};
+
+static void sc27xx_vibra_set(struct vibra_info *info, bool on)
+{
+ if (on) {
+ regmap_update_bits(info->regmap, info->base, LDO_VIBR_PD, 0);
+ regmap_update_bits(info->regmap, info->base,
+ SLP_LDOVIBR_PD_EN, 0);
+ info->enabled = true;
+ } else {
+ regmap_update_bits(info->regmap, info->base, LDO_VIBR_PD,
+ LDO_VIBR_PD);
+ regmap_update_bits(info->regmap, info->base,
+ SLP_LDOVIBR_PD_EN, SLP_LDOVIBR_PD_EN);
+ info->enabled = false;
+ }
+}
+
+static int sc27xx_vibra_hw_init(struct vibra_info *info)
+{
+ return regmap_update_bits(info->regmap, info->base, CUR_DRV_CAL_SEL, 0);
+}
+
+static void sc27xx_vibra_play_work(struct work_struct *work)
+{
+ struct vibra_info *info = container_of(work, struct vibra_info,
+ play_work);
+
+ if (info->strength && !info->enabled)
+ sc27xx_vibra_set(info, true);
+ else if (info->strength == 0 && info->enabled)
+ sc27xx_vibra_set(info, false);
+}
+
+static int sc27xx_vibra_play(struct input_dev *input, void *data,
+ struct ff_effect *effect)
+{
+ struct vibra_info *info = input_get_drvdata(input);
+
+ info->strength = effect->u.rumble.weak_magnitude;
+ schedule_work(&info->play_work);
+
+ return 0;
+}
+
+static void sc27xx_vibra_close(struct input_dev *input)
+{
+ struct vibra_info *info = input_get_drvdata(input);
+
+ cancel_work_sync(&info->play_work);
+ if (info->enabled)
+ sc27xx_vibra_set(info, false);
+}
+
+static int sc27xx_vibra_probe(struct platform_device *pdev)
+{
+ struct vibra_info *info;
+ int error;
+
+ info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ info->regmap = dev_get_regmap(pdev->dev.parent, NULL);
+ if (!info->regmap) {
+ dev_err(&pdev->dev, "failed to get vibrator regmap.\n");
+ return -ENODEV;
+ }
+
+ error = device_property_read_u32(&pdev->dev, "reg", &info->base);
+ if (error) {
+ dev_err(&pdev->dev, "failed to get vibrator base address.\n");
+ return error;
+ }
+
+ info->input_dev = devm_input_allocate_device(&pdev->dev);
+ if (!info->input_dev) {
+ dev_err(&pdev->dev, "failed to allocate input device.\n");
+ return -ENOMEM;
+ }
+
+ info->input_dev->name = "sc27xx:vibrator";
+ info->input_dev->id.version = 0;
+ info->input_dev->close = sc27xx_vibra_close;
+
+ input_set_drvdata(info->input_dev, info);
+ input_set_capability(info->input_dev, EV_FF, FF_RUMBLE);
+ INIT_WORK(&info->play_work, sc27xx_vibra_play_work);
+ info->enabled = false;
+
+ error = sc27xx_vibra_hw_init(info);
+ if (error) {
+ dev_err(&pdev->dev, "failed to initialize the vibrator.\n");
+ return error;
+ }
+
+ error = input_ff_create_memless(info->input_dev, NULL,
+ sc27xx_vibra_play);
+ if (error) {
+ dev_err(&pdev->dev, "failed to register vibrator to FF.\n");
+ return error;
+ }
+
+ error = input_register_device(info->input_dev);
+ if (error) {
+ dev_err(&pdev->dev, "failed to register input device.\n");
+ return error;
+ }
+
+ return 0;
+}
+
+static const struct of_device_id sc27xx_vibra_of_match[] = {
+ { .compatible = "sprd,sc2731-vibrator", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, sc27xx_vibra_of_match);
+
+static struct platform_driver sc27xx_vibra_driver = {
+ .driver = {
+ .name = "sc27xx-vibrator",
+ .of_match_table = sc27xx_vibra_of_match,
+ },
+ .probe = sc27xx_vibra_probe,
+};
+
+module_platform_driver(sc27xx_vibra_driver);
+
+MODULE_DESCRIPTION("Spreadtrum SC27xx Vibrator Driver");
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Xiaotong Lu <xiaotong.lu@spreadtrum.com>");
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v4 0/2] regulator: add QCOM RPMh regulator driver
From: Mark Brown @ 2018-05-31 10:38 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: <da40510b-443d-d8fd-7285-c6e7eff45dc6@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 473 bytes --]
On Wed, May 30, 2018 at 05:11:54PM -0700, David Collins wrote:
> I'll split up the patches so that reviewing is easier. For the base
> patch, would you prefer that I remove *all* mode support (handled by
> generic regulator framework DT properties) or only remove the special
> purpose drms mode handling support (i.e. qcom,regulator-drms-modes and
> qcom,drms-mode-max-microamps)?
Standard operations should be fine, just weird custom stuff that's been
causing issues.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v2] arm64: dts: msm8996: Use dwc3-qcom glue driver for USB
From: Manu Gautam @ 2018-05-31 10:47 UTC (permalink / raw)
To: andy.gross
Cc: vivek.gautam, linux-soc, devicetree, linux-arm-msm, dianders,
linux-usb, felipe.balbi, gregkh, bjorn.andersson, Manu Gautam
Move from dwc3-of-simple to dwc3-qcom glue driver to
support peripheral mode which requires qscratch wrapper
programming on VBUS event.
Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver")
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
---
Changes since v1:
- Update unit address of DT node as per Doug's comment
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 6 ++++--
arch/arm64/boot/dts/qcom/msm8996.dtsi | 10 ++++++----
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
index f45a0ab30d30..00be0d53891a 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
@@ -106,8 +106,9 @@
status = "okay";
};
- usb@6a00000 {
+ usb@6af8800 {
status = "okay";
+ extcon = <&usb3_id>;
dwc3@6a00000 {
extcon = <&usb3_id>;
@@ -122,8 +123,9 @@
pinctrl-0 = <&usb3_vbus_det_gpio>;
};
- usb@7600000 {
+ usb@76f8800 {
status = "okay";
+ extcon = <&usb2_id>;
dwc3@7600000 {
extcon = <&usb2_id>;
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 26292027ba9b..8b6dd5443524 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -776,8 +776,9 @@
status = "disabled";
};
- usb2: usb@7600000 {
- compatible = "qcom,dwc3";
+ usb2: usb@76f8800 {
+ compatible = "qcom,msm8996-dwc3", "qcom,dwc3";
+ reg = <0x76f8800 0x400>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
@@ -804,8 +805,9 @@
};
};
- usb3: usb@6a00000 {
- compatible = "qcom,dwc3";
+ usb3: usb@6af8800 {
+ compatible = "qcom,msm8996-dwc3", "qcom,dwc3";
+ reg = <0x6af8800 0x400>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v3 1/5] PM / Domains: dt: Allow power-domain property to be a list of specifiers
From: Ulf Hansson @ 2018-05-31 10:59 UTC (permalink / raw)
To: Rafael J . Wysocki, linux-pm
Cc: Ulf Hansson, Greg Kroah-Hartman, Jon Hunter, Geert Uytterhoeven,
Todor Tomov, Rajendra Nayak, Viresh Kumar, Vincent Guittot,
Kevin Hilman, linux-kernel, linux-arm-kernel, linux-tegra,
Rob Herring, devicetree
In-Reply-To: <20180531105959.14843-1-ulf.hansson@linaro.org>
To be able to describe topologies where devices are partitioned across
multiple power domains, let's extend the power-domain property to allow
being a list of PM domain specifiers.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Suggested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
---
.../bindings/power/power_domain.txt | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index 4733f76cbe48..9b387f861aed 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -111,8 +111,8 @@ Example 3:
==PM domain consumers==
Required properties:
- - power-domains : A phandle and PM domain specifier as defined by bindings of
- the power controller specified by phandle.
+ - power-domains : A list of PM domain specifiers, as defined by bindings of
+ the power controller that is the PM domain provider.
Example:
@@ -122,9 +122,18 @@ Example:
power-domains = <&power 0>;
};
-The node above defines a typical PM domain consumer device, which is located
-inside a PM domain with index 0 of a power controller represented by a node
-with the label "power".
+ leaky-device@12351000 {
+ compatible = "foo,i-leak-current";
+ reg = <0x12351000 0x1000>;
+ power-domains = <&power 0>, <&power 1> ;
+ };
+
+The first example above defines a typical PM domain consumer device, which is
+located inside a PM domain with index 0 of a power controller represented by a
+node with the label "power".
+In the second example the consumer device are partitioned across two PM domains,
+the first with index 0 and the second with index 1, of a power controller that
+is represented by a node with the label "power.
Optional properties:
- required-opps: This contains phandle to an OPP node in another device's OPP
--
2.17.0
^ permalink raw reply related
* [PATCH v3 2/5] PM / Domains: Don't attach devices in genpd with multi PM domains
From: Ulf Hansson @ 2018-05-31 10:59 UTC (permalink / raw)
To: Rafael J . Wysocki, linux-pm
Cc: Ulf Hansson, Greg Kroah-Hartman, Jon Hunter, Geert Uytterhoeven,
Todor Tomov, Rajendra Nayak, Viresh Kumar, Vincent Guittot,
Kevin Hilman, linux-kernel, linux-arm-kernel, linux-tegra,
Rob Herring, devicetree
In-Reply-To: <20180531105959.14843-1-ulf.hansson@linaro.org>
The power-domain DT property may now contain a list of PM domain
specifiers, which represents that a device are partitioned across multiple
PM domains. This leads to a new situation in genpd_dev_pm_attach(), as only
one PM domain can be attached per device.
To remain things simple for the most common configuration, when a single PM
domain is used, let's treat the multiple PM domain case as being specific.
In other words, let's change genpd_dev_pm_attach() to check for multiple PM
domains and prevent it from attach any PM domain for this case. Instead,
leave this to be managed separately, from following changes to genpd.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Suggested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/base/power/domain.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 6f403d6fccb2..908c44779ae7 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2229,10 +2229,10 @@ static void genpd_dev_pm_sync(struct device *dev)
* attaches the device to retrieved pm_domain ops.
*
* Returns 1 on successfully attached PM domain, 0 when the device don't need a
- * PM domain or a negative error code in case of failures. Note that if a
- * power-domain exists for the device, but it cannot be found or turned on,
- * then return -EPROBE_DEFER to ensure that the device is not probed and to
- * re-try again later.
+ * PM domain or when multiple power-domains exists for it, else a negative error
+ * code. Note that if a power-domain exists for the device, but it cannot be
+ * found or turned on, then return -EPROBE_DEFER to ensure that the device is
+ * not probed and to re-try again later.
*/
int genpd_dev_pm_attach(struct device *dev)
{
@@ -2243,10 +2243,18 @@ int genpd_dev_pm_attach(struct device *dev)
if (!dev->of_node)
return 0;
+ /*
+ * Devices with multiple PM domains must be attached separately, as we
+ * can only attach one PM domain per device.
+ */
+ if (of_count_phandle_with_args(dev->of_node, "power-domains",
+ "#power-domain-cells") != 1)
+ return 0;
+
ret = of_parse_phandle_with_args(dev->of_node, "power-domains",
"#power-domain-cells", 0, &pd_args);
if (ret < 0)
- return 0;
+ return ret;
mutex_lock(&gpd_list_lock);
pd = genpd_get_from_provider(&pd_args);
--
2.17.0
^ permalink raw reply related
* RE: [PATCH v2 21/40] iommu/arm-smmu-v3: Add support for Substream IDs
From: Bharat Kumar Gogada @ 2018-05-31 11:01 UTC (permalink / raw)
To: Jean-Philippe Brucker,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org
Cc: xuzaibo-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org,
okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
rfranz-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org,
Ravikiran Gummaluri,
ilias.apalodimas-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
christian.koenig-5C7GfCeVMHo@public.gmane.org
In-Reply-To: <20180511190641.23008-22-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
>
> At the moment, the SMMUv3 driver offers only one stage-1 or stage-2
> address space to each device. SMMUv3 allows to associate multiple address
> spaces per device. In addition to the Stream ID (SID), that identifies a device,
> we can now have Substream IDs (SSID) identifying an address space.
> In PCIe lingo, SID is called Requester ID (RID) and SSID is called Process
> Address-Space ID (PASID).
>
> Prepare the driver for SSID support, by adding context descriptor tables in
> STEs (previously a single static context descriptor). A complete
> stage-1 walk is now performed like this by the SMMU:
>
> Stream tables Ctx. tables Page tables
> +--------+ ,------->+-------+ ,------->+-------+
> : : | : : | : :
> +--------+ | +-------+ | +-------+
> SID->| STE |---' SSID->| CD |---' IOVA->| PTE |--> IPA
> +--------+ +-------+ +-------+
> : : : : : :
> +--------+ +-------+ +-------+
>
> We only implement one level of context descriptor table for now, but as with
> stream and page tables, an SSID can be split to target multiple levels of
> tables.
>
> In all stream table entries, we set S1DSS=SSID0 mode, making translations
> without an ssid use context descriptor 0.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
>
> ---
> v1->v2: use GENMASK throughout SMMU patches
> ---
> drivers/iommu/arm-smmu-v3-context.c | 141 +++++++++++++++++++++------
> -
> drivers/iommu/arm-smmu-v3.c | 82 +++++++++++++++-
> drivers/iommu/iommu-pasid-table.h | 7 ++
> 3 files changed, 190 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3-context.c b/drivers/iommu/arm-
> smmu-v3-context.c
> index 15d3d02c59b2..0969a3626110 100644
> --- a/drivers/iommu/arm-smmu-v3-context.c
> +++ b/drivers/iommu/arm-smmu-v3-context.c
> @@ -62,11 +62,14 @@ struct arm_smmu_cd { #define
> pasid_entry_to_cd(entry) \
> container_of((entry), struct arm_smmu_cd, entry)
>
> +struct arm_smmu_cd_table {
> + __le64 *ptr;
> + dma_addr_t ptr_dma;
> +};
> +
> struct arm_smmu_cd_tables {
> struct iommu_pasid_table pasid;
> -
> - void *ptr;
> - dma_addr_t ptr_dma;
> + struct arm_smmu_cd_table table;
> };
>
> #define pasid_to_cd_tables(pasid_table) \ @@ -77,6 +80,36 @@ struct
> arm_smmu_cd_tables {
>
> static DEFINE_IDA(asid_ida);
>
> +static int arm_smmu_alloc_cd_leaf_table(struct device *dev,
> + struct arm_smmu_cd_table *desc,
> + size_t num_entries)
> +{
> + size_t size = num_entries * (CTXDESC_CD_DWORDS << 3);
> +
> + desc->ptr = dmam_alloc_coherent(dev, size, &desc->ptr_dma,
> + GFP_ATOMIC | __GFP_ZERO);
> + if (!desc->ptr) {
> + dev_warn(dev, "failed to allocate context descriptor
> table\n");
> + return -ENOMEM;
> + }
> +
> + return 0;
> +}
> +
> +static void arm_smmu_free_cd_leaf_table(struct device *dev,
> + struct arm_smmu_cd_table *desc,
> + size_t num_entries)
> +{
> + size_t size = num_entries * (CTXDESC_CD_DWORDS << 3);
> +
> + dmam_free_coherent(dev, size, desc->ptr, desc->ptr_dma); }
> +
> +static __le64 *arm_smmu_get_cd_ptr(struct arm_smmu_cd_tables *tbl,
> u32
> +ssid) {
> + return tbl->table.ptr + ssid * CTXDESC_CD_DWORDS; }
> +
> static u64 arm_smmu_cpu_tcr_to_cd(u64 tcr) {
> u64 val = 0;
> @@ -95,34 +128,74 @@ static u64 arm_smmu_cpu_tcr_to_cd(u64 tcr)
> return val;
> }
>
> -static void arm_smmu_write_ctx_desc(struct arm_smmu_cd_tables *tbl,
> - struct arm_smmu_cd *cd)
> +static int arm_smmu_write_ctx_desc(struct arm_smmu_cd_tables *tbl, int
> ssid,
> + struct arm_smmu_cd *cd)
> {
> u64 val;
> - __u64 *cdptr = tbl->ptr;
> + bool cd_live;
> + __le64 *cdptr = arm_smmu_get_cd_ptr(tbl, ssid);
> struct arm_smmu_context_cfg *cfg = &tbl->pasid.cfg.arm_smmu;
>
> /*
> - * We don't need to issue any invalidation here, as we'll invalidate
> - * the STE when installing the new entry anyway.
> + * This function handles the following cases:
> + *
> + * (1) Install primary CD, for normal DMA traffic (SSID = 0).
> + * (2) Install a secondary CD, for SID+SSID traffic, followed by an
> + * invalidation.
> + * (3) Update ASID of primary CD. This is allowed by atomically
> writing
> + * the first 64 bits of the CD, followed by invalidation of the old
> + * entry and mappings.
> + * (4) Remove a secondary CD and invalidate it.
> */
> - val = arm_smmu_cpu_tcr_to_cd(cd->tcr) |
> +
> + if (!cdptr)
> + return -ENOMEM;
> +
> + val = le64_to_cpu(cdptr[0]);
> + cd_live = !!(val & CTXDESC_CD_0_V);
> +
> + if (!cd) { /* (4) */
> + cdptr[0] = 0;
> + } else if (cd_live) { /* (3) */
> + val &= ~CTXDESC_CD_0_ASID;
> + val |= FIELD_PREP(CTXDESC_CD_0_ASID, cd->entry.tag);
> +
> + cdptr[0] = cpu_to_le64(val);
> + /*
> + * Until CD+TLB invalidation, both ASIDs may be used for
> tagging
> + * this substream's traffic
> + */
> + } else { /* (1) and (2) */
> + cdptr[1] = cpu_to_le64(cd->ttbr &
> CTXDESC_CD_1_TTB0_MASK);
> + cdptr[2] = 0;
> + cdptr[3] = cpu_to_le64(cd->mair);
> +
> + /*
> + * STE is live, and the SMMU might fetch this CD at any
> + * time. Ensure it observes the rest of the CD before we
> + * enable it.
> + */
> + iommu_pasid_flush(&tbl->pasid, ssid, true);
> +
> +
> + val = arm_smmu_cpu_tcr_to_cd(cd->tcr) |
> #ifdef __BIG_ENDIAN
> - CTXDESC_CD_0_ENDI |
> + CTXDESC_CD_0_ENDI |
> #endif
> - CTXDESC_CD_0_R | CTXDESC_CD_0_A | CTXDESC_CD_0_ASET |
> - CTXDESC_CD_0_AA64 | FIELD_PREP(CTXDESC_CD_0_ASID, cd-
> >entry.tag) |
> - CTXDESC_CD_0_V;
> + CTXDESC_CD_0_R | CTXDESC_CD_0_A |
> CTXDESC_CD_0_ASET |
> + CTXDESC_CD_0_AA64 |
> + FIELD_PREP(CTXDESC_CD_0_ASID, cd->entry.tag) |
> + CTXDESC_CD_0_V;
>
> - if (cfg->stall)
> - val |= CTXDESC_CD_0_S;
> + if (cfg->stall)
> + val |= CTXDESC_CD_0_S;
>
> - cdptr[0] = cpu_to_le64(val);
> + cdptr[0] = cpu_to_le64(val);
> + }
>
> - val = cd->ttbr & CTXDESC_CD_1_TTB0_MASK;
> - cdptr[1] = cpu_to_le64(val);
> + iommu_pasid_flush(&tbl->pasid, ssid, true);
>
> - cdptr[3] = cpu_to_le64(cd->mair);
> + return 0;
> }
>
> static void arm_smmu_free_cd(struct iommu_pasid_entry *entry) @@ -
> 190,8 +263,10 @@ static int arm_smmu_set_cd(struct
> iommu_pasid_table_ops *ops, int pasid,
> struct arm_smmu_cd_tables *tbl = pasid_ops_to_tables(ops);
> struct arm_smmu_cd *cd = pasid_entry_to_cd(entry);
>
> - arm_smmu_write_ctx_desc(tbl, cd);
> - return 0;
> + if (WARN_ON(pasid > (1 << tbl->pasid.cfg.order)))
> + return -EINVAL;
> +
> + return arm_smmu_write_ctx_desc(tbl, pasid, cd);
> }
>
> static void arm_smmu_clear_cd(struct iommu_pasid_table_ops *ops, int
> pasid, @@ -199,30 +274,26 @@ static void arm_smmu_clear_cd(struct
> iommu_pasid_table_ops *ops, int pasid, {
> struct arm_smmu_cd_tables *tbl = pasid_ops_to_tables(ops);
>
> - arm_smmu_write_ctx_desc(tbl, NULL);
> + if (WARN_ON(pasid > (1 << tbl->pasid.cfg.order)))
> + return;
> +
> + arm_smmu_write_ctx_desc(tbl, pasid, NULL);
> }
>
> static struct iommu_pasid_table *
> arm_smmu_alloc_cd_tables(struct iommu_pasid_table_cfg *cfg, void
> *cookie) {
> + int ret;
> struct arm_smmu_cd_tables *tbl;
> struct device *dev = cfg->iommu_dev;
>
> - if (cfg->order) {
> - /* TODO: support SSID */
> - return NULL;
> - }
> -
> tbl = devm_kzalloc(dev, sizeof(*tbl), GFP_KERNEL);
> if (!tbl)
> return NULL;
>
> - tbl->ptr = dmam_alloc_coherent(dev, CTXDESC_CD_DWORDS << 3,
> - &tbl->ptr_dma, GFP_KERNEL |
> __GFP_ZERO);
> - if (!tbl->ptr) {
> - dev_warn(dev, "failed to allocate context descriptor\n");
> + ret = arm_smmu_alloc_cd_leaf_table(dev, &tbl->table, 1 << cfg-
> >order);
> + if (ret)
> goto err_free_tbl;
> - }
>
> tbl->pasid.ops = (struct iommu_pasid_table_ops) {
> .alloc_priv_entry = arm_smmu_alloc_priv_cd,
> @@ -230,7 +301,8 @@ arm_smmu_alloc_cd_tables(struct
> iommu_pasid_table_cfg *cfg, void *cookie)
> .set_entry = arm_smmu_set_cd,
> .clear_entry = arm_smmu_clear_cd,
> };
> - cfg->base = tbl->ptr_dma;
> + cfg->base = tbl->table.ptr_dma;
> + cfg->arm_smmu.s1fmt = ARM_SMMU_S1FMT_LINEAR;
>
> return &tbl->pasid;
>
> @@ -246,8 +318,7 @@ static void arm_smmu_free_cd_tables(struct
> iommu_pasid_table *pasid_table)
> struct device *dev = cfg->iommu_dev;
> struct arm_smmu_cd_tables *tbl = pasid_to_cd_tables(pasid_table);
>
> - dmam_free_coherent(dev, CTXDESC_CD_DWORDS << 3,
> - tbl->ptr, tbl->ptr_dma);
> + arm_smmu_free_cd_leaf_table(dev, &tbl->table, 1 << cfg->order);
> devm_kfree(dev, tbl);
> }
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 68764a200e44..16b08f2fb8ac 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -224,10 +224,14 @@
> #define STRTAB_STE_0_CFG_S2_TRANS 6
>
> #define STRTAB_STE_0_S1FMT GENMASK_ULL(5, 4)
> -#define STRTAB_STE_0_S1FMT_LINEAR 0
> #define STRTAB_STE_0_S1CTXPTR_MASK GENMASK_ULL(51, 6)
> #define STRTAB_STE_0_S1CDMAX GENMASK_ULL(63, 59)
>
> +#define STRTAB_STE_1_S1DSS GENMASK_ULL(1, 0)
> +#define STRTAB_STE_1_S1DSS_TERMINATE 0x0
> +#define STRTAB_STE_1_S1DSS_BYPASS 0x1
> +#define STRTAB_STE_1_S1DSS_SSID0 0x2
> +
> #define STRTAB_STE_1_S1C_CACHE_NC 0UL
> #define STRTAB_STE_1_S1C_CACHE_WBRA 1UL
> #define STRTAB_STE_1_S1C_CACHE_WT 2UL
> @@ -275,6 +279,7 @@
> #define CMDQ_PREFETCH_1_SIZE GENMASK_ULL(4, 0)
> #define CMDQ_PREFETCH_1_ADDR_MASK GENMASK_ULL(63, 12)
>
> +#define CMDQ_CFGI_0_SSID GENMASK_ULL(31, 12)
> #define CMDQ_CFGI_0_SID GENMASK_ULL(63, 32)
> #define CMDQ_CFGI_1_LEAF (1UL << 0)
> #define CMDQ_CFGI_1_RANGE GENMASK_ULL(4, 0)
> @@ -381,8 +386,11 @@ struct arm_smmu_cmdq_ent {
>
> #define CMDQ_OP_CFGI_STE 0x3
> #define CMDQ_OP_CFGI_ALL 0x4
> + #define CMDQ_OP_CFGI_CD 0x5
> + #define CMDQ_OP_CFGI_CD_ALL 0x6
> struct {
> u32 sid;
> + u32 ssid;
> union {
> bool leaf;
> u8 span;
> @@ -555,6 +563,7 @@ struct arm_smmu_master_data {
> struct list_head list; /* domain->devices */
>
> struct device *dev;
> + size_t ssid_bits;
> };
>
> /* SMMU private data for an IOMMU domain */ @@ -753,10 +762,16 @@
> static int arm_smmu_cmdq_build_cmd(u64 *cmd, struct
> arm_smmu_cmdq_ent *ent)
> cmd[1] |= FIELD_PREP(CMDQ_PREFETCH_1_SIZE, ent-
> >prefetch.size);
> cmd[1] |= ent->prefetch.addr &
> CMDQ_PREFETCH_1_ADDR_MASK;
> break;
> + case CMDQ_OP_CFGI_CD:
> + cmd[0] |= FIELD_PREP(CMDQ_CFGI_0_SSID, ent->cfgi.ssid);
> + /* Fallthrough */
> case CMDQ_OP_CFGI_STE:
> cmd[0] |= FIELD_PREP(CMDQ_CFGI_0_SID, ent->cfgi.sid);
> cmd[1] |= FIELD_PREP(CMDQ_CFGI_1_LEAF, ent->cfgi.leaf);
> break;
> + case CMDQ_OP_CFGI_CD_ALL:
> + cmd[0] |= FIELD_PREP(CMDQ_CFGI_0_SID, ent->cfgi.sid);
> + break;
> case CMDQ_OP_CFGI_ALL:
> /* Cover the entire SID range */
> cmd[1] |= FIELD_PREP(CMDQ_CFGI_1_RANGE, 31); @@ -
> 1048,8 +1063,11 @@ static void arm_smmu_write_strtab_ent(struct
> arm_smmu_device *smmu, u32 sid,
> }
>
> if (ste->s1_cfg) {
> + struct iommu_pasid_table_cfg *cfg = &ste->s1_cfg->tables;
> +
> BUG_ON(ste_live);
> dst[1] = cpu_to_le64(
> + FIELD_PREP(STRTAB_STE_1_S1DSS,
> STRTAB_STE_1_S1DSS_SSID0) |
> FIELD_PREP(STRTAB_STE_1_S1CIR,
> STRTAB_STE_1_S1C_CACHE_WBRA) |
> FIELD_PREP(STRTAB_STE_1_S1COR,
> STRTAB_STE_1_S1C_CACHE_WBRA) |
> FIELD_PREP(STRTAB_STE_1_S1CSH,
> ARM_SMMU_SH_ISH) | @@ -1063,7 +1081,9 @@ static void
> arm_smmu_write_strtab_ent(struct arm_smmu_device *smmu, u32 sid,
> dst[1] |= cpu_to_le64(STRTAB_STE_1_S1STALLD);
>
> val |= (ste->s1_cfg->tables.base &
> STRTAB_STE_0_S1CTXPTR_MASK) |
> - FIELD_PREP(STRTAB_STE_0_CFG,
> STRTAB_STE_0_CFG_S1_TRANS);
> + FIELD_PREP(STRTAB_STE_0_CFG,
> STRTAB_STE_0_CFG_S1_TRANS) |
> + FIELD_PREP(STRTAB_STE_0_S1CDMAX, cfg->order) |
> + FIELD_PREP(STRTAB_STE_0_S1FMT, cfg-
> >arm_smmu.s1fmt);
> }
>
> if (ste->s2_cfg) {
> @@ -1352,17 +1372,62 @@ static const struct iommu_gather_ops
> arm_smmu_gather_ops = { };
>
> /* PASID TABLE API */
> +static void __arm_smmu_sync_cd(struct arm_smmu_domain
> *smmu_domain,
> + struct arm_smmu_cmdq_ent *cmd) {
> + size_t i;
> + unsigned long flags;
> + struct arm_smmu_master_data *master;
> + struct arm_smmu_device *smmu = smmu_domain->smmu;
> +
> + spin_lock_irqsave(&smmu_domain->devices_lock, flags);
> + list_for_each_entry(master, &smmu_domain->devices, list) {
> + struct iommu_fwspec *fwspec = master->dev-
> >iommu_fwspec;
> +
> + for (i = 0; i < fwspec->num_ids; i++) {
> + cmd->cfgi.sid = fwspec->ids[i];
> + arm_smmu_cmdq_issue_cmd(smmu, cmd);
> + }
> + }
> + spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
> +
> + __arm_smmu_tlb_sync(smmu);
> +}
> +
> static void arm_smmu_sync_cd(void *cookie, int ssid, bool leaf) {
> + struct arm_smmu_cmdq_ent cmd = {
> + .opcode = CMDQ_OP_CFGI_CD_ALL,
Hi Jean, here CMDQ_OP_CFGI_CD opcode 0x5.
> + .cfgi = {
> + .ssid = ssid,
> + .leaf = leaf,
> + },
> + };
> +
> + __arm_smmu_sync_cd(cookie, &cmd);
> }
>
Regards,
Bharat
^ permalink raw reply
* Re: [PATCH v2 1/6] soc: qcom: rpmpd: Add a powerdomain driver to model corners
From: Ulf Hansson @ 2018-05-31 11:09 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Viresh Kumar, Stephen Boyd, Andy Gross, devicetree, linux-arm-msm,
Linux Kernel Mailing List, collinsd
In-Reply-To: <c4d9f752-0368-6257-bdab-6459b18eb893@codeaurora.org>
On 31 May 2018 at 06:20, Rajendra Nayak <rnayak@codeaurora.org> wrote:
>
>
> On 05/30/2018 06:14 PM, Ulf Hansson wrote:
>> [...]
>>
>>>>> +
>>>>> +static DEFINE_MUTEX(rpmpd_lock);
>>>>> +
>>>>> +/* msm8996 RPM powerdomains */
>>>>> +DEFINE_RPMPD_CORN_SMPA(msm8996, vddcx, vddcx_ao, 1);
>>>>> +DEFINE_RPMPD_CORN_SMPA(msm8996, vddmx, vddmx_ao, 2);
>>>>> +DEFINE_RPMPD_CORN_LDOA(msm8996, vddsscx, 26);
>>>>> +
>>>>> +DEFINE_RPMPD_VFC_SMPA(msm8996, vddcx_vfc, 1);
>>>>> +DEFINE_RPMPD_VFC_LDOA(msm8996, vddsscx_vfc, 26);
>>>>> +
>>>>> +static struct rpmpd *msm8996_rpmpds[] = {
>>>>> + [0] = &msm8996_vddcx,
>>>>> + [1] = &msm8996_vddcx_ao,
>>>>> + [2] = &msm8996_vddcx_vfc,
>>>>> + [3] = &msm8996_vddmx,
>>>>> + [4] = &msm8996_vddmx_ao,
>>>>> + [5] = &msm8996_vddsscx,
>>>>> + [6] = &msm8996_vddsscx_vfc,
>>>>> +};
>>>>
>>>> It's not my call, but honestly the above all macros makes the code
>>>> less readable.
>>>
>>> This is all static data per SoC. The macros will keep the new additions
>>> needed for every new SoC to a minimal. Currently this supports only
>>> msm8996.
>>
>> Right, that's fine then.
>>
>>>
>>>>
>>>> Anyway, I think you should convert to allocate these structs
>>>> dynamically from the heap (kzalloc/kcalloc), instead of statically as
>>>> above.
>>
>> However, I assume this is still doable!?
>
> Perhaps it is, but is there any specific advantage of constructing these structures
> dynamically vs statically, given they are static data?
Well, I was just thinking that the genpd struct has grown quite big.
> Most other powerdomain/clock/regulator drivers I see do it statically, and thats
> what I followed.
Right, so forget it and keep it as is.
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v2 5/6] ARM: dts: Add generic interconnect target module node for MCAN
From: Faiz Abbas @ 2018-05-31 11:26 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, paul, tony, linux-kernel, t-kristo, bcousson,
linux-omap, linux-clk, linux-arm-kernel
In-Reply-To: <20180531040638.GA26751@rob-hp-laptop>
Hi,
On Thursday 31 May 2018 09:36 AM, Rob Herring wrote:
> On Wed, May 30, 2018 at 07:41:32PM +0530, Faiz Abbas wrote:
>> The ti-sysc driver provides support for manipulating the idlemodes
>> and interconnect level resets.
>>
>> Add the generic interconnect target module node for MCAN to support
>> the same.
>>
>> CC: Tony Lindgren <tony@atomide.com>
>> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
>> ---
>> arch/arm/boot/dts/dra76x.dtsi | 19 +++++++++++++++++++
>> 1 file changed, 19 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
>> index bfc82636999c..57b8dc0fe719 100644
>> --- a/arch/arm/boot/dts/dra76x.dtsi
>> +++ b/arch/arm/boot/dts/dra76x.dtsi
>> @@ -11,6 +11,25 @@
>> / {
>> compatible = "ti,dra762", "ti,dra7";
>>
>> + ocp {
>> +
>> + target-module@0x42c00000 {
>
> Build your dtb with W=1 and fix warnings you add (drop '0x').
Sure, Will fix this.
>
> This is a CAN bus controller? If so, then use 'can' for node name.
Yes but I am using m_can along the lines of dcan in other boards (For
example, see arch/arm/boot/dts/am33xx.dtsi:1046). Are you saying all CAN
controllers should only be called can?
Thanks,
Faiz
^ permalink raw reply
* Re: [PATCH 6/9] ARM: dts: wheat: Drop MTD partitioning from DT
From: Simon Horman @ 2018-05-31 11:40 UTC (permalink / raw)
To: Marek Vasut
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Wolfram Sang, Richard Weinberger,
Linux-Renesas, Boris Brezillon, Geert Uytterhoeven,
Laurent Pinchart, Linux ARM, Marek Vasut
In-Reply-To: <d78bb8a8-a351-409c-54d2-33ee02fd8afe@gmail.com>
On Wed, May 30, 2018 at 12:13:31PM +0200, Marek Vasut wrote:
> On 05/28/2018 11:36 AM, Simon Horman wrote:
> > On Mon, May 28, 2018 at 10:54:57AM +0200, Geert Uytterhoeven wrote:
> >> Hi Simon,
> >>
> >> On Mon, May 28, 2018 at 10:41 AM, Simon Horman <horms@verge.net.au> wrote:
> >>> On Thu, May 24, 2018 at 04:52:59PM +0200, Marek Vasut wrote:
> >>>> On 05/23/2018 08:25 AM, Geert Uytterhoeven wrote:
> >>>>> On Wed, May 23, 2018 at 12:01 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>>>> On 05/22/2018 04:43 PM, Geert Uytterhoeven wrote:
> >>>>>>> On Tue, May 22, 2018 at 2:02 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>>>>>> Drop the MTD partitioning from DT, since it does not describe HW
> >>>>>>>> and to give way to a more flexible kernel command line partition
> >>>>>>>> passing.
> >>>>>>>>
> >>>>>>>> To retain the original partitioning, assure you have enabled
> >>>>>>>> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
> >>>>>>>> following to your kernel command line:
> >>>>>>>>
> >>>>>>>> mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
> >>>>>>>
> >>>>>>> I think the "@0" can be dropped, as it's optional?
> >>>>>>> 4m?
> >>>>>>
> >>>>>> My take on this is that the loader is actually at offset 0x0 of the MTD
> >>>>>> device and we explicitly state that in the mtdparts to anchor the first
> >>>>>> partition within the MTD device and all the other partitions are at
> >>>>>> offset +(sum of the sizes of all partitions listed before the current
> >>>>>> one) relative to that first partition.
> >>>>>
> >>>>> Where is this explicitly states for the first partition?
> >>>>>
> >>>>>> Removing the @0 feels fragile at best and it seems to depend on the
> >>>>>> current behavior of the code.
> >>>>>
> >>>>> Better, it also depends on the documented behavior:
> >>>>>
> >>>>> Documentation/admin-guide/kernel-parameters.txt refers to
> >>>>> drivers/mtd/cmdlinepart.c, which states:
> >>>>>
> >>>>> * <offset> := standard linux memsize
> >>>>> * if omitted the part will immediately follow the previous part
> >>>>> * or 0 if the first part
> >>>>>
> >>>>> None of the examples listed there or under the MTD_CMDLINE_PARTS Kconfig
> >>>>> help text, or in a defconfig bundled with the kernel, use @0 for the first
> >>>>> partition.
> >>>>
> >>>> I think this is exceptionally fragile and dangerous to depend on this,
> >>>> but so be it.
> >>>
> >>> Could you respin with this change?
> >>>
> >>> I would also like to ask for another change, in light of recent
> >>> feedback from Olof Johansson ("Re: [GIT PULL] Renesas ARM64 Based SoC DT
> >>> Updates for v4.18").
> >>>
> >>> Please consolidate the dts patches into a single patch?
> >>
> >> I think it's better to keep them split, as each commit description mentions
> >> what needs to be passed on the kernel command line for the corresponding
> >> board.
> >>
> >> Combining it in a single patch makes it much harder to extract this information.
> >> Unless you're fine with a list:
> >>
> >> koelsch: ...
> >> wheat: mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
> >
> > Lets try a list.
>
> Reposted with a list, twice :/
Thanks, got it :)
^ permalink raw reply
* Re: [DPU PATCH 10/11] drm/msm/dpu: correct dpu_io_util.h include path
From: ryadav-sgV2jX0FEOL9JmXXK+q4OQ @ 2018-05-31 11:41 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: <20180530163005.GC5028-9PYrDHPZ2Orvke4nUoYGnHL1okKdlPRT@public.gmane.org>
On 2018-05-30 22:00, Jordan Crouse wrote:
> 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.
Hi Jordan,
Yeah you are right, will squash it in v2.
We are trying to keep msm core and dpu changes in separate patches for
better squashing when they are pulled by Sean in dpu-staging tree but
for this instance can't break compilation so yeah I'll squash it with
previous one.
Thanks,
Rajesh
>
>> ---
>> 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
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply
* Re: [PATCH v2 0/8] gnss: add new GNSS subsystem
From: Johan Hovold @ 2018-05-31 11:47 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Johan Hovold, Richard Cochran, Greg Kroah-Hartman, Rob Herring,
Mark Rutland, Andreas Kemnade, Arnd Bergmann, Pavel Machek,
Marcel Holtmann, Sebastian Reichel, Tony Lindgren, linux-kernel,
devicetree
In-Reply-To: <943C21CA-EEC6-45E2-997E-A6E1FA0549EB@goldelico.com>
On Thu, May 31, 2018 at 11:52:18AM +0200, H. Nikolaus Schaller wrote:
>
> > Am 31.05.2018 um 10:52 schrieb Johan Hovold <johan@kernel.org>:
> >
> > On Wed, May 30, 2018 at 07:38:22AM -0700, Richard Cochran wrote:
> >> On Wed, May 30, 2018 at 12:32:34PM +0200, Johan Hovold wrote:
> >>> Another possible extension is to add generic 1PPS support.
> >>
> >> There are two possibilities to consider.
> >>
> >> 1. If the PPS causes an interrupt, then it should hook into the PPS
> >> subsystem.
> >
> > Registering a PPS child device is what I had in mind for this.
>
> This seems to be duplicating functionality that is already solved by
>
> https://elixir.bootlin.com/linux/v4.17-rc7/source/Documentation/devicetree/bindings/pps/pps-gpio.txt
>
> and
>
> https://elixir.bootlin.com/linux/v4.17-rc7/source/drivers/pps/clients/pps-gpio.c
>
> Or what is bad with just using that?
Using pps-gpio would not allow you to describe the hardware properly,
something which, for example, may be needed for power management (e.g.
to power on the GNSS receiver when the pps device is being accessed).
Johan
^ permalink raw reply
* Re: [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Mark Brown @ 2018-05-31 11:48 UTC (permalink / raw)
To: David Collins
Cc: Doug Anderson, Liam Girdwood, Rob Herring, Mark Rutland,
linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak,
Stephen Boyd
In-Reply-To: <75088820-f20d-32ac-780a-5e7dacdf20ff@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 3406 bytes --]
On Wed, May 30, 2018 at 04:39:10PM -0700, David Collins wrote:
> The DRMS modes to use and max allowed current per mode need to be
> specified at the board level in device tree instead of hard-coded per
> regulator type in the driver. There are at least two use cases driving
> this need: LDOs shared between RPMh client processors and SMPSes requiring
> PWM mode in certain circumstances.
Is there really no way to improve the RPM firmware?
> Consider the case of a regulator with physical 10 mA LPM max current. Say
> that modem and application processors each have a load on the regulator
> that draws 9 mA. If they each respect the 10 mA limit, then they'd each
> vote for LPM. The VRM block in RPMh hardware will aggregate these requests
This is, of course, why the regulator API aggregates this stuff based on
the current not based on having every individual user select a mode.
> together using a max function which will result in the regulator being set
> to LPM, even though the total load is 18 mA (which would require high
> power mode (HPM)). To get around this corner case, a LPM max current of 1
> uA can be used for all LDO supplies that have non-application processor
> consumers. Thus, any non-zero regulator_set_load() current request will
> result in setting the regulator to HPM (which is always safe).
That's obviously just never going to work well, the best you can do here
is just pretend that the other components are always operating at full
power (which I assume all the other components are doing too...) or not
try to use load based mode switching in the first place.
> The second situation that needs board-level DRMS mode and current limit
> specification is SMPS regulator AUTO mode to PWM (HPM) mode switching.
> SMPS regulators should theoretically always be able to operate in AUTO
> mode as it switches automatically between PWM mode (which can provide the
> maximum current) and PFM mode (which supports lower current but has higher
> efficiency). However, there may be board/system issues that require
> switching to PWM mode for certain use cases as it has better load
> regulation (i.e. no PFM ripple for lower loads) and supports more
> aggressive load current steps (i.e. greater A/ns).
> If a Linux consumer requires the ability to force a given SMPS regulator
> from AUTO mode into PWM mode and that SMPS is shared by other Linux
> consumers (which may be the case, but at least must be guaranteed to work
> architecturally), then regulator_set_load() is the only option since it
> provides aggregation, where as regulator_set_mode() does not.
That's obviously broken though, what you're describing is just clearly
nothing to do with load so trying to configure it using load is just
going to lead to problems later on. Honestly it sounds like you just
want to force the regulator into forced PWM mode all the time, otherwise
you need to look into implementing support for describing the thing
you're actually trying to do and add a mechanism for per consumer mode
configuration.
This has been a frequent pattern with these RPM drivers, trying to find
some way to shoehorn something that happens to work right now into the
code. That's going to make things fragile and hard to maintain, we need
code that does the thing it's saying it does so that it's easier to
understand and work with - getting things running isn't enough, they
need to be clear.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/5] crypto: ccree: correct host regs offset
From: Gilad Ben-Yossef @ 2018-05-31 11:49 UTC (permalink / raw)
To: Simon Horman
Cc: Magnus Damm, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Herbert Xu, David S. Miller, Ofir Drang, stable, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Linux kernel mailing list, linux-clk,
Linux Crypto Mailing List
In-Reply-To: <20180529161248.fphjnceozoyxqy7v@verge.net.au>
[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]
On Tue, May 29, 2018 at 7:12 PM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, May 24, 2018 at 03:19:06PM +0100, Gilad Ben-Yossef wrote:
> > The product signature and HW revision register have different offset on
> the
> > older HW revisions.
> > This fixes the problem of the driver failing sanity check on silicon
> > despite working on the FPGA emulation systems.
> >
> > Fixes: 27b3b22dd98c ("crypto: ccree - add support for older HW revs")
>
> Did the above introduce a regression that is fixed by this patch
> or did it add a feature that only works with this patch?
>
>
Sort of in between - the first patch made more devices work but
unreliability (it will sometime work, sometime doesn't).
This one make it work reliably.
> In the case of the latter I would drop the Fixes tag,
> but I don't feel strongly about it.
>
>
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
>
> Minor not below not withstanding,
>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
>
> Thank you for the review and help :-)
Gilad
[-- Attachment #2: Type: text/html, Size: 3303 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/5] crypto: ccree: correct host regs offset
From: Gilad Ben-Yossef @ 2018-05-31 11:51 UTC (permalink / raw)
To: Simon Horman
Cc: Magnus Damm, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Herbert Xu, David S. Miller, Ofir Drang, stable, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Linux kernel mailing list, linux-clk
In-Reply-To: <20180529161248.fphjnceozoyxqy7v@verge.net.au>
On Tue, May 29, 2018 at 7:12 PM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, May 24, 2018 at 03:19:06PM +0100, Gilad Ben-Yossef wrote:
>> The product signature and HW revision register have different offset on the
>> older HW revisions.
>> This fixes the problem of the driver failing sanity check on silicon
>> despite working on the FPGA emulation systems.
>>
>> Fixes: 27b3b22dd98c ("crypto: ccree - add support for older HW revs")
>
> Did the above introduce a regression that is fixed by this patch
> or did it add a feature that only works with this patch?
>
Sort of in between - the first patch made more devices work but
unreliability (it will sometime work, sometime doesn't).
This one make it work reliably.
> In the case of the latter I would drop the Fixes tag,
> but I don't feel strongly about it.
>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
>
> Minor not below not withstanding,
>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Thank you for the review and help :-)
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
^ permalink raw reply
* Re: [PATCH v2 5/5] arm64: dts: renesas: r8a7795: add ccree binding
From: Gilad Ben-Yossef @ 2018-05-31 11:55 UTC (permalink / raw)
To: Simon Horman
Cc: Magnus Damm, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Herbert Xu, David S. Miller, Ofir Drang, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Linux kernel mailing list, linux-clk,
Linux Crypto Mailing List
In-Reply-To: <20180529161936.prhp4oikzamr6u3n@verge.net.au>
On Tue, May 29, 2018 at 7:19 PM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, May 24, 2018 at 03:19:10PM +0100, Gilad Ben-Yossef wrote:
>> Add bindings for CryptoCell instance in the SoC.
>>
>> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
>
> In so far as I can review the details of this (which is not much) this
> looks fine to me. I am, however, a little unclear in when it should be
> accepted.
Since Herbert Xu ACKed the driver changes, I would say the only gating
commit is Geert's CR clock patch.
If that one is in, than I would say this one should go in as well.
Thanks,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
^ 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