* Re: [PATCH 2/2] dt-bindings: power: sbs-battery: re-document "ti,bq20z75"
From: Rhyland Klein @ 2018-06-01 16:14 UTC (permalink / raw)
To: Brian Norris, Sebastian Reichel
Cc: linux-kernel, Rob Herring, linux-pm, devicetree, Alexandru Stan,
Guenter Roeck, Doug Anderson
In-Reply-To: <20180601003252.42810-2-briannorris@chromium.org>
On 5/31/2018 8:32 PM, Brian Norris wrote:
> This compatible property was documented before the driver was renamed to
> "SBS" (see commit e57f1b68c406 ("devicetree-bindings: Propagate
> bq20z75->sbs rename to dt bindings")). The driver has continued to
> support this property as an alternative to "sbs,sbs-battery", and
> because we've noticed there are some lingering TI specifics (in the
> manufacturer-specific portion of the SBS spec), we'd like to start using
> this property again to differentiate.
>
> Cc: Rhyland Klein <rklein@nvidia.com>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> .../devicetree/bindings/power/supply/sbs_sbs-battery.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt b/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
> index c40e8926facf..a7a9c3366f82 100644
> --- a/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
> +++ b/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
> @@ -2,7 +2,7 @@ SBS sbs-battery
> ~~~~~~~~~~
>
> Required properties :
> - - compatible : "sbs,sbs-battery"
> + - compatible : "sbs,sbs-battery" or "ti,bq20z75"
>
> Optional properties :
> - sbs,i2c-retry-count : The number of times to retry i2c transactions on i2c
>
Acked-by: Rhyland Klein <rklein@nvidia.com>
--
nvpublic
^ permalink raw reply
* Re: [PATCH 06/15] drm/sun4i: tcon: Add support for tcon-top
From: Maxime Ripard @ 2018-06-01 15:29 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Chen-Yu Tsai, Rob Herring, Mark Rutland, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, linux-sunxi
In-Reply-To: <2293030.uW1p7mJGcj@jernej-laptop>
[-- Attachment #1: Type: text/plain, Size: 10683 bytes --]
On Thu, May 31, 2018 at 07:54:08PM +0200, Jernej Škrabec wrote:
> Dne četrtek, 31. maj 2018 ob 11:21:33 CEST je Maxime Ripard napisal(a):
> > On Thu, May 24, 2018 at 03:01:09PM -0700, Chen-Yu Tsai wrote:
> > > >> > > + if (tcon->quirks->needs_tcon_top) {
> > > >> > > + struct device_node *np;
> > > >> > > +
> > > >> > > + np = of_parse_phandle(dev->of_node, "allwinner,tcon-top",
> > > >> > > 0);
> > > >> > > + if (np) {
> > > >> > > + struct platform_device *pdev;
> > > >> > > +
> > > >> > > + pdev = of_find_device_by_node(np);
> > > >> > > + if (pdev)
> > > >> > > + tcon->tcon_top =
> > > >> > > platform_get_drvdata(pdev);
> > > >> > > + of_node_put(np);
> > > >> > > +
> > > >> > > + if (!tcon->tcon_top)
> > > >> > > + return -EPROBE_DEFER;
> > > >> > > + }
> > > >> > > + }
> > > >> > > +
> > > >> >
> > > >> > I might have missed it, but I've not seen the bindings additions for
> > > >> > that property. This shouldn't really be done that way anyway, instead
> > > >> > of using a direct phandle, you should be using the of-graph, with the
> > > >> > TCON-top sitting where it belongs in the flow of data.
> > > >>
> > > >> Just to answer to the first question, it did describe it in "[PATCH
> > > >> 07/15] dt- bindings: display: sun4i-drm: Add R40 HDMI pipeline".
> > > >>
> > > >> As why I designed it that way - HW representation could be described
> > > >> that way> >>
> > > >> (ASCII art makes sense when fixed width font is used to view it):
> > > >> / LCD0/LVDS0
> > > >>
> > > >> / TCON-LCD0
> > > >>
> > > >> | \ MIPI DSI
> > > >>
> > > >> mixer0 |
> > > >>
> > > >> \ / TCON-LCD1 - LCD1/LVDS1
> > > >>
> > > >> TCON-TOP
> > > >>
> > > >> / \ TCON-TV0 - TVE0/RGB
> > > >>
> > > >> mixer1 | \
> > > >>
> > > >> | TCON-TOP - HDMI
> > > >> |
> > > >> | /
> > > >>
> > > >> \ TCON-TV1 - TVE1/RGB
> > > >>
> > > >> This is a bit simplified, since there is also TVE-TOP, which is
> > > >> responsible
> > > >> for sharing 4 DACs between both TVE encoders. You can have two TV outs
> > > >> (PAL/ NTSC) or TVE0 as TV out and TVE1 as RGB or vice versa. It even
> > > >> seems that you can arbitrarly choose which DAC is responsible for
> > > >> which signal, so there is a ton of possible end combinations, but I'm
> > > >> not 100% sure.
> > > >>
> > > >> Even though I wrote TCON-TOP twice, this is same unit in HW. R40 manual
> > > >> suggest more possibilities, although some of them seem wrong, like RGB
> > > >> feeding from LCD TCON. That is confirmed to be wrong when checking BSP
> > > >> code.
> > > >>
> > > >> Additionally, TCON-TOP comes in the middle of TVE0 and LCD0, TVE1 and
> > > >> LCD1 for pin muxing, although I'm not sure why is that needed at all,
> > > >> since according to R40 datasheet, TVE0 and TVE1 pins are dedicated and
> > > >> not on PORT D and PORT H, respectively, as TCON-TOP documentation
> > > >> suggest. However, HSYNC and PSYNC lines might be shared between TVE
> > > >> (when it works in RGB mode) and LCD. But that is just my guess since
> > > >> I'm not really familiar with RGB and LCD interfaces.
> > > >>
> > > >> I'm really not sure what would be the best representation in OF-graph.
> > > >> Can you suggest one?
> > > >
> > > > Rob might disagree on this one, but I don't see anything wrong with
> > > > having loops in the graph. If the TCON-TOP can be both the input and
> > > > output of the TCONs, then so be it, and have it described that way in
> > > > the graph.
> > > >
> > > > The code is already able to filter out nodes that have already been
> > > > added to the list of devices we need to wait for in the component
> > > > framework, so that should work as well.
> > > >
> > > > And we'd need to describe TVE-TOP as well, even though we don't have a
> > > > driver for it yet. That will simplify the backward compatibility later
> > > > on.
> > >
> > > I'm getting the feeling that TCON-TOP / TVE-TOP is the glue layer that
> > > binds everything together, and provides signal routing, kind of like
> > > DE-TOP on A64. So the signal mux controls that were originally found
> > > in TCON0 and TVE0 were moved out.
> > >
> > > The driver needs to know about that, but the graph about doesn't make
> > > much sense directly. Without looking at the manual, I understand it to
> > > likely be one mux between the mixers and TCONs, and one between the
> > > TCON-TVs and HDMI. Would it make more sense to just have the graph
> > > connections between the muxed components, and remove TCON-TOP from
> > > it, like we had in the past? A phandle could be used to reference
> > > the TCON-TOP for mux controls, in addition to the clocks and resets.
> > >
> > > For TVE, we would need something to represent each of the output pins,
> > > so the device tree can actually describe what kind of signal, be it
> > > each component of RGB/YUV or composite video, is wanted on each pin,
> > > if any. This is also needed on the A20 for the Cubietruck, so we can
> > > describe which pins are tied to the VGA connector, and which one does
> > > R, G, or B.
> >
> > I guess we'll see how the DT maintainers feel about this, but my
> > impression is that the OF graph should model the flow of data between
> > the devices. If there's a mux somewhere, then the data is definitely
> > going through it, and as such it should be part of the graph.
>
> I concur, but I spent few days thinking how to represent this sanely in graph,
> but I didn't find any good solution. I'll represent here my idea and please
> tell your opinion before I start implementing it.
>
> First, let me be clear that mixer0 and mixer1 don't have same capabilities
> (different number of planes, mixer0 supports writeback, mixer1 does not,
> etc.). Thus, it does matter which mixer is connected to which TCON/encoder.
> mixer0 is meant to be connected to main display and mixer1 to auxiliary. That
> obviously depends on end system.
>
> So, TCON TOP has 3 muxes, which have to be represented in graph. Two of them
> are for mixer/TCON relationship (each of them 1 input and 4 possible outputs)
> and one for TV TCON/HDMI pair selection (2 possible inputs, 1 output).
>
> According to current practice in sun4i-drm driver, graph has to have port 0,
> representing input and port 1, representing output. This would mean that graph
> looks something like that:
>
> tcon_top: tcon-top@1c70000 {
> compatible = "allwinner,sun8i-r40-tcon-top";
> ...
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> tcon_top_in: port@0 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0>;
>
> tcon_top_in_mixer0: endpoint@0 {
> reg = <0>;
> remote-endpoint = <&mixer0_out_tcon_top>;
> };
>
> tcon_top_in_mixer1: endpoint@1 {
> reg = <1>;
> remote-endpoint = <&mixer1_out_tcon_top>;
> };
>
> tcon_top_in_tcon_tv: endpoint@2 {
> reg = <2>;
> // here is HDMI input connection, part of board DTS
> remote-endpoint = <board specific phandle to TV TCON output>;
> };
> };
>
> tcon_top_out: port@1 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <1>;
>
> tcon_top_out_tcon0: endpoint@0 {
> reg = <0>;
> // here is mixer0 output connection, part of board DTS
> remote-endpoint = <board specific phandle to TCON>;
> };
>
> tcon_top_out_tcon1: endpoint@1 {
> reg = <1>;
> // here is mixer1 output connection, part of board DTS
> remote-endpoint = <board specific phandle to TCON>;
> };
>
> tcon_top_out_hdmi: endpoint@2 {
> reg = <2>;
> remote-endpoint = <&hdmi_in_tcon_top>;
> };
> };
> };
> };
IIRC, each port is supposed to be one route for the data, so we would
have multiple ports, one for the mixers in input and for the tcon in
output, and one for the TCON in input and for the HDMI/TV in
output. Rob might correct me here.
> tcon_tv0: lcd-controller@1c73000 {
> compatible = "allwinner,sun8i-r40-tcon-tv-0";
> ...
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> tcon_tv0_in: port@0 {
> reg = <0>;
>
> tcon_tv0_in_tcon_top: endpoint {
> // endpoint depends on board, part of board DTS
> remote-endpoint = <phandle to one of tcon_top_out_tcon>;
Just curious, what would be there?
> };
> };
>
> tcon_tv0_out: port@1 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <1>;
>
> // endpoints to TV TOP and TCON TOP HDMI input
> ...
> };
> };
> };
>
> tcon_tv1: lcd-controller@1c74000 {
> compatible = "allwinner,sun8i-r40-tcon-tv-1";
> ...
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> tcon_tv1_in: port@0 {
> reg = <0>;
>
> tcon_tv1_in_tcon_top: endpoint {
> // endpoint depends on board, part of board DTS
> remote-endpoint = <phandle to one of tcon_top_out_tcon>;
> };
> };
>
> tcon_tv1_out: port@1 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <1>;
>
> // endpoints to TV TOP and TCON TOP HDMI input
> ...
> };
> };
> };
>
> tcon_lcd0 and tcon_lcd1 would have similar connections, except that for
> outputs would be LCD or LVDS panels or MIPI DSI encoder.
>
> Please note that each TCON (there are 4 of them) would need to have unique
> compatible and have HW index stored in quirks data. It would be used by TCON
> TOP driver for configuring muxes.
Can't we use the port/endpoint ID instead? If the mux is the only
thing that changes, the compatible has no reason to. It's the same IP,
and the only thing that changes is something that is not part of that
IP.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 06/15] arm: dts: sun: Add missing cooling device properties for CPUs
From: Maxime Ripard @ 2018-06-01 15:17 UTC (permalink / raw)
To: Viresh Kumar
Cc: arm, Rob Herring, Mark Rutland, Chen-Yu Tsai, Vincent Guittot,
ionela.voinescu, Daniel Lezcano, chris.redpath, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20180528105734.bkplm7tfaqsurdrn@vireshk-i7>
[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]
Hi,
On Mon, May 28, 2018 at 04:27:34PM +0530, Viresh Kumar wrote:
> On 28-05-18, 10:44, Maxime Ripard wrote:
> > Hi,
> >
> > On Fri, May 25, 2018 at 04:01:52PM +0530, Viresh Kumar wrote:
> > > The cooling device properties, like "#cooling-cells" and
> > > "dynamic-power-coefficient", should either be present for all the CPUs
> > > of a cluster or none. If these are present only for a subset of CPUs of
> > > a cluster then things will start falling apart as soon as the CPUs are
> > > brought online in a different order. For example, this will happen
> > > because the operating system looks for such properties in the CPU node
> > > it is trying to bring up, so that it can register a cooling device.
> > >
> > > Add such missing properties.
> > >
> > > Fix other missing properties (clocks, OPP, clock latency) as well to
> > > make it all work.
> > >
> > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> >
> > The prefix should be sunxi and not sun, but it looks good to me
> > otherwise.
> >
> > Let me know what your preferred merge method is.
>
> Please pick it up directly and send it as part of your pull request.
> Do you want me to resend or can you fix the $subject ?
I just tried to apply it, and it failed. We have usually two different
PR for the H3 SoCs and the others. Could you split the H3 in a
separate patch (and fix the subject in the process?)
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] arm64: allwinner: a64-amarula-relic: Enable AP6330 WiFi support
From: Maxime Ripard @ 2018-06-01 15:06 UTC (permalink / raw)
To: Jagan Teki
Cc: Chen-Yu Tsai, Michael Trimarchi, Icenowy Zheng,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20180531165109.8476-1-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 690 bytes --]
Hi,
On Thu, May 31, 2018 at 10:21:09PM +0530, Jagan Teki wrote:
> Enable AP6330 WiFi/BT combo chip on Amarula A64-Relic board:
> - WiFi SDIO interface is connected to MMC1
> - WiFi WL-PMU-EN pin connected to gpio PL2: attach to mmc-pwrseq
> - WiFi WL-WAKE-AP pin connected to gpio PL3
> - 32kHz external oscillator gate clock from RTC
>
> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> ---
> Changes for v2:
> - Move external rtc clock nodes into main rtc node definition
> of sun50i-a64.dtsi
Please make that a separate patch.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3 2/8] dt-bindings: media: Document data-enable-active property
From: jacopo mondi @ 2018-06-01 14:58 UTC (permalink / raw)
To: Sakari Ailus
Cc: devicetree, robh+dt, linux-renesas-soc, horms, geert,
laurent.pinchart, niklas.soderlund, Jacopo Mondi, mchehab,
hans.verkuil, linux-arm-kernel, linux-media
In-Reply-To: <20180601102910.3qhe6bhg3w263chq@paasikivi.fi.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 1783 bytes --]
Hi Sakari,
On Fri, Jun 01, 2018 at 01:29:10PM +0300, Sakari Ailus wrote:
> Hi Jacopo,
>
> Thanks for the patch.
>
> On Tue, May 29, 2018 at 05:05:53PM +0200, Jacopo Mondi wrote:
> > Add 'data-enable-active' property to endpoint node properties list.
> >
> > The property allows to specify the polarity of the data-enable signal, which
> > when in active state determinates when data lanes have to sampled for valid
> > pixel data.
>
> Lanes or lines? I understand this is forthe parallel interface.
>
Now I'm confused. Are the parallel data 'lines' and the CSI-2 one
'lanes'? I thought 'lanes' applies to both.. am I wrong?
Thanks
j
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> > v3:
> > - new patch
> > ---
> > Documentation/devicetree/bindings/media/video-interfaces.txt | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt
> > index 258b8df..9839d26 100644
> > --- a/Documentation/devicetree/bindings/media/video-interfaces.txt
> > +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
> > @@ -109,6 +109,8 @@ Optional endpoint properties
> > Note, that if HSYNC and VSYNC polarities are not specified, embedded
> > synchronization may be required, where supported.
> > - data-active: similar to HSYNC and VSYNC, specifies data line polarity.
> > +- data-enable-active: similar to HSYNC and VSYNC, specifies the data enable
> > + signal polarity.
> > - field-even-active: field signal level during the even field data transmission.
> > - pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock
> > signal.
>
> --
> Sakari Ailus
> sakari.ailus@linux.intel.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 2/4] dt-bindings: Add bindings for SPI NAND devices
From: Geert Uytterhoeven @ 2018-06-01 14:42 UTC (permalink / raw)
To: Boris Brezillon
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Pawel Moll, Ian Campbell, Richard Weinberger, Kumar Gala,
Rob Herring, linux-spi, Marek Vasut, Mark Brown, MTD Maling List,
Miquel Raynal, Brian Norris, David Woodhouse
In-Reply-To: <20180601131400.17634-3-boris.brezillon@bootlin.com>
Hi Boris,
I became interested after reading the cover letter...
On Fri, Jun 1, 2018 at 3:13 PM, Boris Brezillon
<boris.brezillon@bootlin.com> wrote:
> Add bindings for SPI NAND chips.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Thanks for your patch!
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/spi-nand.txt
> @@ -0,0 +1,27 @@
> +SPI NAND flash
> +
> +Required properties:
> +- compatible: should be "spi-nand"
> +- reg: should encode the chip-select line used to access the NAND chip
> +
> +Optional properties
> +- spi-max-frequency: maximum frequency of the SPI bus the chip can operate at.
> + This should encode board limitations (i.e. max freq can't
> + be achieved due to crosstalk on IO lines).
> + When unspecified, the driver assumes the chip can run at
> + the max frequency defined in the spec (information
> + extracted chip detection time).
This is a standard property according to
Documentation/devicetree/bindings/spi/spi-bus.txt. Can't you just refer
to that file, or just omit it, as it applies to all SPI slaves anyway?
> +- spi-tx-bus-width: The bus width (number of data wires) that is used for MOSI.
> + Only encodes the board constraints (i.e. when not all IO
> + signals are routed on the board). Device constraints are
> + extracted when detecting the chip, and controller
> + constraints are exposed by the SPI mem controller. If this
> + property is missing that means no constraint at the board
> + level.
> +- spi-rx-bus-width: The bus width (number of data wires) that is used for MISO.
> + Only encodes the board constraints (i.e. when not all IO
> + signals are routed on the board). Device constraints are
> + extracted when detecting the chip, and controller
> + constraints are exposed by the SPI mem controller. If this
> + property is missing that means no constraint at the board
> + level.
This does not match Documentation/devicetree/bindings/spi/spi-bus.txt,
which says the default is 1.
As these properties are handled by the SPI core in of_spi_parse_dt, why
would you want to deviate?
Commenting to the question in the cover letter: what would be the
purpose of spi-max-bus-width?
Thanks!
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
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v3 4/8] dt-bindings: gnss: add u-blox binding
From: Rob Herring @ 2018-06-01 14:34 UTC (permalink / raw)
To: Johan Hovold
Cc: Greg Kroah-Hartman, Mark Rutland, Andreas Kemnade, Arnd Bergmann,
H . Nikolaus Schaller, Pavel Machek, Marcel Holtmann,
Sebastian Reichel, Tony Lindgren, linux-kernel@vger.kernel.org,
devicetree
In-Reply-To: <20180601082259.17563-5-johan@kernel.org>
On Fri, Jun 1, 2018 at 3:22 AM, Johan Hovold <johan@kernel.org> wrote:
> Add binding for u-blox GNSS receivers.
>
> Note that the u-blox product names encodes form factor (e.g. "neo"),
> chipset (e.g. "8") and variant (e.g. "q"), but that only formfactor and
> chipset is used for the compatible strings (for now).
>
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
> .../devicetree/bindings/gnss/u-blox.txt | 44 +++++++++++++++++++
> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> 2 files changed, 45 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 4/4] MAINTAINERS: Add entry for Mellanox Bluefield Soc
From: Liming Sun @ 2018-06-01 14:31 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, David Woods, Robin Murphy
Cc: devicetree, Liming Sun, linux-arm-kernel
In-Reply-To: <b143b40446c1870fb8d422b364ead95d54552be9.1527264077.git.lsun@mellanox.com>
Add maintainer information for Mellanox BlueField SoC.
Reviewed-by: David Woods <dwoods@mellanox.com>
Signed-off-by: Liming Sun <lsun@mellanox.com>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 58b9861..85d5639 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1636,6 +1636,14 @@ L: linux-mediatek@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: drivers/phy/mediatek/phy-mtk-tphy.c
+ARM/Mellanox BlueField SoC support
+M: David Woods <dwoods@mellanox.com>
+M: Liming Sun <lsun@mellanox.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: drivers/soc/mellanox/*
+F: Documentation/devicetree/bindings/soc/mellanox/tmfifo.txt
+
ARM/MICREL KS8695 ARCHITECTURE
M: Greg Ungerer <gerg@uclinux.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 3/4] dt-bindings: soc: Add TmFifo binding for Mellanox BlueField SoC
From: Liming Sun @ 2018-06-01 14:31 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, David Woods, Robin Murphy
Cc: devicetree, Liming Sun, linux-arm-kernel
In-Reply-To: <b143b40446c1870fb8d422b364ead95d54552be9.1527264077.git.lsun@mellanox.com>
Add devicetree bindings for the TmFifo which is found on Mellanox
BlueField SoCs.
Reviewed-by: David Woods <dwoods@mellanox.com>
Signed-off-by: Liming Sun <lsun@mellanox.com>
---
.../devicetree/bindings/soc/mellanox/tmfifo.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/mellanox/tmfifo.txt
diff --git a/Documentation/devicetree/bindings/soc/mellanox/tmfifo.txt b/Documentation/devicetree/bindings/soc/mellanox/tmfifo.txt
new file mode 100644
index 0000000..8a13fa6
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mellanox/tmfifo.txt
@@ -0,0 +1,23 @@
+* Mellanox BlueField SoC TmFifo
+
+BlueField TmFifo provides a shared FIFO between the target and the
+external host machine, which can be accessed by external host via
+USB or PCIe. In the current tmfifo driver, this FIFO has been demuxed
+to implement virtual console and network interface based on the virtio
+framework.
+
+Required properties:
+
+- compatible: Should be "mellanox,bf-tmfifo"
+- reg: Physical base address and length of Rx/Tx block
+- interrupts: The interrupt number of Rx low water mark, Rx high water mark
+ Tx low water mark, Tx high water mark respectively.
+
+Example:
+
+tmfifo@800a20 {
+ compatible = "mellanox,bf-tmfifo";
+ reg = <0x00800a20 0x00000018
+ 0x00800a40 0x00000018>;
+ interrupts = <41, 42, 43, 44>;
+};
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 2/4] arm64: Add Mellanox BlueField SoC config option
From: Liming Sun @ 2018-06-01 14:31 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, David Woods, Robin Murphy
Cc: devicetree, Liming Sun, linux-arm-kernel
In-Reply-To: <b143b40446c1870fb8d422b364ead95d54552be9.1527264077.git.lsun@mellanox.com>
This commit introduces config option for Mellanox BlueField SoC,
which can be used to build the SoC specific drivers, and enables
it by default in configs/defconfig.
Reviewed-by: David Woods <dwoods@mellanox.com>
Signed-off-by: Liming Sun <lsun@mellanox.com>
---
arch/arm64/Kconfig.platforms | 6 ++++++
arch/arm64/configs/defconfig | 1 +
2 files changed, 7 insertions(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 2b1535c..74ad03f 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -110,6 +110,12 @@ config ARCH_MESON
help
This enables support for the Amlogic S905 SoCs.
+config ARCH_MLNX_BLUEFIELD
+ bool "Mellanox BlueField SoC Family"
+ select SOC_MLNX
+ help
+ This enables support for the Mellanox BlueField SoC.
+
config ARCH_MVEBU
bool "Marvell EBU SoC Family"
select ARMADA_AP806_SYSCON
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 1c98939..842f607 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -43,6 +43,7 @@ CONFIG_ARCH_LG1K=y
CONFIG_ARCH_HISI=y
CONFIG_ARCH_MEDIATEK=y
CONFIG_ARCH_MESON=y
+CONFIG_ARCH_MLNX_BLUEFIELD=y
CONFIG_ARCH_MVEBU=y
CONFIG_ARCH_QCOM=y
CONFIG_ARCH_ROCKCHIP=y
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 1/4] soc: Add TmFifo driver for Mellanox BlueField Soc
From: Liming Sun @ 2018-06-01 14:31 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, David Woods, Robin Murphy
Cc: devicetree, Liming Sun, linux-arm-kernel
In-Reply-To: <b143b40446c1870fb8d422b364ead95d54552be9.1527264077.git.lsun@mellanox.com>
This commit adds the TmFifo driver for Mellanox BlueField Soc.
TmFifo is a shared FIFO which enables external host machine to
exchange data with the SoC via USB or PCIe. The driver is based on
virtio framework and has console and network access enabled.
Reviewed-by: David Woods <dwoods@mellanox.com>
Signed-off-by: Liming Sun <lsun@mellanox.com>
---
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/mellanox/Kconfig | 18 +
drivers/soc/mellanox/Makefile | 5 +
drivers/soc/mellanox/tmfifo.c | 1239 ++++++++++++++++++++++++++++++++++++
drivers/soc/mellanox/tmfifo_regs.h | 75 +++
6 files changed, 1339 insertions(+)
create mode 100644 drivers/soc/mellanox/Kconfig
create mode 100644 drivers/soc/mellanox/Makefile
create mode 100644 drivers/soc/mellanox/tmfifo.c
create mode 100644 drivers/soc/mellanox/tmfifo_regs.h
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index c07b4a8..fa87dc8 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -7,6 +7,7 @@ source "drivers/soc/bcm/Kconfig"
source "drivers/soc/fsl/Kconfig"
source "drivers/soc/imx/Kconfig"
source "drivers/soc/mediatek/Kconfig"
+source "drivers/soc/mellanox/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/renesas/Kconfig"
source "drivers/soc/rockchip/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 4052357..868163f 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_ARCH_GEMINI) += gemini/
obj-$(CONFIG_ARCH_MXC) += imx/
obj-$(CONFIG_SOC_XWAY) += lantiq/
obj-y += mediatek/
+obj-$(CONFIG_SOC_MLNX) += mellanox/
obj-$(CONFIG_ARCH_MESON) += amlogic/
obj-$(CONFIG_ARCH_QCOM) += qcom/
obj-y += renesas/
diff --git a/drivers/soc/mellanox/Kconfig b/drivers/soc/mellanox/Kconfig
new file mode 100644
index 0000000..d88efa1
--- /dev/null
+++ b/drivers/soc/mellanox/Kconfig
@@ -0,0 +1,18 @@
+menuconfig SOC_MLNX
+ bool "Mellanox SoC drivers"
+ default y if ARCH_MLNX_BLUEFIELD
+
+if ARCH_MLNX_BLUEFIELD || COMPILE_TEST
+
+config MLNX_BLUEFIELD_TMFIFO
+ tristate "Mellanox BlueField SoC TmFifo driver"
+ depends on ARM64
+ default m
+ select VIRTIO_CONSOLE
+ select VIRTIO_NET
+ help
+ Say y here to enable TmFifo support. The TmFifo driver provides the
+ virtio driver framework for the TMFIFO of Mellanox BlueField SoC and
+ the implementation of a console and network driver.
+
+endif # ARCH_MLNX_BLUEFIELD
diff --git a/drivers/soc/mellanox/Makefile b/drivers/soc/mellanox/Makefile
new file mode 100644
index 0000000..c44c0e2
--- /dev/null
+++ b/drivers/soc/mellanox/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for Mellanox SoC drivers.
+#
+obj-$(CONFIG_MLNX_BLUEFIELD_TMFIFO) += tmfifo.o
diff --git a/drivers/soc/mellanox/tmfifo.c b/drivers/soc/mellanox/tmfifo.c
new file mode 100644
index 0000000..5647cb6
--- /dev/null
+++ b/drivers/soc/mellanox/tmfifo.c
@@ -0,0 +1,1239 @@
+/*
+ * Copyright (c) 2018, Mellanox Technologies. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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/acpi.h>
+#include <linux/bitfield.h>
+#include <linux/cache.h>
+#include <linux/device.h>
+#include <linux/dma-mapping.h>
+#include <linux/efi.h>
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/kernel.h>
+#include <linux/math64.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
+#include <linux/resource.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/version.h>
+#include <linux/virtio.h>
+#include <linux/virtio_config.h>
+#include <linux/virtio_console.h>
+#include <linux/virtio_ids.h>
+#include <linux/virtio_net.h>
+#include <linux/virtio_ring.h>
+#include <asm/byteorder.h>
+
+#include "tmfifo_regs.h"
+
+#define TMFIFO_GET_FIELD(reg, mask) FIELD_GET(mask, reg)
+
+#define TMFIFO_SET_FIELD(reg, mask, value) \
+ ((reg & ~mask) | FIELD_PREP(mask, value))
+
+/* Vring size. */
+#define TMFIFO_VRING_SIZE 1024
+
+/* Console Tx buffer size. */
+#define TMFIFO_CONS_TX_BUF_SIZE (32 * 1024)
+
+/* Use a timer for house-keeping. */
+static int tmfifo_timer_interval = HZ / 10;
+
+/* Global lock. */
+static struct mutex tmfifo_lock;
+
+/* Virtio ring size. */
+static int tmfifo_vring_size = TMFIFO_VRING_SIZE;
+module_param(tmfifo_vring_size, int, 0444);
+MODULE_PARM_DESC(tmfifo_vring_size, "Size of the vring.");
+
+struct tmfifo;
+
+/* A flag to indicate TmFifo ready. */
+static bool tmfifo_ready;
+
+/* Virtual devices sharing the TM FIFO. */
+#define TMFIFO_VDEV_MAX (VIRTIO_ID_CONSOLE + 1)
+
+/* Spin lock. */
+static DEFINE_SPINLOCK(tmfifo_spin_lock);
+
+/* Structure to maintain the ring state. */
+struct tmfifo_vring {
+ void *va; /* virtual address */
+ dma_addr_t dma; /* dma address */
+ struct virtqueue *vq; /* virtqueue pointer */
+ struct vring_desc *desc; /* current desc */
+ struct vring_desc *desc_head; /* current desc head */
+ int cur_len; /* processed len in current desc */
+ int rem_len; /* remaining length to be processed */
+ int size; /* vring size */
+ int align; /* vring alignment */
+ int id; /* vring id */
+ int vdev_id; /* TMFIFO_VDEV_xxx */
+ u32 pkt_len; /* packet total length */
+ __virtio16 next_avail; /* next avail desc id */
+ struct tmfifo *fifo; /* pointer back to the tmfifo */
+};
+
+/* Interrupt types. */
+enum {
+ TM_RX_LWM_IRQ, /* Rx low water mark irq */
+ TM_RX_HWM_IRQ, /* Rx high water mark irq */
+ TM_TX_LWM_IRQ, /* Tx low water mark irq */
+ TM_TX_HWM_IRQ, /* Tx high water mark irq */
+ TM_IRQ_CNT
+};
+
+/* Ring types (Rx & Tx). */
+enum {
+ TMFIFO_VRING_RX, /* Rx ring */
+ TMFIFO_VRING_TX, /* Tx ring */
+ TMFIFO_VRING_NUM
+};
+
+struct tmfifo_vdev {
+ struct virtio_device vdev; /* virtual device */
+ u8 status;
+ u64 features;
+ union { /* virtio config space */
+ struct virtio_console_config cons;
+ struct virtio_net_config net;
+ } config;
+ struct tmfifo_vring vrings[TMFIFO_VRING_NUM];
+ u8 *tx_buf; /* tx buffer */
+ u32 tx_head; /* tx buffer head */
+ u32 tx_tail; /* tx buffer tail */
+};
+
+#define TMFIFO_VDEV_TX_BUF_AVAIL(vdev) \
+ (((vdev)->tx_tail >= (vdev)->tx_head) ? \
+ (TMFIFO_CONS_TX_BUF_SIZE - 8 - ((vdev)->tx_tail - (vdev)->tx_head)) : \
+ ((vdev)->tx_head - (vdev)->tx_tail - 8))
+
+#define TMFIFO_VDEV_TX_BUF_PUSH(vdev, len) do { \
+ (vdev)->tx_tail += (len); \
+ if ((vdev)->tx_tail >= TMFIFO_CONS_TX_BUF_SIZE) \
+ (vdev)->tx_tail -= TMFIFO_CONS_TX_BUF_SIZE; \
+} while (0)
+
+#define TMFIFO_VDEV_TX_BUF_POP(vdev, len) do { \
+ (vdev)->tx_head += (len); \
+ if ((vdev)->tx_head >= TMFIFO_CONS_TX_BUF_SIZE) \
+ (vdev)->tx_head -= TMFIFO_CONS_TX_BUF_SIZE; \
+} while (0)
+
+/* TMFIFO device structure */
+struct tmfifo {
+ struct tmfifo_vdev *vdev[TMFIFO_VDEV_MAX]; /* virtual devices */
+ struct platform_device *pdev; /* platform device */
+ struct mutex lock;
+ void __iomem *rx_base; /* mapped register base */
+ void __iomem *tx_base; /* mapped register base */
+ int tx_fifo_size; /* number of entries of the Tx FIFO */
+ int rx_fifo_size; /* number of entries of the Rx FIFO */
+ unsigned long pend_events; /* pending bits for deferred process */
+ int irq[TM_IRQ_CNT]; /* irq numbers */
+ struct work_struct work; /* work struct for deferred process */
+ struct timer_list timer; /* keepalive timer */
+ struct tmfifo_vring *vring[2]; /* current Tx/Rx ring */
+};
+
+union tmfifo_msg_hdr {
+ struct {
+ u8 type; /* message type */
+ __be16 len; /* payload length */
+ u8 unused[5]; /* reserved, set to 0 */
+ } __packed;
+ u64 data;
+};
+
+/*
+ * Default MAC.
+ * This MAC address will be read from EFI persistent variable if configured.
+ * It can also be reconfigured with standard Linux tools.
+ */
+static u8 tmfifo_net_default_mac[6] = {0x00, 0x1A, 0xCA, 0xFF, 0xFF, 0x01};
+
+/* MTU setting of the virtio-net interface. */
+#define TMFIFO_NET_MTU 1500
+
+/* Supported virtio-net features. */
+#define TMFIFO_NET_FEATURES ((1UL << VIRTIO_NET_F_MTU) | \
+ (1UL << VIRTIO_NET_F_STATUS) | \
+ (1UL << VIRTIO_NET_F_MAC))
+
+/* Forward declaration. */
+static void tmfifo_virtio_rxtx(struct virtqueue *vq, bool is_rx);
+static void tmfifo_release_pkt(struct virtio_device *vdev,
+ struct tmfifo_vring *vring,
+ struct vring_desc **desc);
+
+/* Allocate vrings for the fifo. */
+static int tmfifo_alloc_vrings(struct tmfifo *fifo,
+ struct tmfifo_vdev *tm_vdev, int vdev_id)
+{
+ dma_addr_t dma;
+ void *va;
+ int i, size;
+ struct tmfifo_vring *vring;
+
+ for (i = 0; i < ARRAY_SIZE(tm_vdev->vrings); i++) {
+ vring = &tm_vdev->vrings[i];
+ vring->fifo = fifo;
+ vring->size = tmfifo_vring_size;
+ vring->align = SMP_CACHE_BYTES;
+ vring->id = i;
+ vring->vdev_id = vdev_id;
+
+ size = PAGE_ALIGN(vring_size(vring->size, vring->align));
+ va = dma_alloc_coherent(tm_vdev->vdev.dev.parent, size, &dma,
+ GFP_KERNEL);
+ if (!va) {
+ dev_err(tm_vdev->vdev.dev.parent,
+ "vring allocation failed\n");
+ return -EINVAL;
+ }
+
+ vring->va = va;
+ vring->dma = dma;
+ }
+
+ return 0;
+}
+
+/* Free vrings of the fifo device. */
+static void tmfifo_free_vrings(struct tmfifo *fifo, int vdev_id)
+{
+ int i, size;
+ struct tmfifo_vring *vring;
+ struct tmfifo_vdev *tm_vdev = fifo->vdev[vdev_id];
+
+ for (i = 0; i < ARRAY_SIZE(tm_vdev->vrings); i++) {
+ vring = &tm_vdev->vrings[i];
+
+ size = PAGE_ALIGN(vring_size(vring->size, vring->align));
+ if (vring->va) {
+ dma_free_coherent(tm_vdev->vdev.dev.parent, size,
+ vring->va, vring->dma);
+ vring->va = NULL;
+ if (vring->vq) {
+ vring_del_virtqueue(vring->vq);
+ vring->vq = NULL;
+ }
+ }
+ }
+}
+
+/* Free interrupts of the fifo device. */
+static void tmfifo_free_irqs(struct tmfifo *fifo)
+{
+ int i, irq;
+
+ for (i = 0; i < TM_IRQ_CNT; i++) {
+ irq = fifo->irq[i];
+ if (irq) {
+ fifo->irq[i] = 0;
+ disable_irq(irq);
+ free_irq(irq, (u8 *)fifo + i);
+ }
+ }
+}
+
+/* Work handler for Rx, Tx or activity monitoring. */
+static void tmfifo_work_handler(struct work_struct *work)
+{
+ int i;
+ struct tmfifo_vdev *tm_vdev;
+ struct tmfifo *fifo = container_of(work, struct tmfifo, work);
+
+ if (!tmfifo_ready)
+ return;
+
+ mutex_lock(&fifo->lock);
+
+ /* Tx. */
+ if (test_and_clear_bit(TM_TX_LWM_IRQ, &fifo->pend_events) &&
+ fifo->irq[TM_TX_LWM_IRQ]) {
+ for (i = 0; i < TMFIFO_VDEV_MAX; i++) {
+ tm_vdev = fifo->vdev[i];
+ if (tm_vdev != NULL) {
+ tmfifo_virtio_rxtx(
+ tm_vdev->vrings[TMFIFO_VRING_TX].vq,
+ false);
+ }
+ }
+ }
+
+ /* Rx. */
+ if (test_and_clear_bit(TM_RX_HWM_IRQ, &fifo->pend_events) &&
+ fifo->irq[TM_RX_HWM_IRQ]) {
+ for (i = 0; i < TMFIFO_VDEV_MAX; i++) {
+ tm_vdev = fifo->vdev[i];
+ if (tm_vdev != NULL) {
+ tmfifo_virtio_rxtx(
+ tm_vdev->vrings[TMFIFO_VRING_RX].vq,
+ true);
+ }
+ }
+ }
+
+ mutex_unlock(&fifo->lock);
+}
+
+/* Interrupt handler. */
+static irqreturn_t tmfifo_irq_handler(int irq, void *dev_id)
+{
+ int i = (uintptr_t)dev_id % sizeof(void *);
+ struct tmfifo *fifo = dev_id - i;
+
+ if (i < TM_IRQ_CNT && !test_and_set_bit(i, &fifo->pend_events))
+ schedule_work(&fifo->work);
+
+ return IRQ_HANDLED;
+}
+
+/* Nothing to do for now. */
+static void tmfifo_virtio_dev_release(struct device *dev)
+{
+}
+
+/* Get the next packet descriptor from the vring. */
+static inline struct vring_desc *
+tmfifo_virtio_get_next_desc(struct virtqueue *vq)
+{
+ unsigned int idx, head;
+ struct vring *vr = (struct vring *)virtqueue_get_vring(vq);
+ struct tmfifo_vring *vring = (struct tmfifo_vring *)vq->priv;
+
+ if (!vr || vring->next_avail == vr->avail->idx)
+ return NULL;
+
+ idx = vring->next_avail % vr->num;
+ head = vr->avail->ring[idx];
+ BUG_ON(head >= vr->num);
+ vring->next_avail++;
+ return &vr->desc[head];
+}
+
+static inline void tmfifo_virtio_release_desc(struct virtio_device *vdev,
+ struct vring *vr,
+ struct vring_desc *desc, u32 len)
+{
+ unsigned int idx;
+
+ idx = vr->used->idx % vr->num;
+ vr->used->ring[idx].id = desc - vr->desc;
+ vr->used->ring[idx].len = cpu_to_virtio32(vdev, len);
+
+ /* Virtio could poll and check the 'idx' to decide
+ * whether the desc is done or not. Add a memory
+ * barrier here to make sure the update above completes
+ * before updating the idx.
+ */
+ mb();
+ vr->used->idx++;
+}
+
+/* Get the total length of a descriptor chain. */
+static inline u32 tmfifo_virtio_get_pkt_len(struct virtio_device *vdev,
+ struct vring_desc *desc, struct vring *vr)
+{
+ u32 len = 0, idx;
+
+ while (desc) {
+ len += virtio32_to_cpu(vdev, desc->len);
+ if (!(virtio16_to_cpu(vdev, desc->flags) & VRING_DESC_F_NEXT))
+ break;
+ idx = virtio16_to_cpu(vdev, desc->next);
+ desc = &vr->desc[idx];
+ }
+
+ return len;
+}
+
+static void tmfifo_release_pkt(struct virtio_device *vdev,
+ struct tmfifo_vring *vring,
+ struct vring_desc **desc)
+{
+ struct vring *vr = (struct vring *)virtqueue_get_vring(vring->vq);
+ struct vring_desc *desc_head;
+ uint32_t pkt_len = 0;
+
+ if (!vr)
+ return;
+
+ if (desc != NULL && *desc != NULL && vring->desc_head != NULL) {
+ desc_head = vring->desc_head;
+ pkt_len = vring->pkt_len;
+ } else {
+ desc_head = tmfifo_virtio_get_next_desc(vring->vq);
+ if (desc_head != NULL) {
+ pkt_len = tmfifo_virtio_get_pkt_len(vdev,
+ desc_head, vr);
+ }
+ }
+
+ if (desc_head != NULL)
+ tmfifo_virtio_release_desc(vdev, vr, desc_head, pkt_len);
+
+ if (desc != NULL)
+ *desc = NULL;
+ vring->pkt_len = 0;
+}
+
+/* House-keeping timer. */
+static void tmfifo_timer(struct timer_list *arg)
+{
+ struct tmfifo *fifo = container_of(arg, struct tmfifo, timer);
+
+ /*
+ * Wake up the work handler to poll the Rx FIFO in case interrupt
+ * missing or any leftover bytes stuck in the FIFO.
+ */
+ test_and_set_bit(TM_RX_HWM_IRQ, &fifo->pend_events);
+
+ /*
+ * Wake up Tx handler in case virtio has queued too many packets
+ * and are waiting for buffer return.
+ */
+ test_and_set_bit(TM_TX_LWM_IRQ, &fifo->pend_events);
+
+ schedule_work(&fifo->work);
+
+ mod_timer(&fifo->timer, jiffies + tmfifo_timer_interval);
+}
+
+/* Buffer the console output. */
+static void tmfifo_console_output(struct tmfifo_vdev *cons,
+ struct virtqueue *vq)
+{
+ u32 len, pkt_len, idx;
+ struct vring_desc *head_desc, *desc = NULL;
+ struct vring *vr = (struct vring *)virtqueue_get_vring(vq);
+ struct virtio_device *vdev = &cons->vdev;
+ void *addr;
+ union tmfifo_msg_hdr *hdr;
+
+ for (;;) {
+ head_desc = tmfifo_virtio_get_next_desc(vq);
+ if (head_desc == NULL)
+ break;
+
+ /* Release the packet if no more space. */
+ pkt_len = tmfifo_virtio_get_pkt_len(vdev, head_desc, vr);
+ if (pkt_len + sizeof(*hdr) > TMFIFO_VDEV_TX_BUF_AVAIL(cons)) {
+ tmfifo_virtio_release_desc(vdev, vr, head_desc,
+ pkt_len);
+ break;
+ }
+
+ hdr = (union tmfifo_msg_hdr *)&cons->tx_buf[cons->tx_tail];
+ hdr->data = 0;
+ hdr->type = VIRTIO_ID_CONSOLE;
+ hdr->len = htons(pkt_len);
+
+ TMFIFO_VDEV_TX_BUF_PUSH(cons, sizeof(*hdr));
+ desc = head_desc;
+
+ while (desc != NULL) {
+ addr = phys_to_virt(virtio64_to_cpu(vdev, desc->addr));
+ len = virtio32_to_cpu(vdev, desc->len);
+
+ if (len <= TMFIFO_CONS_TX_BUF_SIZE - cons->tx_tail) {
+ memcpy(cons->tx_buf + cons->tx_tail, addr, len);
+ } else {
+ u32 seg;
+
+ seg = TMFIFO_CONS_TX_BUF_SIZE - cons->tx_tail;
+ memcpy(cons->tx_buf + cons->tx_tail, addr, seg);
+ addr += seg;
+ memcpy(cons->tx_buf, addr, len - seg);
+ }
+ TMFIFO_VDEV_TX_BUF_PUSH(cons, len);
+
+ if (!(virtio16_to_cpu(vdev, desc->flags) &
+ VRING_DESC_F_NEXT))
+ break;
+ idx = virtio16_to_cpu(vdev, desc->next);
+ desc = &vr->desc[idx];
+ }
+
+ /* Make each packet 8-byte aligned. */
+ TMFIFO_VDEV_TX_BUF_PUSH(cons, ((pkt_len + 7) & -8) - pkt_len);
+
+ tmfifo_virtio_release_desc(vdev, vr, head_desc, pkt_len);
+ }
+}
+
+/* Rx & Tx processing of a virtual queue. */
+static void tmfifo_virtio_rxtx(struct virtqueue *vq, bool is_rx)
+{
+ struct tmfifo_vring *vring;
+ struct tmfifo *fifo;
+ struct vring *vr;
+ struct virtio_device *vdev;
+ u64 sts, data;
+ int num_avail = 0, hdr_len, tx_reserve;
+ void *addr;
+ u32 len, idx;
+ struct vring_desc *desc;
+ unsigned long flags;
+ struct tmfifo_vdev *cons;
+
+ if (!vq)
+ return;
+
+ vring = (struct tmfifo_vring *)vq->priv;
+ fifo = vring->fifo;
+ vr = (struct vring *)virtqueue_get_vring(vq);
+
+ if (!fifo->vdev[vring->vdev_id])
+ return;
+ vdev = &fifo->vdev[vring->vdev_id]->vdev;
+ cons = fifo->vdev[VIRTIO_ID_CONSOLE];
+
+ /* Don't continue if another vring is running. */
+ if (fifo->vring[is_rx] != NULL && fifo->vring[is_rx] != vring)
+ return;
+
+ /* tx_reserve is used to reserved some room in FIFO for console. */
+ if (vring->vdev_id == VIRTIO_ID_NET) {
+ hdr_len = sizeof(struct virtio_net_hdr);
+ tx_reserve = fifo->tx_fifo_size / 16;
+ } else {
+ BUG_ON(vring->vdev_id != VIRTIO_ID_CONSOLE);
+ hdr_len = 0;
+ tx_reserve = 1;
+ }
+
+ desc = vring->desc;
+
+again:
+ while (1) {
+ /* Get available FIFO space. */
+ if (num_avail == 0) {
+ if (is_rx) {
+ /* Get the number of available words in FIFO. */
+ sts = readq(fifo->rx_base + TMFIFO_RX_STS);
+ num_avail = TMFIFO_GET_FIELD(sts,
+ TMFIFO_RX_STS__COUNT_MASK);
+
+ /* Don't continue if nothing in FIFO. */
+ if (num_avail <= 0)
+ break;
+ } else {
+ /* Get available space in FIFO. */
+ sts = readq(fifo->tx_base + TMFIFO_TX_STS);
+ num_avail = fifo->tx_fifo_size - tx_reserve -
+ TMFIFO_GET_FIELD(sts,
+ TMFIFO_TX_STS__COUNT_MASK);
+
+ if (num_avail <= 0)
+ break;
+ }
+ }
+
+ /* Console output always comes from the Tx buffer. */
+ if (!is_rx && vring->vdev_id == VIRTIO_ID_CONSOLE &&
+ cons != NULL && cons->tx_buf != NULL) {
+ for (;;) {
+ spin_lock_irqsave(&tmfifo_spin_lock, flags);
+ if (cons->tx_head == cons->tx_tail) {
+ spin_unlock_irqrestore(
+ &tmfifo_spin_lock, flags);
+ return;
+ }
+ addr = cons->tx_buf + cons->tx_head;
+ writeq(cpu_to_le64(*(u64 *)addr),
+ fifo->tx_base + TMFIFO_TX_DATA);
+ TMFIFO_VDEV_TX_BUF_POP(cons, sizeof(u64));
+ spin_unlock_irqrestore(&tmfifo_spin_lock,
+ flags);
+ if (--num_avail <= 0)
+ goto again;
+ }
+ }
+
+ /* Get the desc of next packet. */
+ if (!desc) {
+ /* Save the head desc of the chain. */
+ vring->desc_head = tmfifo_virtio_get_next_desc(vq);
+ if (!vring->desc_head) {
+ vring->desc = NULL;
+ return;
+ }
+ desc = vring->desc_head;
+ vring->desc = desc;
+
+ if (is_rx && vring->vdev_id == VIRTIO_ID_NET) {
+ struct virtio_net_hdr *net_hdr;
+
+ /* Initialize the packet header. */
+ net_hdr = (struct virtio_net_hdr *)
+ phys_to_virt(virtio64_to_cpu(
+ vdev, desc->addr));
+ memset(net_hdr, 0, sizeof(*net_hdr));
+ }
+ }
+
+ /* Beginning of each packet. */
+ if (vring->pkt_len == 0) {
+ int vdev_id, vring_change = 0;
+ union tmfifo_msg_hdr hdr;
+
+ num_avail--;
+
+ /* Read/Write packet length. */
+ if (is_rx) {
+ hdr.data = readq(fifo->rx_base +
+ TMFIFO_RX_DATA);
+ hdr.data = le64_to_cpu(hdr.data);
+
+ /* Skip the length 0 packet (keepalive). */
+ if (hdr.len == 0)
+ continue;
+
+ /* Check packet type. */
+ if (hdr.type == VIRTIO_ID_NET) {
+ vdev_id = VIRTIO_ID_NET;
+ hdr_len = sizeof(struct virtio_net_hdr);
+ } else if (hdr.type == VIRTIO_ID_CONSOLE) {
+ vdev_id = VIRTIO_ID_CONSOLE;
+ hdr_len = 0;
+ } else {
+ continue;
+ }
+
+ /*
+ * Check whether the new packet still belongs
+ * to this vring or not. If not, update the
+ * pkt_len of the new vring and return.
+ */
+ if (vdev_id != vring->vdev_id) {
+ struct tmfifo_vdev *dev2 =
+ fifo->vdev[vdev_id];
+
+ if (!dev2)
+ break;
+ vring->desc = desc;
+ vring = &dev2->vrings[TMFIFO_VRING_RX];
+ vring_change = 1;
+ }
+ vring->pkt_len = ntohs(hdr.len) + hdr_len;
+ } else {
+ vring->pkt_len = tmfifo_virtio_get_pkt_len(
+ vdev, desc, vr);
+
+ hdr.data = 0;
+ hdr.type = (vring->vdev_id == VIRTIO_ID_NET) ?
+ VIRTIO_ID_NET :
+ VIRTIO_ID_CONSOLE;
+ hdr.len = htons(vring->pkt_len - hdr_len);
+ writeq(cpu_to_le64(hdr.data),
+ fifo->tx_base + TMFIFO_TX_DATA);
+ }
+
+ vring->cur_len = hdr_len;
+ vring->rem_len = vring->pkt_len;
+ fifo->vring[is_rx] = vring;
+
+ if (vring_change)
+ return;
+ continue;
+ }
+
+ /* Check available space in this desc. */
+ len = virtio32_to_cpu(vdev, desc->len);
+ if (len > vring->rem_len)
+ len = vring->rem_len;
+
+ /* Check if the current desc is already done. */
+ if (vring->cur_len == len)
+ goto check_done;
+
+ addr = phys_to_virt(virtio64_to_cpu(vdev, desc->addr));
+
+ /* Read a word from FIFO for Rx. */
+ if (is_rx) {
+ data = readq(fifo->rx_base + TMFIFO_RX_DATA);
+ data = le64_to_cpu(data);
+ }
+
+ if (vring->cur_len + sizeof(u64) <= len) {
+ /* The whole word. */
+ if (is_rx) {
+ memcpy(addr + vring->cur_len, &data,
+ sizeof(u64));
+ } else {
+ memcpy(&data, addr + vring->cur_len,
+ sizeof(u64));
+ }
+ vring->cur_len += sizeof(u64);
+ } else {
+ /* Leftover bytes. */
+ BUG_ON(vring->cur_len > len);
+ if (is_rx) {
+ memcpy(addr + vring->cur_len, &data,
+ len - vring->cur_len);
+ } else {
+ memcpy(&data, addr + vring->cur_len,
+ len - vring->cur_len);
+ }
+ vring->cur_len = len;
+ }
+
+ /* Write the word into FIFO for Tx. */
+ if (!is_rx) {
+ writeq(cpu_to_le64(data),
+ fifo->tx_base + TMFIFO_TX_DATA);
+ }
+
+ num_avail--;
+
+check_done:
+ /* Check whether this desc is full or completed. */
+ if (vring->cur_len == len) {
+ vring->cur_len = 0;
+ vring->rem_len -= len;
+
+ /* Get the next desc on the chain. */
+ if (vring->rem_len > 0 &&
+ (virtio16_to_cpu(vdev, desc->flags) &
+ VRING_DESC_F_NEXT)) {
+ idx = virtio16_to_cpu(vdev, desc->next);
+ desc = &vr->desc[idx];
+ continue;
+ }
+
+ /* Done and release the desc. */
+ tmfifo_release_pkt(vdev, vring, &desc);
+ fifo->vring[is_rx] = NULL;
+
+ /* Notify upper layer that packet is done. */
+ spin_lock_irqsave(&tmfifo_spin_lock, flags);
+ vring_interrupt(0, vq);
+ spin_unlock_irqrestore(&tmfifo_spin_lock, flags);
+ continue;
+ }
+ }
+
+ /* Save the current desc. */
+ vring->desc = desc;
+}
+
+/* The notify function is called when new buffers are posted. */
+static bool tmfifo_virtio_notify(struct virtqueue *vq)
+{
+ struct tmfifo_vring *vring = (struct tmfifo_vring *)vq->priv;
+ struct tmfifo *fifo = vring->fifo;
+ unsigned long flags;
+
+ /*
+ * Virtio maintains vrings in pairs, even number ring for Rx
+ * and odd number ring for Tx.
+ */
+ if (!(vring->id & 1)) {
+ /* Set the RX HWM bit to start Rx. */
+ if (!test_and_set_bit(TM_RX_HWM_IRQ, &fifo->pend_events))
+ schedule_work(&fifo->work);
+ } else {
+ /*
+ * Console could make blocking call with interrupts disabled.
+ * In such case, the vring needs to be served right away. For
+ * other cases, just set the TX LWM bit to start Tx in the
+ * worker handler.
+ */
+ if (vring->vdev_id == VIRTIO_ID_CONSOLE) {
+ spin_lock_irqsave(&tmfifo_spin_lock, flags);
+ tmfifo_console_output(fifo->vdev[VIRTIO_ID_CONSOLE],
+ vq);
+ spin_unlock_irqrestore(&tmfifo_spin_lock, flags);
+ schedule_work(&fifo->work);
+ } else if (!test_and_set_bit(TM_TX_LWM_IRQ, &fifo->pend_events))
+ schedule_work(&fifo->work);
+ }
+
+ return true;
+}
+
+/* Get the array of feature bits for this device. */
+static u64 tmfifo_virtio_get_features(struct virtio_device *vdev)
+{
+ struct tmfifo_vdev *tm_vdev = container_of(vdev, struct tmfifo_vdev,
+ vdev);
+
+ return tm_vdev->features;
+}
+
+/* Confirm device features to use. */
+static int tmfifo_virtio_finalize_features(struct virtio_device *vdev)
+{
+ struct tmfifo_vdev *tm_vdev = container_of(vdev, struct tmfifo_vdev,
+ vdev);
+
+ tm_vdev->features = vdev->features;
+ return 0;
+}
+
+/* Free virtqueues found by find_vqs(). */
+static void tmfifo_virtio_del_vqs(struct virtio_device *vdev)
+{
+ int i;
+ struct tmfifo_vring *vring;
+ struct virtqueue *vq;
+ struct tmfifo_vdev *tm_vdev = container_of(vdev, struct tmfifo_vdev,
+ vdev);
+
+ for (i = 0; i < ARRAY_SIZE(tm_vdev->vrings); i++) {
+ vring = &tm_vdev->vrings[i];
+
+ /* Release the pending packet. */
+ if (vring->desc != NULL)
+ tmfifo_release_pkt(&tm_vdev->vdev, vring, &vring->desc);
+
+ vq = vring->vq;
+ if (vq) {
+ vring->vq = NULL;
+ vring_del_virtqueue(vq);
+ }
+ }
+}
+
+/* Create and initialize the virtual queues. */
+static int tmfifo_virtio_find_vqs(struct virtio_device *vdev,
+ unsigned int nvqs,
+ struct virtqueue *vqs[],
+ vq_callback_t *callbacks[],
+ const char * const names[],
+ const bool *ctx,
+ struct irq_affinity *desc)
+{
+ int i, ret = -EINVAL, size;
+ struct tmfifo_vring *vring;
+ struct virtqueue *vq;
+ struct tmfifo_vdev *tm_vdev = container_of(vdev, struct tmfifo_vdev,
+ vdev);
+
+ if (nvqs > ARRAY_SIZE(tm_vdev->vrings))
+ return -EINVAL;
+
+ for (i = 0; i < nvqs; ++i) {
+ if (!names[i])
+ goto error;
+ vring = &tm_vdev->vrings[i];
+
+ /* zero vring */
+ size = vring_size(vring->size, vring->align);
+ memset(vring->va, 0, size);
+ vq = vring_new_virtqueue(i, vring->size, vring->align, vdev,
+ false, false, vring->va,
+ tmfifo_virtio_notify,
+ callbacks[i], names[i]);
+ if (!vq) {
+ dev_err(&vdev->dev, "vring_new_virtqueue failed\n");
+ ret = -ENOMEM;
+ goto error;
+ }
+
+ vqs[i] = vq;
+ vring->vq = vq;
+ vq->priv = vring;
+ }
+
+ return 0;
+
+error:
+ tmfifo_virtio_del_vqs(vdev);
+ return ret;
+}
+
+/* Read the status byte. */
+static u8 tmfifo_virtio_get_status(struct virtio_device *vdev)
+{
+ struct tmfifo_vdev *tm_vdev = container_of(vdev, struct tmfifo_vdev,
+ vdev);
+
+ return tm_vdev->status;
+}
+
+/* Write the status byte. */
+static void tmfifo_virtio_set_status(struct virtio_device *vdev, u8 status)
+{
+ struct tmfifo_vdev *tm_vdev = container_of(vdev, struct tmfifo_vdev,
+ vdev);
+
+ tm_vdev->status = status;
+}
+
+/* Reset the device. Not much here for now. */
+static void tmfifo_virtio_reset(struct virtio_device *vdev)
+{
+ struct tmfifo_vdev *tm_vdev = container_of(vdev, struct tmfifo_vdev,
+ vdev);
+
+ tm_vdev->status = 0;
+}
+
+/* Read the value of a configuration field. */
+static void tmfifo_virtio_get(struct virtio_device *vdev,
+ unsigned int offset,
+ void *buf,
+ unsigned int len)
+{
+ struct tmfifo_vdev *tm_vdev = container_of(vdev, struct tmfifo_vdev,
+ vdev);
+
+ if (offset + len > sizeof(tm_vdev->config) || offset + len < len) {
+ dev_err(vdev->dev.parent, "virtio_get access out of bounds\n");
+ return;
+ }
+
+ memcpy(buf, (u8 *)&tm_vdev->config + offset, len);
+}
+
+/* Write the value of a configuration field. */
+static void tmfifo_virtio_set(struct virtio_device *vdev,
+ unsigned int offset,
+ const void *buf,
+ unsigned int len)
+{
+ struct tmfifo_vdev *tm_vdev = container_of(vdev, struct tmfifo_vdev,
+ vdev);
+
+ if (offset + len > sizeof(tm_vdev->config) || offset + len < len) {
+ dev_err(vdev->dev.parent, "virtio_get access out of bounds\n");
+ return;
+ }
+
+ memcpy((u8 *)&tm_vdev->config + offset, buf, len);
+}
+
+/* Virtio config operations. */
+static const struct virtio_config_ops tmfifo_virtio_config_ops = {
+ .get_features = tmfifo_virtio_get_features,
+ .finalize_features = tmfifo_virtio_finalize_features,
+ .find_vqs = tmfifo_virtio_find_vqs,
+ .del_vqs = tmfifo_virtio_del_vqs,
+ .reset = tmfifo_virtio_reset,
+ .set_status = tmfifo_virtio_set_status,
+ .get_status = tmfifo_virtio_get_status,
+ .get = tmfifo_virtio_get,
+ .set = tmfifo_virtio_set,
+};
+
+/* Create vdev type in a tmfifo. */
+int tmfifo_create_vdev(struct tmfifo *fifo, int vdev_id, u64 features,
+ void *config, u32 size)
+{
+ struct tmfifo_vdev *tm_vdev;
+ int ret = 0;
+
+ mutex_lock(&fifo->lock);
+
+ tm_vdev = fifo->vdev[vdev_id];
+ if (tm_vdev != NULL) {
+ pr_err("vdev %d already exists\n", vdev_id);
+ ret = -EEXIST;
+ goto already_exist;
+ }
+
+ tm_vdev = kzalloc(sizeof(*tm_vdev), GFP_KERNEL);
+ if (!tm_vdev) {
+ ret = -ENOMEM;
+ goto already_exist;
+ }
+
+ tm_vdev->vdev.id.device = vdev_id;
+ tm_vdev->vdev.config = &tmfifo_virtio_config_ops;
+ tm_vdev->vdev.dev.parent = &fifo->pdev->dev;
+ tm_vdev->vdev.dev.release = tmfifo_virtio_dev_release;
+ tm_vdev->features = features;
+ if (config)
+ memcpy(&tm_vdev->config, config, size);
+ if (tmfifo_alloc_vrings(fifo, tm_vdev, vdev_id)) {
+ pr_err("Unable to allocate vring\n");
+ ret = -ENOMEM;
+ goto alloc_vring_fail;
+ }
+ if (vdev_id == VIRTIO_ID_CONSOLE) {
+ tm_vdev->tx_buf = kmalloc(TMFIFO_CONS_TX_BUF_SIZE,
+ GFP_KERNEL);
+ }
+ fifo->vdev[vdev_id] = tm_vdev;
+
+ /* Register the virtio device. */
+ ret = register_virtio_device(&tm_vdev->vdev);
+ if (ret) {
+ dev_err(&fifo->pdev->dev, "register_virtio_device() failed\n");
+ goto register_fail;
+ }
+
+ mutex_unlock(&fifo->lock);
+ return 0;
+
+register_fail:
+ tmfifo_free_vrings(fifo, vdev_id);
+ fifo->vdev[vdev_id] = NULL;
+alloc_vring_fail:
+ kfree(tm_vdev);
+already_exist:
+ mutex_unlock(&fifo->lock);
+ return ret;
+}
+
+/* Delete vdev type from a tmfifo. */
+int tmfifo_delete_vdev(struct tmfifo *fifo, int vdev_id)
+{
+ struct tmfifo_vdev *tm_vdev;
+
+ mutex_lock(&fifo->lock);
+
+ /* Unregister vdev. */
+ tm_vdev = fifo->vdev[vdev_id];
+ if (tm_vdev) {
+ unregister_virtio_device(&tm_vdev->vdev);
+ tmfifo_free_vrings(fifo, vdev_id);
+ kfree(tm_vdev->tx_buf);
+ kfree(tm_vdev);
+ fifo->vdev[vdev_id] = NULL;
+ }
+
+ mutex_unlock(&fifo->lock);
+
+ return 0;
+}
+
+/* Device remove function. */
+static int tmfifo_remove(struct platform_device *pdev)
+{
+ int i;
+ struct tmfifo *fifo = platform_get_drvdata(pdev);
+ struct resource *rx_res, *tx_res;
+
+ tmfifo_ready = false;
+
+ if (fifo) {
+ mutex_lock(&tmfifo_lock);
+
+ /* Stop the timer. */
+ del_timer_sync(&fifo->timer);
+
+ /* Release interrupts. */
+ tmfifo_free_irqs(fifo);
+
+ /* Cancel the pending work. */
+ cancel_work_sync(&fifo->work);
+
+ for (i = 0; i < TMFIFO_VDEV_MAX; i++)
+ tmfifo_delete_vdev(fifo, i);
+
+ /* Release IO resources. */
+ if (fifo->rx_base)
+ iounmap(fifo->rx_base);
+ if (fifo->tx_base)
+ iounmap(fifo->tx_base);
+
+ platform_set_drvdata(pdev, NULL);
+ kfree(fifo);
+
+ mutex_unlock(&tmfifo_lock);
+ }
+
+ rx_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (rx_res)
+ release_mem_region(rx_res->start, resource_size(rx_res));
+ tx_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (tx_res)
+ release_mem_region(tx_res->start, resource_size(tx_res));
+
+ return 0;
+}
+
+/* Read the configured network MAC address from efi variable. */
+static void tmfifo_get_cfg_mac(u8 *mac)
+{
+ u8 buf[6];
+ efi_status_t status;
+ unsigned long size = sizeof(buf);
+ efi_char16_t name[] = { 'R', 's', 'h', 'i', 'm', 'M', 'a', 'c',
+ 'A', 'd', 'd', 'r', 0 };
+ efi_guid_t guid = EFI_GLOBAL_VARIABLE_GUID;
+
+ status = efi.get_variable(name, &guid, NULL, &size, buf);
+ if (status == EFI_SUCCESS && size == sizeof(buf))
+ memcpy(mac, buf, sizeof(buf));
+}
+
+/* Probe the TMFIFO. */
+static int tmfifo_probe(struct platform_device *pdev)
+{
+ u64 ctl;
+ struct tmfifo *fifo;
+ struct resource *rx_res, *tx_res;
+ struct virtio_net_config net_config;
+ int i, ret;
+
+ /* Get the resource of the Rx & Tx FIFO. */
+ rx_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ tx_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!rx_res || !tx_res) {
+ ret = -EINVAL;
+ goto err;
+ }
+
+ if (request_mem_region(rx_res->start,
+ resource_size(rx_res), "bf-tmfifo") == NULL) {
+ ret = -EBUSY;
+ goto early_err;
+ }
+
+ if (request_mem_region(tx_res->start,
+ resource_size(tx_res), "bf-tmfifo") == NULL) {
+ release_mem_region(rx_res->start, resource_size(rx_res));
+ ret = -EBUSY;
+ goto early_err;
+ }
+
+ ret = -ENOMEM;
+ fifo = kzalloc(sizeof(struct tmfifo), GFP_KERNEL);
+ if (!fifo)
+ goto err;
+
+ fifo->pdev = pdev;
+ platform_set_drvdata(pdev, fifo);
+
+ INIT_WORK(&fifo->work, tmfifo_work_handler);
+
+ timer_setup(&fifo->timer, tmfifo_timer, 0);
+ fifo->timer.function = tmfifo_timer;
+
+ for (i = 0; i < TM_IRQ_CNT; i++) {
+ fifo->irq[i] = platform_get_irq(pdev, i);
+ ret = request_irq(fifo->irq[i], tmfifo_irq_handler, 0,
+ "tmfifo", (u8 *)fifo + i);
+ if (ret) {
+ pr_err("Unable to request irq\n");
+ fifo->irq[i] = 0;
+ goto err;
+ }
+ }
+
+ fifo->rx_base = ioremap(rx_res->start, resource_size(rx_res));
+ if (!fifo->rx_base)
+ goto err;
+
+ fifo->tx_base = ioremap(tx_res->start, resource_size(tx_res));
+ if (!fifo->tx_base)
+ goto err;
+
+ /* Get Tx FIFO size and set the low/high watermark. */
+ ctl = readq(fifo->tx_base + TMFIFO_TX_CTL);
+ fifo->tx_fifo_size =
+ TMFIFO_GET_FIELD(ctl, TMFIFO_TX_CTL__MAX_ENTRIES_MASK);
+ ctl = TMFIFO_SET_FIELD(ctl, TMFIFO_TX_CTL__LWM_MASK,
+ fifo->tx_fifo_size / 2);
+ ctl = TMFIFO_SET_FIELD(ctl, TMFIFO_TX_CTL__HWM_MASK,
+ fifo->tx_fifo_size - 1);
+ writeq(ctl, fifo->tx_base + TMFIFO_TX_CTL);
+
+ /* Get Rx FIFO size and set the low/high watermark. */
+ ctl = readq(fifo->rx_base + TMFIFO_RX_CTL);
+ fifo->rx_fifo_size =
+ TMFIFO_GET_FIELD(ctl, TMFIFO_RX_CTL__MAX_ENTRIES_MASK);
+ ctl = TMFIFO_SET_FIELD(ctl, TMFIFO_RX_CTL__LWM_MASK, 0);
+ ctl = TMFIFO_SET_FIELD(ctl, TMFIFO_RX_CTL__HWM_MASK, 1);
+ writeq(ctl, fifo->rx_base + TMFIFO_RX_CTL);
+
+ mutex_init(&fifo->lock);
+
+ /* Create the console vdev. */
+ ret = tmfifo_create_vdev(fifo, VIRTIO_ID_CONSOLE, 0, NULL, 0);
+ if (ret)
+ goto err;
+
+ /* Create the network vdev. */
+ memset(&net_config, 0, sizeof(net_config));
+ net_config.mtu = TMFIFO_NET_MTU;
+ net_config.status = VIRTIO_NET_S_LINK_UP;
+ memcpy(net_config.mac, tmfifo_net_default_mac, 6);
+ tmfifo_get_cfg_mac(net_config.mac);
+ ret = tmfifo_create_vdev(fifo, VIRTIO_ID_NET, TMFIFO_NET_FEATURES,
+ &net_config, sizeof(net_config));
+ if (ret)
+ goto err;
+
+ mod_timer(&fifo->timer, jiffies + tmfifo_timer_interval);
+
+ tmfifo_ready = true;
+
+ return 0;
+
+err:
+ tmfifo_remove(pdev);
+early_err:
+ dev_err(&pdev->dev, "Probe Failed\n");
+ return ret;
+}
+
+static const struct of_device_id tmfifo_match[] = {
+ { .compatible = "mellanox,bf-tmfifo" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, tmfifo_match);
+
+static const struct acpi_device_id bf_tmfifo_acpi_match[] = {
+ { "MLNXBF01", 0 },
+ {},
+};
+MODULE_DEVICE_TABLE(acpi, bf_tmfifo_acpi_match);
+
+static struct platform_driver tmfifo_driver = {
+ .probe = tmfifo_probe,
+ .remove = tmfifo_remove,
+ .driver = {
+ .name = "bf-tmfifo",
+ .of_match_table = tmfifo_match,
+ .acpi_match_table = ACPI_PTR(bf_tmfifo_acpi_match),
+ },
+};
+
+static int __init tmfifo_init(void)
+{
+ int ret;
+
+ mutex_init(&tmfifo_lock);
+
+ ret = platform_driver_register(&tmfifo_driver);
+ if (ret)
+ pr_err("Failed to register tmfifo driver.\n");
+
+ return ret;
+}
+
+static void __exit tmfifo_exit(void)
+{
+ platform_driver_unregister(&tmfifo_driver);
+}
+
+module_init(tmfifo_init);
+module_exit(tmfifo_exit);
+
+MODULE_DESCRIPTION("Mellanox BlueField SoC TMFIFO Driver");
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Mellanox Technologies");
diff --git a/drivers/soc/mellanox/tmfifo_regs.h b/drivers/soc/mellanox/tmfifo_regs.h
new file mode 100644
index 0000000..f42c9d6
--- /dev/null
+++ b/drivers/soc/mellanox/tmfifo_regs.h
@@ -0,0 +1,75 @@
+/*
+ * Copyright (c) 2018, Mellanox Technologies. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ */
+
+#ifndef __TMFIFO_REGS_H__
+#define __TMFIFO_REGS_H__
+
+#include <linux/types.h>
+
+#define TMFIFO_TX_DATA 0x0
+
+#define TMFIFO_TX_STS 0x8
+#define TMFIFO_TX_STS__LENGTH 0x0001
+#define TMFIFO_TX_STS__COUNT_SHIFT 0
+#define TMFIFO_TX_STS__COUNT_WIDTH 9
+#define TMFIFO_TX_STS__COUNT_RESET_VAL 0
+#define TMFIFO_TX_STS__COUNT_RMASK 0x1ff
+#define TMFIFO_TX_STS__COUNT_MASK 0x1ff
+
+#define TMFIFO_TX_CTL 0x10
+#define TMFIFO_TX_CTL__LENGTH 0x0001
+#define TMFIFO_TX_CTL__LWM_SHIFT 0
+#define TMFIFO_TX_CTL__LWM_WIDTH 8
+#define TMFIFO_TX_CTL__LWM_RESET_VAL 128
+#define TMFIFO_TX_CTL__LWM_RMASK 0xff
+#define TMFIFO_TX_CTL__LWM_MASK 0xff
+#define TMFIFO_TX_CTL__HWM_SHIFT 8
+#define TMFIFO_TX_CTL__HWM_WIDTH 8
+#define TMFIFO_TX_CTL__HWM_RESET_VAL 128
+#define TMFIFO_TX_CTL__HWM_RMASK 0xff
+#define TMFIFO_TX_CTL__HWM_MASK 0xff00
+#define TMFIFO_TX_CTL__MAX_ENTRIES_SHIFT 32
+#define TMFIFO_TX_CTL__MAX_ENTRIES_WIDTH 9
+#define TMFIFO_TX_CTL__MAX_ENTRIES_RESET_VAL 256
+#define TMFIFO_TX_CTL__MAX_ENTRIES_RMASK 0x1ff
+#define TMFIFO_TX_CTL__MAX_ENTRIES_MASK 0x1ff00000000ULL
+
+#define TMFIFO_RX_DATA 0x0
+
+#define TMFIFO_RX_STS 0x8
+#define TMFIFO_RX_STS__LENGTH 0x0001
+#define TMFIFO_RX_STS__COUNT_SHIFT 0
+#define TMFIFO_RX_STS__COUNT_WIDTH 9
+#define TMFIFO_RX_STS__COUNT_RESET_VAL 0
+#define TMFIFO_RX_STS__COUNT_RMASK 0x1ff
+#define TMFIFO_RX_STS__COUNT_MASK 0x1ff
+
+#define TMFIFO_RX_CTL 0x10
+#define TMFIFO_RX_CTL__LENGTH 0x0001
+#define TMFIFO_RX_CTL__LWM_SHIFT 0
+#define TMFIFO_RX_CTL__LWM_WIDTH 8
+#define TMFIFO_RX_CTL__LWM_RESET_VAL 128
+#define TMFIFO_RX_CTL__LWM_RMASK 0xff
+#define TMFIFO_RX_CTL__LWM_MASK 0xff
+#define TMFIFO_RX_CTL__HWM_SHIFT 8
+#define TMFIFO_RX_CTL__HWM_WIDTH 8
+#define TMFIFO_RX_CTL__HWM_RESET_VAL 128
+#define TMFIFO_RX_CTL__HWM_RMASK 0xff
+#define TMFIFO_RX_CTL__HWM_MASK 0xff00
+#define TMFIFO_RX_CTL__MAX_ENTRIES_SHIFT 32
+#define TMFIFO_RX_CTL__MAX_ENTRIES_WIDTH 9
+#define TMFIFO_RX_CTL__MAX_ENTRIES_RESET_VAL 256
+#define TMFIFO_RX_CTL__MAX_ENTRIES_RMASK 0x1ff
+#define TMFIFO_RX_CTL__MAX_ENTRIES_MASK 0x1ff00000000ULL
+
+#endif /* !defined(__TMFIFO_REGS_H__) */
--
1.8.3.1
^ permalink raw reply related
* RE: [PATCH v2 3/4] dt-bindings: soc: Add TmFifo binding for Mellanox BlueField SoC
From: Liming Sun @ 2018-06-01 14:31 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree@vger.kernel.org, David Woods, Arnd Bergmann,
Olof Johansson, Robin Murphy,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20180531034352.GA32666@rob-hp-laptop>
Thanks for the comments. Please see response inline.
> -----Original Message-----
> From: Rob Herring [mailto:robh@kernel.org]
> Sent: Wednesday, May 30, 2018 11:44 PM
> To: Liming Sun <lsun@mellanox.com>
> Cc: Olof Johansson <olof@lixom.net>; Arnd Bergmann <arnd@arndb.de>;
> David Woods <dwoods@mellanox.com>; Robin Murphy
> <robin.murphy@arm.com>; devicetree@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH v2 3/4] dt-bindings: soc: Add TmFifo binding for
> Mellanox BlueField SoC
>
> On Fri, May 25, 2018 at 04:17:15PM -0400, Liming Sun wrote:
>
> Commit msg?
Updated in patch v3 3/4.
>
> > Reviewed-by: David Woods <dwoods@mellanox.com>
> > Signed-off-by: Liming Sun <lsun@mellanox.com>
> > ---
> > .../devicetree/bindings/soc/mellanox/tmfifo.txt | 20
> ++++++++++++++++++++
> > 1 file changed, 20 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/soc/mellanox/tmfifo.txt
> >
> > diff --git a/Documentation/devicetree/bindings/soc/mellanox/tmfifo.txt
> b/Documentation/devicetree/bindings/soc/mellanox/tmfifo.txt
> > new file mode 100644
> > index 0000000..0a362f5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/soc/mellanox/tmfifo.txt
> > @@ -0,0 +1,20 @@
> > +* Mellanox BlueField SoC TmFifo
> > +
> > +BlueField TmFifo provides a shared FIFO between the target and the
> > +external host machine, which can be accessed via USB or PCIe.
>
> A FIFO for what? I'd like to find a better spot than bindings/soc/
This is a generic HW FIFO which can be accessed by the SoC SW and external Host machine to exchange any data. In the current Linux tmfifo driver, this FIFO has been used (demuxed) to implement a virtual console and network interface based on virtio framework.
Updated the tmfifo.txt in patch v3 3/4 with the above explanation. Please advise if there is a better place for this file.
> > +
> > +Required properties:
> > +
> > +- compatible: Should be "mellanox,bf-tmfifo"
> > +- reg: Physical base address and length of Rx/Tx block
> > +- interrupts: The interrupt number of Rx low water mark, Rx high water
> mark
> > + Tx low water mark, Tx high water mark respectively.
> > +
> > +Example:
> > +
> > +tmfifo@800a20 {
> > + compatible = "mellanox,bf-tmfifo";
> > + reg = <0x00800a20 0x00000018
> > + 0x00800a40 0x00000018>;
> > + interrupts = <41, 42, 43, 44>;
> > +};
> > --
> > 1.8.3.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: thermal: Add binding document for SR thermal
From: Rob Herring @ 2018-06-01 14:29 UTC (permalink / raw)
To: Srinath Mannam
Cc: Zhang Rui, Eduardo Valentin, Mark Rutland, devicetree,
linux-kernel@vger.kernel.org, BCM Kernel Feedback, Pramod Kumar
In-Reply-To: <CABe79T7=LK=PgaftQeCRE8kmMMztFBNeJ4cdnZhv8ULDO=6+Jw@mail.gmail.com>
On Fri, Jun 1, 2018 at 3:51 AM, Srinath Mannam
<srinath.mannam@broadcom.com> wrote:
> Hi Rob Herring,
>
> Thank you for the review.
> Please find my answers inline..
>
> On Thu, May 31, 2018 at 10:18 PM, Rob Herring <robh@kernel.org> wrote:
>> On Mon, May 28, 2018 at 11:11:22AM +0530, Srinath Mannam wrote:
>>> From: Pramod Kumar <pramod.kumar@broadcom.com>
>>>
>>> Add binding document for supported thermal implementation
>>> in Stingray.
>>>
>>> Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
>>> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
>>> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
>>> Reviewed-by: Srinath Mannam <srinath.mannam@broadcom.com>
>>> ---
>>> .../bindings/thermal/brcm,sr-thermal.txt | 45 ++++++++++++++++++++++
>>> 1 file changed, 45 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt b/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
>>> new file mode 100644
>>> index 0000000..33f9e11
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
>>> @@ -0,0 +1,45 @@
>>> +* Broadcom Stingray Thermal
>>> +
>>> +This binding describes thermal sensors that is part of Stingray SoCs.
>>> +
>>> +Required properties:
>>> +- compatible : Must be "brcm,sr-thermal"
>>> +- reg : memory where tmon data will be available.
>>
>> What type of memory is this?
> This is shared memory(cache-able) which is shared between two micro controllers.
What else is in this shared memory? You should probably be
representing that as a whole somewhere in DT.
> One micro controller update temperature of all thermal zones in this
> shared memory.
> thermal driver running on another micro controller monitors
> temperature data of all thermal zones.
>>
>>> +
>>> +Example:
>>> + tmons {
>>> + compatible = "simple-bus";
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + ranges;
>>> +
>>> + tmon_ihost0: thermal@8f100000 {
>>> + compatible = "brcm,sr-thermal";
>>> + reg = <0x8f100000 0x4>;
>>> + };
>>
>> Convince me that you need a node per register. This can all be
>> accomplished with a single node and either a single reg entry or a
>> series of reg entries.
>>
> In our system we have 6 different thermal zones. each node belongs to
> one thermal zone.
> thermal driver detects each node as separate thermal zone and monitors
> separately.
> register entry is only 4byte memory which contains the temperature
> value of respective thermal zone.
> Based on requirement we can increase or decrease the number thermal
> zones need to monitor.
Still, all this can be accomplished with a single node. Having a node
per register in DT doesn't scale.
Rob
^ permalink raw reply
* Re: [PATCH v2 3/6] clk: ti: dra7: Add clkctrl clock data for the mcan clocks
From: Tony Lindgren @ 2018-06-01 14:26 UTC (permalink / raw)
To: Faiz Abbas
Cc: Tero Kristo, Rob Herring, linux-kernel, devicetree, linux-omap,
linux-arm-kernel, linux-clk, bcousson, paul
In-Reply-To: <d7532c7a-d2ae-5cbf-cfd0-c347b975ed6b@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [180601 06:49]:
> Hi,
>
> On Thursday 31 May 2018 06:59 PM, Tero Kristo wrote:
> > On 31/05/18 13:14, Faiz Abbas wrote:
> >> Hi,
> >>
> >> On Thursday 31 May 2018 09:33 AM, Rob Herring wrote:
> >>> On Wed, May 30, 2018 at 07:41:30PM +0530, Faiz Abbas wrote:
> >>>> Add clkctrl data for the m_can clocks and register it within the
> >> ...
> >>>> diff --git a/include/dt-bindings/clock/dra7.h
> >>>> b/include/dt-bindings/clock/dra7.h
> >>>> index 5e1061b15aed..d7549c57cac3 100644
> >>>> --- a/include/dt-bindings/clock/dra7.h
> >>>> +++ b/include/dt-bindings/clock/dra7.h
> >>>> @@ -168,5 +168,6 @@
> >>>> #define DRA7_COUNTER_32K_CLKCTRL DRA7_CLKCTRL_INDEX(0x50)
> >>>> #define DRA7_UART10_CLKCTRL DRA7_CLKCTRL_INDEX(0x80)
> >>>> #define DRA7_DCAN1_CLKCTRL DRA7_CLKCTRL_INDEX(0x88)
> >>>> +#define DRA7_ADC_CLKCTRL DRA7_CLKCTRL_INDEX(0xa0)
> >>>
> >>> ADC and mcan are the same thing?
> >>>
> >>
> >> The register to control MCAN clocks is called ADC_CLKCTRL, Yes.
> >
> > Is there any reason for this or is that just a documentation bug?
> >
>
> Looks like they meant to have an ADC in dra74 or dra72 but decided
> against it and then many years later used the same registers for MCAN
> instead. You can see ADC_CLKCTRL exists in dra72 TRM but is explicitly
> disabled.
>
> http://www.ti.com/lit/ug/spruic2b/spruic2b.pdf pg:1524
How about make add also something like to dra7.h:
#define DRA7_MCAN_CLKCTRL DRA7_ADC_CLKCTRL
And you can add a comment to the dts file to avoid people
getting confused with this constantly.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 2/3] ASoC: simple-card: make sysclk index configurable
From: Rob Herring @ 2018-06-01 14:21 UTC (permalink / raw)
To: Daniel Mack
Cc: devicetree, Linux-ALSA, Mark Brown, Liam Girdwood,
Kuninori Morimoto
In-Reply-To: <d5df3c6b-22ae-408b-5727-516fed648b2a@zonque.org>
On Thu, May 31, 2018 at 3:03 PM, Daniel Mack <daniel@zonque.org> wrote:
> On Thursday, May 31, 2018 07:02 PM, Rob Herring wrote:
>>
>> On Tue, May 29, 2018 at 10:23:48PM +0200, Daniel Mack wrote:
>
>
>>> If that's the case, could you depict how the DT bindings should look like
>>> by
>>> example?
>>
>>
>> In clock providers, you just add #clock-cells. Then the consumer side
>> defines 'clocks'. Which clock(s) comes from the dai is defined by the
>> index in the 'clocks' property for that node.
>>
>> Both ends can be providers, but who is active is determined by defining
>> the actual connections with 'clocks'. Or perhaps you have both
>> directions shown and there is some other means to select which one is
>> active such as solving for who can provide the desired freq.
>
>
> How about entities that are a clock producer and consume their clocks
> themselves? That's a rather typical thing for DAIs. Is that expressible in
> DT?
And I assume something else consumes those clocks, too? If not, you
can just handle all that within the driver and don't need the clock
binding or clock framework.
But yes, you can do something like this:
myclk: clock-controller {
#clock-cells = <1>;
clocks = <&myclk 123>, <&otherclk 1>;
};
You'll have to handle clk registration and clk_get in the right order
to avoid deferring probe on yourself.
Rob
^ permalink raw reply
* Re: [PATCH] Input: of_touchscreen / generic bindings - Add support for touchscreen-min-x|y
From: Rob Herring @ 2018-06-01 14:15 UTC (permalink / raw)
To: Hans de Goede
Cc: Dmitry Torokhov, Benjamin Tissoires, devicetree, linux-input
In-Reply-To: <66774364-2f51-e326-651f-f3beee7837e1@redhat.com>
On Thu, May 31, 2018 at 3:42 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 31-05-18 19:25, Rob Herring wrote:
>>
>> On Tue, May 29, 2018 at 01:52:38PM +0200, Hans de Goede wrote:
>>>
>>> Some touchscreens, depending on the firmware and/or the digitizer report
>>> coordinates which never reach 0 along one or both of their axis.
>>>
>>> This has been seen for example on the Silead touchscreens on a Onda V891w
>>> and a Point of View mobii TAB-P800w(v2.0).
>>>
>>> This commit adds support for touchscreen-min-x and touchscreen-min-y
>>> device-properties which can be set to communicate the actual start
>>> coordinates (rather then 0,0) to userspace.
>>>
>>> When set this fixes e.g. not being able to click things in the GNOME3
>>> top-bar on the 2 example tablets.
>>>
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>> ---
>>> .../input/touchscreen/touchscreen.txt | 6 ++--
>>
>>
>> Please split bindings to separate patch.
>
>
> Will do for v2.
>
>>> drivers/input/touchscreen/of_touchscreen.c | 36 ++++++++++++++-----
>>> 2 files changed, 32 insertions(+), 10 deletions(-)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>>> b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>>> index 537643e86f61..8aff9551259f 100644
>>> --- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>>> +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>>> @@ -1,10 +1,12 @@
>>> General Touchscreen Properties:
>>> Optional properties for Touchscreens:
>>> + - touchscreen-min-x : minimum x coordinate reported (0 if not
>>> set)
>>> + - touchscreen-min-y : minimum y coordinate reported (0 if not
>>> set)
>>
>>
>> Maybe a min-max range would be better if size (in pixels) is also
>> needed?
>
>
> Size in pixels is never needed. The touchscreen-size-x /
> touchscreen-size-y have always been the max x/y coordinate reported + 1
> and may or may not have anything to do with pixels. I've noticed on
> some ARM tablets that the firmware in the touchscreen controller was
> programmed to send coordinates in the same range as the display
> resolution, but then the manufacturer would turn around, put in
> a higher res display and keep the same touchscreen range (or the
> otherway around). So it seems that there has been a 1:1 mapping on
> some devices, but that has not been true for a long time now.
>
>>> - touchscreen-size-x : horizontal resolution of touchscreen
>>> - (in pixels)
>>> + (maximum x coordinate reported + 1)
>>
>>
>> This is unrelated or at least not explained in the commit msg. I agree
>> this probably makes sense as units are often not pixels unless the hw/fw
>> is doing some scaling itself.
>
>
> Right I added this fix to make clear that we are indeed specifying a
> min-max range, with the oddity that instead of max we specify max + 1
> for historical reasons.
>
> Do you want me to split this out into a separate patch?
No, just some explanation in this one is fine.
Rob
^ permalink raw reply
* Re: [PATCH v3 1/6] mtd: rawnand: add Reed-Solomon error correction algorithm
From: Boris Brezillon @ 2018-06-01 13:43 UTC (permalink / raw)
To: Stefan Agner
Cc: mark.rutland, devicetree, pgaikwad, dev, mirza.krak,
benjamin.lindqvist, pdeschrijver, miquel.raynal, linux-kernel,
robh+dt, jonathanh, marek.vasut, thierry.reding, linux-mtd, krzk,
richard, linux-tegra, digetx, computersforpeace, dwmw2, marcel
In-Reply-To: <18ce3100aabf42059dbd514fb8c93e84@agner.ch>
On Fri, 01 Jun 2018 15:34:33 +0200
Stefan Agner <stefan@agner.ch> wrote:
> On 01.06.2018 11:25, Boris Brezillon wrote:
> > On Fri, 1 Jun 2018 09:26:00 +0200
> > Boris Brezillon <boris.brezillon@bootlin.com> wrote:
> >
> >> On Fri, 1 Jun 2018 00:16:32 +0200
> >> Stefan Agner <stefan@agner.ch> wrote:
> >>
> >> > Add Reed-Solomon (RS) to the enumeration of ECC algorithms.
> >> >
> >> > Signed-off-by: Stefan Agner <stefan@agner.ch>
> >>
> >> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
> >>
> >> > ---
> >> > drivers/mtd/nand/raw/nand_base.c | 1 +
> >> > include/linux/mtd/rawnand.h | 1 +
> >
> > Hm, you forgot to update Documentation/devicetree/bindings/mtd/nand.txt.
> >
>
> Yeah I was not sure about that. Currently it says:
>
> - nand-ecc-algo: string, algorithm of NAND ECC.
>
> Supported values are: "hamming", "bch".
>
> Is supported meant by software ECC here? I feel "supported" is a rather
> strong word since it is clearly controller dependent whether it is
> actually supported...
I guess "valid values" or "accepted values" would be more appropriate
here.
^ permalink raw reply
* Re: [PATCH v3 1/6] mtd: rawnand: add Reed-Solomon error correction algorithm
From: Stefan Agner @ 2018-06-01 13:34 UTC (permalink / raw)
To: Boris Brezillon
Cc: mark.rutland, devicetree, pgaikwad, dev, mirza.krak,
benjamin.lindqvist, pdeschrijver, miquel.raynal, linux-kernel,
robh+dt, jonathanh, marek.vasut, thierry.reding, linux-mtd, krzk,
richard, linux-tegra, digetx, computersforpeace, dwmw2, marcel
In-Reply-To: <20180601112506.2157e8b0@bbrezillon>
On 01.06.2018 11:25, Boris Brezillon wrote:
> On Fri, 1 Jun 2018 09:26:00 +0200
> Boris Brezillon <boris.brezillon@bootlin.com> wrote:
>
>> On Fri, 1 Jun 2018 00:16:32 +0200
>> Stefan Agner <stefan@agner.ch> wrote:
>>
>> > Add Reed-Solomon (RS) to the enumeration of ECC algorithms.
>> >
>> > Signed-off-by: Stefan Agner <stefan@agner.ch>
>>
>> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
>>
>> > ---
>> > drivers/mtd/nand/raw/nand_base.c | 1 +
>> > include/linux/mtd/rawnand.h | 1 +
>
> Hm, you forgot to update Documentation/devicetree/bindings/mtd/nand.txt.
>
Yeah I was not sure about that. Currently it says:
- nand-ecc-algo: string, algorithm of NAND ECC.
Supported values are: "hamming", "bch".
Is supported meant by software ECC here? I feel "supported" is a rather
strong word since it is clearly controller dependent whether it is
actually supported...
--
Stefan
>> > 2 files changed, 2 insertions(+)
>> >
>> > diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
>> > index f28c3a555861..9eb5678dd6d0 100644
>> > --- a/drivers/mtd/nand/raw/nand_base.c
>> > +++ b/drivers/mtd/nand/raw/nand_base.c
>> > @@ -5744,6 +5744,7 @@ static int of_get_nand_ecc_mode(struct device_node *np)
>> > static const char * const nand_ecc_algos[] = {
>> > [NAND_ECC_HAMMING] = "hamming",
>> > [NAND_ECC_BCH] = "bch",
>> > + [NAND_ECC_RS] = "rs",
>> > };
>> >
>> > static int of_get_nand_ecc_algo(struct device_node *np)
>> > diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
>> > index 5dad59b31244..6a82da8c44ce 100644
>> > --- a/include/linux/mtd/rawnand.h
>> > +++ b/include/linux/mtd/rawnand.h
>> > @@ -114,6 +114,7 @@ enum nand_ecc_algo {
>> > NAND_ECC_UNKNOWN,
>> > NAND_ECC_HAMMING,
>> > NAND_ECC_BCH,
>> > + NAND_ECC_RS,
>> > };
>> >
>> > /*
>>
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v9 01/15] ARM: Add Krait L2 register accessor functions
From: Sricharan R @ 2018-06-01 13:20 UTC (permalink / raw)
To: Stephen Boyd, Bjorn Andersson
Cc: robh, viresh.kumar, mark.rutland, mturquette, sboyd, linux,
andy.gross, david.brown, rjw, linux-arm-kernel, devicetree,
linux-kernel, linux-clk, linux-arm-msm, linux-soc, linux-pm,
linux
In-Reply-To: <152775249799.144038.9269415086304305030@swboyd.mtv.corp.google.com>
Hi Stephen,
On 5/31/2018 1:11 PM, Stephen Boyd wrote:
> Quoting Sricharan R (2018-05-30 21:57:20)
>> Hi Stephen,
>>
>> On 5/30/2018 9:25 PM, Stephen Boyd wrote:
>>> Quoting Sricharan R (2018-05-24 22:40:11)
>>>> Hi Bjorn,
>>>>
>>>> On 5/24/2018 11:09 PM, Bjorn Andersson wrote:
>>>>> On Tue 06 Mar 06:38 PST 2018, Sricharan R wrote:
>>>>>
>>>>>> From: Stephen Boyd <sboyd@codeaurora.org>
>>>>>>
>>>>>> Krait CPUs have a handful of L2 cache controller registers that
>>>>>> live behind a cp15 based indirection register. First you program
>>>>>> the indirection register (l2cpselr) to point the L2 'window'
>>>>>> register (l2cpdr) at what you want to read/write. Then you
>>>>>> read/write the 'window' register to do what you want. The
>>>>>> l2cpselr register is not banked per-cpu so we must lock around
>>>>>> accesses to it to prevent other CPUs from re-pointing l2cpdr
>>>>>> underneath us.
>>>>>>
>>>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>>>> Cc: Russell King <linux@arm.linux.org.uk>
>>>>>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>>>>>
>>>>> This should have your signed-off-by here as well.
>>>>>
>>>>
>>>> ok.
>>>>
>>>>> Apart from that:
>>>>>
>>>>> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>>>>>
>>>>
>>>
>>> Will these patches come around again? I'll do a quick sweep on them
>>> today but I expect them to be resent.
>>
>> Sure, i will have to resend them again, fixing couple of Bjorn's
>> minor comments. Will address your comments that you would give
>> as well along with that.
>>
>
> Ok. One general comment is that it would be nice if the bindings for all
> the nodes that are introduced included 'clocks' properties and also
> maybe 'clock-names' properties for the clocks that are consumed by each
> node. Right now, we hide those details from DT and rely on the string
> names to hook the clk tree up for us. That sort of prevents us from
> moving away from string easily, so I would just throw the clocks into
> the binding right now and always have them there just in case we want to
> use the binding to figure out the hierarchy in the future.
>
ok, understand that mostly. So will try to revamp those patches with
the 'clocks' property in the binding added, reading them in the driver
from DT.
> I've been thinking we need to do something similar for the gcc and other
> nodes for any clks they use, but I haven't gotten around to it.
>
> Otherwise the patches look mostly ok to me. Not sure I'll have any other
> comments.
>
Thanks, will respin.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* [RFC PATCH 8/8] dts: juno: Update coresight bindings for hw port
From: Suzuki K Poulose @ 2018-06-01 13:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mathieu.poirier, sudeep.holla, robh, mark.rutland, frowand.list,
matt.sealey, charles.garcia-tobin, john.horley, mike.leach,
coresight, linux-kernel, devicetree, Suzuki K Poulose,
Liviu Dudau
In-Reply-To: <1527858967-16047-1-git-send-email-suzuki.poulose@arm.com>
Switch to updated coresight bindings for hw ports.
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 82 +++++++++++++++++++++++++---------
arch/arm64/boot/dts/arm/juno.dts | 5 ++-
2 files changed, 63 insertions(+), 24 deletions(-)
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index eb749c5..33b41ba 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -122,15 +122,18 @@
port@0 {
reg = <0>;
etf0_in_port: endpoint {
- slave-mode;
+ direction = <0>;
remote-endpoint = <&main_funnel_out_port>;
+ coresight,hwid = <0>;
};
};
/* output port */
port@1 {
- reg = <0>;
+ reg = <1>;
etf0_out_port: endpoint {
+ coresight,hwid = <0>;
+ direction = <1>;
};
};
};
@@ -145,8 +148,9 @@
power-domains = <&scpi_devpd 0>;
port {
tpiu_in_port: endpoint {
- slave-mode;
+ direction = <0>;
remote-endpoint = <&replicator_out_port0>;
+ coresight,hwid = <0>;
};
};
};
@@ -168,23 +172,27 @@
reg = <0>;
main_funnel_out_port: endpoint {
remote-endpoint = <&etf0_in_port>;
+ coresight,hwid = <0>;
+ direction = <1>;
};
};
/* input ports */
port@1 {
- reg = <0>;
+ reg = <1>;
main_funnel_in_port0: endpoint {
- slave-mode;
+ direction = <0>;
remote-endpoint = <&cluster0_funnel_out_port>;
+ coresight,hwid = <0>;
};
};
port@2 {
- reg = <1>;
+ reg = <2>;
main_funnel_in_port1: endpoint {
- slave-mode;
+ direction = <0>;
remote-endpoint = <&cluster1_funnel_out_port>;
+ coresight,hwid = <1>;
};
};
};
@@ -200,8 +208,9 @@
power-domains = <&scpi_devpd 0>;
port {
etr_in_port: endpoint {
- slave-mode;
+ direction = <0>;
remote-endpoint = <&replicator_out_port1>;
+ coresight,hwid = <0>;
};
};
};
@@ -217,6 +226,8 @@
power-domains = <&scpi_devpd 0>;
port {
stm_out_port: endpoint {
+ coresight,hwid = <0>;
+ direction = <1>;
};
};
};
@@ -240,6 +251,8 @@
port {
cluster0_etm0_out_port: endpoint {
remote-endpoint = <&cluster0_funnel_in_port0>;
+ coresight,hwid = <0>;
+ direction = <1>;
};
};
};
@@ -259,22 +272,26 @@
reg = <0>;
cluster0_funnel_out_port: endpoint {
remote-endpoint = <&main_funnel_in_port0>;
+ coresight,hwid = <0>;
+ direction = <1>;
};
};
port@1 {
- reg = <0>;
+ reg = <1>;
cluster0_funnel_in_port0: endpoint {
- slave-mode;
+ direction = <0>;
remote-endpoint = <&cluster0_etm0_out_port>;
+ coresight,hwid = <0>;
};
};
port@2 {
- reg = <1>;
+ reg = <2>;
cluster0_funnel_in_port1: endpoint {
- slave-mode;
+ direction = <0>;
remote-endpoint = <&cluster0_etm1_out_port>;
+ coresight,hwid = <1>;
};
};
};
@@ -299,6 +316,8 @@
port {
cluster0_etm1_out_port: endpoint {
remote-endpoint = <&cluster0_funnel_in_port1>;
+ coresight,hwid = <0>;
+ direction = <1>;
};
};
};
@@ -322,6 +341,8 @@
port {
cluster1_etm0_out_port: endpoint {
remote-endpoint = <&cluster1_funnel_in_port0>;
+ coresight,hwid = <0>;
+ direction = <1>;
};
};
};
@@ -341,36 +362,42 @@
reg = <0>;
cluster1_funnel_out_port: endpoint {
remote-endpoint = <&main_funnel_in_port1>;
+ coresight,hwid = <0>;
+ direction = <1>;
};
};
port@1 {
- reg = <0>;
+ reg = <1>;
cluster1_funnel_in_port0: endpoint {
- slave-mode;
+ direction = <0>;
remote-endpoint = <&cluster1_etm0_out_port>;
+ coresight,hwid = <0>;
};
};
port@2 {
- reg = <1>;
+ reg = <2>;
cluster1_funnel_in_port1: endpoint {
- slave-mode;
+ direction = <0>;
remote-endpoint = <&cluster1_etm1_out_port>;
+ coresight,hwid = <1>;
};
};
port@3 {
- reg = <2>;
+ reg = <3>;
cluster1_funnel_in_port2: endpoint {
- slave-mode;
+ direction = <0>;
remote-endpoint = <&cluster1_etm2_out_port>;
+ coresight,hwid = <2>;
};
};
port@4 {
- reg = <3>;
+ reg = <4>;
cluster1_funnel_in_port3: endpoint {
- slave-mode;
+ direction = <0>;
remote-endpoint = <&cluster1_etm3_out_port>;
+ coresight,hwid = <3>;
};
};
};
@@ -395,6 +422,8 @@
port {
cluster1_etm1_out_port: endpoint {
remote-endpoint = <&cluster1_funnel_in_port1>;
+ coresight,hwid = <0>;
+ direction = <1>;
};
};
};
@@ -418,6 +447,8 @@
port {
cluster1_etm2_out_port: endpoint {
remote-endpoint = <&cluster1_funnel_in_port2>;
+ coresight,hwid = <0>;
+ direction = <1>;
};
};
};
@@ -441,6 +472,8 @@
port {
cluster1_etm3_out_port: endpoint {
remote-endpoint = <&cluster1_funnel_in_port3>;
+ coresight,hwid = <0>;
+ direction = <1>;
};
};
};
@@ -462,6 +495,8 @@
reg = <0>;
replicator_out_port0: endpoint {
remote-endpoint = <&tpiu_in_port>;
+ coresight,hwid = <0>;
+ direction = <1>;
};
};
@@ -469,14 +504,17 @@
reg = <1>;
replicator_out_port1: endpoint {
remote-endpoint = <&etr_in_port>;
+ coresight,hwid = <1>;
+ direction = <1>;
};
};
/* replicator input port */
port@2 {
- reg = <0>;
+ reg = <2>;
replicator_in_port0: endpoint {
- slave-mode;
+ direction = <0>;
+ coresight,hwid = <0>;
};
};
};
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index c9236c4..27b8036 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -260,10 +260,11 @@
&main_funnel {
ports {
port@3 {
- reg = <2>;
+ reg = <3>;
main_funnel_in_port2: endpoint {
- slave-mode;
+ direction = <0>;
remote-endpoint = <&stm_out_port>;
+ coresight,hwid = <2>;
};
};
};
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 7/8] dts: coresight: Define new bindings for direction of data flow
From: Suzuki K Poulose @ 2018-06-01 13:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mathieu.poirier, sudeep.holla, robh, mark.rutland, frowand.list,
matt.sealey, charles.garcia-tobin, john.horley, mike.leach,
coresight, linux-kernel, devicetree, Suzuki K Poulose
In-Reply-To: <1527858967-16047-1-git-send-email-suzuki.poulose@arm.com>
So far we have relied on an undocumented property "slave-mode",
to indicate if the given port is input or not. Since we are
redefining the coresight bindings, define new property for the
"direction" of data flow for a given connection endpoint in the
device.
Each endpoint must define the following property.
- "direction" : 0 => Port is input
1 => Port is output
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
drivers/hwtracing/coresight/of_coresight.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
index 99d7a9c..63c1668 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -52,7 +52,19 @@ of_coresight_get_endpoint_device(struct device_node *endpoint)
endpoint, of_dev_node_match);
}
-static void of_coresight_get_ports(const struct device_node *node,
+static bool of_coresight_ep_is_input(struct device *dev, struct device_node *ep_node)
+{
+ u32 dir;
+
+ if (!of_property_read_u32(ep_node, "direction", &dir))
+ return dir == 0;
+
+ dev_warn_once(dev, "Missing mandatory \"direction\" property!\n");
+ return of_property_read_bool(ep_node, "slave-mode");
+}
+
+static void of_coresight_get_ports(struct device *dev,
+ const struct device_node *node,
int *nr_inport, int *nr_outport)
{
struct device_node *ep = NULL;
@@ -63,7 +75,7 @@ static void of_coresight_get_ports(const struct device_node *node,
if (!ep)
break;
- if (of_property_read_bool(ep, "slave-mode"))
+ if (of_coresight_ep_is_input(dev, ep))
in++;
else
out++;
@@ -149,7 +161,7 @@ of_get_coresight_platform_data(struct device *dev,
pdata->name = dev_name(dev);
/* Get the number of input and output port for this component */
- of_coresight_get_ports(node, &pdata->nr_inport, &pdata->nr_outport);
+ of_coresight_get_ports(dev, node, &pdata->nr_inport, &pdata->nr_outport);
if (pdata->nr_outport) {
ret = of_coresight_alloc_memory(dev, pdata);
@@ -168,7 +180,7 @@ of_get_coresight_platform_data(struct device *dev,
* No need to deal with input ports, processing for as
* processing for output ports will deal with them.
*/
- if (of_find_property(ep, "slave-mode", NULL))
+ if (of_coresight_ep_is_input(dev, ep))
continue;
outport = of_graph_ep_coresight_get_port_id(dev, ep);
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings
From: Suzuki K Poulose @ 2018-06-01 13:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mathieu.poirier, sudeep.holla, robh, mark.rutland, frowand.list,
matt.sealey, charles.garcia-tobin, john.horley, mike.leach,
coresight, linux-kernel, devicetree, Suzuki K Poulose
In-Reply-To: <1527858967-16047-1-git-send-email-suzuki.poulose@arm.com>
The coresight drivers relied on default bindings for graph
in DT, while reusing the "reg" field of the "ports" to indicate
the actual hardware port number for the connections. However,
with the rules getting stricter w.r.t to the address mismatch
with the label, it is no longer possible to use the port address
field for the hardware port number. Hence, we add an explicit
property to denote the hardware port number, "coresight,hwid"
which must be specified for each "endpoint".
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
.../devicetree/bindings/arm/coresight.txt | 26 +++++++++---
drivers/hwtracing/coresight/of_coresight.c | 46 ++++++++++++++++------
2 files changed, 54 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
index bd36e40..385581a 100644
--- a/Documentation/devicetree/bindings/arm/coresight.txt
+++ b/Documentation/devicetree/bindings/arm/coresight.txt
@@ -104,7 +104,11 @@ properties to uniquely identify the connection details.
"slave-mode"
* Hardware Port number at the component:
- - The hardware port number is assumed to be the address of the "port" component.
+ - (Obsolete) The hardware port number is assumed to be the address of the "port" component.
+ - Each "endpoint" must define the hardware port of the local end of the
+ connection using the following property:
+ "coresight,hwid" - 32bit integer, hardware port number at the local end.
+
Example:
@@ -120,6 +124,7 @@ Example:
etb_in_port: endpoint@0 {
slave-mode;
remote-endpoint = <&replicator_out_port0>;
+ coresight,hwid = <0>;
};
};
};
@@ -134,6 +139,7 @@ Example:
tpiu_in_port: endpoint@0 {
slave-mode;
remote-endpoint = <&replicator_out_port1>;
+ coresight,hwid = <0>;
};
};
};
@@ -154,6 +160,7 @@ Example:
reg = <0>;
replicator_out_port0: endpoint {
remote-endpoint = <&etb_in_port>;
+ coresight,hwid = <0>;
};
};
@@ -161,15 +168,17 @@ Example:
reg = <1>;
replicator_out_port1: endpoint {
remote-endpoint = <&tpiu_in_port>;
+ coresight,hwid = <1>;
};
};
/* replicator input port */
port@2 {
- reg = <0>;
+ reg = <1>;
replicator_in_port0: endpoint {
slave-mode;
remote-endpoint = <&funnel_out_port0>;
+ coresight,hwid = <0>;
};
};
};
@@ -191,31 +200,35 @@ Example:
funnel_out_port0: endpoint {
remote-endpoint =
<&replicator_in_port0>;
+ coresight,hwid = <0>;
};
};
/* funnel input ports */
port@1 {
- reg = <0>;
+ reg = <1>;
funnel_in_port0: endpoint {
slave-mode;
remote-endpoint = <&ptm0_out_port>;
+ coresight,hwid = <0>;
};
};
port@2 {
- reg = <1>;
+ reg = <2>;
funnel_in_port1: endpoint {
slave-mode;
remote-endpoint = <&ptm1_out_port>;
+ coresight,hwid = <1>;
};
};
port@3 {
- reg = <2>;
+ reg = <3>;
funnel_in_port2: endpoint {
slave-mode;
remote-endpoint = <&etm0_out_port>;
+ coresight,hwid = <2>;
};
};
@@ -233,6 +246,7 @@ Example:
port {
ptm0_out_port: endpoint {
remote-endpoint = <&funnel_in_port0>;
+ coresight,hwid = <0>;
};
};
};
@@ -247,6 +261,7 @@ Example:
port {
ptm1_out_port: endpoint {
remote-endpoint = <&funnel_in_port1>;
+ coresight,hwid = <0>;
};
};
};
@@ -263,6 +278,7 @@ Example:
port {
stm_out_port: endpoint {
remote-endpoint = <&main_funnel_in_port2>;
+ coresight,hwid = <0>;
};
};
};
diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
index a3f3416..99d7a9c 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -105,14 +105,37 @@ int of_coresight_get_cpu(const struct device_node *node)
}
EXPORT_SYMBOL_GPL(of_coresight_get_cpu);
+/*
+ * of_graph_ep_coresight_get_port_id : Get the hardware port number for the
+ * given endpoint device node. Prefer the explicit "coresight,hwid" property
+ * over the endpoint register id (obsolete bindings).
+ */
+static int of_graph_ep_coresight_get_port_id(struct device *dev,
+ struct device_node *ep_node)
+{
+ struct of_endpoint ep;
+ int rc, port_id;
+
+
+ if (!of_property_read_u32(ep_node, "coresight,hwid", &port_id))
+ return port_id;
+
+ rc = of_graph_parse_endpoint(ep_node, &ep);
+ if (rc)
+ return rc;
+ dev_warn_once(dev,
+ "ep%d: Mandatory \"coresight,hwid\" property missing."
+ " DT uses obsolete coresight bindings\n", ep.port);
+ return ep.port;
+}
+
struct coresight_platform_data *
of_get_coresight_platform_data(struct device *dev,
const struct device_node *node)
{
- int ret = 0;
+ int ret = 0, outport, inport;
struct coresight_platform_data *pdata;
struct coresight_connection *conn;
- struct of_endpoint endpoint, rendpoint;
struct device *rdev;
struct device_node *ep = NULL;
struct device_node *rparent = NULL;
@@ -148,14 +171,10 @@ of_get_coresight_platform_data(struct device *dev,
if (of_find_property(ep, "slave-mode", NULL))
continue;
- /* Get a handle on the local endpoint */
- ret = of_graph_parse_endpoint(ep, &endpoint);
-
- if (ret)
+ outport = of_graph_ep_coresight_get_port_id(dev, ep);
+ if (outport < 0)
continue;
-
- /* The local out port number */
- conn->outport = endpoint.port;
+ conn->outport = outport;
/*
* Get a handle on the remote endpoint and the device
@@ -168,15 +187,16 @@ of_get_coresight_platform_data(struct device *dev,
if (!rparent)
continue;
- if (of_graph_parse_endpoint(rep, &rendpoint))
- continue;
-
rdev = of_coresight_get_endpoint_device(rparent);
if (!rdev)
return ERR_PTR(-EPROBE_DEFER);
+ inport = of_graph_ep_coresight_get_port_id(rdev, rep);
+ if (inport < 0)
+ continue;
+
conn->child_name = dev_name(rdev);
- conn->child_port = rendpoint.port;
+ conn->child_port = inport;
conn++;
} while (ep);
}
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 5/8] coresight: Handle errors in finding input/output ports
From: Suzuki K Poulose @ 2018-06-01 13:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mathieu.poirier, sudeep.holla, robh, mark.rutland, frowand.list,
matt.sealey, charles.garcia-tobin, john.horley, mike.leach,
coresight, linux-kernel, devicetree, Suzuki K Poulose
In-Reply-To: <1527858967-16047-1-git-send-email-suzuki.poulose@arm.com>
If we fail to find the input / output port for a LINK component
while enabling a path, we should fail gracefully rather than
assuming port "0".
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
drivers/hwtracing/coresight/coresight.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 3b3756e..4dcea6e 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -115,7 +115,7 @@ static int coresight_find_link_inport(struct coresight_device *csdev,
dev_err(&csdev->dev, "couldn't find inport, parent: %s, child: %s\n",
dev_name(&parent->dev), dev_name(&csdev->dev));
- return 0;
+ return -ENODEV;
}
static int coresight_find_link_outport(struct coresight_device *csdev,
@@ -133,7 +133,7 @@ static int coresight_find_link_outport(struct coresight_device *csdev,
dev_err(&csdev->dev, "couldn't find outport, parent: %s, child: %s\n",
dev_name(&csdev->dev), dev_name(&child->dev));
- return 0;
+ return -ENODEV;
}
static int coresight_enable_sink(struct coresight_device *csdev, u32 mode)
@@ -186,6 +186,9 @@ static int coresight_enable_link(struct coresight_device *csdev,
else
refport = 0;
+ if (refport < 0)
+ return refport;
+
if (atomic_inc_return(&csdev->refcnt[refport]) == 1) {
if (link_ops(csdev)->enable) {
ret = link_ops(csdev)->enable(csdev, inport, outport);
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 4/8] coresight: platform: Cleanup coresight connection handling
From: Suzuki K Poulose @ 2018-06-01 13:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mathieu.poirier, sudeep.holla, robh, mark.rutland, frowand.list,
matt.sealey, charles.garcia-tobin, john.horley, mike.leach,
coresight, linux-kernel, devicetree, Suzuki K Poulose
In-Reply-To: <1527858967-16047-1-git-send-email-suzuki.poulose@arm.com>
The platform code parses the component connections and populates
a platform-description of the output connections in arrays of fields
(which is never freed). This is later copied in the coresight_register
to a newly allocated area, represented by coresight_connection(s).
This patch cleans up the code dealing with connections by making
use of the "coresight_connection" structure right at the platform
code and lets the generic driver simply re-use information provided
by the platform.
Thus making it reader friendly as well as avoiding the wastage of
unused memory.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
drivers/hwtracing/coresight/coresight.c | 21 +---------------
drivers/hwtracing/coresight/of_coresight.c | 40 +++++++++++-------------------
include/linux/coresight.h | 9 ++-----
3 files changed, 17 insertions(+), 53 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 389c4ba..3b3756e 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -961,13 +961,11 @@ postcore_initcall(coresight_init);
struct coresight_device *coresight_register(struct coresight_desc *desc)
{
- int i;
int ret;
int link_subtype;
int nr_refcnts = 1;
atomic_t *refcnts = NULL;
struct coresight_device *csdev;
- struct coresight_connection *conns = NULL;
csdev = kzalloc(sizeof(*csdev), GFP_KERNEL);
if (!csdev) {
@@ -996,22 +994,7 @@ struct coresight_device *coresight_register(struct coresight_desc *desc)
csdev->nr_inport = desc->pdata->nr_inport;
csdev->nr_outport = desc->pdata->nr_outport;
- /* Initialise connections if there is at least one outport */
- if (csdev->nr_outport) {
- conns = kcalloc(csdev->nr_outport, sizeof(*conns), GFP_KERNEL);
- if (!conns) {
- ret = -ENOMEM;
- goto err_kzalloc_conns;
- }
-
- for (i = 0; i < csdev->nr_outport; i++) {
- conns[i].outport = desc->pdata->outports[i];
- conns[i].child_name = desc->pdata->child_names[i];
- conns[i].child_port = desc->pdata->child_ports[i];
- }
- }
-
- csdev->conns = conns;
+ csdev->conns = desc->pdata->conns;
csdev->type = desc->type;
csdev->subtype = desc->subtype;
@@ -1039,8 +1022,6 @@ struct coresight_device *coresight_register(struct coresight_desc *desc)
return csdev;
err_device_register:
- kfree(conns);
-err_kzalloc_conns:
kfree(refcnts);
err_kzalloc_refcnts:
kfree(csdev);
diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
index e0deab0..a3f3416 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -77,26 +77,13 @@ static void of_coresight_get_ports(const struct device_node *node,
static int of_coresight_alloc_memory(struct device *dev,
struct coresight_platform_data *pdata)
{
- /* List of output port on this component */
- pdata->outports = devm_kzalloc(dev, pdata->nr_outport *
- sizeof(*pdata->outports),
- GFP_KERNEL);
- if (!pdata->outports)
- return -ENOMEM;
-
- /* Children connected to this component via @outports */
- pdata->child_names = devm_kzalloc(dev, pdata->nr_outport *
- sizeof(*pdata->child_names),
- GFP_KERNEL);
- if (!pdata->child_names)
- return -ENOMEM;
-
- /* Port number on the child this component is connected to */
- pdata->child_ports = devm_kzalloc(dev, pdata->nr_outport *
- sizeof(*pdata->child_ports),
- GFP_KERNEL);
- if (!pdata->child_ports)
- return -ENOMEM;
+ if (pdata->nr_outport) {
+ pdata->conns = devm_kzalloc(dev, pdata->nr_outport *
+ sizeof(*pdata->conns),
+ GFP_KERNEL);
+ if (!pdata->conns)
+ return -ENOMEM;
+ }
return 0;
}
@@ -122,8 +109,9 @@ struct coresight_platform_data *
of_get_coresight_platform_data(struct device *dev,
const struct device_node *node)
{
- int i = 0, ret = 0;
+ int ret = 0;
struct coresight_platform_data *pdata;
+ struct coresight_connection *conn;
struct of_endpoint endpoint, rendpoint;
struct device *rdev;
struct device_node *ep = NULL;
@@ -145,6 +133,7 @@ of_get_coresight_platform_data(struct device *dev,
if (ret)
return ERR_PTR(ret);
+ conn = pdata->conns;
/* Iterate through each port to discover topology */
do {
/* Get a handle on a port */
@@ -166,7 +155,7 @@ of_get_coresight_platform_data(struct device *dev,
continue;
/* The local out port number */
- pdata->outports[i] = endpoint.port;
+ conn->outport = endpoint.port;
/*
* Get a handle on the remote endpoint and the device
@@ -186,10 +175,9 @@ of_get_coresight_platform_data(struct device *dev,
if (!rdev)
return ERR_PTR(-EPROBE_DEFER);
- pdata->child_names[i] = dev_name(rdev);
- pdata->child_ports[i] = rendpoint.port;
-
- i++;
+ conn->child_name = dev_name(rdev);
+ conn->child_port = rendpoint.port;
+ conn++;
} while (ep);
}
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 32aaa1c..c2363bb 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -89,20 +89,15 @@ struct coresight_dev_subtype {
* @cpu: the CPU a source belongs to. Only applicable for ETM/PTMs.
* @name: name of the component as shown under sysfs.
* @nr_inport: number of input ports for this component.
- * @outports: list of remote endpoint port number.
- * @child_names:name of all child components connected to this device.
- * @child_ports:child component port number the current component is
- connected to.
* @nr_outport: number of output ports for this component.
+ * @conns: Array of nr_outport connections from this component
*/
struct coresight_platform_data {
int cpu;
const char *name;
int nr_inport;
- int *outports;
- const char **child_names;
- int *child_ports;
int nr_outport;
+ struct coresight_connection *conns;
};
/**
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 3/8] coresight: Cleanup platform description data
From: Suzuki K Poulose @ 2018-06-01 13:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mathieu.poirier, sudeep.holla, robh, mark.rutland, frowand.list,
matt.sealey, charles.garcia-tobin, john.horley, mike.leach,
coresight, linux-kernel, devicetree, Suzuki K Poulose
In-Reply-To: <1527858967-16047-1-git-send-email-suzuki.poulose@arm.com>
Nobody uses the "clk" field in struct coresight_platform_data.
Remove it.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
include/linux/coresight.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index d950dad..32aaa1c 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -94,7 +94,6 @@ struct coresight_dev_subtype {
* @child_ports:child component port number the current component is
connected to.
* @nr_outport: number of output ports for this component.
- * @clk: The clock this component is associated to.
*/
struct coresight_platform_data {
int cpu;
@@ -104,7 +103,6 @@ struct coresight_platform_data {
const char **child_names;
int *child_ports;
int nr_outport;
- struct clk *clk;
};
/**
--
2.7.4
^ permalink raw reply related
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