* Re: [PATCH v8 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager
From: Joel Holdsworth @ 2016-11-07 18:57 UTC (permalink / raw)
To: Marek Vasut, atull, moritz.fischer, geert, robh, devicetree,
linux-kernel, linux-spi, clifford
In-Reply-To: <7876f66a-f8c2-409b-0f18-e8055ddc7784@denx.de>
>> + cdone-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>;
>> + reset-gpios = <&gpio 22 GPIO_ACTIVE_LOW>;
>
> Wouldn't it make more sense to have "gpios" and "gpio-names" ? That
> scales better imo, although in this case we cannot really talk about
> scaling.
>
I don't believe that would be conventional. '-gpios' seems to be the
standard over '-gpio' even for a single GPIO.
Having multiple GPIOs in that field is only relevant when it could be an
array e.g. multiple chip-select GPIO lines. Not for multiple GPIOs with
differing functions.
Also it doesn't fit with the way devm_gpiod_get works where you select
GPIO(s) from the device-tree, and specify whether it's an input or an
output. In this case one is an output, one is an input.
Joel
^ permalink raw reply
* Re: [PATCH v8 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Marek Vasut @ 2016-11-07 18:53 UTC (permalink / raw)
To: Joel Holdsworth, atull, moritz.fischer, geert, robh, devicetree,
linux-kernel, linux-spi, clifford
In-Reply-To: <01d1a97b-2f43-49a6-51fb-e223ef4dce9b@airwebreathe.org.uk>
On 11/07/2016 07:49 PM, Joel Holdsworth wrote:
> Hi Marek,
Hi,
> Thanks again for your comments.
>
>
> On 07/11/16 11:01, Marek Vasut wrote:
>> On 11/07/2016 03:49 AM, Joel Holdsworth wrote:
>>> The Lattice iCE40 is a family of FPGAs with a minimalistic architecture
>>> and very regular structure, designed for low-cost, high-volume consumer
>>> and system applications.
>>
>> [...]
>>
>>> +static int ice40_fpga_ops_write_init(struct fpga_manager *mgr, u32
>>> flags,
>>> + const char *buf, size_t count)
>>> +{
>>> + struct ice40_fpga_priv *priv = mgr->priv;
>>> + struct spi_device *dev = priv->dev;
>>> + struct spi_message message;
>>> + struct spi_transfer assert_cs_then_reset_delay = {.cs_change = 1,
>>> + .delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY};
>>
>> Should be this way for the sake of readability, fix globally:
>>
>> struct spi_transfer assert_cs_then_reset_delay = {
>> .cs_change = 1,
>> .delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY
>> };
>
> Sure ok. Personally, I prefer it to be concise, but I'm happy to accept
> the norms.
I prefer it to be readable :)
>> Also I believe this could be const.
>
> It doesn't work const - I tried it. spi_message_add_tail() expects it to
> be non-const. Looking at 'struct spi_transfer' it appears there is
> various bits of state used to perform the transfer, as well as the
> pointer to the next item in the single-linked list.
Ah, right.
>>
>>> + struct spi_transfer housekeeping_delay_then_release_cs = {
>>> + .delay_usecs = ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY};
>>
>> Don't we have some less hacky way of toggling the nCS ? Is this even nCS
>> or is this some control pin of the FPGA ? Maybe it should be treated
>> like a regular GPIO instead ?
>
> I've been round this loop before also. drivers/spi/spi.c has a static
> function 'static void spi_set_cs(struct spi_device *dev, bool enable)'.
> It manipulates the CS line of devices where CS is built into the SPI
> master, and manipulates the GPIO on other devices.
>
> I don't know why it's non-public - I tried to get an answer from the SPI
> folks, but didn't get one. I guess they don't want to encourage drivers
> to manually manipulate the CS line - because SPI transfers are usually
> meant to be interruptible by higher priority transfers to other devices
> at any time. The only reason it's legit for me to manually manipulate CS
> is because I first lock the bus.
>
> Previously I had a copy of spi_set_cs copy-pasted into my driver, but in
> the end I decided to replace that with the zero-length transfers because
> there's a danger that if the original spi_set_cs() gets rewritten some
> time, my copy-paste code would leave around some nasty legacy.
>
> On the whole, I don't think the zero-length transfers are too
> egregiously bad, and all the alternatives seem worse to me.
So why not turn the CS line into GPIO and just toggle the GPIO?
>>> + const u8 padding[ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BYTES] = {0,};
>>
>> The comma is not needed.
>
> True. I'll make that change.
>
>
>>> + /* Check board setup data. */
>>> + if (spi->max_speed_hz > 25000000) {
>>> + dev_err(dev, "Speed is too high\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + if (spi->max_speed_hz < 1000000) {
>>> + dev_err(dev, "Speed is too low\n");
>>> + return -EINVAL;
>>> + }
>>
>> Do you have some explanation for this limitation ?
>>
>
> Not really no.
>
> The 'DS1040 - iCE40 LP/HX Family Data Sheet' page 3-18 claims f_max for
> Slave SPI Writing is >=1MHz && <=25MHz.
>
> The exact reason I don't know.
OK
> Are they running a PLL off the clock? What if the clock is really
> jittery - it seems to work fine when I've tested it with bit-banged SPI
> on the RPi; just as well as with hardware SPI.
>
> Or is it something to do with some pre-commit on-chip firmware storage?
> e.g. to check the CRC. Does the storage buffer have some time limitation
> before it gets committed to the FPGA core?
>
> I'm not sure, so I decided to just reflect the datasheet instructions
> back to the user.
Sounds good, thanks.
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: Issue with dt_to_config with dts files that include headers from dt-bindings
From: Frank Rowand @ 2016-11-07 18:51 UTC (permalink / raw)
To: Gaurav Minocha, Peter Robinson
Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CA+rpMbK=T+Z=-pML4RHLJpLziy-UuANpUcgKNbq06tMNrdAPKw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/05/16 13:56, Gaurav Minocha wrote:
> On Nov 4, 2016 1:19 PM, "Peter Robinson" <pbrobinson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> Hi Gaurav, Rob and Frank,
>>
>> I've just discovered the dt_to_config script (awesome thanks!) but it
>> errors out when a dts(i) includes a header file from dt-bindings. EG
>>
>> ./scripts/dtc/dt_to_config arch/arm/boot/dts/am335x-boneblack.dts
>> In file included from arch/arm/boot/dts/am335x-boneblack.dts:10:0:
>> arch/arm/boot/dts/am33xx.dtsi:11:35: error: no include path in which
>> to search for dt-bindings/gpio/gpio.h
>> #include <dt-bindings/gpio/gpio.h>
>> ^
>> arch/arm/boot/dts/am33xx.dtsi:12:40: error: no include path in which
>> to search for dt-bindings/pinctrl/am33xx.h
>> #include <dt-bindings/pinctrl/am33xx.h>
>> ^
>> arch/arm/boot/dts/am335x-boneblack.dts:12:41: error: no include path
>> in which to search for dt-bindings/display/tda998x.h
>> #include <dt-bindings/display/tda998x.h>
>> ^
>> Error: arch/arm/boot/dts/am335x-bone-common.dtsi:33.23-24 syntax error
>> FATAL ERROR: Unable to parse input tree
>>
>
> In bash do, export ARCH=arm
>
> Works for me!
>
>>
>> Regards,
>> Peter
>
Were there any other error messages reported? There should have
been a message suggesting that $ARCH was not set (if it wasn't)
and that it did not have the value of "arm".
If that message did not exist, I would like to understand why.
If the message did exist, but was not clear, how could the
message change to be more helpful?
-Frank
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v8 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Joel Holdsworth @ 2016-11-07 18:49 UTC (permalink / raw)
To: Marek Vasut, atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w,
geert-Td1EMuHUCqxL1ZNQvxDV9g, robh-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA, clifford-cPpHkPqGOEfk7+2FdBfRIA
In-Reply-To: <2255968d-b97c-2b9c-4e4d-7f3717a748e3-ynQEQJNshbs@public.gmane.org>
Hi Marek,
Thanks again for your comments.
On 07/11/16 11:01, Marek Vasut wrote:
> On 11/07/2016 03:49 AM, Joel Holdsworth wrote:
>> The Lattice iCE40 is a family of FPGAs with a minimalistic architecture
>> and very regular structure, designed for low-cost, high-volume consumer
>> and system applications.
>
> [...]
>
>> +static int ice40_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
>> + const char *buf, size_t count)
>> +{
>> + struct ice40_fpga_priv *priv = mgr->priv;
>> + struct spi_device *dev = priv->dev;
>> + struct spi_message message;
>> + struct spi_transfer assert_cs_then_reset_delay = {.cs_change = 1,
>> + .delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY};
>
> Should be this way for the sake of readability, fix globally:
>
> struct spi_transfer assert_cs_then_reset_delay = {
> .cs_change = 1,
> .delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY
> };
Sure ok. Personally, I prefer it to be concise, but I'm happy to accept
the norms.
>
> Also I believe this could be const.
It doesn't work const - I tried it. spi_message_add_tail() expects it to
be non-const. Looking at 'struct spi_transfer' it appears there is
various bits of state used to perform the transfer, as well as the
pointer to the next item in the single-linked list.
>
>> + struct spi_transfer housekeeping_delay_then_release_cs = {
>> + .delay_usecs = ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY};
>
> Don't we have some less hacky way of toggling the nCS ? Is this even nCS
> or is this some control pin of the FPGA ? Maybe it should be treated
> like a regular GPIO instead ?
I've been round this loop before also. drivers/spi/spi.c has a static
function 'static void spi_set_cs(struct spi_device *dev, bool enable)'.
It manipulates the CS line of devices where CS is built into the SPI
master, and manipulates the GPIO on other devices.
I don't know why it's non-public - I tried to get an answer from the SPI
folks, but didn't get one. I guess they don't want to encourage drivers
to manually manipulate the CS line - because SPI transfers are usually
meant to be interruptible by higher priority transfers to other devices
at any time. The only reason it's legit for me to manually manipulate CS
is because I first lock the bus.
Previously I had a copy of spi_set_cs copy-pasted into my driver, but in
the end I decided to replace that with the zero-length transfers because
there's a danger that if the original spi_set_cs() gets rewritten some
time, my copy-paste code would leave around some nasty legacy.
On the whole, I don't think the zero-length transfers are too
egregiously bad, and all the alternatives seem worse to me.
>> + const u8 padding[ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BYTES] = {0,};
>
> The comma is not needed.
True. I'll make that change.
>> + /* Check board setup data. */
>> + if (spi->max_speed_hz > 25000000) {
>> + dev_err(dev, "Speed is too high\n");
>> + return -EINVAL;
>> + }
>> +
>> + if (spi->max_speed_hz < 1000000) {
>> + dev_err(dev, "Speed is too low\n");
>> + return -EINVAL;
>> + }
>
> Do you have some explanation for this limitation ?
>
Not really no.
The 'DS1040 - iCE40 LP/HX Family Data Sheet' page 3-18 claims f_max for
Slave SPI Writing is >=1MHz && <=25MHz.
The exact reason I don't know.
Are they running a PLL off the clock? What if the clock is really
jittery - it seems to work fine when I've tested it with bit-banged SPI
on the RPi; just as well as with hardware SPI.
Or is it something to do with some pre-commit on-chip firmware storage?
e.g. to check the CRC. Does the storage buffer have some time limitation
before it gets committed to the FPGA core?
I'm not sure, so I decided to just reflect the datasheet instructions
back to the user.
Thanks
Joel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 1/2] ARM: shmobile: r8a7745: add CPG clock index macros
From: Geert Uytterhoeven @ 2016-11-07 18:41 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Rob Herring, Mark Rutland, Michael Turquette, linux-clk,
Stephen Boyd, devicetree@vger.kernel.org, Linux-Renesas,
Simon Horman
In-Reply-To: <CAMuHMdVcCwbXRCVy50k=tm=PKi3F3nnyq8UMjdq71k7Yd1tBtA@mail.gmail.com>
On Mon, Nov 7, 2016 at 9:34 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Sat, Nov 5, 2016 at 11:31 PM, Sergei Shtylyov
> <sergei.shtylyov@cogentembedded.com> wrote:
>> Add macros usable by the device tree sources to reference the R8A7745 CPG
>> clocks by index. The data comes from the table 7.2c in the revision 0.50
>> of the RZ/G Series User's Manual.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>
>> ---
>> Changes in version 2:
>> - added Geert's tag.
>>
>> include/dt-bindings/clock/r8a7745-cpg-mssr.h | 44 +++++++++++++++++++++++++++
>> 1 file changed, 44 insertions(+)
>>
>> Index: linux/include/dt-bindings/clock/r8a7745-cpg-mssr.h
>> ===================================================================
>> --- /dev/null
>> +++ linux/include/dt-bindings/clock/r8a7745-cpg-mssr.h
>
>> +#define R8A7745_CLK_ACP 26
>
> This clock is called CPEX instead of ACP in rev. 1.00 of the RZ/G Series User's
> Manual: Hardware.
Applied with s/ACP/CPEX/, and included in second clk-renesas-for-v4.10
pull request.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v5 1/2] ARM: shmobile: r8a7743: add CPG clock index macros
From: Geert Uytterhoeven @ 2016-11-07 18:40 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Rob Herring, Mark Rutland, devicetree@vger.kernel.org,
Michael Turquette, linux-clk, Stephen Boyd, Linux-Renesas,
Simon Horman
In-Reply-To: <2213928.GM4AGq02MQ@wasted.cogentembedded.com>
On Wed, Nov 2, 2016 at 10:57 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Add macros usable by the device tree sources to reference the R8A7743 CPG
> clocks by index. The data comes from the table 7.2b in the revision 0.50
> of the RZ/G Series User's Manual.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Applied and included in second clk-renesas-for-v4.10 pull request.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/3] ipmi/bt-bmc: add a sysfs file to configure a maximum response time
From: Corey Minyard @ 2016-11-07 18:37 UTC (permalink / raw)
To: Cédric Le Goater,
openipmi-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Joel Stanley
Cc: Rob Herring, Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478073426-3714-4-git-send-email-clg-Bxea+6Xhats@public.gmane.org>
Sorry, I was at Plumbers and extra busy with other stuff. Just getting
around to reviewing this.
On 11/02/2016 02:57 AM, Cédric Le Goater wrote:
> We could also use an ioctl for that purpose. sysfs seems a better
> approach.
>
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
> ---
> drivers/char/ipmi/bt-bmc.c | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
> index e751e4a754b7..d7146f0e900e 100644
> --- a/drivers/char/ipmi/bt-bmc.c
> +++ b/drivers/char/ipmi/bt-bmc.c
> @@ -84,6 +84,33 @@ struct bt_bmc {
>
> static atomic_t open_count = ATOMIC_INIT(0);
>
> +static ssize_t bt_bmc_show_response_time(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct bt_bmc *bt_bmc = dev_get_drvdata(dev);
> +
> + return snprintf(buf, PAGE_SIZE - 1, "%d\n", bt_bmc->response_time);
> +}
> +
> +static ssize_t bt_bmc_set_response_time(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct bt_bmc *bt_bmc = dev_get_drvdata(dev);
> + unsigned long val;
> + int err;
> +
> + err = kstrtoul(buf, 0, &val);
> + if (err)
> + return err;
> + bt_bmc->response_time = val;
> + return count;
> +}
> +
> +static DEVICE_ATTR(response_time, 0644,
> + bt_bmc_show_response_time, bt_bmc_set_response_time);
> +
> static u8 bt_inb(struct bt_bmc *bt_bmc, int reg)
> {
> return ioread8(bt_bmc->base + reg);
> @@ -572,6 +599,10 @@ static int bt_bmc_probe(struct platform_device *pdev)
> bt_bmc_config_irq(bt_bmc, pdev);
>
> bt_bmc->response_time = BT_BMC_RESPONSE_TIME;
> + rc = device_create_file(&pdev->dev, &dev_attr_response_time);
> + if (rc)
> + dev_warn(&pdev->dev, "can't create response_time file\n");
> +
You added an extra space here.
>
> if (bt_bmc->irq) {
> dev_info(dev, "Using IRQ %d\n", bt_bmc->irq);
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
From: Krzysztof Kozlowski @ 2016-11-07 18:33 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert Uytterhoeven, Arnd Bergmann, Greg Kroah-Hartman, Yangbo Lu,
Simon Horman, Magnus Damm, Rob Herring, Mark Rutland, Dirk Behme,
Linux-Renesas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Pankaj Dubey,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdV4HG0aOr4Qp_OZXU=3jLeOJ2QaMKp09a3v4489ABbRcA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Nov 07, 2016 at 10:35:31AM +0100, Geert Uytterhoeven wrote:
> On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven
> <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> wrote:
> > Some Renesas SoCs may exist in different revisions, providing slightly
> > different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
> > (errate and quirks). This needs to be catered for by drivers and/or
> > platform code. The recently proposed soc_device_match() API seems like
> > a good fit to handle this.
> >
> > This patch series implements the core infrastructure to provide SoC and
> > revision information through the SoC bus for Renesas ARM SoCs. It
> > consists of 7 patches:
> > - Patches 1-4 provide soc_device_match(), with some related fixes,
> > - Patches 5-7 implement identification of Renesas SoCs and
> > registration with the SoC bus,
> >
> > Changes compared to v1:
> > - Add Acked-by,
> > - New patches:
> > - "[4/7] base: soc: Provide a dummy implementation of
> > soc_device_match()",
> > - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
> > - "[6/7] arm64: dts: r8a7795: Add device node for PRR"
> > (more similar patches available, I'm not yet spamming you all
> > with them),
> > - Drop SoC families and family names; use fixed "Renesas" instead,
> > - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
> > devices with other SoCs,
> > - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
> > M1A: not accessible from the ARM core?),
> > - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
> > for SoCs that provide a chip ID register,
> > - Build renesas-soc only if SOC_BUS is enabled,
> > - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> > available, else fall back to hardcoded addresses for compatibility
> > with existing DTBs,
> > - Remove verification of product IDs; just print the ID instead,
> > - Don't register the SoC bus if the chip ID register is missing,
> > - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
> > both).
> >
> > Merge strategy:
> > - In theory, patches 1-4 should go through Greg's driver core tree.
> > But it's a hard dependency for all users.
> > If people agree, I can provide an immutable branch in my
> > renesas-drivers repository, to be merged by all interested parties.
> > So far I'm aware of Freescale/NXP, and Renesas.
>
> And Samsung.
Yes, I would need it as well.
> Shall I create the immutable branch now?
...or the applying person could provide one.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 6/6] ARM: dts: sun6i: sina31s: Enable internal audio codec
From: Maxime Ripard @ 2016-11-07 18:29 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161107100703.5586-7-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 387 bytes --]
On Mon, Nov 07, 2016 at 06:07:03PM +0800, Chen-Yu Tsai wrote:
> The SinA31s routes the SoC's LINEOUT pins to a line out jack, and MIC1
> to a microphone jack, with MBIAS providing phantom power.
>
> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v3 5/6] ARM: dts: sun6i: hummingbird: Enable internal audio codec
From: Maxime Ripard @ 2016-11-07 18:29 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
alsa-devel, linux-arm-kernel, linux-kernel, devicetree,
linux-sunxi
In-Reply-To: <20161107100703.5586-6-wens@csie.org>
[-- Attachment #1: Type: text/plain, Size: 481 bytes --]
On Mon, Nov 07, 2016 at 06:07:02PM +0800, Chen-Yu Tsai wrote:
> The Hummingbird A31 has headset and line in audio jacks and an onboard
> mic routed to the pins for the SoC's internal codec. The line out pins
> are routed to an onboard speaker amp, whose output is available on a
> pin header.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v3 4/6] ARM: dts: sun6i: Add audio codec device node
From: Maxime Ripard @ 2016-11-07 18:28 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161107100703.5586-5-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 940 bytes --]
On Mon, Nov 07, 2016 at 06:07:01PM +0800, Chen-Yu Tsai wrote:
> The A31 SoC includes the Allwinner audio codec, capable of 24-bit
> playback up to 192 kHz and 24-bit capture up to 48 kHz.
>
> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> ---
> arch/arm/boot/dts/sun6i-a31.dtsi | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
> index 2e8bf93dcfb2..f68e6102b01b 100644
> --- a/arch/arm/boot/dts/sun6i-a31.dtsi
> +++ b/arch/arm/boot/dts/sun6i-a31.dtsi
> @@ -784,6 +784,19 @@
> reset-names = "ahb";
> };
>
> + codec: codec@01c22c00 {
> + #sound-dai-cells = <0>;
> + compatible = "allwinner,sun6i-a31-codec";
> + reg = <0x01c22c00 0x98>;
The memory mapped region is 0x400. I fixed this and applied.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v8 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Moritz Fischer @ 2016-11-07 18:26 UTC (permalink / raw)
To: Joel Holdsworth
Cc: Alan Tull, Geert Uytterhoeven, Rob Herring, Devicetree List,
Linux Kernel Mailing List, linux-spi-u79uwXL29TY76Z2rM5mHXA,
Marek Vašut, clifford-cPpHkPqGOEfk7+2FdBfRIA
In-Reply-To: <1478486962-26794-3-git-send-email-joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
Hi Joel,
couple of nits inline below:
On Sun, Nov 6, 2016 at 6:49 PM, Joel Holdsworth
<joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org> wrote:
> The Lattice iCE40 is a family of FPGAs with a minimalistic architecture
> and very regular structure, designed for low-cost, high-volume consumer
> and system applications.
>
> This patch adds support to the FPGA manager for configuring the SRAM of
> iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite and iCE40
> UltraPlus devices, through slave SPI.
>
> The iCE40 family is notable because it is the first FPGA family to have
> complete reverse engineered bit-stream documentation for the iCE40LP and
> iCE40HX devices. Furthermore, there is now a Free Software Verilog
> synthesis tool-chain: the "IceStorm" tool-chain.
>
> This project is the work of Clifford Wolf, who is the maintainer of
> Yosys Verilog RTL synthesis framework, and Mathias Lasser, with notable
> contributions from "Cotton Seed", the main author of "arachne-pnr"; a
> place-and-route tool for iCE40 FPGAs.
>
> Having a Free Software synthesis tool-chain offers interesting
> opportunities for embedded devices that are able reconfigure themselves
> with open firmware that is generated on the device itself. For example
> a mobile device might have an application processor with an iCE40 FPGA
> attached, which implements slave devices, or through which the processor
> communicates with other devices through the FPGA fabric.
>
> A kernel driver for the iCE40 is useful, because in some cases, the FPGA
> may need to be configured before other devices can be accessed.
>
> An example of such a device is the icoBoard; a RaspberryPI HAT which
> features an iCE40HX8K with a 1 or 8 MBit SRAM and ports for
> Digilent-compatible PMOD modules. A PMOD module may contain a device
> with which the kernel communicates, via the FPGA.
Personally I find this a bit verbose, but that's just me.
>
> Signed-off-by: Joel Holdsworth <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
> ---
> drivers/fpga/Kconfig | 6 ++
> drivers/fpga/Makefile | 1 +
> drivers/fpga/ice40-spi.c | 217 +++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 224 insertions(+)
> create mode 100644 drivers/fpga/ice40-spi.c
>
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index d614102..5b0f137 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -13,6 +13,12 @@ config FPGA
>
> if FPGA
>
> +config FPGA_MGR_ICE40_SPI
> + tristate "Lattice iCE40 SPI"
> + depends on OF && SPI
> + help
> + FPGA manager driver support for Lattice iCE40 FPGAs 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..adb5811 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_ICE40_SPI) += ice40-spi.o
> obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
> obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
> diff --git a/drivers/fpga/ice40-spi.c b/drivers/fpga/ice40-spi.c
> new file mode 100644
> index 0000000..7d7595b
> --- /dev/null
> +++ b/drivers/fpga/ice40-spi.c
> @@ -0,0 +1,217 @@
> +/*
> + * FPGA Manager Driver for Lattice iCE40.
> + *
> + * Copyright (c) 2016 Joel Holdsworth
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This driver adds support to the FPGA manager for configuring the SRAM of
> + * Lattice iCE40 FPGAs through slave SPI.
> + */
> +
> +#include <linux/fpga/fpga-mgr.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/module.h>
> +#include <linux/of_gpio.h>
> +#include <linux/spi/spi.h>
> +
> +#define ICE40_SPI_FPGAMGR_RESET_DELAY 1 /* us (>200ns) */
> +#define ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY 1200 /* us */
> +
> +#define ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BYTES DIV_ROUND_UP(49, 8)
> +
> +struct ice40_fpga_priv {
> + struct spi_device *dev;
> + struct gpio_desc *reset;
> + struct gpio_desc *cdone;
> +};
> +
> +static enum fpga_mgr_states ice40_fpga_ops_state(struct fpga_manager *mgr)
> +{
> + struct ice40_fpga_priv *priv = mgr->priv;
> +
> + return gpiod_get_value(priv->cdone) ? FPGA_MGR_STATE_OPERATING :
> + FPGA_MGR_STATE_UNKNOWN;
> +}
> +
> +static int ice40_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
> + const char *buf, size_t count)
> +{
> + struct ice40_fpga_priv *priv = mgr->priv;
> + struct spi_device *dev = priv->dev;
> + struct spi_message message;
> + struct spi_transfer assert_cs_then_reset_delay = {.cs_change = 1,
> + .delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY};
Formatting looks odd, can you move the .cs_change to the next line?
> + struct spi_transfer housekeeping_delay_then_release_cs = {
> + .delay_usecs = ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY};
> + int ret;
> +
> + if ((flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> + dev_err(&dev->dev,
> + "Partial reconfiguration is not supported\n");
> + return -ENOTSUPP;
> + }
> +
> + /* Lock the bus, assert CRESET_B and SS_B and delay >200ns */
> + spi_bus_lock(dev->master);
> +
> + gpiod_set_value(priv->reset, 1);
> +
> + spi_message_init(&message);
> + spi_message_add_tail(&assert_cs_then_reset_delay, &message);
> + ret = spi_sync_locked(dev, &message);
> +
> + /* Come out of reset */
> + gpiod_set_value(priv->reset, 0);
> +
> + /* Abort if the chip-select failed */
> + if (ret)
> + goto fail;
> +
> + /* Check CDONE is de-asserted i.e. the FPGA is reset */
> + if (gpiod_get_value(priv->cdone)) {
> + dev_err(&dev->dev, "Device reset failed, CDONE is asserted\n");
> + ret = -EIO;
> + goto fail;
> + }
> +
> + /* Wait for the housekeeping to complete, and release SS_B */
> + spi_message_init(&message);
> + spi_message_add_tail(&housekeeping_delay_then_release_cs, &message);
> + ret = spi_sync_locked(dev, &message);
> +
> +fail:
> + spi_bus_unlock(dev->master);
> +
> + return ret;
> +}
> +
> +static int ice40_fpga_ops_write(struct fpga_manager *mgr,
> + const char *buf, size_t count)
> +{
> + struct ice40_fpga_priv *priv = mgr->priv;
> +
> + return spi_write(priv->dev, buf, count);
> +}
> +
> +static int ice40_fpga_ops_write_complete(struct fpga_manager *mgr, u32 flags)
> +{
> + struct ice40_fpga_priv *priv = mgr->priv;
> + struct spi_device *dev = priv->dev;
> + const u8 padding[ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BYTES] = {0,};
> +
> + /* Check CDONE is asserted */
> + if (!gpiod_get_value(priv->cdone)) {
> + dev_err(&dev->dev,
> + "CDONE was not asserted after firmware transfer\n");
> + return -EIO;
> + }
> +
> + /* Send of zero-padding to activate the firmware */
> + return spi_write(dev, padding, sizeof(padding));
I'd move all of these into the write() callback.
> +}
> +
> +static void ice40_fpga_ops_fpga_remove(struct fpga_manager *mgr)
> +{
> + struct ice40_fpga_priv *priv = mgr->priv;
> +
> + /* Enter reset */
> + gpiod_set_value(priv->reset, 1);
I know Marek had suggested this, none of the other drivers behave like that.
I'm not sure this is expected behavior for most people.
> +}
> +
> +static const struct fpga_manager_ops ice40_fpga_ops = {
> + .state = ice40_fpga_ops_state,
> + .write_init = ice40_fpga_ops_write_init,
> + .write = ice40_fpga_ops_write,
> + .write_complete = ice40_fpga_ops_write_complete,
> + .fpga_remove = ice40_fpga_ops_fpga_remove
> +};
> +
> +static int ice40_fpga_probe(struct spi_device *spi)
> +{
> + struct device *dev = &spi->dev;
> + struct device_node *np = spi->dev.of_node;
> + struct ice40_fpga_priv *priv;
> + int ret;
> +
> + if (!np) {
> + dev_err(dev, "No Device Tree entry\n");
> + return -EINVAL;
> + }
> +
> + priv = devm_kzalloc(&spi->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->dev = spi;
> +
> + /* Check board setup data. */
> + if (spi->max_speed_hz > 25000000) {
> + dev_err(dev, "Speed is too high\n");
> + return -EINVAL;
> + }
> +
> + if (spi->max_speed_hz < 1000000) {
> + dev_err(dev, "Speed is too low\n");
> + return -EINVAL;
> + }
> +
> + if (spi->mode & SPI_CPHA) {
> + dev_err(dev, "Bad mode\n");
> + return -EINVAL;
> + }
> +
> + /* Set up the GPIOs */
> + priv->cdone = devm_gpiod_get(dev, "cdone", GPIOD_IN);
> + if (IS_ERR(priv->cdone)) {
> + dev_err(dev, "Failed to get CDONE GPIO: %ld\n",
> + PTR_ERR(priv->cdone));
> + return -EINVAL;
> + }
> +
> + priv->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(priv->reset)) {
> + dev_err(dev, "Failed to get CRESET_B GPIO: %ld\n",
> + PTR_ERR(priv->reset));
> + return -EINVAL;
> + }
> +
> + /* Register with the FPGA manager */
> + ret = fpga_mgr_register(dev, "Lattice iCE40 FPGA Manager",
> + &ice40_fpga_ops, priv);
> + if (ret) {
> + dev_err(dev, "Unable to register FPGA manager");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int ice40_fpga_remove(struct spi_device *spi)
> +{
> + fpga_mgr_unregister(&spi->dev);
> + return 0;
> +}
> +
> +static const struct of_device_id ice40_fpga_of_match[] = {
> + { .compatible = "lattice,ice40-fpga-mgr", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ice40_fpga_of_match);
> +
> +static struct spi_driver ice40_fpga_driver = {
> + .probe = ice40_fpga_probe,
> + .remove = ice40_fpga_remove,
> + .driver = {
> + .name = "ice40spi",
> + .of_match_table = of_match_ptr(ice40_fpga_of_match),
> + },
> +};
> +
> +module_spi_driver(ice40_fpga_driver);
> +
> +MODULE_AUTHOR("Joel Holdsworth <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>");
> +MODULE_DESCRIPTION("Lattice iCE40 FPGA Manager");
> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 2/3] ARM64: dts: sun6i: add dma node for a64.
From: Hao Zhang @ 2016-11-07 18:22 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt, mark.rutland, catalin.marinas,
will.deacon
Cc: hao5781286, devicetree, linux-kernel, linux-arm-kernel
This adds the dma node for sun50i a64.
Signed-off-by: Hao Zhang <hao5781286@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index e3c3d7d8..855ae2c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -227,6 +227,15 @@
};
};
+ dma: dma-controller@01c02000 {
+ compatible = "allwinner,sun50i-a64-dma";
+ reg = <0x01c02000 0x1000>;
+ interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_DMA>;
+ resets = <&ccu RST_BUS_DMA>;
+ #dma-cells = <1>;
+ };
+
uart0: serial@1c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/3] Documentation: DT: add dma compatible for sun50i A64 SOC.
From: Hao Zhang @ 2016-11-07 18:14 UTC (permalink / raw)
To: maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
mark.rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
hao5781286-Re5JQEeQqe8AvxtiuMwx3w
This adds documentation of the sun50i a64 dma binding compatible.
Signed-off-by: Hao Zhang <hao5781286-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Documentation/devicetree/bindings/dma/sun6i-dma.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/dma/sun6i-dma.txt b/Documentation/devicetree/bindings/dma/sun6i-dma.txt
index 6b26704..4398b99 100644
--- a/Documentation/devicetree/bindings/dma/sun6i-dma.txt
+++ b/Documentation/devicetree/bindings/dma/sun6i-dma.txt
@@ -9,6 +9,7 @@ Required properties:
"allwinner,sun8i-a23-dma"
"allwinner,sun8i-a83t-dma"
"allwinner,sun8i-h3-dma"
+ "allwinner,sun50i-a64-dma"
- reg: Should contain the registers base address and length
- interrupts: Should contain a reference to the interrupt used by this device
- clocks: Should contain a reference to the parent AHB clock
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v6 0/7] add NS2 support to bgmac
From: David Miller @ 2016-11-07 18:11 UTC (permalink / raw)
To: jon.mason
Cc: robh+dt, mark.rutland, f.fainelli, rafal,
bcm-kernel-feedback-list, netdev, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <1478236262-3351-1-git-send-email-jon.mason@broadcom.com>
From: Jon Mason <jon.mason@broadcom.com>
Date: Fri, 4 Nov 2016 01:10:55 -0400
> Changes in v6:
> * Use a common bgmac_phy_connect_direct (per Rafal Milecki)
> * Rebased on latest net-next
> * Added Reviewed-by to the relevant patches
>
>
> Changes in v5:
> * Change a pr_err to netdev_err (per Scott Branden)
> * Reword the lane swap binding documentation (per Andrew Lunn)
>
>
> Changes in v4:
> * Actually send out the lane swap binding doc patch (Per Scott Branden)
> * Remove unused #define (Per Andrew Lunn)
>
>
> Changes in v3:
> * Clean-up the bgmac DT binding doc (per Rob Herring)
> * Document the lane swap binding and make it generic (Per Andrew Lunn)
>
>
> Changes in v2:
> * Remove the PHY power-on (per Andrew Lunn)
> * Misc PHY clean-ups regarding comments and #defines (per Andrew Lunn)
> This results on none of the original PHY code from Vikas being
> present. So, I'm removing him as an author and giving him
> "Inspired-by" credit.
> * Move PHY lane swapping to PHY driver (per Andrew Lunn and Florian
> Fainelli)
> * Remove bgmac sleep (per Florian Fainelli)
> * Re-add bgmac chip reset (per Florian Fainelli and Ray Jui)
> * Rebased on latest net-next
> * Added patch for bcm54xx_auxctl_read, which is used in the BCM54810
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v8 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Marek Vasut @ 2016-11-07 18:01 UTC (permalink / raw)
To: Joel Holdsworth, atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w,
geert-Td1EMuHUCqxL1ZNQvxDV9g, robh-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA, clifford-cPpHkPqGOEfk7+2FdBfRIA
In-Reply-To: <1478486962-26794-3-git-send-email-joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
On 11/07/2016 03:49 AM, Joel Holdsworth wrote:
> The Lattice iCE40 is a family of FPGAs with a minimalistic architecture
> and very regular structure, designed for low-cost, high-volume consumer
> and system applications.
[...]
> +static int ice40_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
> + const char *buf, size_t count)
> +{
> + struct ice40_fpga_priv *priv = mgr->priv;
> + struct spi_device *dev = priv->dev;
> + struct spi_message message;
> + struct spi_transfer assert_cs_then_reset_delay = {.cs_change = 1,
> + .delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY};
Should be this way for the sake of readability, fix globally:
struct spi_transfer assert_cs_then_reset_delay = {
.cs_change = 1,
.delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY
};
Also I believe this could be const.
> + struct spi_transfer housekeeping_delay_then_release_cs = {
> + .delay_usecs = ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY};
Don't we have some less hacky way of toggling the nCS ? Is this even nCS
or is this some control pin of the FPGA ? Maybe it should be treated
like a regular GPIO instead ?
[...]
> +static int ice40_fpga_ops_write_complete(struct fpga_manager *mgr, u32 flags)
> +{
> + struct ice40_fpga_priv *priv = mgr->priv;
> + struct spi_device *dev = priv->dev;
> + const u8 padding[ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BYTES] = {0,};
The comma is not needed.
> +
> + /* Check CDONE is asserted */
> + if (!gpiod_get_value(priv->cdone)) {
> + dev_err(&dev->dev,
> + "CDONE was not asserted after firmware transfer\n");
> + return -EIO;
> + }
> +
> + /* Send of zero-padding to activate the firmware */
> + return spi_write(dev, padding, sizeof(padding));
> +}
[...]
> + /* Check board setup data. */
> + if (spi->max_speed_hz > 25000000) {
> + dev_err(dev, "Speed is too high\n");
> + return -EINVAL;
> + }
> +
> + if (spi->max_speed_hz < 1000000) {
> + dev_err(dev, "Speed is too low\n");
> + return -EINVAL;
> + }
Do you have some explanation for this limitation ?
[...]
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v8 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager
From: Marek Vasut @ 2016-11-07 17:53 UTC (permalink / raw)
To: Joel Holdsworth, atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w,
geert-Td1EMuHUCqxL1ZNQvxDV9g, robh-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA, clifford-cPpHkPqGOEfk7+2FdBfRIA
In-Reply-To: <1478486962-26794-2-git-send-email-joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
On 11/07/2016 03:49 AM, Joel Holdsworth wrote:
> This adds documentation of the device tree bindings of the Lattice iCE40
> FPGA driver for the FPGA manager framework.
>
> Signed-off-by: Joel Holdsworth <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
> ---
> .../bindings/fpga/lattice-ice40-fpga-mgr.txt | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
>
> diff --git a/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
> new file mode 100644
> index 0000000..7e7a78b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
> @@ -0,0 +1,21 @@
> +Lattice iCE40 FPGA Manager
> +
> +Required properties:
> +- compatible: Should contain "lattice,ice40-fpga-mgr"
> +- reg: SPI chip select
> +- spi-max-frequency: Maximum SPI frequency (>=1000000, <=25000000)
> +- cdone-gpios: GPIO input connected to CDONE pin
> +- reset-gpios: Active-low GPIO output connected to CRESET_B pin. Note
> + that unless the GPIO is held low during startup, the
> + FPGA will enter Master SPI mode and drive SCK with a
> + clock signal potentially jamming other devices on the
> + bus until the firmware is loaded.
> +
> +Example:
> + ice40: ice40@0 {
> + compatible = "lattice,ice40-fpga-mgr";
> + reg = <0>;
> + spi-max-frequency = <1000000>;
> + cdone-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&gpio 22 GPIO_ACTIVE_LOW>;
Wouldn't it make more sense to have "gpios" and "gpio-names" ? That
scales better imo, although in this case we cannot really talk about
scaling.
> + };
>
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/6] ARM: dts: Extend the S3C RTC node with rtc_src clock
From: Krzysztof Kozlowski @ 2016-11-07 17:44 UTC (permalink / raw)
To: Pankaj Dubey
Cc: linux-samsung-soc, linux-arm-kernel, krzk, javier, kgene,
thomas.ab, myungjoo.ham, Rob Herring, devicetree
In-Reply-To: <1478513376-14307-7-git-send-email-pankaj.dubey@samsung.com>
On Mon, Nov 07, 2016 at 03:39:36PM +0530, Pankaj Dubey wrote:
> Extend the S3C RTC node with rtc_src clock so it could be operational.
> The rtc_src clock is provided by MAX8997.
>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: devicetree@vger.kernel.org
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> arch/arm/boot/dts/exynos4210-origen.dts | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4210-origen.dts b/arch/arm/boot/dts/exynos4210-origen.dts
> index 6c7ef4e..4cac9b6 100644
> --- a/arch/arm/boot/dts/exynos4210-origen.dts
> +++ b/arch/arm/boot/dts/exynos4210-origen.dts
> @@ -18,6 +18,7 @@
> #include "exynos4210.dtsi"
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/input/input.h>
> +#include <dt-bindings/clock/maxim,max8997.h>
Just a nit: put the system-wide includes in alphabetical order, so
clock, gpio and finally input. It helps reducing conflicting changes
(when more people add includes in the same time).
Beside that, looks good, but it requires a dt-bindings in separate patch
so I could pull it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/6] clk: Add driver for Maxim-8997 PMIC clocks
From: Krzysztof Kozlowski @ 2016-11-07 17:41 UTC (permalink / raw)
To: Pankaj Dubey
Cc: linux-samsung-soc, linux-arm-kernel, krzk, javier, kgene,
thomas.ab, myungjoo.ham, Michael Turquette, Rob Herring,
devicetree, linux-clk
In-Reply-To: <1478513376-14307-4-git-send-email-pankaj.dubey@samsung.com>
On Mon, Nov 07, 2016 at 03:39:33PM +0530, Pankaj Dubey wrote:
> The MAX8997 PMIC has 32.786kHz crystal oscillator which provides an
> accurate low frequency clock for MAX8997 internal circuit as well as
> external circuit. This patch adds support for these two clocks.
>
> CC: Michael Turquette <mturquette@baylibre.com>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: devicetree@vger.kernel.org
> CC: linux-clk@vger.kernel.org
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> drivers/clk/Kconfig | 10 ++++
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-max8997.c | 76 +++++++++++++++++++++++++++++++
> include/dt-bindings/clock/maxim,max8997.h | 23 ++++++++++
You need to split the dt-bindings header into separate one so others
could pull it. Please also mention the dependencies between patches in
cover letter, because it does not look like it could be applied as is.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: Add #pinctrl-cells for pinctrl-single instances
From: Tony Lindgren @ 2016-11-07 17:39 UTC (permalink / raw)
To: Linus Walleij
Cc: Jon Hunter, Mark Rutland, Rob Herring, Grygorii Strashko,
Nishanth Menon,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-OMAP
In-Reply-To: <CACRpkdaRGmUg19zu1kTm6ZcODPFxjXnOKxATbp7HbKnGsPESCQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
* Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> [161104 14:55]:
> On Thu, Nov 3, 2016 at 5:35 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
>
> > Drivers using pinctrl-single,pins have #pinctrl-cells = <1>, while
> > pinctrl-single,bits need #pinctrl-cells = <2>.
> >
> > Note that this patch can be optionally applied separately from the
> > driver changes as the driver supports also the legacy binding without
> > #pinctrl-cells.
> >
> > Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>
> Reviewed-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> Please take this through the OMAP tree to avoid hazzle.
OK applied into omap-for-v4.10/pinctrl-cells.
Thanks,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 1/9] doc: DT: vidc: binding document for Qualcomm video driver
From: Stanimir Varbanov @ 2016-11-07 17:33 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Hans Verkuil
Cc: Andy Gross, Bjorn Andersson, Stephen Boyd, Srinivas Kandagatla,
linux-media, linux-kernel, linux-arm-msm, Stanimir Varbanov,
Rob Herring, Mark Rutland, devicetree
In-Reply-To: <1478540043-24558-1-git-send-email-stanimir.varbanov@linaro.org>
Add binding document for Venus video encoder/decoder driver
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
---
.../devicetree/bindings/media/qcom,venus.txt | 98 ++++++++++++++++++++++
1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/qcom,venus.txt
diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt b/Documentation/devicetree/bindings/media/qcom,venus.txt
new file mode 100644
index 000000000000..b2af347fbce4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
@@ -0,0 +1,98 @@
+* Qualcomm Venus video encode/decode accelerator
+
+- compatible:
+ Usage: required
+ Value type: <stringlist>
+ Definition: Value should contain one of:
+ - "qcom,venus-msm8916"
+ - "qcom,venus-msm8996"
+- reg:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: Register ranges as listed in the reg-names property.
+- reg-names:
+ Usage: required
+ Value type: <stringlist>
+ Definition: Should contain following entries:
+ - "venus" Venus register base
+- reg-names:
+ Usage: optional for msm8996
+ Value type: <stringlist>
+ Definition: Should contain following entries:
+ - "vmem" Video memory register base
+- interrupts:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: Should contain interrupts as listed in the interrupt-names
+ property.
+- interrupt-names:
+ Usage: required
+ Value type: <stringlist>
+ Definition: Should contain following entries:
+ - "venus" Venus interrupt line
+- interrupt-names:
+ Usage: optional for msm8996
+ Value type: <stringlist>
+ Definition: Should contain following entries:
+ - "vmem" Video memory interrupt line
+- clocks:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A List of phandle and clock specifier pairs as listed
+ in clock-names property.
+- clock-names:
+ Usage: required
+ Value type: <stringlist>
+ Definition: Should contain the following entries:
+ - "core" Core video accelerator clock
+ - "iface" Video accelerator AHB clock
+ - "bus" Video accelerator AXI clock
+- clock-names:
+ Usage: required for msm8996
+ Value type: <stringlist>
+ Definition: Should contain the following entries:
+ - "subcore0" Subcore0 video accelerator clock
+ - "subcore1" Subcore1 video accelerator clock
+ - "mmssnoc_axi" Multimedia subsystem NOC AXI clock
+ - "mmss_mmagic_iface" Multimedia subsystem MMAGIC AHB clock
+ - "mmss_mmagic_mbus" Multimedia subsystem MMAGIC MAXI clock
+ - "mmagic_video_bus" MMAGIC video AXI clock
+ - "video_mbus" Video MAXI clock
+- clock-names:
+ Usage: optional for msm8996
+ Value type: <stringlist>
+ Definition: Should contain the following entries:
+ - "vmem_bus" Video memory MAXI clock
+ - "vmem_iface" Video memory AHB clock
+- power-domains:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A phandle and power domain specifier pairs to the
+ power domain which is responsible for collapsing
+ and restoring power to the peripheral.
+- rproc:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A phandle to remote processor responsible for
+ firmware loading and processor booting.
+
+- iommus:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A list of phandle and IOMMU specifier pairs.
+
+* An Example
+ video-codec@1d00000 {
+ compatible = "qcom,venus-msm8916";
+ reg = <0x01d00000 0xff000>;
+ reg-names = "venus";
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "venus";
+ clocks = <&gcc GCC_VENUS0_VCODEC0_CLK>,
+ <&gcc GCC_VENUS0_AHB_CLK>,
+ <&gcc GCC_VENUS0_AXI_CLK>;
+ clock-names = "core", "iface", "bus";
+ power-domains = <&gcc VENUS_GDSC>;
+ rproc = <&venus_rproc>;
+ iommus = <&apps_iommu 5>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/3] remoteproc: qcom: add Venus video core firmware loader driver
From: Stanimir Varbanov @ 2016-11-07 17:30 UTC (permalink / raw)
To: Ohad Ben-Cohen, Bjorn Andersson, Stephen Boyd, Andy Gross,
Rob Herring, Mark Rutland
Cc: Srinivas Kandagatla, linux-remoteproc, linux-kernel,
linux-arm-msm, linux-soc, devicetree, Stanimir Varbanov
In-Reply-To: <1478539853-23218-1-git-send-email-stanimir.varbanov@linaro.org>
This driver will load and authenticate the Venus firmware and
bringing it core out of reset. Those two functionalities are
via secure monitor calls to trusted environment.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
---
drivers/remoteproc/Kconfig | 12 ++
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/qcom_venus_pil.c | 213 ++++++++++++++++++++++++++++++++++++
3 files changed, 226 insertions(+)
create mode 100644 drivers/remoteproc/qcom_venus_pil.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index f396bfef5d42..0e90a2491873 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -107,6 +107,18 @@ config QCOM_WCNSS_PIL
Say y here to support the Peripheral Image Loader for the Qualcomm
Wireless Connectivity Subsystem.
+config QCOM_VENUS_PIL
+ tristate "Qualcomm Venus Peripheral Image Loader"
+ depends on OF && ARCH_QCOM
+ depends on QCOM_SCM
+ select QCOM_MDT_LOADER
+ select REMOTEPROC
+ help
+ Say y here to support Qualcomm Peripherial Image Loader for the
+ Venus remote processor. The Venus remote processor is a
+ micro-controller plus dedicated hardware for video acceleration
+ of video decoding and encoding operations.
+
config ST_REMOTEPROC
tristate "ST remoteproc support"
depends on ARCH_STI
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 6dfb62ed643f..852711b89844 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -15,4 +15,5 @@ obj-$(CONFIG_QCOM_MDT_LOADER) += qcom_mdt_loader.o
obj-$(CONFIG_QCOM_Q6V5_PIL) += qcom_q6v5_pil.o
obj-$(CONFIG_QCOM_WCNSS_IRIS) += qcom_wcnss_iris.o
obj-$(CONFIG_QCOM_WCNSS_PIL) += qcom_wcnss.o
+obj-$(CONFIG_QCOM_VENUS_PIL) += qcom_venus_pil.o
obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
diff --git a/drivers/remoteproc/qcom_venus_pil.c b/drivers/remoteproc/qcom_venus_pil.c
new file mode 100644
index 000000000000..6d4e55bffef5
--- /dev/null
+++ b/drivers/remoteproc/qcom_venus_pil.c
@@ -0,0 +1,213 @@
+/*
+ * Qualcomm Venus Peripheral Image Loader
+ *
+ * Copyright (C) 2016 Linaro Ltd
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/dma-mapping.h>
+#include <linux/firmware.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_reserved_mem.h>
+#include <linux/platform_device.h>
+#include <linux/qcom_scm.h>
+#include <linux/remoteproc.h>
+
+#include "qcom_mdt_loader.h"
+#include "remoteproc_internal.h"
+
+#define VENUS_CRASH_REASON_SMEM 425
+#define VENUS_FIRMWARE_NAME "venus.mdt"
+#define VENUS_PAS_ID 9
+#define VENUS_FW_MEM_SIZE SZ_8M
+
+struct qcom_venus {
+ struct device *dev;
+ struct rproc *rproc;
+ phys_addr_t fw_addr;
+ phys_addr_t mem_phys;
+ void *mem_va;
+ size_t mem_size;
+};
+
+static int venus_load(struct rproc *rproc, const struct firmware *fw)
+{
+ struct qcom_venus *venus = rproc->priv;
+ phys_addr_t pa;
+ size_t fw_size;
+ bool relocate;
+ int ret;
+
+ ret = qcom_scm_pas_init_image(VENUS_PAS_ID, fw->data, fw->size);
+ if (ret) {
+ dev_err(&rproc->dev, "invalid firmware metadata (%d)\n", ret);
+ return -EINVAL;
+ }
+
+ ret = qcom_mdt_parse(fw, &venus->fw_addr, &fw_size, &relocate);
+ if (ret) {
+ dev_err(&rproc->dev, "failed to parse mdt header (%d)\n", ret);
+ return ret;
+ }
+
+ if (fw_size > venus->mem_size)
+ return -ENOMEM;
+
+ pa = relocate ? venus->mem_phys : venus->fw_addr;
+
+ ret = qcom_scm_pas_mem_setup(VENUS_PAS_ID, pa, fw_size);
+ if (ret) {
+ dev_err(&rproc->dev, "unable to setup memory (%d)\n", ret);
+ return -EINVAL;
+ }
+
+ return qcom_mdt_load(rproc, fw, VENUS_FIRMWARE_NAME);
+}
+
+static const struct rproc_fw_ops venus_fw_ops = {
+ .find_rsc_table = qcom_mdt_find_rsc_table,
+ .load = venus_load,
+};
+
+static int venus_start(struct rproc *rproc)
+{
+ struct qcom_venus *venus = rproc->priv;
+ int ret;
+
+ ret = qcom_scm_pas_auth_and_reset(VENUS_PAS_ID);
+ if (ret)
+ dev_err(venus->dev,
+ "authentication image and release reset failed (%d)\n",
+ ret);
+
+ return ret;
+}
+
+static int venus_stop(struct rproc *rproc)
+{
+ struct qcom_venus *venus = rproc->priv;
+ int ret;
+
+ ret = qcom_scm_pas_shutdown(VENUS_PAS_ID);
+ if (ret)
+ dev_err(venus->dev, "failed to shutdown: %d\n", ret);
+
+ return ret;
+}
+
+static void *venus_da_to_va(struct rproc *rproc, u64 da, int len)
+{
+ struct qcom_venus *venus = rproc->priv;
+ s64 offset;
+
+ offset = da - venus->fw_addr;
+
+ if (offset < 0 || offset + len > venus->mem_size)
+ return NULL;
+
+ return venus->mem_va + offset;
+}
+
+static const struct rproc_ops venus_ops = {
+ .start = venus_start,
+ .stop = venus_stop,
+ .da_to_va = venus_da_to_va,
+};
+
+static int venus_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct qcom_venus *venus;
+ struct rproc *rproc;
+ int ret;
+
+ if (!qcom_scm_is_available())
+ return -EPROBE_DEFER;
+
+ if (!qcom_scm_pas_supported(VENUS_PAS_ID)) {
+ dev_err(dev, "PAS is not available for venus\n");
+ return -ENXIO;
+ }
+
+ ret = of_reserved_mem_device_init(dev);
+ if (ret)
+ return ret;
+
+ rproc = rproc_alloc(dev, pdev->name, &venus_ops, VENUS_FIRMWARE_NAME,
+ sizeof(*venus));
+ if (!rproc) {
+ dev_err(dev, "unable to allocate remoteproc\n");
+ ret = -ENOMEM;
+ goto release_mem;
+ }
+
+ rproc->fw_ops = &venus_fw_ops;
+ venus = rproc->priv;
+ venus->dev = dev;
+ venus->rproc = rproc;
+ venus->mem_size = VENUS_FW_MEM_SIZE;
+
+ platform_set_drvdata(pdev, venus);
+
+ venus->mem_va = dma_alloc_coherent(dev, venus->mem_size,
+ &venus->mem_phys, GFP_KERNEL);
+ if (!venus->mem_va) {
+ ret = -ENOMEM;
+ goto free_rproc;
+ }
+
+ ret = rproc_add(rproc);
+ if (ret)
+ goto free_mem;
+
+ return 0;
+
+free_mem:
+ dma_free_coherent(dev, venus->mem_size, venus->mem_va, venus->mem_phys);
+free_rproc:
+ rproc_put(rproc);
+release_mem:
+ of_reserved_mem_device_release(dev);
+
+ return ret;
+}
+
+static int venus_remove(struct platform_device *pdev)
+{
+ struct qcom_venus *venus = platform_get_drvdata(pdev);
+ struct device *dev = venus->dev;
+
+ rproc_del(venus->rproc);
+ rproc_put(venus->rproc);
+ dma_free_coherent(dev, venus->mem_size, venus->mem_va, venus->mem_phys);
+ of_reserved_mem_device_release(dev);
+
+ return 0;
+}
+
+static const struct of_device_id venus_of_match[] = {
+ { .compatible = "qcom,venus-pil" },
+ { },
+};
+
+static struct platform_driver venus_driver = {
+ .probe = venus_probe,
+ .remove = venus_remove,
+ .driver = {
+ .name = "qcom-venus-pil",
+ .of_match_table = venus_of_match,
+ },
+};
+
+module_platform_driver(venus_driver);
+MODULE_DESCRIPTION("Peripheral Image Loader for Venus");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] dt-binding: remoteproc: venus rproc dt binding document
From: Stanimir Varbanov @ 2016-11-07 17:30 UTC (permalink / raw)
To: Ohad Ben-Cohen, Bjorn Andersson, Stephen Boyd, Andy Gross,
Rob Herring, Mark Rutland
Cc: Srinivas Kandagatla, linux-remoteproc, linux-kernel,
linux-arm-msm, linux-soc, devicetree, Stanimir Varbanov
In-Reply-To: <1478539853-23218-1-git-send-email-stanimir.varbanov@linaro.org>
Add devicetree binding document for Venus remote processor.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
---
.../devicetree/bindings/remoteproc/qcom,venus.txt | 33 ++++++++++++++++++++++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt b/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
new file mode 100644
index 000000000000..06a2db60fa38
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
@@ -0,0 +1,33 @@
+Qualcomm Venus Peripheral Image Loader
+
+This document defines the binding for a component that loads and boots firmware
+on the Qualcomm Venus remote processor core.
+
+- compatible:
+ Usage: required
+ Value type: <string>
+ Definition: must contain "qcom,venus-pil"
+
+- memory-region:
+ Usage: required
+ Value type: <phandle>
+ Definition: a phandle to a node describing reserved memory
+
+* An example
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ venus_mem: venus@89900000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x89900000 0x0 0x800000>;
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+
+ rproc_venus@0 {
+ compatible = "qcom,venus-pil";
+ memory-region = <&venus_mem>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/3] firmware: qcom: scm: add a video command for state setting
From: Stanimir Varbanov @ 2016-11-07 17:30 UTC (permalink / raw)
To: Ohad Ben-Cohen, Bjorn Andersson, Stephen Boyd, Andy Gross,
Rob Herring, Mark Rutland
Cc: Srinivas Kandagatla, linux-remoteproc, linux-kernel,
linux-arm-msm, linux-soc, devicetree, Stanimir Varbanov
In-Reply-To: <1478539853-23218-1-git-send-email-stanimir.varbanov@linaro.org>
This scm call is used to change the video core state, more
specifically it is used to suspend and resume the core.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
---
drivers/firmware/qcom_scm-32.c | 18 ++++++++++++++++++
drivers/firmware/qcom_scm-64.c | 16 ++++++++++++++++
drivers/firmware/qcom_scm.c | 16 ++++++++++++++++
drivers/firmware/qcom_scm.h | 2 ++
include/linux/qcom_scm.h | 2 ++
5 files changed, 54 insertions(+)
diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index c6aeedbdcbb0..82c1d8d0d36b 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -560,3 +560,21 @@ int __qcom_scm_pas_mss_reset(struct device *dev, bool reset)
return ret ? : le32_to_cpu(out);
}
+
+int __qcom_scm_video_set_state(struct device *dev, u32 state, u32 spare)
+{
+ struct {
+ __le32 state;
+ __le32 spare;
+ } req;
+ __le32 scm_ret = 0;
+ int ret;
+
+ req.state = cpu_to_le32(state);
+ req.spare = cpu_to_le32(spare);
+
+ ret = qcom_scm_call(dev, QCOM_SCM_SVC_BOOT, QCOM_SCM_VIDEO_SET_STATE,
+ &req, sizeof(req), &scm_ret, sizeof(scm_ret));
+
+ return ret ? : le32_to_cpu(scm_ret);
+}
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index 4a0f5ead4fb5..68484ea2aa51 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -358,3 +358,19 @@ int __qcom_scm_pas_mss_reset(struct device *dev, bool reset)
return ret ? : res.a1;
}
+
+int __qcom_scm_video_set_state(struct device *dev, u32 state, u32 spare)
+{
+ struct qcom_scm_desc desc = {0};
+ struct arm_smccc_res res;
+ int ret;
+
+ desc.args[0] = state;
+ desc.args[1] = spare;
+ desc.arginfo = QCOM_SCM_ARGS(2);
+
+ ret = qcom_scm_call(dev, QCOM_SCM_SVC_BOOT, QCOM_SCM_VIDEO_SET_STATE,
+ &desc, &res);
+
+ return ret ? : res.a1;
+}
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index d95c70227c05..7e364691a87c 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -320,6 +320,22 @@ bool qcom_scm_is_available(void)
}
EXPORT_SYMBOL(qcom_scm_is_available);
+int qcom_scm_video_set_state(u32 state, u32 spare)
+{
+ int ret;
+
+ ret = qcom_scm_clk_enable();
+ if (ret)
+ return ret;
+
+ ret = __qcom_scm_video_set_state(__scm->dev, state, spare);
+
+ qcom_scm_clk_disable();
+
+ return ret;
+}
+EXPORT_SYMBOL(qcom_scm_video_set_state);
+
static int qcom_scm_probe(struct platform_device *pdev)
{
struct qcom_scm *scm;
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index 3584b00fe7e6..4830559b2639 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -15,6 +15,8 @@
#define QCOM_SCM_SVC_BOOT 0x1
#define QCOM_SCM_BOOT_ADDR 0x1
#define QCOM_SCM_BOOT_ADDR_MC 0x11
+#define QCOM_SCM_VIDEO_SET_STATE 0xa
+extern int __qcom_scm_video_set_state(struct device *dev, u32 state, u32 spare);
#define QCOM_SCM_FLAG_HLOS 0x01
#define QCOM_SCM_FLAG_COLDBOOT_MC 0x02
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index cc32ab852fbc..2ece81a6b078 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -46,4 +46,6 @@ extern void qcom_scm_cpu_power_down(u32 flags);
extern u32 qcom_scm_get_version(void);
+extern int qcom_scm_video_set_state(u32 state, u32 spare);
+
#endif
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/3] Venus remoteproc driver
From: Stanimir Varbanov @ 2016-11-07 17:30 UTC (permalink / raw)
To: Ohad Ben-Cohen, Bjorn Andersson, Stephen Boyd, Andy Gross,
Rob Herring, Mark Rutland
Cc: Srinivas Kandagatla, linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Stanimir Varbanov
Hi,
here is v2 of the Venus remoteproc driver, the changes are:
- removed page table size and page table init SCM calls.
regards,
Stan
Stanimir Varbanov (3):
firmware: qcom: scm: add a video command for state setting
dt-binding: remoteproc: venus rproc dt binding document
remoteproc: qcom: add Venus video core firmware loader driver
.../devicetree/bindings/remoteproc/qcom,venus.txt | 33 ++++
drivers/firmware/qcom_scm-32.c | 18 ++
drivers/firmware/qcom_scm-64.c | 16 ++
drivers/firmware/qcom_scm.c | 16 ++
drivers/firmware/qcom_scm.h | 2 +
drivers/remoteproc/Kconfig | 12 ++
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/qcom_venus_pil.c | 213 +++++++++++++++++++++
include/linux/qcom_scm.h | 2 +
9 files changed, 313 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
create mode 100644 drivers/remoteproc/qcom_venus_pil.c
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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