* [PATCH 1/3] fpga manager: Add cyclonespi driver for Altera fpgas
From: Moritz Fischer @ 2016-10-07 2:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4b4432c04b4ea92a2af814e3d7866c33f2eb12ea.1475783742.git.stillcompiling@gmail.com>
Hi Joshua,
couple of nits inline below:
On Thu, Oct 6, 2016 at 1:34 PM, Joshua Clayton <stillcompiling@gmail.com> wrote:
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index cd84934..ccad5b1 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -13,6 +13,12 @@ config FPGA
>
> if FPGA
>
> +config FPGA_MGR_CYCLONE_SPI
> + tristate "Altera Cyclone V SPI"
> + depends on SPI
> + help
> + FPGA manager driver support for Altera Cyclone V over SPI
> +
> config FPGA_MGR_SOCFPGA
> tristate "Altera SOCFPGA FPGA Manager"
> depends on ARCH_SOCFPGA
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 8d83fc6..c03f40de 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -6,5 +6,6 @@
> obj-$(CONFIG_FPGA) += fpga-mgr.o
>
> # FPGA Manager Drivers
> +obj-$(CONFIG_FPGA_MGR_CYCLONE_SPI) += cyclonespi.o
> obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
> obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
> diff --git a/drivers/fpga/cyclonespi.c b/drivers/fpga/cyclonespi.c
> new file mode 100644
> index 0000000..1ffa67c
> --- /dev/null
> +++ b/drivers/fpga/cyclonespi.c
> @@ -0,0 +1,173 @@
> +/**
> + * Copyright (c) 2015 United Western Technologies, Corporation
> + *
> + * Joshua Clayton <stillcompiling@gmail.com>
> + *
> + * Manage Altera fpga firmware that is loaded over spi.
> + * Firmware must be in binary "rbf" format.
> + * Works on Cyclone V. Should work on cyclone series.
> + * May work on other Altera fpgas.
I think at one point we decided it's gonna be 'FPGA' to be consistent.
> +
> +static const struct of_device_id of_ef_match[] = {
> + { .compatible = "altr,cyclonespi-fpga-mgr", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, of_ef_match);
> +
> +static enum fpga_mgr_states cyclonespi_state(struct fpga_manager *mgr)
> +{
> + return mgr->state;
> +}
> +
> +static inline u32 revbit8x4(u32 n)
> +{
> + n = ((n & 0xF0F0F0F0UL) >> 4) | ((n & 0x0F0F0F0FUL) << 4);
> + n = ((n & 0xCCCCCCCCUL) >> 2) | ((n & 0x33333333UL) << 2);
> + n = ((n & 0xAAAAAAAAUL) >> 1) | ((n & 0x55555555UL) << 1);
> + return n;
> +}
During the Zynq FPGA manager reviews we decided that manipulating the bitstream
to be consumable by the driver is userland's job.
> +
> +static int cyclonespi_write_init(struct fpga_manager *mgr, u32 flags,
> + const char *buf, size_t count)
> +{
> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
> + u32 *fw32 = (u32 *)buf;
> + const u32 *fw_end = (u32 *)(buf + count);
> +
> + if (flags & FPGA_MGR_PARTIAL_RECONFIG) {
> + dev_err(&mgr->dev, "Partial reconfiguration not supported.\n");
> + return -EINVAL;
-ENOTSUPP?
> + }
> +
> + gpiod_set_value(conf->reset, 0);
> + udelay(50);
Should that value either be configurable, or a named constant?
> + msleep(1);
See above.
> + /* set buffer to lsb first */
> + while (fw32 < fw_end) {
> + *fw32 = revbit8x4(*fw32);
> + fw32++;
> + }
See above.
> +
> + return 0;
> +}
> +
> +static int cyclonespi_write(struct fpga_manager *mgr, const char *buf,
> + size_t count)
> +{
> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
> + const char *fw_data = buf;
> + const char *fw_data_end = fw_data + count;
> +
> + while (fw_data < fw_data_end) {
> + int ret;
> + int stride = fw_data_end - fw_data;
> +
> + if (stride > SZ_4K)
> + stride = SZ_4K;
> +
> + ret = spi_write(conf->spi, fw_data, stride);
> + if (ret) {
> + dev_err(&mgr->dev, "spi error in firmware write: %d\n",
> + ret);
> + return ret;
> + }
> + fw_data += stride;
> + }
> +
> + return 0;
> +}
> +
> +static int cyclonespi_write_complete(struct fpga_manager *mgr, u32 flags)
> +{
> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
> +
> + if (gpiod_get_value(conf->status) == 0) {
> + dev_err(&mgr->dev, "Error during configuration.\n");
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static const struct fpga_manager_ops cyclonespi_ops = {
> + .state = cyclonespi_state,
> + .write_init = cyclonespi_write_init,
> + .write = cyclonespi_write,
> + .write_complete = cyclonespi_write_complete,
> +};
> +
> +static int cyclonespi_probe(struct spi_device *spi)
> +{
> + struct cyclonespi_conf *conf = devm_kzalloc(&spi->dev, sizeof(*conf),
> + GFP_KERNEL);
> +
> + if (!conf)
> + return -ENOMEM;
> +
> + conf->spi = spi;
> + conf->reset = devm_gpiod_get(&spi->dev, "reset", GPIOD_OUT_LOW);
> + if (IS_ERR(conf->reset)) {
> + dev_err(&spi->dev, "Failed to get reset gpio: %ld\n",
> + PTR_ERR(conf->reset));
> + return PTR_ERR(conf->reset);
> + }
> +
> + conf->status = devm_gpiod_get(&spi->dev, "status", GPIOD_IN);
> + if (IS_ERR(conf->status)) {
> + dev_err(&spi->dev, "Failed to get status gpio: %ld\n",
> + PTR_ERR(conf->status));
> + return PTR_ERR(conf->status);
> + }
> +
> + return fpga_mgr_register(&spi->dev, "Altera SPI FPGA Manager",
> + &cyclonespi_ops, conf);
Nit: Altera >Cyclone< SPI FPGA Manager
Thanks ... reminds me I wanted to submit my patch for the icoboard ;-)
Moritz
^ permalink raw reply
* [PATCH 2/3] doc: dt: add cyclone-spi binding document
From: Moritz Fischer @ 2016-10-07 2:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8d89e70475e8e1c3ce5117a0367c8444c11c61e3.1475783742.git.stillcompiling@gmail.com>
Hi Joshua,
On Thu, Oct 6, 2016 at 1:34 PM, Joshua Clayton <stillcompiling@gmail.com> wrote:
> Describe a cyclonespi devicetree entry, required features
>
> Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
> ---
> .../bindings/fpga/cyclone-spi-fpga-mgr.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fpga/cyclone-spi-fpga-mgr.txt
>
> diff --git a/Documentation/devicetree/bindings/fpga/cyclone-spi-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/cyclone-spi-fpga-mgr.txt
> new file mode 100644
> index 0000000..8de34db
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/cyclone-spi-fpga-mgr.txt
> @@ -0,0 +1,23 @@
> +Altera SOCFPGA FPGA Manager
Copy & Paste? :)
> +Altera cyclone FPGAs support a method of loading the bitstream over what is
cyclone->Cyclone
> +referred to as "passive serial".
> +The passive serial link is not technically spi, and might require extra
> +circuits in order to play nicely with other spi slaves on the same bus.
> +
> +See https://www.altera.com/literature/hb/cyc/cyc_c51013.pdf
> +
> +Required properties:
> +- compatible : should contain "altr,cyclonespi-fpga-mgr"
Alan, do you guys have any input on the compat string?
I think generally the bindings should go before the actual usage in
your patch series. Meaning you wanna document the binding
before you use it. I think this patch should be [1/3].
Cheers,
Moritz
^ permalink raw reply
* [PATCH v3 04/11] ARM: dts: r8a7743: initial SoC device tree
From: Simon Horman @ 2016-10-07 3:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2883940.Oo8sg10L7m@wasted.cogentembedded.com>
Hi Sergei,
On Thu, Oct 06, 2016 at 12:38:18AM +0300, Sergei Shtylyov wrote:
> The initial R8A7743 SoC device tree including CPU cores, GIC, timer, SYSC,
> CPG, and the required clock descriptions.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
I notice that this patch enables two CPUs. Have you tested SMP and:
- CPU hotplug
- Suspend to RAM
^ permalink raw reply
* [PATCH v3 03/11] ARM: shmobile: r8a7743: basic SoC support
From: Simon Horman @ 2016-10-07 3:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15557770.lH5aPepOeZ@wasted.cogentembedded.com>
On Thu, Oct 06, 2016 at 12:37:08AM +0300, Sergei Shtylyov wrote:
> Add minimal support for the RZ/G1M (R8A7743) SoC.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, I have queued this up.
^ permalink raw reply
* [PATCH 0/2] ARM: shmobile: alt/gose: Add board part number to DT bindings
From: Simon Horman @ 2016-10-07 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475587248-13670-1-git-send-email-geert+renesas@glider.be>
On Tue, Oct 04, 2016 at 03:20:46PM +0200, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> This series at the missing board part numbers for r8a7794/alt and
> r8a7793/gose to the DT binding documentation, like is done for the other
> boards.
>
> Thanks for applying!
>
> Geert Uytterhoeven (2):
> ARM: shmobile: r8a7794/alt: Add board part number to DT bindings
> ARM: shmobile: r8a7793/gose: Add board part number to DT bindings
Thanks, I have queued these up.
^ permalink raw reply
* [PATCH] ARM: dts: r8a7794: Fix W=1 dtc warnings
From: Simon Horman @ 2016-10-07 3:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475587908-22151-1-git-send-email-geert+renesas@glider.be>
On Tue, Oct 04, 2016 at 03:31:48PM +0200, Geert Uytterhoeven wrote:
> Warning (unit_address_vs_reg): Node /sound at ec500000/rcar_sound,dvc/dvc at 0 has a unit name, but no reg property
...
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> arch/arm/boot/dts/r8a7794.dtsi | 58 +++++++++++++++++++++---------------------
> 1 file changed, 29 insertions(+), 29 deletions(-)
Thanks, I have queued this up.
^ permalink raw reply
* [PATCH v2 2/6] pwm: core: make the PWM_POLARITY flag in DTB optional
From: Bhuvanchandra DV @ 2016-10-07 4:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006083642.6a28a629@jawa>
Hi Lukasz,
On 10/06/16 12:06, Lukasz Majewski wrote:
> Hi Bhuvanchandra,
>
>> From: Lothar Wassmann <LW@KARO-electronics.de>
>>
>> Change the pwm chip driver registration, so that a chip driver that
>> supports polarity inversion can still be used with DTBs that don't
>> provide the 'PWM_POLARITY' flag.
>>
>> This is done to provide polarity inversion support for the pwm-imx
>> driver without having to modify all existing DTS files.
>>
>> Signed-off-by: Lothar Wassmann <LW@KARO-electronics.de>
>> Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
>> Suggested-by: Thierry Reding <thierry.reding@gmail.com>
>> ---
>> drivers/pwm/core.c | 27 ++++++++++++++++-----------
>> 1 file changed, 16 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
>> index 195373e..aae8db3 100644
>> --- a/drivers/pwm/core.c
>> +++ b/drivers/pwm/core.c
>> @@ -137,9 +137,14 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc,
>> const struct of_phandle_args *args) {
>> struct pwm_device *pwm;
>>
>> + /* check, whether the driver supports a third cell for flags
>> */ if (pc->of_pwm_n_cells < 3)
>> return ERR_PTR(-EINVAL);
>>
>> + /* flags in the third cell are optional */
>> + if (args->args_count < 2)
>> + return ERR_PTR(-EINVAL);
>> +
>> if (args->args[0] >= pc->npwm)
>> return ERR_PTR(-EINVAL);
>>
>> @@ -149,10 +154,12 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc,
>> const struct of_phandle_args *args)
>> pwm->args.period = args->args[1];
>>
>> - if (args->args[2] & PWM_POLARITY_INVERTED)
>> - pwm->args.polarity = PWM_POLARITY_INVERSED;
>> - else
>> - pwm->args.polarity = PWM_POLARITY_NORMAL;
>> + if (args->args_count > 2) {
>> + if (args->args[2] & PWM_POLARITY_INVERTED)
>> + pwm_set_polarity(pwm, PWM_POLARITY_INVERSED);
> ^^^^^^^^^^^^^^^^
> here we should set pwm->args.polarity, since
> the pwm_set_polarity() calls pwm_apply_state()
> which requires duty_cycle and period to be set.
>
> In this particular moment it is not yet set and
> polarity is not properly configured.
Agreed. Will do a clean v3 patchset along with the patch you sent
(pwm: core: Use pwm->args.polarity to setup PWM_POLARITY_INVERSED).
--
Bhuvan
>
> Patch fixing this will be sent as a reply to this e-mail. Please just
> squash it and test on your platform.
>
> Best regards,
> ?ukasz Majewski
>
>> + else
>> + pwm_set_polarity(pwm, PWM_POLARITY_NORMAL);
>> + }
>>
>> return pwm;
>> }
>> @@ -163,9 +170,14 @@ of_pwm_simple_xlate(struct pwm_chip *pc, const
>> struct of_phandle_args *args) {
>> struct pwm_device *pwm;
>>
>> + /* sanity check driver support */
>> if (pc->of_pwm_n_cells < 2)
>> return ERR_PTR(-EINVAL);
>>
>> + /* all cells are required */
>> + if (args->args_count != pc->of_pwm_n_cells)
>> + return ERR_PTR(-EINVAL);
>> +
>> if (args->args[0] >= pc->npwm)
>> return ERR_PTR(-EINVAL);
>>
>> @@ -672,13 +684,6 @@ struct pwm_device *of_pwm_get(struct device_node
>> *np, const char *con_id) goto put;
>> }
>>
>> - if (args.args_count != pc->of_pwm_n_cells) {
>> - pr_debug("%s: wrong #pwm-cells for %s\n",
>> np->full_name,
>> - args.np->full_name);
>> - pwm = ERR_PTR(-EINVAL);
>> - goto put;
>> - }
>> -
>> pwm = pc->of_xlate(pc, &args);
>> if (IS_ERR(pwm))
>> goto put;
^ permalink raw reply
* [PATCH v2 5/6] arm: dts: imx7-colibri: Use pwm polarity control
From: Bhuvanchandra DV @ 2016-10-07 4:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006084007.44c5cbae@jawa>
On 10/06/16 12:10, Lukasz Majewski wrote:
> On Sat, 1 Oct 2016 15:42:34 +0530
> Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> wrote:
>
>> Configure PWM polarity control.
>>
>> Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
>> ---
>> arch/arm/boot/dts/imx7-colibri.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi
>> b/arch/arm/boot/dts/imx7-colibri.dtsi index a9cc657..2af5e3e 100644
>> --- a/arch/arm/boot/dts/imx7-colibri.dtsi
>> +++ b/arch/arm/boot/dts/imx7-colibri.dtsi
>> @@ -43,7 +43,7 @@
>> / {
>> bl: backlight {
>> compatible = "pwm-backlight";
>> - pwms = <&pwm1 0 5000000>;
>> + pwms = <&pwm1 0 5000000 0>;
> My recommendation would be to add:
> #include <dt-bindings/pwm/pwm.h>
>
> and then define pwms as:
>
> pwms = <&pwm1 0 5000000 PWM_POLARITY_NORMAL>;
>
> It would be more readable
Ok, will add that.
--
Bhuvan
>
> Best regards,
> ?ukasz Majewski
>
>> };
>>
>> reg_module_3v3: regulator-module-3v3 {
^ permalink raw reply
* [PATCH v5 2/5] drm/bridge: Add RGB to VGA bridge support
From: Archit Taneja @ 2016-10-07 4:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1757833.hOePAQC2sg@avalon>
On 10/07/2016 02:34 AM, Laurent Pinchart wrote:
> Hi Sean,
>
> On Thursday 06 Oct 2016 15:53:28 Sean Paul wrote:
>> On Thu, Oct 6, 2016 at 1:27 PM, Laurent Pinchart wrote:
>>> On Thursday 06 Oct 2016 17:09:57 Archit Taneja wrote:
>>>> On 10/06/2016 12:51 PM, Maxime Ripard wrote:
>>>>> On Mon, Oct 03, 2016 at 04:40:57PM +0530, Archit Taneja wrote:
>>>>>> On 09/30/2016 08:07 PM, Maxime Ripard wrote:
>>>>>>> Some boards have an entirely passive RGB to VGA bridge, based on
>>>>>>> either DACs or resistor ladders.
>>>>>>>
>>>>>>> Those might or might not have an i2c bus routed to the VGA connector
>>>>>>> in order to access the screen EDIDs.
>>>>>>>
>>>>>>> Add a bridge that doesn't do anything but expose the modes available
>>>>>>> on the screen, either based on the EDIDs if available, or based on
>>>>>>> the XGA standards.
>>>>>>>
>>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>>> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>>>>>>> ---
>>>>>>> .../bindings/display/bridge/rgb-to-vga-bridge.txt | 48 +++++
>>>>>>> drivers/gpu/drm/bridge/Kconfig | 7 +
>>>>>>> drivers/gpu/drm/bridge/Makefile | 1 +
>>>>>>> drivers/gpu/drm/bridge/rgb-to-vga.c | 229 +++++++++++++
>>>>>>> 4 files changed, 285 insertions(+)
>>>>>>> create mode 100644
>>>>>>> Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.tx
>>>>>>> t
>>>>>>> create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
>>>>>>>
>>>>>>> diff --git
>>>>>>> a/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.
>>>>>>> txt
>>>>>>> b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.
>>>>>>> txt
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..a8375bc1f9cb
>>>>>>> --- /dev/null
>>>>>>> +++
>>>>>>> b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.
>>>>>>> tx
>>>>>>> t @@ -0,0 +1,48 @@
>>>>>>> +Dumb RGB to VGA bridge
>>>>>>> +----------------------
>>>>>>> +
>>>>>>> +This binding is aimed for dumb RGB to VGA bridges that do not
>>>>>>> require
>>>>>>> +any configuration.
>>>>>>> +
>>>>>>> +Required properties:
>>>>>>> +
>>>>>>> +- compatible: Must be "rgb-to-vga-bridge"
>>>>>>
>>>>>> I'd talked to Laurent on IRC if he's okay with this. And I guess you
>>>>>> to had discussed it during XDC too. He's suggested that it'd be better
>>>>>> to have the compatible string as "simple-vga-dac".
>>>>>
>>>>> I just wished this bikeshedding had taken place publicly and be
>>>>> actually part of that discussion, but yeah, ok.
>>>>
>>>> Sorry about that. I'd pinged him for an Ack, the discussion went
>>>> more than that :)
>>>>
>>>>>> Some of the reasons behind having this:
>>>>>>
>>>>>> - We don't need to specify "rgb" in the compatible string since most
>>>>>> simple VGA DACs can only work with an RGB input.
>>>>>
>>>>> Ok.
>>>>>
>>>>>> - Also, with "dac" specified in the string, we don't need to
>>>>>> specifically mention "bridge" in the string. Also, bridge is a drm
>>>>>> specific term.
>>>>>>
>>>>>> - "simple" is considered because it's an unconfigurable bridge, and it
>>>>>> might be misleading for other VGA DACs to not use "vga-dac".
>>>>>
>>>>> All those "simple" bindings are just the biggest lie we ever
>>>>> told. It's simple when you introduce it, and then grows into something
>>>>> much more complicated than a non-simple implementation.
>>>>
>>>> "simple" here is supposed to mean that it's an unconfigurable RGB to
>>>> VGA DAC. This isn't supposed to follow the simple-panel model, where
>>>> you add the "simple-panel" string in the compatible node, along with
>>>> you chip specific compatible string.
>>>
>>> I agree with Maxime, I don't like the word "simple". My preference would
>>> be "vga-dac" for a lack of a better qualifier than "simple" to describe
>>> the fact that the device requires no configuration. My only concern with
>>> "vga-dac" is that we would restrict usage of that compatible string for a
>>> subset of VGA DACs, with more complex devices not being compatible with
>>> "vga-dac" even though they are VGA DACs. That's a problem I can live with
>>> though.
>>
>> While we're bikeshedding (feel free to ignore my input on this), I
>> think Maxime's initial "dumb" qualifier was better than "simple".
>
> I think I agree.
>
>> I think "passive" also gets the point across better than "simple", which
>> we've already established as something else in drm.
>
> To my electrical engineer's ear, passive refers to a component or combination
> of components that is not capable of power gain. The resistors ladder VGA DAC
> that Maxime is trying to support is a passive system, but the ADV7123 VGA DAC
> that equally requires no configuration is an active component.
If no one has any more objections within the next day, I'll pull in
Maxime's v5 RGB to VGA bridge driver, and change the compatible to
"dumb-vga-dac".
Thanks,
Archit
>
>> Now that I've gotten that out of the way, this patch looks good to me
>> regardless of the name.
>>
>> Reviewed-by: Sean Paul <seanpaul@chromium.org>
>>
>> Sean
>>
>>>> In other words, this driver shouldn't be touched again in the future :)
>>>> If someone wants to write a RGB to VGA driver which is even
>>>> slightly configurable, they'll need to write a new bridge driver.
>>>
>>> I'm sure that won't be true. I can certainly foresee the addition of
>>> regulators support for instance. It's unfortunately never black and white.
>>>
>>>>>> What do you think about this? If you think it's good, would it be
>>>>>> possible for you to change this? I guess it's okay for the rest of
>>>>>> the patch to stay the same.
>>>>>
>>>>> I'll update and respin the serie.
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V5 00/10] dmaengine: qcom_hidma: add MSI interrupt support
From: Sinan Kaya @ 2016-10-07 5:25 UTC (permalink / raw)
To: linux-arm-kernel
The new version of the HW supports MSI interrupts instead of wired
interrupts. The MSI interrupts are especially useful for the guest machine
execution. The wired interrupts usually trap to the hypervisor and then are
relayed to the actual interrupt.
The MSI interrupts can be directly fed into the interrupt controller.
Adding a new OF compat string (qcom,hidma-1.1) and ACPI string (QCOM8062)
to distinguish newer HW from the older ones.
v5:
* dmaengine: qcom_hidma: add MSI support for interrupts
** Return MSI interrupts before calling platform_msi_domain_free_irqs.
Also cleanup MSI interrupts on the error path.
** Free the legacy IRQ only if MSI is disabled
* add dmaengine: qcom_hidma: break completion processing on error
in order to break the completions if an error is observed while servicing
completed work.
* drop dmaengine: qcom_hidma: make error and success path common
as the success path assumes that we'll get the number of notifications for
the
jobs queued. This is not true under error conditions.
* simplify dmaengine: qcom_hidma: protect common data structures. We just
need to protect the TRE processed offset. It is the variable that keeps
track
of outstanding requests.
* document assumptions about of_msi_configure routine call.
v4:
http://www.spinics.net/lists/devicetree/msg144563.html
* device tree binding update to refer to msi.txt
v3:
* day 0 fix for when ACPI is not compiled in
* https://www.spinics.net/lists/arm-kernel/msg532179.html
v2:
https://patchwork.kernel.org/patch/9326399/
* Documentation update for DT bindings
* Rebased to slave-next
* Dropped dmaengine: qcom_hidma: eliminate processed variables. Replaced it
with dmaengine: qcom_hidma: protect common data structures
v1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/444167.html
* initial implementation
Sinan Kaya (10):
Documentation: DT: qcom_hidma: update binding for MSI
Documentation: DT: qcom_hidma: correct spelling mistakes
of: irq: make of_msi_configure accessible from modules
dmaengine: qcom_hidma: configure DMA and MSI for OF
dmaengine: qcom_hidma: make pending_tre_count atomic
dmaengine: qcom_hidma: bring out interrupt cause
dmaengine: qcom_hidma: add a common API to setup the interrupt
dmaengine: qcom_hidma: protect common data structures
dmaengine: qcom_hidma: break completion processing on error
dmaengine: qcom_hidma: add MSI support for interrupts
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt | 12 +-
drivers/dma/qcom/hidma.c | 143 ++++++++++++++++++-
drivers/dma/qcom/hidma.h | 6 +-
drivers/dma/qcom/hidma_dbg.c | 3 +-
drivers/dma/qcom/hidma_ll.c | 156 ++++++++++++---------
drivers/dma/qcom/hidma_mgmt.c | 9 +-
drivers/of/irq.c | 1 +
7 files changed, 250 insertions(+), 80 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH V5 01/10] Documentation: DT: qcom_hidma: update binding for MSI
From: Sinan Kaya @ 2016-10-07 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475817915-11976-1-git-send-email-okaya@codeaurora.org>
Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting
MSI interrupts from the older revision.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
index fd5618b..2c5e4b8 100644
--- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -47,12 +47,18 @@ When the OS is not in control of the management interface (i.e. it's a guest),
the channel nodes appear on their own, not under a management node.
Required properties:
-- compatible: must contain "qcom,hidma-1.0"
+- compatible: must contain "qcom,hidma-1.0" for initial HW or "qcom,hidma-1.1"
+for MSI capable HW.
- reg: Addresses for the transfer and event channel
- interrupts: Should contain the event interrupt
- desc-count: Number of asynchronous requests this channel can handle
- iommus: required a iommu node
+Optional properties for MSI:
+- msi-parent : See the generic MSI binding described in
+ devicetree/bindings/interrupt-controller/msi.txt for a description of the
+ msi-parent property.
+
Example:
Hypervisor OS configuration:
--
1.9.1
^ permalink raw reply related
* [PATCH V5 02/10] Documentation: DT: qcom_hidma: correct spelling mistakes
From: Sinan Kaya @ 2016-10-07 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475817915-11976-1-git-send-email-okaya@codeaurora.org>
Fix the spelling mistakes and extra and statements in the sentences.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
index 2c5e4b8..55492c2 100644
--- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -5,13 +5,13 @@ memcpy and memset capabilities. It has been designed for virtualized
environments.
Each HIDMA HW instance consists of multiple DMA channels. These channels
-share the same bandwidth. The bandwidth utilization can be parititioned
+share the same bandwidth. The bandwidth utilization can be partitioned
among channels based on the priority and weight assignments.
There are only two priority levels and 15 weigh assignments possible.
Other parameters here determine how much of the system bus this HIDMA
-instance can use like maximum read/write request and and number of bytes to
+instance can use like maximum read/write request and number of bytes to
read/write in a single burst.
Main node required properties:
--
1.9.1
^ permalink raw reply related
* [PATCH V5 03/10] of: irq: make of_msi_configure accessible from modules
From: Sinan Kaya @ 2016-10-07 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475817915-11976-1-git-send-email-okaya@codeaurora.org>
The of_msi_configure routine is only accessible by the built-in
kernel drivers. Export this function so that modules can use it
too.
This function is useful for configuring MSI on child device tree
nodes on hierarchical objects.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/of/irq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index a2e68f7..20c09e0 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -767,3 +767,4 @@ void of_msi_configure(struct device *dev, struct device_node *np)
dev_set_msi_domain(dev,
of_msi_get_domain(dev, np, DOMAIN_BUS_PLATFORM_MSI));
}
+EXPORT_SYMBOL_GPL(of_msi_configure);
--
1.9.1
^ permalink raw reply related
* [PATCH V5 04/10] dmaengine: qcom_hidma: configure DMA and MSI for OF
From: Sinan Kaya @ 2016-10-07 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475817915-11976-1-git-send-email-okaya@codeaurora.org>
Configure the DMA bindings for the device tree based firmware.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma_mgmt.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index 82f36e4..185d29c 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -375,8 +375,15 @@ static int __init hidma_mgmt_of_populate_channels(struct device_node *np)
ret = PTR_ERR(new_pdev);
goto out;
}
+ of_node_get(child);
+ new_pdev->dev.of_node = child;
of_dma_configure(&new_pdev->dev, child);
-
+ /*
+ * It is assumed that calling of_msi_configure is safe on
+ * platforms with or without MSI support.
+ */
+ of_msi_configure(&new_pdev->dev, child);
+ of_node_put(child);
kfree(res);
res = NULL;
}
--
1.9.1
^ permalink raw reply related
* [PATCH V5 05/10] dmaengine: qcom_hidma: make pending_tre_count atomic
From: Sinan Kaya @ 2016-10-07 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475817915-11976-1-git-send-email-okaya@codeaurora.org>
Getting ready for the MSI interrupts. The pending_tre_count is used
in the interrupt handler to make sure all outstanding requests are
serviced.
The driver will allocate 11 MSI interrupts. Each MSI interrupt can be
assigned to a different CPU. Then, we have a race condition for common
variables as they share the same interrupt handler with a different
cause bit and they can potentially be executed in parallel. Making this
variable atomic so that it can be updated from multiple processor
contexts.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma.h | 2 +-
drivers/dma/qcom/hidma_dbg.c | 3 ++-
drivers/dma/qcom/hidma_ll.c | 13 ++++++-------
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index b209942..afaeb9a 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -58,7 +58,7 @@ struct hidma_lldev {
void __iomem *evca; /* Event Channel address */
struct hidma_tre
**pending_tre_list; /* Pointers to pending TREs */
- s32 pending_tre_count; /* Number of TREs pending */
+ atomic_t pending_tre_count; /* Number of TREs pending */
void *tre_ring; /* TRE ring */
dma_addr_t tre_dma; /* TRE ring to be shared with HW */
diff --git a/drivers/dma/qcom/hidma_dbg.c b/drivers/dma/qcom/hidma_dbg.c
index 3d83b99..3bdcb80 100644
--- a/drivers/dma/qcom/hidma_dbg.c
+++ b/drivers/dma/qcom/hidma_dbg.c
@@ -74,7 +74,8 @@ static void hidma_ll_devstats(struct seq_file *s, void *llhndl)
seq_printf(s, "tre_ring_handle=%pap\n", &lldev->tre_dma);
seq_printf(s, "tre_ring_size = 0x%x\n", lldev->tre_ring_size);
seq_printf(s, "tre_processed_off = 0x%x\n", lldev->tre_processed_off);
- seq_printf(s, "pending_tre_count=%d\n", lldev->pending_tre_count);
+ seq_printf(s, "pending_tre_count=%d\n",
+ atomic_read(&lldev->pending_tre_count));
seq_printf(s, "evca=%p\n", lldev->evca);
seq_printf(s, "evre_ring=%p\n", lldev->evre_ring);
seq_printf(s, "evre_ring_handle=%pap\n", &lldev->evre_dma);
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
index ad20dfb..a4fc941 100644
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -218,10 +218,9 @@ static int hidma_post_completed(struct hidma_lldev *lldev, int tre_iterator,
* Keep track of pending TREs that SW is expecting to receive
* from HW. We got one now. Decrement our counter.
*/
- lldev->pending_tre_count--;
- if (lldev->pending_tre_count < 0) {
+ if (atomic_dec_return(&lldev->pending_tre_count) < 0) {
dev_warn(lldev->dev, "tre count mismatch on completion");
- lldev->pending_tre_count = 0;
+ atomic_set(&lldev->pending_tre_count, 0);
}
spin_unlock_irqrestore(&lldev->lock, flags);
@@ -321,7 +320,7 @@ void hidma_cleanup_pending_tre(struct hidma_lldev *lldev, u8 err_info,
u32 tre_read_off;
tre_iterator = lldev->tre_processed_off;
- while (lldev->pending_tre_count) {
+ while (atomic_read(&lldev->pending_tre_count)) {
if (hidma_post_completed(lldev, tre_iterator, err_info,
err_code))
break;
@@ -564,7 +563,7 @@ void hidma_ll_queue_request(struct hidma_lldev *lldev, u32 tre_ch)
tre->err_code = 0;
tre->err_info = 0;
tre->queued = 1;
- lldev->pending_tre_count++;
+ atomic_inc(&lldev->pending_tre_count);
lldev->tre_write_offset = (lldev->tre_write_offset + HIDMA_TRE_SIZE)
% lldev->tre_ring_size;
spin_unlock_irqrestore(&lldev->lock, flags);
@@ -670,7 +669,7 @@ int hidma_ll_setup(struct hidma_lldev *lldev)
u32 val;
u32 nr_tres = lldev->nr_tres;
- lldev->pending_tre_count = 0;
+ atomic_set(&lldev->pending_tre_count, 0);
lldev->tre_processed_off = 0;
lldev->evre_processed_off = 0;
lldev->tre_write_offset = 0;
@@ -834,7 +833,7 @@ int hidma_ll_uninit(struct hidma_lldev *lldev)
tasklet_kill(&lldev->rst_task);
memset(lldev->trepool, 0, required_bytes);
lldev->trepool = NULL;
- lldev->pending_tre_count = 0;
+ atomic_set(&lldev->pending_tre_count, 0);
lldev->tre_write_offset = 0;
rc = hidma_ll_reset(lldev);
--
1.9.1
^ permalink raw reply related
* [PATCH V5 06/10] dmaengine: qcom_hidma: bring out interrupt cause
From: Sinan Kaya @ 2016-10-07 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475817915-11976-1-git-send-email-okaya@codeaurora.org>
Bring out the interrupt cause to the top level so that MSI interrupts
can be hooked at a later stage.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma_ll.c | 57 ++++++++++++++++++++++++++-------------------
1 file changed, 33 insertions(+), 24 deletions(-)
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
index a4fc941..015df4b 100644
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -432,12 +432,24 @@ static void hidma_ll_abort(unsigned long arg)
* requests traditionally to the destination, this concept does not apply
* here for this HW.
*/
-irqreturn_t hidma_ll_inthandler(int chirq, void *arg)
+static void hidma_ll_int_handler_internal(struct hidma_lldev *lldev, int cause)
{
- struct hidma_lldev *lldev = arg;
- u32 status;
- u32 enable;
- u32 cause;
+ if (cause & HIDMA_ERR_INT_MASK) {
+ dev_err(lldev->dev, "error 0x%x, disabling...\n",
+ cause);
+
+ /* Clear out pending interrupts */
+ writel(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
+
+ /* No further submissions. */
+ hidma_ll_disable(lldev);
+
+ /* Driver completes the txn and intimates the client.*/
+ hidma_cleanup_pending_tre(lldev, 0xFF,
+ HIDMA_EVRE_STATUS_ERROR);
+
+ return;
+ }
/*
* Fine tuned for this HW...
@@ -446,30 +458,28 @@ irqreturn_t hidma_ll_inthandler(int chirq, void *arg)
* read and write accessors are used for performance reasons due to
* interrupt delivery guarantees. Do not copy this code blindly and
* expect that to work.
+ *
+ * Try to consume as many EVREs as possible.
*/
+ hidma_handle_tre_completion(lldev);
+
+ /* We consumed TREs or there are pending TREs or EVREs. */
+ writel_relaxed(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
+}
+
+irqreturn_t hidma_ll_inthandler(int chirq, void *arg)
+{
+ struct hidma_lldev *lldev = arg;
+ u32 status;
+ u32 enable;
+ u32 cause;
+
status = readl_relaxed(lldev->evca + HIDMA_EVCA_IRQ_STAT_REG);
enable = readl_relaxed(lldev->evca + HIDMA_EVCA_IRQ_EN_REG);
cause = status & enable;
while (cause) {
- if (cause & HIDMA_ERR_INT_MASK) {
- dev_err(lldev->dev, "error 0x%x, resetting...\n",
- cause);
-
- /* Clear out pending interrupts */
- writel(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
-
- tasklet_schedule(&lldev->rst_task);
- goto out;
- }
-
- /*
- * Try to consume as many EVREs as possible.
- */
- hidma_handle_tre_completion(lldev);
-
- /* We consumed TREs or there are pending TREs or EVREs. */
- writel_relaxed(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
+ hidma_ll_int_handler_internal(lldev, cause);
/*
* Another interrupt might have arrived while we are
@@ -480,7 +490,6 @@ irqreturn_t hidma_ll_inthandler(int chirq, void *arg)
cause = status & enable;
}
-out:
return IRQ_HANDLED;
}
--
1.9.1
^ permalink raw reply related
* [PATCH V5 07/10] dmaengine: qcom_hidma: add a common API to setup the interrupt
From: Sinan Kaya @ 2016-10-07 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475817915-11976-1-git-send-email-okaya@codeaurora.org>
Introducing the hidma_ll_setup_irq function to set up the interrupt
type externally from the OS interface.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma.h | 2 ++
drivers/dma/qcom/hidma_ll.c | 27 +++++++++++++++++++++++----
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index afaeb9a..b74a56e 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -46,6 +46,7 @@ struct hidma_tre {
};
struct hidma_lldev {
+ bool msi_support; /* flag indicating MSI support */
bool initialized; /* initialized flag */
u8 trch_state; /* trch_state of the device */
u8 evch_state; /* evch_state of the device */
@@ -148,6 +149,7 @@ int hidma_ll_disable(struct hidma_lldev *lldev);
int hidma_ll_enable(struct hidma_lldev *llhndl);
void hidma_ll_set_transfer_params(struct hidma_lldev *llhndl, u32 tre_ch,
dma_addr_t src, dma_addr_t dest, u32 len, u32 flags);
+void hidma_ll_setup_irq(struct hidma_lldev *lldev, bool msi);
int hidma_ll_setup(struct hidma_lldev *lldev);
struct hidma_lldev *hidma_ll_init(struct device *dev, u32 max_channels,
void __iomem *trca, void __iomem *evca,
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
index 015df4b..9d78c86 100644
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -715,17 +715,36 @@ int hidma_ll_setup(struct hidma_lldev *lldev)
writel(HIDMA_EVRE_SIZE * nr_tres,
lldev->evca + HIDMA_EVCA_RING_LEN_REG);
- /* support IRQ only for now */
+ /* configure interrupts */
+ hidma_ll_setup_irq(lldev, lldev->msi_support);
+
+ rc = hidma_ll_enable(lldev);
+ if (rc)
+ return rc;
+
+ return rc;
+}
+
+void hidma_ll_setup_irq(struct hidma_lldev *lldev, bool msi)
+{
+ u32 val;
+
+ lldev->msi_support = msi;
+
+ /* disable interrupts again after reset */
+ writel(0, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
+ writel(0, lldev->evca + HIDMA_EVCA_IRQ_EN_REG);
+
+ /* support IRQ by default */
val = readl(lldev->evca + HIDMA_EVCA_INTCTRL_REG);
val &= ~0xF;
- val |= 0x1;
+ if (!lldev->msi_support)
+ val = val | 0x1;
writel(val, lldev->evca + HIDMA_EVCA_INTCTRL_REG);
/* clear all pending interrupts and enable them */
writel(ENABLE_IRQS, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
writel(ENABLE_IRQS, lldev->evca + HIDMA_EVCA_IRQ_EN_REG);
-
- return hidma_ll_enable(lldev);
}
struct hidma_lldev *hidma_ll_init(struct device *dev, u32 nr_tres,
--
1.9.1
^ permalink raw reply related
* [PATCH V5 08/10] dmaengine: qcom_hidma: protect common data structures
From: Sinan Kaya @ 2016-10-07 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475817915-11976-1-git-send-email-okaya@codeaurora.org>
When MSI interrupts are supported, error and the transfer interrupt can
come from multiple processor contexts.
Each error interrupt is an MSI interrupt. If the channel is disabled by
the first error interrupt, the remaining error interrupts will gracefully
return in the interrupt handler.
If an error is observed while servicing the completions in success case,
the posting of the completions will be aborted as soon as channel disabled
state is observed. The error interrupt handler will take it from there and
finish the remaining completions. We don't want to create multiple success
and error messages to be delivered to the client in mixed order.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma_ll.c | 44 +++++++++++---------------------------------
1 file changed, 11 insertions(+), 33 deletions(-)
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
index 9d78c86..c4e8b64 100644
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -198,13 +198,16 @@ static void hidma_ll_tre_complete(unsigned long arg)
}
}
-static int hidma_post_completed(struct hidma_lldev *lldev, int tre_iterator,
- u8 err_info, u8 err_code)
+static int hidma_post_completed(struct hidma_lldev *lldev, u8 err_info,
+ u8 err_code)
{
struct hidma_tre *tre;
unsigned long flags;
+ u32 tre_iterator;
spin_lock_irqsave(&lldev->lock, flags);
+
+ tre_iterator = lldev->tre_processed_off;
tre = lldev->pending_tre_list[tre_iterator / HIDMA_TRE_SIZE];
if (!tre) {
spin_unlock_irqrestore(&lldev->lock, flags);
@@ -223,6 +226,9 @@ static int hidma_post_completed(struct hidma_lldev *lldev, int tre_iterator,
atomic_set(&lldev->pending_tre_count, 0);
}
+ HIDMA_INCREMENT_ITERATOR(tre_iterator, HIDMA_TRE_SIZE,
+ lldev->tre_ring_size);
+ lldev->tre_processed_off = tre_iterator;
spin_unlock_irqrestore(&lldev->lock, flags);
tre->err_info = err_info;
@@ -244,13 +250,11 @@ static int hidma_post_completed(struct hidma_lldev *lldev, int tre_iterator,
static int hidma_handle_tre_completion(struct hidma_lldev *lldev)
{
u32 evre_ring_size = lldev->evre_ring_size;
- u32 tre_ring_size = lldev->tre_ring_size;
u32 err_info, err_code, evre_write_off;
- u32 tre_iterator, evre_iterator;
+ u32 evre_iterator;
u32 num_completed = 0;
evre_write_off = readl_relaxed(lldev->evca + HIDMA_EVCA_WRITE_PTR_REG);
- tre_iterator = lldev->tre_processed_off;
evre_iterator = lldev->evre_processed_off;
if ((evre_write_off > evre_ring_size) ||
@@ -273,12 +277,9 @@ static int hidma_handle_tre_completion(struct hidma_lldev *lldev)
err_code =
(cfg >> HIDMA_EVRE_CODE_BIT_POS) & HIDMA_EVRE_CODE_MASK;
- if (hidma_post_completed(lldev, tre_iterator, err_info,
- err_code))
+ if (hidma_post_completed(lldev, err_info, err_code))
break;
- HIDMA_INCREMENT_ITERATOR(tre_iterator, HIDMA_TRE_SIZE,
- tre_ring_size);
HIDMA_INCREMENT_ITERATOR(evre_iterator, HIDMA_EVRE_SIZE,
evre_ring_size);
@@ -295,16 +296,10 @@ static int hidma_handle_tre_completion(struct hidma_lldev *lldev)
if (num_completed) {
u32 evre_read_off = (lldev->evre_processed_off +
HIDMA_EVRE_SIZE * num_completed);
- u32 tre_read_off = (lldev->tre_processed_off +
- HIDMA_TRE_SIZE * num_completed);
-
evre_read_off = evre_read_off % evre_ring_size;
- tre_read_off = tre_read_off % tre_ring_size;
-
writel(evre_read_off, lldev->evca + HIDMA_EVCA_DOORBELL_REG);
/* record the last processed tre offset */
- lldev->tre_processed_off = tre_read_off;
lldev->evre_processed_off = evre_read_off;
}
@@ -314,27 +309,10 @@ static int hidma_handle_tre_completion(struct hidma_lldev *lldev)
void hidma_cleanup_pending_tre(struct hidma_lldev *lldev, u8 err_info,
u8 err_code)
{
- u32 tre_iterator;
- u32 tre_ring_size = lldev->tre_ring_size;
- int num_completed = 0;
- u32 tre_read_off;
-
- tre_iterator = lldev->tre_processed_off;
while (atomic_read(&lldev->pending_tre_count)) {
- if (hidma_post_completed(lldev, tre_iterator, err_info,
- err_code))
+ if (hidma_post_completed(lldev, err_info, err_code))
break;
- HIDMA_INCREMENT_ITERATOR(tre_iterator, HIDMA_TRE_SIZE,
- tre_ring_size);
- num_completed++;
}
- tre_read_off = (lldev->tre_processed_off +
- HIDMA_TRE_SIZE * num_completed);
-
- tre_read_off = tre_read_off % tre_ring_size;
-
- /* record the last processed tre offset */
- lldev->tre_processed_off = tre_read_off;
}
static int hidma_ll_reset(struct hidma_lldev *lldev)
--
1.9.1
^ permalink raw reply related
* [PATCH V5 09/10] dmaengine: qcom_hidma: break completion processing on error
From: Sinan Kaya @ 2016-10-07 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475817915-11976-1-git-send-email-okaya@codeaurora.org>
We try to consume as much successful transfers as possible. Now that we
support MSI interrupts, an error interrupt might be observed by another
processor while we are finishing the successful ones.
Try to abort successful processing if this is the case.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma_ll.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
index c4e8b64..aa76ec1 100644
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -291,6 +291,13 @@ static int hidma_handle_tre_completion(struct hidma_lldev *lldev)
evre_write_off =
readl_relaxed(lldev->evca + HIDMA_EVCA_WRITE_PTR_REG);
num_completed++;
+
+ /*
+ * An error interrupt might have arrived while we are processing
+ * the completed interrupt.
+ */
+ if (!hidma_ll_isenabled(lldev))
+ break;
}
if (num_completed) {
--
1.9.1
^ permalink raw reply related
* [PATCH V5 10/10] dmaengine: qcom_hidma: add MSI support for interrupts
From: Sinan Kaya @ 2016-10-07 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475817915-11976-1-git-send-email-okaya@codeaurora.org>
The interrupts can now be delivered as platform MSI interrupts on newer
platforms. The code looks for a new OF and ACPI strings in order to enable
the functionality.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma.c | 143 ++++++++++++++++++++++++++++++++++++++++++--
drivers/dma/qcom/hidma.h | 2 +
drivers/dma/qcom/hidma_ll.c | 8 +++
3 files changed, 147 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index 10a9e3a..7b13213 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -56,6 +56,7 @@
#include <linux/irq.h>
#include <linux/atomic.h>
#include <linux/pm_runtime.h>
+#include <linux/msi.h>
#include "../dmaengine.h"
#include "hidma.h"
@@ -70,6 +71,7 @@
#define HIDMA_ERR_INFO_SW 0xFF
#define HIDMA_ERR_CODE_UNEXPECTED_TERMINATE 0x0
#define HIDMA_NR_DEFAULT_DESC 10
+#define HIDMA_MSI_INTS 11
static inline struct hidma_dev *to_hidma_dev(struct dma_device *dmadev)
{
@@ -530,6 +532,15 @@ static irqreturn_t hidma_chirq_handler(int chirq, void *arg)
return hidma_ll_inthandler(chirq, lldev);
}
+static irqreturn_t hidma_chirq_handler_msi(int chirq, void *arg)
+{
+ struct hidma_lldev **lldevp = arg;
+ struct hidma_dev *dmadev = to_hidma_dev_from_lldev(lldevp);
+
+ return hidma_ll_inthandler_msi(chirq, *lldevp,
+ 1 << (chirq - dmadev->msi_virqbase));
+}
+
static ssize_t hidma_show_values(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -584,6 +595,104 @@ static int hidma_sysfs_init(struct hidma_dev *dev)
return device_create_file(dev->ddev.dev, dev->chid_attrs);
}
+#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
+static void hidma_write_msi_msg(struct msi_desc *desc, struct msi_msg *msg)
+{
+ struct device *dev = msi_desc_to_dev(desc);
+ struct hidma_dev *dmadev = dev_get_drvdata(dev);
+
+ if (!desc->platform.msi_index) {
+ writel(msg->address_lo, dmadev->dev_evca + 0x118);
+ writel(msg->address_hi, dmadev->dev_evca + 0x11C);
+ writel(msg->data, dmadev->dev_evca + 0x120);
+ }
+}
+#endif
+
+static void hidma_free_msis(struct hidma_dev *dmadev)
+{
+#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
+ struct device *dev = dmadev->ddev.dev;
+ struct msi_desc *desc;
+
+ /* free allocated MSI interrupts above */
+ for_each_msi_entry(desc, dev)
+ devm_free_irq(dev, desc->irq, &dmadev->lldev);
+
+ platform_msi_domain_free_irqs(dev);
+#endif
+}
+
+static int hidma_request_msi(struct hidma_dev *dmadev,
+ struct platform_device *pdev)
+{
+#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
+ int rc;
+ struct msi_desc *desc;
+ struct msi_desc *failed_desc = NULL;
+
+ rc = platform_msi_domain_alloc_irqs(&pdev->dev, HIDMA_MSI_INTS,
+ hidma_write_msi_msg);
+ if (rc)
+ return rc;
+
+ for_each_msi_entry(desc, &pdev->dev) {
+ if (!desc->platform.msi_index)
+ dmadev->msi_virqbase = desc->irq;
+
+ rc = devm_request_irq(&pdev->dev, desc->irq,
+ hidma_chirq_handler_msi,
+ 0, "qcom-hidma-msi",
+ &dmadev->lldev);
+ if (rc) {
+ failed_desc = desc;
+ break;
+ }
+ }
+
+ if (rc) {
+ /* free allocated MSI interrupts above */
+ for_each_msi_entry(desc, &pdev->dev) {
+ if (desc == failed_desc)
+ break;
+ devm_free_irq(&pdev->dev, desc->irq,
+ &dmadev->lldev);
+ }
+ } else {
+ /* Add callback to free MSIs on teardown */
+ hidma_ll_setup_irq(dmadev->lldev, true);
+
+ }
+ if (rc)
+ dev_warn(&pdev->dev,
+ "failed to request MSI irq, falling back to wired IRQ\n");
+ return rc;
+#else
+ return -EINVAL;
+#endif
+}
+
+static bool hidma_msi_capable(struct device *dev)
+{
+ struct acpi_device *adev = ACPI_COMPANION(dev);
+ const char *of_compat;
+ int ret = -EINVAL;
+
+ if (!adev || acpi_disabled) {
+ ret = device_property_read_string(dev, "compatible",
+ &of_compat);
+ if (ret)
+ return false;
+
+ ret = strcmp(of_compat, "qcom,hidma-1.1");
+ } else {
+#ifdef CONFIG_ACPI
+ ret = strcmp(acpi_device_hid(adev), "QCOM8062");
+#endif
+ }
+ return ret == 0;
+}
+
static int hidma_probe(struct platform_device *pdev)
{
struct hidma_dev *dmadev;
@@ -593,6 +702,7 @@ static int hidma_probe(struct platform_device *pdev)
void __iomem *evca;
void __iomem *trca;
int rc;
+ bool msi;
pm_runtime_set_autosuspend_delay(&pdev->dev, HIDMA_AUTOSUSPEND_TIMEOUT);
pm_runtime_use_autosuspend(&pdev->dev);
@@ -654,6 +764,12 @@ static int hidma_probe(struct platform_device *pdev)
dmadev->ddev.device_terminate_all = hidma_terminate_all;
dmadev->ddev.copy_align = 8;
+ /*
+ * Determine the MSI capability of the platform. Old HW doesn't
+ * support MSI.
+ */
+ msi = hidma_msi_capable(&pdev->dev);
+
device_property_read_u32(&pdev->dev, "desc-count",
&dmadev->nr_descriptors);
@@ -682,10 +798,17 @@ static int hidma_probe(struct platform_device *pdev)
goto dmafree;
}
- rc = devm_request_irq(&pdev->dev, chirq, hidma_chirq_handler, 0,
- "qcom-hidma", dmadev->lldev);
- if (rc)
- goto uninit;
+ platform_set_drvdata(pdev, dmadev);
+ if (msi)
+ rc = hidma_request_msi(dmadev, pdev);
+
+ if (!msi || rc) {
+ hidma_ll_setup_irq(dmadev->lldev, false);
+ rc = devm_request_irq(&pdev->dev, chirq, hidma_chirq_handler,
+ 0, "qcom-hidma", dmadev->lldev);
+ if (rc)
+ goto uninit;
+ }
INIT_LIST_HEAD(&dmadev->ddev.channels);
rc = hidma_chan_init(dmadev, 0);
@@ -701,12 +824,14 @@ static int hidma_probe(struct platform_device *pdev)
hidma_debug_init(dmadev);
hidma_sysfs_init(dmadev);
dev_info(&pdev->dev, "HI-DMA engine driver registration complete\n");
- platform_set_drvdata(pdev, dmadev);
pm_runtime_mark_last_busy(dmadev->ddev.dev);
pm_runtime_put_autosuspend(dmadev->ddev.dev);
return 0;
uninit:
+ if (msi)
+ hidma_free_msis(dmadev);
+
hidma_debug_uninit(dmadev);
hidma_ll_uninit(dmadev->lldev);
dmafree:
@@ -724,7 +849,11 @@ static int hidma_remove(struct platform_device *pdev)
pm_runtime_get_sync(dmadev->ddev.dev);
dma_async_device_unregister(&dmadev->ddev);
- devm_free_irq(dmadev->ddev.dev, dmadev->irq, dmadev->lldev);
+ if (!dmadev->lldev->msi_support)
+ devm_free_irq(dmadev->ddev.dev, dmadev->irq, dmadev->lldev);
+ else
+ hidma_free_msis(dmadev);
+
tasklet_kill(&dmadev->task);
hidma_sysfs_uninit(dmadev);
hidma_debug_uninit(dmadev);
@@ -741,12 +870,14 @@ static int hidma_remove(struct platform_device *pdev)
#if IS_ENABLED(CONFIG_ACPI)
static const struct acpi_device_id hidma_acpi_ids[] = {
{"QCOM8061"},
+ {"QCOM8062"},
{},
};
#endif
static const struct of_device_id hidma_match[] = {
{.compatible = "qcom,hidma-1.0",},
+ {.compatible = "qcom,hidma-1.1",},
{},
};
MODULE_DEVICE_TABLE(of, hidma_match);
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index b74a56e..b6a9028 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -115,6 +115,7 @@ struct hidma_dev {
int irq;
int chidx;
u32 nr_descriptors;
+ int msi_virqbase;
struct hidma_lldev *lldev;
void __iomem *dev_trca;
@@ -156,6 +157,7 @@ struct hidma_lldev *hidma_ll_init(struct device *dev, u32 max_channels,
u8 chidx);
int hidma_ll_uninit(struct hidma_lldev *llhndl);
irqreturn_t hidma_ll_inthandler(int irq, void *arg);
+irqreturn_t hidma_ll_inthandler_msi(int irq, void *arg, int cause);
void hidma_cleanup_pending_tre(struct hidma_lldev *llhndl, u8 err_info,
u8 err_code);
int hidma_debug_init(struct hidma_dev *dmadev);
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
index aa76ec1..40bcf31 100644
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -478,6 +478,14 @@ irqreturn_t hidma_ll_inthandler(int chirq, void *arg)
return IRQ_HANDLED;
}
+irqreturn_t hidma_ll_inthandler_msi(int chirq, void *arg, int cause)
+{
+ struct hidma_lldev *lldev = arg;
+
+ hidma_ll_int_handler_internal(lldev, cause);
+ return IRQ_HANDLED;
+}
+
int hidma_ll_enable(struct hidma_lldev *lldev)
{
u32 val;
--
1.9.1
^ permalink raw reply related
* [PATCH] ARM: shmobile: Consolidate R8A779[234] machine definitions
From: Simon Horman @ 2016-10-07 5:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <18001316.v0q3v65y95@avalon>
On Wed, Oct 05, 2016 at 04:51:26PM +0300, Laurent Pinchart wrote:
> On Wednesday 05 Oct 2016 13:31:29 Laurent Pinchart wrote:
> > The three SoCs use the exact same machine definition, consolidate them
> > into a single one.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> > arch/arm/mach-shmobile/Makefile | 3 ---
> > arch/arm/mach-shmobile/setup-r8a7792.c | 35
> > -------------------------------- arch/arm/mach-shmobile/setup-r8a7793.c |
> > 33 ------------------------------ arch/arm/mach-shmobile/setup-r8a7794.c
> > | 33 ------------------------------
> > arch/arm/mach-shmobile/setup-rcar-gen2.c | 20 ++++++++++++++++++
> > 5 files changed, 20 insertions(+), 104 deletions(-)
> > delete mode 100644 arch/arm/mach-shmobile/setup-r8a7792.c
> > delete mode 100644 arch/arm/mach-shmobile/setup-r8a7793.c
> > delete mode 100644 arch/arm/mach-shmobile/setup-r8a7794.c
> >
> > I don't have access to any R8A779[234] board, I'd appreciate if someone
> > could test the patch series.
I have tested this on an r8a7793/gose and r8a7794/alt.
Tested-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH v2 5/6] arm: dts: imx7-colibri: Use pwm polarity control
From: Bhuvanchandra DV @ 2016-10-07 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006084007.44c5cbae@jawa>
On 10/06/16 12:10, Lukasz Majewski wrote:
> On Sat, 1 Oct 2016 15:42:34 +0530
> Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> wrote:
>
>> Configure PWM polarity control.
>>
>> Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
>> ---
>> arch/arm/boot/dts/imx7-colibri.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi
>> b/arch/arm/boot/dts/imx7-colibri.dtsi index a9cc657..2af5e3e 100644
>> --- a/arch/arm/boot/dts/imx7-colibri.dtsi
>> +++ b/arch/arm/boot/dts/imx7-colibri.dtsi
>> @@ -43,7 +43,7 @@
>> / {
>> bl: backlight {
>> compatible = "pwm-backlight";
>> - pwms = <&pwm1 0 5000000>;
>> + pwms = <&pwm1 0 5000000 0>;
> My recommendation would be to add:
> #include <dt-bindings/pwm/pwm.h>
>
> and then define pwms as:
>
> pwms = <&pwm1 0 5000000 PWM_POLARITY_NORMAL>;
Addendum:
There is no "PWM_POLARITY_NORMAL" defined in "#include <dt-bindings/pwm/pwm.h>"
I guess it is helpful when polarity inversion is enabled.
--
Bhuvan
>
> It would be more readable
>
> Best regards,
> ?ukasz Majewski
>
>> };
>>
>> reg_module_3v3: regulator-module-3v3 {
^ permalink raw reply
* [PATCH v2 5/6] arm: dts: imx7-colibri: Use pwm polarity control
From: Lukasz Majewski @ 2016-10-07 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5fd194a3-5bfb-2fab-af82-95c87a0e7af1@toradex.com>
On Fri, 7 Oct 2016 11:38:52 +0530
Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> wrote:
> On 10/06/16 12:10, Lukasz Majewski wrote:
>
> > On Sat, 1 Oct 2016 15:42:34 +0530
> > Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> wrote:
> >
> >> Configure PWM polarity control.
> >>
> >> Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
> >> ---
> >> arch/arm/boot/dts/imx7-colibri.dtsi | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi
> >> b/arch/arm/boot/dts/imx7-colibri.dtsi index a9cc657..2af5e3e 100644
> >> --- a/arch/arm/boot/dts/imx7-colibri.dtsi
> >> +++ b/arch/arm/boot/dts/imx7-colibri.dtsi
> >> @@ -43,7 +43,7 @@
> >> / {
> >> bl: backlight {
> >> compatible = "pwm-backlight";
> >> - pwms = <&pwm1 0 5000000>;
> >> + pwms = <&pwm1 0 5000000 0>;
> > My recommendation would be to add:
> > #include <dt-bindings/pwm/pwm.h>
> >
> > and then define pwms as:
> >
> > pwms = <&pwm1 0 5000000 PWM_POLARITY_NORMAL>;
>
> Addendum:
> There is no "PWM_POLARITY_NORMAL" defined in "#include
> <dt-bindings/pwm/pwm.h>" I guess it is helpful when polarity
> inversion is enabled.
Yes, you are right :-), the normal polarity is assumed to be the
default.
There is only defined flag for inversion.
Sorry for the noise.
Best regards,
?ukasz Majewski
>
> --
> Bhuvan
>
> >
> > It would be more readable
> >
> > Best regards,
> > ?ukasz Majewski
> >
> >> };
> >>
> >> reg_module_3v3: regulator-module-3v3 {
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161007/d9a2f031/attachment.sig>
^ permalink raw reply
* PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
From: Felipe Balbi @ 2016-10-07 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475771380.22019.5.camel@mniewoehner.de>
Hi,
Michael Niew?hner <linux@mniewoehner.de> writes:
>> The clocks are same across working/non-working.
>> Is it possible to bisect the commit that's causing hang for 4.8x ?
>
>
> [c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: re-factor init and exit paths
> This patch causes both the hang on reboot and the lsusb hang.
How to reproduce? Why don't we see this on x86 and TI boards? I'm
guessing this is failed bisection, as I can't see anything in that
commit that would cause reboot hang. Also, that code path is *NOT*
executed when you run lsusb.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161007/291447b6/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: shmobile: Consolidate R8A779[234] machine definitions
From: Geert Uytterhoeven @ 2016-10-07 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475663489-4789-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Hi Laurent,
On Wed, Oct 5, 2016 at 12:31 PM, Laurent Pinchart
<laurent.pinchart+renesas@ideasonboard.com> wrote:
> The three SoCs use the exact same machine definition, consolidate them
> into a single one.
Thanks for your patch!
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
I'm wondering if we can improve upon...
> --- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
> +++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
> @@ -203,3 +204,22 @@ void __init rcar_gen2_reserve(void)
> }
> #endif
> }
> +
> +static const char * const rcar_gen2_boards_compat_dt[] __initconst = {
> + /*
> + * R8A7790 and R8A7791 can't be handled here as long as they need SMP
> + * initialization fallback.
> + */
> + "renesas,r8a7792",
> + "renesas,r8a7793",
> + "renesas,r8a7794",
> + NULL,
> +};
> +
> +DT_MACHINE_START(RCAR_GEN2_DT, "Generic Gen2 (Flattened Device Tree)")
> + .init_early = shmobile_init_delay,
shmobile_init_delay() is not really Renesas-specific, but ARM-specific.
This is just to avoid calibrating the delay loop?
> + .init_late = shmobile_init_late,
This calls only into shmobile_suspend_init(), which is also not
Renesas-specific.
> + .init_time = rcar_gen2_timer_init,
This is about fixing up the ARM Arch timer, and initializing clocks as we
need to pass the mode pin state (ugh, will hopefully go away soon).
> + .reserve = rcar_gen2_reserve,
Reserving a block for CMA DMA is also not really Renesas-specific.
> + .dt_compat = rcar_gen2_boards_compat_dt,
> +MACHINE_END
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
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