* Re: [PATCH 2/3] dt-bindings: display/bridge: Add binding for IMX NWL mipi dsi host controller
From: Guido Günther @ 2019-07-31 14:37 UTC (permalink / raw)
To: Laurent Pinchart
Cc: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Andrzej Hajda, Neil Armstrong, Jonas Karlman,
Jernej Skrabec, Lee Jones, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, Robert Chiras
In-Reply-To: <20190727015716.GA4902@pendragon.ideasonboard.com>
Hi Laurent,
thanks for having a look.
On Sat, Jul 27, 2019 at 04:57:16AM +0300, Laurent Pinchart wrote:
> Hi Guido,
>
> Thank you for the patch.
>
> On Wed, Jul 24, 2019 at 05:52:25PM +0200, Guido Günther wrote:
> > The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
> >
> > Signed-off-by: Guido Günther <agx@sigxcpu.org>
> > ---
> > .../bindings/display/bridge/imx-nwl-dsi.txt | 89 +++++++++++++++++++
> > 1 file changed, 89 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt b/Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> > new file mode 100644
> > index 000000000000..288fdb726d5a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> > @@ -0,0 +1,89 @@
> > +Northwest Logic MIPI-DSI on imx SoCs
> > +=====================================
>
> There's one too many =.
>
> > +
> > +NWL MIPI-DSI host controller found on i.MX8 platforms. This is a
> > +dsi bridge for the for the NWL MIPI-DSI host.
>
> s/dsi/DSI/
> s/for the for the /for the /
>
> > +
> > +Required properties:
> > +- compatible: "fsl,<chip>-nwl-dsi"
> > + The following strings are expected:
> > + "fsl,imx8mq-nwl-dsi"
> > +- reg: the register range of the MIPI-DSI controller
> > +- interrupts: the interrupt number for this module
>
> It's not just a number but a specifier (with flags).
>
> > +- clock, clock-names: phandles to the MIPI-DSI clocks
>
> That should be phandles and names.
>
> > + The following clocks are expected on all platforms:
>
> Expected or required ?
>
> s/ on all platforms// as you only support a single platform.
>
> > + "core" - DSI core clock
> > + "tx_esc" - TX_ESC clock (used in escape mode)
> > + "rx_esc" - RX_ESC clock (used in escape mode)
> > + "phy_ref" - PHY_REF clock. Clock is managed by the phy. Only
> > + used to read the clock rate.
> > +- assigned-clocks: phandles to clocks that require initial configuration
> > +- assigned-clock-rates: rates of the clocks that require initial configuration
> > + The following clocks need to have an initial configuration:
> > + "tx_esc" (20 MHz) and "rx_esc" (80 Mhz).
>
> I think those two properties are out of scope for these bindings.
>
> > +- phys: phandle to the phy module representing the DPHY
> > + inside the MIPI-DSI IP block
> > +- phy-names: should be "dphy"
> > +
> > +Optional properties:
> > +- power-domains phandle to the power domain
> > +- src phandle to the system reset controller (required on
> > + i.MX8MQ)
>
> Should this use the standard resets property ?
>
> > +- mux-sel phandle to the MUX register set (required on i.MX8MQ)
> > +- assigned-clock-parents phandles to parent clocks that needs to be assigned as
> > + parents to clocks defined in assigned-clocks
>
> This property is also out of scope.
>
> > +
> > +Example:
> > + mipi_dsi: mipi_dsi@30a00000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "fsl,imx8mq-nwl-dsi";
> > + reg = <0x30A00000 0x300>;
> > + clocks = <&clk IMX8MQ_CLK_DSI_CORE>,
> > + <&clk IMX8MQ_CLK_DSI_AHB>,
> > + <&clk IMX8MQ_CLK_DSI_IPG_DIV>,
> > + <&clk IMX8MQ_CLK_DSI_PHY_REF>;
> > + clock-names = "core", "rx_esc", "tx_esc", "phy_ref";
> > + assigned-clocks = <&clk IMX8MQ_CLK_DSI_AHB>,
> > + <&clk IMX8MQ_CLK_DSI_CORE>,
> > + <&clk IMX8MQ_CLK_DSI_IPG_DIV>;
> > + assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_80M>,
> > + <&clk IMX8MQ_SYS1_PLL_266M>;
> > + assigned-clock-rates = <80000000>,
> > + <266000000>,
> > + <20000000>;
> > + interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
> > + power-domains = <&pgc_mipi>;
> > + src = <&src>;
> > + mux-sel = <&iomuxc_gpr>;
> > + phys = <&dphy>;
> > + phy-names = "dphy";
> > + status = "okay";
> > +
> > + panel@0 {
> > + compatible = "...";
> > + port {
> > + panel_in: endpoint {
> > + remote-endpoint = <&mipi_dsi_out>;
> > + };
> > + };
> > + };
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + mipi_dsi_in: endpoint {
> > + remote-endpoint = <&dcss_disp0_mipi_dsi>;
> > + };
> > + };
> > + port@1 {
> > + reg = <1>;
> > + mipi_dsi_out: endpoint {
> > + remote-endpoint = <&panel_in>;
> > + };
> > + };
> > + };
>
> The ports should be documented too. There are multiple example bindings
> available.
I've followed you suggestions while moving the whole thing to YAML
syntax for an upcoming v2.
Thanks for having a look,
Cheers,
-- Guido
> > + };
>
> --
> Regards,
>
> Laurent Pinchart
>
^ permalink raw reply
* Re: [PATCH 3/3] drm/bridge: Add NWL MIPI DSI host controller support
From: Guido Günther @ 2019-07-31 14:38 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Fabio Estevam, David Airlie, Daniel Vetter, Rob Herring,
Mark Rutland, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
NXP Linux Team, Andrzej Hajda, Neil Armstrong, Jonas Karlman,
Jernej Skrabec, Lee Jones, DRI mailing list,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190727020444.GC4902@pendragon.ideasonboard.com>
Hi,
On Sat, Jul 27, 2019 at 05:04:44AM +0300, Laurent Pinchart wrote:
> Hello,
>
> On Fri, Jul 26, 2019 at 05:01:52PM -0300, Fabio Estevam wrote:
> > Hi Guido,
> >
> > Thanks for your work on this driver!
> >
> > On Wed, Jul 24, 2019 at 12:52 PM Guido Günther <agx@sigxcpu.org> wrote:
> >
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/bridge/imx-nwl/Kconfig
> > > @@ -0,0 +1,15 @@
> > > +config DRM_IMX_NWL_DSI
> > > + tristate "Support for Northwest Logic MIPI DSI Host controller"
> > > + depends on DRM && (ARCH_MXC || ARCH_MULTIPLATFORM || COMPILE_TEST)
> >
> > This IP could potentially be found on other SoCs, so no need to make
> > it depend on ARCH_MXC.
>
> I'd go even further and not use the prefix imx in the driver name or
> anywhere in the code.
My idea was to do that when another possible user comes up to see what
can be shared but I can do that for v2.
Cheers,
-- Guido
>
> [snip]
>
> --
> Regards,
>
> Laurent Pinchart
>
^ permalink raw reply
* Re: [PATCH v2 08/20] ARM: dts: imx7-colibri: Add touch controllers
From: Philippe Schenker @ 2019-07-31 14:39 UTC (permalink / raw)
To: festevam@gmail.com
Cc: s.hauer@pengutronix.de, stefan@agner.ch, Marcel Ziswiler,
kernel@pengutronix.de, Max Krummenacher, mark.rutland@arm.com,
devicetree@vger.kernel.org, michal.vokac@ysoft.com,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, robh+dt@kernel.org,
linux-imx@nxp.com
In-Reply-To: <CAOMZO5B3BcpjbnsXuE5abX8YsuLDrkkHU=RBt6w_SpwuRkTvXA@mail.gmail.com>
On Wed, 2019-07-31 at 09:42 -0300, Fabio Estevam wrote:
> On Wed, Jul 31, 2019 at 9:38 AM Philippe Schenker
> <philippe.schenker@toradex.com> wrote:
> > Add atmel mxt multitouch controller and TouchRevolution multitouch
>
> You missed to updated the commit log ;-)
Ah, shoot! :-) Thanks.
I will send a v3 then, next week.
^ permalink raw reply
* Re: [PATCH v8 00/14] Rockchip ISP1 Driver
From: Helen Koike @ 2019-07-31 14:42 UTC (permalink / raw)
To: Hans Verkuil, linux-rockchip
Cc: devicetree, eddie.cai.linux, mchehab, heiko, jeffy.chen, zyc,
linux-kernel, tfiga, hans.verkuil, laurent.pinchart, sakari.ailus,
kernel, ezequiel, linux-media, linux-arm-kernel, zhengsq
In-Reply-To: <13d89676-ae84-5904-7606-935501cb2d89@xs4all.nl>
On 7/31/19 1:55 AM, Hans Verkuil wrote:
> On 7/31/19 6:33 AM, Hans Verkuil wrote:
>> On 7/31/19 6:29 AM, Hans Verkuil wrote:
>>> On 7/31/19 2:08 AM, Helen Koike wrote:
>>>>
>>>>
>>>> On 7/30/19 5:50 PM, Helen Koike wrote:
>>>>>
>>>>>
>>>>> On 7/30/19 5:15 PM, Hans Verkuil wrote:
>>>>>> On 7/30/19 8:42 PM, Helen Koike wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I'm re-sending a new version of ISP(Camera) v4l2 driver for rockchip
>>>>>>> rk3399 SoC.
>>>>>>>
>>>>>>> I didn't change much from the last version, just applying the
>>>>>>> suggestions made in the previous one.
>>>>>>>
>>>>>>> This patchset is also available at:
>>>>>>> https://gitlab.collabora.com/koike/linux/tree/rockchip/isp/v8
>>>>>>>
>>>>>>> Libcamera patched to work with this version:
>>>>>>> https://gitlab.collabora.com/koike/libcamera
>>>>>>> (also sent to the mailing list)
>>>>>>>
>>>>>>> I tested on the rockpi 4 with a rpi v1.3 sensor and also with the
>>>>>>> Scarlet Chromebook.
>>>>>>>
>>>>>>> Known issues (same as in v7):
>>>>>>> -------------
>>>>>>> - Reloading the module doesn't work (there is some missing cleanup when
>>>>>>> unloading)
>>>>>>> - When capturing in bayer format, changing the size doesn't seem to
>>>>>>> affect the image.
>>>>>>> - crop needs more tests
>>>>>>> - v4l2-compliance error:
>>>>>>> fail: v4l2-test-controls.cpp(824): subscribe event for control 'Image Processing Controls' failed
>>>>>>> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL
>>>>>>
>>>>>> Can you mail me the full v4l2-compliance output?
>>>>>
>>>>> Sure, please check here: http://ix.io/1Q5u
>>>>> I updated v4l-utils with the latest version and I re-ran bootstrap/configure/make,
>>>>> but for some reason the hash from the link above is not the latest commit, probably some
>>>>> old configuration somewhere. I'll resend this log as soon as I get v4l2-compliance
>>>>> properly updated.
>>>>
>>>> Please see the output of v4l2-compliance here with an updated v4l-utils: http://ix.io/1Q6A
>>>
>>> So this FAIL is for /dev/v4l-subdev0 (rkisp1-isp-subdev).
>>>
>>> What is weird that this subdev does not appear to have controls at all.
>>>
>>> What is the output of 'v4l2-ctl -d /dev/v4l-subdev0 -l'? And if it lists
>>> controls, then why?
root@rockpi:~# v4l2-ctl -d /dev/v4l-subdev0 -l
Image Processing Controls
pixel_rate 0x009f0902 (int64) : min=1 max=2147483647 step=1 default=1 value=1 flags=read-only
root@rockpi:~# v4l2-ctl -d /dev/v4l-subdev1 -l
Image Processing Controls
pixel_rate 0x009f0902 (int64) : min=1 max=2147483647 step=1 default=1 value=1 flags=read-only
It seems that ISP heritage the control from the sensor driver. I believe it
happens because isp_dev->ctrl_handler was assigned to the v4l2_dev object:
dev.c: v4l2_ctrl_handler_init(&isp_dev->ctrl_handler, 5);
dev.c: v4l2_dev->ctrl_handler = &isp_dev->ctrl_handler;
>>>
>>> If you run 'v4l2-compliance -u /dev/v4l-subdev0', do you get a fail as
>>> well?
Yes, but if I remove the ctrl_handler field from the struct rkisp1_isp_subdev
I don't get the error on /dev/v4l-subdev0 (ISP) anymore, I just get the error
on /dev/v4l-subdev1 (the sensor).
Here is the output of v4l2-compliance -m /dev/media0 without the
ctrl_handler field: http://ix.io/1Q9N
>>
>> I see the same issue with v4l-subdev1, but I see no "Media Driver Info"
>> in the v4l2-compliance output for that subdev. That's strange. It would
>> be good to know why that's happening.
>
> It looks to be some parenting issue: v4l2-compliance expects to find
> a mediaX directory in /sys/dev/char/81\:Y/device/ where 81:Y is the major/minor
> of /dev/v4l-subdev1.
>
> Because is this mi_get_media_fd() cannot find the media device for the subdev
> in v4l2-compliance.
So from my understanding this seems to be an issue in the sensor driver that
I'm using and not in the ISP (to be verified).
I'll submit the next version without the ctrl_handler field in struct rkisp1_isp_subdev,
is that ok?
Thanks
Helen
>
> Regards,
>
> Hans
>
^ permalink raw reply
* Re: [PATCH 3/3] drm/bridge: Add NWL MIPI DSI host controller support
From: Fabio Estevam @ 2019-07-31 14:43 UTC (permalink / raw)
To: Guido Günther
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Jernej Skrabec, Pengutronix Kernel Team, Neil Armstrong,
David Airlie, Lee Jones, Jonas Karlman, linux-kernel,
DRI mailing list, Rob Herring, NXP Linux Team, Robert Chiras,
Chris Healy, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Laurent Pinchart
In-Reply-To: <20190731143532.GA1935@bogon.m.sigxcpu.org>
Hi Guido,
On Wed, Jul 31, 2019 at 11:35 AM Guido Günther <agx@sigxcpu.org> wrote:
> The idea is to have
>
> "%sabling platform clocks", enable ? "en" : "dis");
>
> depending whether clocks are enabled/disabled.
Yes, I understood the idea, but this would print:
ensabling or dissabling :-)
> > Same here. Please return 'int' instead.
>
> This is from drm_bridge_funcs so the prototype is fixed. I'm not sure
> how what's the best way to bubble up fatal errors through the drm layer?
Ok, so let's not change this one.
> I went for DRM_DEV_ERROR() since that what i used in the rest of the
> driver and these ones were omission. Hope that's o.k.
No strong preferences here. I just think dev_err() easier to type and shorter.
Thanks for this work!
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: r8a77995: draak: Fix backlight regulator name
From: Rob Herring @ 2019-07-31 14:47 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Laurent Pinchart, Geert Uytterhoeven, Mark Brown, Magnus Damm,
Johan Hovold, Linux-Renesas, Simon Horman, Laurent Pinchart,
Linux ARM, Marek Vasut
In-Reply-To: <CAMuHMdV9MEYP97_6RFhmbGGB8uY-Pi8S9q+m+XMmHzKHcibJwQ@mail.gmail.com>
On Wed, Jul 31, 2019 at 2:32 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Laurent,
>
> On Wed, Jul 31, 2019 at 10:12 AM Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > On Wed, Jul 31, 2019 at 09:48:01AM +0200, Geert Uytterhoeven wrote:
> > > Currently there are two nodes named "regulator1" in the Draak DTS: a
> > > 3.3V regulator for the eMMC and the LVDS decoder, and a 12V regulator
> > > for the backlight. This causes the former to be overwritten by the
> > > latter.
> > >
> > > Fix this by renaming all regulators with numerical suffixes to use named
> > > suffixes, which are less likely to conflict.
> >
> > Aren't DT node names supposed to describe the device type, not a
> > particular instance of the device ? This is something that has bothered
> > me too, but I believe the naming scheme should be decided globally, not
> > per board. Is there precedent for using this scheme that has been
> > explicitly approved by the DT maintainers ?
>
> The example in Documentation/devicetree/bindings/regulator/regulator.yaml
> uses "regulator@0", which of course works only if #address-cells = 1, which
> is usually not the case for discrete regulators.
> BTW, the example lacks a "reg" property...
Yeah, that predates our being strict about unit-addresses.
> So some other suffix has to be added to distinguish individual "regulator"
> nodes.
<nodename>-<identifier> is basically the format we've been following
for cases without an address.
As long as we have a consistent base name that we can match schema
with, then I'm happy. But for regulators, we have a lot of node names
like 'buck1', 'LDO2', etc.
Rob
^ permalink raw reply
* Re: [PATCH v2 07/20] ARM: dts: imx7-colibri: fix 1.8V/UHS support
From: Philippe Schenker @ 2019-07-31 14:52 UTC (permalink / raw)
To: festevam@gmail.com
Cc: s.hauer@pengutronix.de, stefan@agner.ch, Marcel Ziswiler,
kernel@pengutronix.de, Max Krummenacher, mark.rutland@arm.com,
devicetree@vger.kernel.org, michal.vokac@ysoft.com,
shawnguo@kernel.org, Stefan Agner, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, linux-imx@nxp.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAOMZO5B5HnqpLrDjyGtqSQpVXmcoZuGLvCzKVUhwLb-_ZO_Xog@mail.gmail.com>
On Wed, 2019-07-31 at 09:56 -0300, Fabio Estevam wrote:
> On Wed, Jul 31, 2019 at 9:38 AM Philippe Schenker
> <philippe.schenker@toradex.com> wrote:
> > From: Stefan Agner <stefan.agner@toradex.com>
> >
> > Add pinmuxing and do not specify voltage restrictions in the
> > module level device tree.
>
> It would be nice to explain the reason for doing this.
This commit is in preparation of another patch that didn't made into this
patchset (downstream stuff in there). But I will do another patch on top that
will use this patch here. That should anyway be in mainline.
Philippe
>
> > Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
> > Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> > ---
> >
> > Changes in v2: None
> >
> > arch/arm/boot/dts/imx7-colibri.dtsi | 23 ++++++++++++++++++++++-
> > 1 file changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-
> > colibri.dtsi
> > index 16d1a1ed1aff..67f5e0c87fdc 100644
> > --- a/arch/arm/boot/dts/imx7-colibri.dtsi
> > +++ b/arch/arm/boot/dts/imx7-colibri.dtsi
> > @@ -326,7 +326,6 @@
> > &usdhc1 {
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_usdhc1 &pinctrl_cd_usdhc1>;
> > - no-1-8-v;
> > cd-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
> > disable-wp;
> > vqmmc-supply = <®_LDO2>;
> > @@ -671,6 +670,28 @@
> > >;
> > };
> >
> > + pinctrl_usdhc1_100mhz: usdhc1grp_100mhz {
> > + fsl,pins = <
> > + MX7D_PAD_SD1_CMD__SD1_CMD 0x5a
> > + MX7D_PAD_SD1_CLK__SD1_CLK 0x1a
> > + MX7D_PAD_SD1_DATA0__SD1_DATA0 0x5a
> > + MX7D_PAD_SD1_DATA1__SD1_DATA1 0x5a
> > + MX7D_PAD_SD1_DATA2__SD1_DATA2 0x5a
> > + MX7D_PAD_SD1_DATA3__SD1_DATA3 0x5a
> > + >;
> > + };
> > +
> > + pinctrl_usdhc1_200mhz: usdhc1grp_200mhz {
> > + fsl,pins = <
> > + MX7D_PAD_SD1_CMD__SD1_CMD 0x5b
> > + MX7D_PAD_SD1_CLK__SD1_CLK 0x1b
> > + MX7D_PAD_SD1_DATA0__SD1_DATA0 0x5b
> > + MX7D_PAD_SD1_DATA1__SD1_DATA1 0x5b
> > + MX7D_PAD_SD1_DATA2__SD1_DATA2 0x5b
> > + MX7D_PAD_SD1_DATA3__SD1_DATA3 0x5b
> > + >;
> > + };
>
> You add the entries for 100MHz and 200MHz, but I don't see them being
> referenced anywhere.
^ permalink raw reply
* Re: [PATCH/RFC] ARM: dts: rza2mevb: Fix numbering of Ethernet aliases
From: Geert Uytterhoeven @ 2019-07-31 15:02 UTC (permalink / raw)
To: Chris Brandt
Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Marek Vasut,
Rob Herring, Mark Rutland, linux-renesas-soc@vger.kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <TY1PR01MB156262DA5C9260BEE51472268ADF0@TY1PR01MB1562.jpnprd01.prod.outlook.com>
Hi Chris,
On Wed, Jul 31, 2019 at 4:28 PM Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Wed, Jul 31, 2019, Geert Uytterhoeven wrote:
> > The two Ethernet ports on the RZA2MEVB development board are labeled
> > "Ether1" and "Ether2". Reflect this numbering in the ethernet aliases.
>
> However, the channels are labeled as ETHERC0 and ETHERC1 in the hardware
> manual.
>
> So I guess my question is, in general, is the board specific Device Tree
> supposed to describe what is on the SoC? Or on the board silk screen?
AFAIK the aliases numbering is supposed to match the board or case labels.
> Maybe this is like "COM1" is labeled on PC motherboard and we expect it
> to show up as /dev/ttyS0 regardless of what physical serial port it is
> connected to.
Those pesky FORTRAN programmers, counting from 1 ;-)
On Koelsch (and Salvator-X(S)), they are called "debug0" and "debug1".
These used to be /dev/ttySC6 and /dev/ttySC7, but got renamed in
commit 1f75cdac773bc9c9 ("ARM: shmobile: koelsch: Rename SCIF[01] serial
ports to ttySC[01]").
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: r8a77995: draak: Fix backlight regulator name
From: Mark Brown @ 2019-07-31 15:09 UTC (permalink / raw)
To: Rob Herring
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Laurent Pinchart, Geert Uytterhoeven, Magnus Damm, Johan Hovold,
Linux-Renesas, Simon Horman, Geert Uytterhoeven, Laurent Pinchart,
Linux ARM, Marek Vasut
In-Reply-To: <CAL_JsqJWJ+o6t2Wb162h7Xz98L=WPSi4une-EC0HfoRiWLmKWA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 438 bytes --]
On Wed, Jul 31, 2019 at 08:47:38AM -0600, Rob Herring wrote:
> As long as we have a consistent base name that we can match schema
> with, then I'm happy. But for regulators, we have a lot of node names
> like 'buck1', 'LDO2', etc.
Those are all types of regulator (LDOs and DCDCs are the main types of
voltage regulator, and buck is another term for DCDC).
I'm still not clear what meaningful effect any of this node name stuff
has :(
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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
* [PATCH v2] ARM: dts: rockchip: A few fixes for veyron-{fievel,tiger}
From: Matthias Kaehlcke @ 2019-07-31 15:15 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Heiko Stuebner
Cc: devicetree, Douglas Anderson, linux-kernel, linux-rockchip,
Matthias Kaehlcke, linux-arm-kernel
Fix/improve a few things for veyron fievel/tiger:
- move 'vccsys' regulator from tiger to fievel, both boards
have it (and tiger includes the fievel .dtsi)
- move 'ext_gmac' node below regulators
- fix GPIO ids of vcc5_host1 and vcc5_host2 regulators
- remove reset configuration from 'gmac' node, this is already done
in rk3288.dtsi
- fixed style issues of some multi-line comments
- switch 'vcc18_lcdt', 'vdd10_lcd' and 'vcc33_ccd' regulators off
during suspend
- no pull-up on the Bluetooth wake-up pin, there is an external
pull-up. The signal is active low, add the 'bt_host_wake_l'
pinctrl config
- move BC 1.2 pins up in the pinctrl config to keep 'wake only' pins
separate
- add BC 1.2 pins to sleep config
Fixes: 0067692b662e ("ARM: dts: rockchip: add veyron-fievel board")
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
Changes in v2:
- remove 'regulator-suspend-microvolt' property from regulators
that are off during suspend
- added Doug's 'Reviewed-by' tag
---
arch/arm/boot/dts/rk3288-veyron-fievel.dts | 58 +++++++++++++---------
arch/arm/boot/dts/rk3288-veyron-tiger.dts | 7 ---
arch/arm/boot/dts/rk3288-veyron.dtsi | 4 ++
3 files changed, 38 insertions(+), 31 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288-veyron-fievel.dts b/arch/arm/boot/dts/rk3288-veyron-fievel.dts
index 696566f72d30..65d029ccc907 100644
--- a/arch/arm/boot/dts/rk3288-veyron-fievel.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-fievel.dts
@@ -20,11 +20,11 @@
/delete-node/ bt-activity;
- ext_gmac: external-gmac-clock {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <125000000>;
- clock-output-names = "ext_gmac";
+ vccsys: vccsys {
+ compatible = "regulator-fixed";
+ regulator-name = "vccsys";
+ regulator-boot-on;
+ regulator-always-on;
};
/*
@@ -41,7 +41,7 @@
vcc5_host1: vcc5-host1-regulator {
compatible = "regulator-fixed";
enable-active-high;
- gpio = <&gpio5 RK_PC1 GPIO_ACTIVE_HIGH>;
+ gpio = <&gpio5 RK_PC2 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&hub_usb1_pwr_en>;
regulator-name = "vcc5_host1";
@@ -52,7 +52,7 @@
vcc5_host2: vcc5-host2-regulator {
compatible = "regulator-fixed";
enable-active-high;
- gpio = <&gpio5 RK_PC2 GPIO_ACTIVE_HIGH>;
+ gpio = <&gpio5 RK_PB6 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&hub_usb2_pwr_en>;
regulator-name = "vcc5_host2";
@@ -70,6 +70,13 @@
regulator-always-on;
regulator-boot-on;
};
+
+ ext_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <125000000>;
+ clock-output-names = "ext_gmac";
+ };
};
&gmac {
@@ -83,13 +90,13 @@
phy-supply = <&vcc33_lan>;
pinctrl-names = "default";
pinctrl-0 = <&rgmii_pins>, <&phy_rst>, <&phy_pmeb>, <&phy_int>;
- resets = <&cru SRST_MAC>;
- reset-names = "stmmaceth";
rx_delay = <0x10>;
tx_delay = <0x30>;
- /* Reset for the RTL8211 PHY which requires a 10-ms reset pulse (low)
- * with a 30ms settling time. */
+ /*
+ * Reset for the RTL8211 PHY which requires a 10-ms reset pulse (low)
+ * with a 30ms settling time.
+ */
snps,reset-gpio = <&gpio4 RK_PB0 0>;
snps,reset-active-low;
snps,reset-delays-us = <0 10000 30000>;
@@ -120,7 +127,8 @@
regulators {
/delete-node/ LDO_REG1;
- /* According to the schematic, vcc18_lcdt is for
+ /*
+ * According to the schematic, vcc18_lcdt is for
* HDMI_AVDD_1V8
*/
vcc18_lcdt: LDO_REG2 {
@@ -130,12 +138,12 @@
regulator-max-microvolt = <1800000>;
regulator-name = "vdd18_lcdt";
regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <1800000>;
+ regulator-off-in-suspend;
};
};
- /* This is not a pwren anymore, but the real power supply,
+ /*
+ * This is not a pwren anymore, but the real power supply,
* vdd10_lcd for HDMI_AVDD_1V0
*/
vdd10_lcd: LDO_REG7 {
@@ -145,8 +153,7 @@
regulator-max-microvolt = <1000000>;
regulator-name = "vdd10_lcd";
regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <1000000>;
+ regulator-off-in-suspend;
};
};
@@ -158,8 +165,7 @@
regulator-max-microvolt = <3300000>;
regulator-name = "vcc33_ccd";
regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <3300000>;
+ regulator-off-in-suspend;
};
};
@@ -180,7 +186,7 @@
interrupts = <RK_PD7 IRQ_TYPE_LEVEL_LOW>;
marvell,wakeup-pin = /bits/ 16 <13>;
pinctrl-names = "default";
- pinctrl-0 = <&bt_host_wake>;
+ pinctrl-0 = <&bt_host_wake_l>;
};
};
@@ -206,13 +212,13 @@
&ddrio_pwroff
&global_pwroff
- /* Wake only */
- &bt_dev_wake_awake
- &pwr_led1_on
-
/* For usb bc1.2 */
&usb_otg_ilim_sel
&usb_usb_ilim_sel
+
+ /* Wake only */
+ &bt_dev_wake_awake
+ &pwr_led1_on
>;
pinctrl-1 = <
@@ -221,6 +227,10 @@
&ddrio_pwroff
&global_pwroff
+ /* For usb bc1.2 */
+ &usb_otg_ilim_sel
+ &usb_usb_ilim_sel
+
/* Sleep only */
&bt_dev_wake_sleep
&pwr_led1_blink
diff --git a/arch/arm/boot/dts/rk3288-veyron-tiger.dts b/arch/arm/boot/dts/rk3288-veyron-tiger.dts
index fae26d530841..27557203ae33 100644
--- a/arch/arm/boot/dts/rk3288-veyron-tiger.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-tiger.dts
@@ -19,13 +19,6 @@
"google,veyron", "rockchip,rk3288";
/delete-node/ vcc18-lcd;
-
- vccsys: vccsys {
- compatible = "regulator-fixed";
- regulator-name = "vccsys";
- regulator-boot-on;
- regulator-always-on;
- };
};
&backlight {
diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi b/arch/arm/boot/dts/rk3288-veyron.dtsi
index 8fc8eac699bf..7525e3dd1fc1 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
@@ -586,6 +586,10 @@
rockchip,pins = <4 RK_PD7 RK_FUNC_GPIO &pcfg_pull_down>;
};
+ bt_host_wake_l: bt-host-wake-l {
+ rockchip,pins = <4 RK_PD7 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
/*
* We run sdio0 at max speed; bump up drive strength.
* We also have external pulls, so disable the internal ones.
--
2.22.0.709.g102302147b-goog
^ permalink raw reply related
* [PATCH] ARM: dts: stm32: remove useless pinctrl entries in stm32mp157-pinctrl
From: Alexandre Torgue @ 2019-07-31 15:26 UTC (permalink / raw)
To: Maxime Coquelin, arnd, robh+dt, mark.rutland
Cc: linux-arm-kernel, devicetree, Alexandre Torgue, linux-stm32,
linux-kernel
This patch removes "ngpios" and "gpio-ranges" information from
stm32mp157-pinctrl.dtsi file as it is now filled in stm32mp157 pinctrl
package files.
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
diff --git a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
index df6470133574..3f6008aa28a4 100644
--- a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
@@ -24,8 +24,6 @@
reg = <0x0 0x400>;
clocks = <&rcc GPIOA>;
st,bank-name = "GPIOA";
- ngpios = <16>;
- gpio-ranges = <&pinctrl 0 0 16>;
status = "disabled";
};
@@ -37,8 +35,6 @@
reg = <0x1000 0x400>;
clocks = <&rcc GPIOB>;
st,bank-name = "GPIOB";
- ngpios = <16>;
- gpio-ranges = <&pinctrl 0 16 16>;
status = "disabled";
};
@@ -50,8 +46,6 @@
reg = <0x2000 0x400>;
clocks = <&rcc GPIOC>;
st,bank-name = "GPIOC";
- ngpios = <16>;
- gpio-ranges = <&pinctrl 0 32 16>;
status = "disabled";
};
@@ -63,8 +57,6 @@
reg = <0x3000 0x400>;
clocks = <&rcc GPIOD>;
st,bank-name = "GPIOD";
- ngpios = <16>;
- gpio-ranges = <&pinctrl 0 48 16>;
status = "disabled";
};
@@ -76,8 +68,6 @@
reg = <0x4000 0x400>;
clocks = <&rcc GPIOE>;
st,bank-name = "GPIOE";
- ngpios = <16>;
- gpio-ranges = <&pinctrl 0 64 16>;
status = "disabled";
};
@@ -89,8 +79,6 @@
reg = <0x5000 0x400>;
clocks = <&rcc GPIOF>;
st,bank-name = "GPIOF";
- ngpios = <16>;
- gpio-ranges = <&pinctrl 0 80 16>;
status = "disabled";
};
@@ -102,8 +90,6 @@
reg = <0x6000 0x400>;
clocks = <&rcc GPIOG>;
st,bank-name = "GPIOG";
- ngpios = <16>;
- gpio-ranges = <&pinctrl 0 96 16>;
status = "disabled";
};
@@ -115,8 +101,6 @@
reg = <0x7000 0x400>;
clocks = <&rcc GPIOH>;
st,bank-name = "GPIOH";
- ngpios = <16>;
- gpio-ranges = <&pinctrl 0 112 16>;
status = "disabled";
};
@@ -128,8 +112,6 @@
reg = <0x8000 0x400>;
clocks = <&rcc GPIOI>;
st,bank-name = "GPIOI";
- ngpios = <16>;
- gpio-ranges = <&pinctrl 0 128 16>;
status = "disabled";
};
@@ -141,8 +123,6 @@
reg = <0x9000 0x400>;
clocks = <&rcc GPIOJ>;
st,bank-name = "GPIOJ";
- ngpios = <16>;
- gpio-ranges = <&pinctrl 0 144 16>;
status = "disabled";
};
@@ -154,8 +134,6 @@
reg = <0xa000 0x400>;
clocks = <&rcc GPIOK>;
st,bank-name = "GPIOK";
- ngpios = <8>;
- gpio-ranges = <&pinctrl 0 160 8>;
status = "disabled";
};
@@ -849,8 +827,6 @@
clocks = <&rcc GPIOZ>;
st,bank-name = "GPIOZ";
st,bank-ioport = <11>;
- ngpios = <8>;
- gpio-ranges = <&pinctrl_z 0 400 8>;
status = "disabled";
};
--
2.17.1
^ permalink raw reply related
* Re: [RFC PATCH 2/2] soc: ti: Add Support for the TI Page-based Address Translator (PAT)
From: Andrew F. Davis @ 2019-07-31 15:28 UTC (permalink / raw)
To: Tero Kristo, Rob Herring, Mark Rutland, Santosh Shilimkar,
Will Deacon, Robin Murphy, Joerg Roedel, David Airlie,
Daniel Vetter, William Mills, Tomi Valkeinen, Sumit Semwal,
John Stultz
Cc: devicetree, linux-kernel, dri-devel, linaro-mm-sig, iommu,
linux-arm-kernel, linux-media
In-Reply-To: <28dea95d-8ae6-431c-ca88-149972d26502@ti.com>
On 6/18/19 5:07 AM, Tero Kristo wrote:
> On 07/06/2019 22:35, Andrew F. Davis wrote:
>> This patch adds a driver for the Page-based Address Translator (PAT)
>> present on various TI SoCs. A PAT device performs address translation
>> using tables stored in an internal SRAM. Each PAT supports a set number
>> of pages, each occupying a programmable 4KB, 16KB, 64KB, or 1MB of
>> addresses in a window for which an incoming transaction will be
>> translated.
>>
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> ---
>> drivers/soc/ti/Kconfig | 9 +
>> drivers/soc/ti/Makefile | 1 +
>> drivers/soc/ti/ti-pat.c | 569 ++++++++++++++++++++++++++++++++++++
>> include/uapi/linux/ti-pat.h | 44 +++
>> 4 files changed, 623 insertions(+)
>> create mode 100644 drivers/soc/ti/ti-pat.c
>> create mode 100644 include/uapi/linux/ti-pat.h
>>
>> diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
>> index f0be35d3dcba..b838ae74d01f 100644
>> --- a/drivers/soc/ti/Kconfig
>> +++ b/drivers/soc/ti/Kconfig
>> @@ -86,4 +86,13 @@ config TI_SCI_INTA_MSI_DOMAIN
>> help
>> Driver to enable Interrupt Aggregator specific MSI Domain.
>> +config TI_PAT
>> + tristate "TI PAT DMA-BUF exporter"
>> + select REGMAP
>
> What is the reasoning for using regmap for internal register access? Why
> not just use direct readl/writel for everything? To me it seems this is
> only used during probe time also...
>
There are two register spaces, the configuration space, and the actual
translation table data. I use regmap for all the configuration space.
Direct readl/writel would also work, but I prefer regmap as it lets me
work with field names vs using masks and shifts, even if it adds a
little extra code in tables at the top.
>> + help
>> + Driver for TI Page-based Address Translator (PAT). This driver
>> + provides the an API allowing the remapping of a non-contiguous
>> + DMA-BUF into a contiguous one that is sutable for devices needing
>> + coniguous memory.
>
> Minor typo: contiguous.
>
ACK
>> +
>> endif # SOC_TI
>> diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
>> index b3868d392d4f..1369642b40c3 100644
>> --- a/drivers/soc/ti/Makefile
>> +++ b/drivers/soc/ti/Makefile
>> @@ -9,3 +9,4 @@ obj-$(CONFIG_AMX3_PM) += pm33xx.o
>> obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
>> obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
>> obj-$(CONFIG_TI_SCI_INTA_MSI_DOMAIN) += ti_sci_inta_msi.o
>> +obj-$(CONFIG_TI_PAT) += ti-pat.o
>> diff --git a/drivers/soc/ti/ti-pat.c b/drivers/soc/ti/ti-pat.c
>> new file mode 100644
>> index 000000000000..7359ea0f7ccf
>> --- /dev/null
>> +++ b/drivers/soc/ti/ti-pat.c
>> @@ -0,0 +1,569 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * TI PAT mapped DMA-BUF memory re-exporter
>> + *
>> + * Copyright (C) 2018-2019 Texas Instruments Incorporated -
>> http://www.ti.com/
>> + * Andrew F. Davis <afd@ti.com>
>> + */
>> +
>> +#include <linux/fs.h>
>> +#include <linux/module.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/mod_devicetable.h>
>> +#include <linux/uaccess.h>
>> +#include <linux/miscdevice.h>
>> +#include <linux/regmap.h>
>> +#include <linux/dma-buf.h>
>> +#include <linux/genalloc.h>
>> +#include <linux/vmalloc.h>
>> +#include <linux/slab.h>
>> +
>> +#include <linux/ti-pat.h>
>> +
>> +#define TI_PAT_DRIVER_NAME "ti-pat"
>
> Why do you have a define for this seeing it is only used in single
> location?
>
Just habit when starting a driver, but you are right it is not needed here.
>> +
>> +/* TI PAT MMRS registers */
>> +#define TI_PAT_MMRS_PID 0x0 /* Revision Register */
>> +#define TI_PAT_MMRS_CONFIG 0x4 /* Config Register */
>> +#define TI_PAT_MMRS_CONTROL 0x10 /* Control Register */
>> +
>> +/* TI PAT CONTROL register field values */
>> +#define TI_PAT_CONTROL_ARB_MODE_UF 0x0 /* Updates first */
>> +#define TI_PAT_CONTROL_ARB_MODE_RR 0x2 /* Round-robin */
>> +
>> +#define TI_PAT_CONTROL_PAGE_SIZE_4KB 0x0
>> +#define TI_PAT_CONTROL_PAGE_SIZE_16KB 0x1
>> +#define TI_PAT_CONTROL_PAGE_SIZE_64KB 0x2
>> +#define TI_PAT_CONTROL_PAGE_SIZE_1MB 0x3
>> +
>> +static unsigned int ti_pat_page_sizes[] = {
>> + [TI_PAT_CONTROL_PAGE_SIZE_4KB] = 4 * 1024,
>> + [TI_PAT_CONTROL_PAGE_SIZE_16KB] = 16 * 1024,
>> + [TI_PAT_CONTROL_PAGE_SIZE_64KB] = 64 * 1024,
>> + [TI_PAT_CONTROL_PAGE_SIZE_1MB] = 1024 * 1024,
>> +};
>> +
>> +enum ti_pat_mmrs_fields {
>> + /* Revision */
>> + F_PID_MAJOR,
>> + F_PID_MINOR,
>> +
>> + /* Controls */
>> + F_CONTROL_ARB_MODE,
>> + F_CONTROL_PAGE_SIZE,
>> + F_CONTROL_REPLACE_OID_EN,
>> + F_CONTROL_EN,
>> +
>> + /* sentinel */
>> + F_MAX_FIELDS
>> +};
>> +
>> +static const struct reg_field ti_pat_mmrs_reg_fields[] = {
>> + /* Revision */
>> + [F_PID_MAJOR] = REG_FIELD(TI_PAT_MMRS_PID, 8, 10),
>> + [F_PID_MINOR] = REG_FIELD(TI_PAT_MMRS_PID, 0, 5),
>> + /* Controls */
>> + [F_CONTROL_ARB_MODE] = REG_FIELD(TI_PAT_MMRS_CONTROL, 6, 7),
>> + [F_CONTROL_PAGE_SIZE] = REG_FIELD(TI_PAT_MMRS_CONTROL, 4, 5),
>> + [F_CONTROL_REPLACE_OID_EN] = REG_FIELD(TI_PAT_MMRS_CONTROL, 1,
>> 1),
>> + [F_CONTROL_EN] = REG_FIELD(TI_PAT_MMRS_CONTROL, 0, 0),
>> +};
>> +
>> +/**
>> + * struct ti_pat_data - PAT device instance data
>> + * @dev: PAT device structure
>> + * @mdev: misc device
>> + * @mmrs_map: Register map of MMRS region
>> + * @table_base: Base address of TABLE region
>
> Please add kerneldoc comments for all fields.
>
Will add.
>> + */
>> +struct ti_pat_data {
>> + struct device *dev;
>> + struct miscdevice mdev;
>> + struct regmap *mmrs_map;
>> + struct regmap_field *mmrs_fields[F_MAX_FIELDS];
>> + void __iomem *table_base;
>> + unsigned int page_count;
>> + unsigned int page_size;
>> + phys_addr_t window_base;
>> + struct gen_pool *pool;
>> +};
>> +
>
> Kerneldoc comments for below structs would be also useful, especially
> for ti_pat_buffer.
>
Will add.
>> +struct ti_pat_dma_buf_attachment {
>> + struct device *dev;
>> + struct sg_table *table;
>> + struct ti_pat_buffer *buffer;
>> + struct list_head list;
>> +};
>> +
>> +struct ti_pat_buffer {
>> + struct ti_pat_data *pat;
>> + struct dma_buf *i_dma_buf;
>> + size_t size;
>> + unsigned long offset;
>> + struct dma_buf *e_dma_buf;
>> +
>> + struct dma_buf_attachment *attachment;
>> + struct sg_table *sgt;
>> +
>> + struct list_head attachments;
>> + int map_count;
>> +
>> + struct mutex lock;
>> +};
>> +
>> +static const struct regmap_config ti_pat_regmap_config = {
>> + .reg_bits = 32,
>> + .val_bits = 32,
>> + .reg_stride = 4,
>> +};
>> +
>> +static int ti_pat_dma_buf_attach(struct dma_buf *dmabuf,
>> + struct dma_buf_attachment *attachment)
>> +{
>> + struct ti_pat_dma_buf_attachment *a;
>> + struct ti_pat_buffer *buffer = dmabuf->priv;
>> +
>> + a = kzalloc(sizeof(*a), GFP_KERNEL);
>> + if (!a)
>> + return -ENOMEM;
>> +
>> + a->dev = attachment->dev;
>> + a->buffer = buffer;
>> + INIT_LIST_HEAD(&a->list);
>> +
>> + a->table = kzalloc(sizeof(*a->table), GFP_KERNEL);
>> + if (!a->table) {
>> + kfree(a);
>> + return -ENOMEM;
>> + }
>> +
>> + if (sg_alloc_table(a->table, 1, GFP_KERNEL)) {
>> + kfree(a->table);
>> + kfree(a);
>> + return -ENOMEM;
>> + }
>> +
>> + sg_set_page(a->table->sgl, pfn_to_page(PFN_DOWN(buffer->offset)),
>> buffer->size, 0);
>> +
>> + attachment->priv = a;
>> +
>> + mutex_lock(&buffer->lock);
>> + /* First time attachment we attach to parent */
>> + if (list_empty(&buffer->attachments)) {
>> + buffer->attachment = dma_buf_attach(buffer->i_dma_buf,
>> buffer->pat->dev);
>> + if (IS_ERR(buffer->attachment)) {
>> + dev_err(buffer->pat->dev, "Unable to attach to parent
>> DMA-BUF\n");
>> + mutex_unlock(&buffer->lock);
>> + kfree(a->table);
>> + kfree(a);
>> + return PTR_ERR(buffer->attachment);
>> + }
>> + }
>> + list_add(&a->list, &buffer->attachments);
>> + mutex_unlock(&buffer->lock);
>> +
>> + return 0;
>> +}
>> +
>> +static void ti_pat_dma_buf_detatch(struct dma_buf *dmabuf,
>> + struct dma_buf_attachment *attachment)
>
> Func name should be ti_pat_dma_buf_detach instead?
>
Good catch, will fix.
> Other than that, I can't see anything obvious with my limited experience
> with dma_buf. Is there a simple way to test this driver btw?
>
Simple way? No not really.. What I've been doing is allocating a
non-contiguous buffer (from system DMA-BUF heaps), writing some test
pattern to it, using this driver to convert the buffer, then sending the
new handle to our DSS (display subsystem which cannot handle
non-contiguous buffers). If all is working the test pattern is displayed
correctly.
Thanks,
Andrew
> -Tero
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* RE: [PATCH net-next v4 0/4] enetc: Add mdio bus driver for the PCIe MDIO endpoint
From: Claudiu Manoil @ 2019-07-31 15:30 UTC (permalink / raw)
To: David Miller
Cc: andrew@lunn.ch, robh+dt@kernel.org, Leo Li, Alexandru Marginean,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190730.095344.401137621326119500.davem@davemloft.net>
>-----Original Message-----
>From: David Miller <davem@davemloft.net>
>Sent: Tuesday, July 30, 2019 7:54 PM
>To: Claudiu Manoil <claudiu.manoil@nxp.com>
>Cc: andrew@lunn.ch; robh+dt@kernel.org; Leo Li <leoyang.li@nxp.com>;
>Alexandru Marginean <alexandru.marginean@nxp.com>;
>netdev@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
>kernel@lists.infradead.org; linux-kernel@vger.kernel.org
>Subject: Re: [PATCH net-next v4 0/4] enetc: Add mdio bus driver for the PCIe
>MDIO endpoint
>
>From: David Miller <davem@davemloft.net>
>Date: Tue, 30 Jul 2019 09:44:36 -0700 (PDT)
>
>> From: Claudiu Manoil <claudiu.manoil@nxp.com>
>> Date: Tue, 30 Jul 2019 12:45:15 +0300
>>
>>> First patch fixes a sparse issue and cleans up accessors to avoid
>>> casting to __iomem.
>>> Second patch just registers the PCIe endpoint device containing
>>> the MDIO registers as a standalone MDIO bus driver, to allow
>>> an alternative way to control the MDIO bus. The same code used
>>> by the ENETC ports (eth controllers) to manage MDIO via local
>>> registers applies and is reused.
>>>
>>> Bindings are provided for the new MDIO node, similarly to ENETC
>>> port nodes bindings.
>>>
>>> Last patch enables the ENETC port 1 and its RGMII PHY on the
>>> LS1028A QDS board, where the MDIO muxing configuration relies
>>> on the MDIO support provided in the first patch.
>> ...
>>
>> Series applied, thank you.
>
>Actually this doesn't compile, I had to revert:
>
Sorry, I overlooked the module part. Turns out I have to define a separate
module for this driver (mdio), refactor common code between the mdio module
and the enetc-pf module, clean up the Makefile... and do more checks.
^ permalink raw reply
* [PATCH v2 0/6] Add support of New Amlogic temperature sensor for G12 SoCs
From: Guillaume La Roque @ 2019-07-31 15:35 UTC (permalink / raw)
To: daniel.lezcano, khilman
Cc: linux-pm, devicetree, linux-amlogic, linux-kernel,
linux-arm-kernel
This patchs series add support of New Amlogic temperature sensor and minimal
thermal zone for SEI510 and ODROID-N2 boards.
First implementation was doing on IIO[1] but after comments i move on thermal framework.
Formulas and calibration values come from amlogic.
Changes since v1:
- fix enum vs const in documentation for compatible
- fix error with thermal-sensor-cells value set to 1 instead of 0
- add some dependencies needed to add cooling-maps
Dependencies :
- patch 3,4 & 5: depends on Neil's patch and series :
- missing dwc2 phy-names[1]
- patchsets to add DVFS on G12a[3] which have deps on [4] and [5]
[1] https://lore.kernel.org/linux-amlogic/20190604144714.2009-1-glaroque@baylibre.com/
[2] https://lore.kernel.org/linux-amlogic/20190625123647.26117-1-narmstrong@baylibre.com/
[3] https://lore.kernel.org/linux-amlogic/20190729132622.7566-1-narmstrong@baylibre.com/
[4] https://lore.kernel.org/linux-amlogic/20190731084019.8451-5-narmstrong@baylibre.com/
[5] https://lore.kernel.org/linux-amlogic/20190729132622.7566-3-narmstrong@baylibre.com/
Guillaume La Roque (6):
dt-bindings: thermal: Add DT bindings documentation for Amlogic
Thermal
thermal: amlogic: Add thermal driver to support G12 SoCs
arm64: dts: amlogic: g12: add temperature sensor
arm64: dts: meson: sei510: Add minimal thermal zone
arm64: dts: amlogic: odroid-n2: add minimal thermal zone
MAINTAINERS: add entry for Amlogic Thermal driver
.../bindings/thermal/amlogic,thermal.yaml | 58 +++
MAINTAINERS | 9 +
.../boot/dts/amlogic/meson-g12-common.dtsi | 22 ++
.../boot/dts/amlogic/meson-g12a-sei510.dts | 56 +++
.../boot/dts/amlogic/meson-g12b-odroid-n2.dts | 60 ++++
drivers/thermal/Kconfig | 11 +
drivers/thermal/Makefile | 1 +
drivers/thermal/amlogic_thermal.c | 332 ++++++++++++++++++
8 files changed, 549 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
create mode 100644 drivers/thermal/amlogic_thermal.c
--
2.17.1
^ permalink raw reply
* [PATCH v2 1/6] dt-bindings: thermal: Add DT bindings documentation for Amlogic Thermal
From: Guillaume La Roque @ 2019-07-31 15:35 UTC (permalink / raw)
To: daniel.lezcano, khilman
Cc: linux-pm, devicetree, linux-amlogic, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190731153529.30159-1-glaroque@baylibre.com>
Adding the devicetree binding documentation for the Amlogic temperature
sensor found in the Amlogic Meson G12 SoCs.
the G12A and G12B SoCs are supported.
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
---
.../bindings/thermal/amlogic,thermal.yaml | 58 +++++++++++++++++++
1 file changed, 58 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
new file mode 100644
index 000000000000..f10537ab4c8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/amlogic,thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Thermal Driver
+
+maintainers:
+ - Guillaume La Roque <glaroque@baylibre.com>
+
+description: Amlogic Thermal driver
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - amlogic,g12-cpu-thermal
+ - amlogic,g12-ddr-thermal
+ - const:
+ - amlogic,g12-thermal
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ amlogic,ao-secure:
+ description: phandle to the ao-secure syscon
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - amlogic,ao-secure
+
+examples:
+ - |
+ cpu_temp: temperature-sensor@ff634800 {
+ compatible = "amlogic,g12-cpu-thermal",
+ "amlogic,g12-thermal";
+ reg = <0x0 0xff634800 0x0 0x50>;
+ interrupts = <0x0 0x24 0x0>;
+ clocks = <&clk 164>;
+ status = "okay";
+ #thermal-sensor-cells = <0>;
+ amlogic,ao-secure = <&sec_AO>;
+ };
+...
\ No newline at end of file
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/6] thermal: amlogic: Add thermal driver to support G12 SoCs
From: Guillaume La Roque @ 2019-07-31 15:35 UTC (permalink / raw)
To: daniel.lezcano, khilman
Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel,
linux-pm
In-Reply-To: <20190731153529.30159-1-glaroque@baylibre.com>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
---
drivers/thermal/Kconfig | 11 +
drivers/thermal/Makefile | 1 +
drivers/thermal/amlogic_thermal.c | 332 ++++++++++++++++++++++++++++++
3 files changed, 344 insertions(+)
create mode 100644 drivers/thermal/amlogic_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 9966364a6deb..0f31bb4bc372 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -348,6 +348,17 @@ config MTK_THERMAL
Enable this option if you want to have support for thermal management
controller present in Mediatek SoCs
+config AMLOGIC_THERMAL
+ tristate "Amlogic Thermal Support"
+ default ARCH_MESON
+ depends on OF && ARCH_MESON
+ help
+ If you say yes here you get support for Amlogic Thermal
+ for G12 SoC Family.
+
+ This driver can also be built as a module. If so, the module will
+ be called amlogic_thermal.
+
menu "Intel thermal drivers"
depends on X86 || X86_INTEL_QUARK || COMPILE_TEST
source "drivers/thermal/intel/Kconfig"
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 74a37c7f847a..baeb70bf0568 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -54,3 +54,4 @@ obj-$(CONFIG_MTK_THERMAL) += mtk_thermal.o
obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
obj-$(CONFIG_ZX2967_THERMAL) += zx2967_thermal.o
obj-$(CONFIG_UNIPHIER_THERMAL) += uniphier_thermal.o
+obj-$(CONFIG_AMLOGIC_THERMAL) += amlogic_thermal.o
diff --git a/drivers/thermal/amlogic_thermal.c b/drivers/thermal/amlogic_thermal.c
new file mode 100644
index 000000000000..13cd4c42721a
--- /dev/null
+++ b/drivers/thermal/amlogic_thermal.c
@@ -0,0 +1,332 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Amlogic Meson Thermal Sensor Driver
+ *
+ * Copyright (C) 2017 Huan Biao <huan.biao@amlogic.com>
+ * Copyright (C) 2019 Guillaume La Roque <glaroque@baylibre.com>
+ *
+ * Register value to celsius temperature formulas:
+ * Read_Val m * U
+ * U = ---------, Uptat = ---------
+ * 2^16 1 + n * U
+ *
+ * Temperature = A * ( Uptat + u_efuse / 2^16 )- B
+ *
+ * A B m n : calibration parameters
+ * u_efuse : fused calibration value, it's a signed 16 bits value
+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/thermal.h>
+
+#include "thermal_core.h"
+
+#define TSENSOR_CFG_REG1 0x4
+ #define TSENSOR_CFG_REG1_RSET_VBG BIT(12)
+ #define TSENSOR_CFG_REG1_RSET_ADC BIT(11)
+ #define TSENSOR_CFG_REG1_VCM_EN BIT(10)
+ #define TSENSOR_CFG_REG1_VBG_EN BIT(9)
+ #define TSENSOR_CFG_REG1_OUT_CTL BIT(6)
+ #define TSENSOR_CFG_REG1_FILTER_EN BIT(5)
+ #define TSENSOR_CFG_REG1_DEM_EN BIT(3)
+ #define TSENSOR_CFG_REG1_CH_SEL GENMASK(1, 0)
+ #define TSENSOR_CFG_REG1_ENABLE \
+ (TSENSOR_CFG_REG1_FILTER_EN | \
+ TSENSOR_CFG_REG1_VCM_EN | \
+ TSENSOR_CFG_REG1_VBG_EN | \
+ TSENSOR_CFG_REG1_DEM_EN | \
+ TSENSOR_CFG_REG1_CH_SEL)
+
+#define TSENSOR_STAT0 0x40
+
+#define TSENSOR_STAT9 0x64
+
+#define TSENSOR_READ_TEMP_MASK GENMASK(15, 0)
+#define TSENSOR_TEMP_MASK GENMASK(11, 0)
+
+#define TSENSOR_TRIM_SIGN_MASK BIT(15)
+#define TSENSOR_TRIM_TEMP_MASK GENMASK(14, 0)
+#define TSENSOR_TRIM_VERSION_MASK GENMASK(31, 24)
+
+#define TSENSOR_TRIM_VERSION(_version) \
+ FIELD_GET(TSENSOR_TRIM_VERSION_MASK, _version)
+
+#define TSENSOR_TRIM_CALIB_VALID_MASK (GENMASK(3, 2) | BIT(7))
+
+#define TSENSOR_CALIB_OFFSET 1
+#define TSENSOR_CALIB_SHIFT 4
+
+/**
+ * struct amlogic_thermal_soc_data
+ * @A, B, m, n: calibration parameters
+ * This structure is required for configuration of amlogic thermal driver.
+ */
+struct amlogic_thermal_soc_data {
+ int A;
+ int B;
+ int m;
+ int n;
+};
+
+/**
+ * struct amlogic_thermal_data
+ * @u_efuse_off: register offset to read fused calibration value
+ * @soc: calibration parameters structure pointer
+ * @regmap_config: regmap config for the device
+ * This structure is required for configuration of amlogic thermal driver.
+ */
+struct amlogic_thermal_data {
+ int u_efuse_off;
+ const struct amlogic_thermal_soc_data *soc;
+ const struct regmap_config *regmap_config;
+};
+
+struct amlogic_thermal {
+ struct platform_device *pdev;
+ const struct amlogic_thermal_data *data;
+ struct regmap *regmap;
+ struct regmap *sec_ao_map;
+ struct clk *clk;
+ struct thermal_zone_device *tzd;
+ u32 trim_info;
+ void __iomem *base;
+};
+
+/*
+ * Calculate a temperature value from a temperature code.
+ * The unit of the temperature is degree Celsius.
+ */
+static int code_to_temp(struct amlogic_thermal *pdata, int temp_code)
+{
+ const struct amlogic_thermal_soc_data *param = pdata->data->soc;
+ int temp;
+ s64 factor, Uptat, uefuse;
+
+ uefuse = pdata->trim_info & TSENSOR_TRIM_SIGN_MASK ?
+ ~(pdata->trim_info & TSENSOR_TRIM_TEMP_MASK) + 1 :
+ (pdata->trim_info & TSENSOR_TRIM_TEMP_MASK);
+
+ factor = param->n * temp_code;
+ factor = div_s64(factor, 100);
+
+ Uptat = temp_code * param->m;
+ Uptat = div_s64(Uptat, 100);
+ Uptat = Uptat * BIT(16);
+ Uptat = div_s64(Uptat, BIT(16) + factor);
+
+ temp = (Uptat + uefuse) * param->A;
+ temp = div_s64(temp, BIT(16));
+ temp = (temp - param->B) * 100;
+
+ return temp;
+}
+
+static int amlogic_thermal_initialize(struct amlogic_thermal *pdata)
+{
+ int ret = 0;
+ int ver;
+
+ regmap_read(pdata->sec_ao_map, pdata->data->u_efuse_off,
+ &pdata->trim_info);
+
+ ver = TSENSOR_TRIM_VERSION(pdata->trim_info);
+
+ if ((ver & TSENSOR_TRIM_CALIB_VALID_MASK) == 0) {
+ ret = -EINVAL;
+ dev_err(&pdata->pdev->dev,
+ "tsensor thermal calibration not supported: 0x%x!\n",
+ ver);
+ }
+
+ return ret;
+}
+
+static int amlogic_thermal_enable(struct amlogic_thermal *data)
+{
+ clk_prepare_enable(data->clk);
+ regmap_update_bits(data->regmap, TSENSOR_CFG_REG1,
+ TSENSOR_CFG_REG1_ENABLE, TSENSOR_CFG_REG1_ENABLE);
+
+ return 0;
+}
+
+static int amlogic_thermal_disable(struct amlogic_thermal *data)
+{
+ regmap_update_bits(data->regmap, TSENSOR_CFG_REG1,
+ TSENSOR_CFG_REG1_ENABLE, 0);
+ clk_disable(data->clk);
+
+ return 0;
+}
+
+static int amlogic_thermal_get_temp(void *data, int *temp)
+{
+ unsigned int tvalue;
+ struct amlogic_thermal *pdata = data;
+
+ if (!data)
+ return -EINVAL;
+
+ regmap_read(pdata->regmap, TSENSOR_STAT0, &tvalue);
+ *temp = code_to_temp(pdata,
+ tvalue & TSENSOR_READ_TEMP_MASK);
+
+ return 0;
+}
+
+static const struct thermal_zone_of_device_ops amlogic_thermal_ops = {
+ .get_temp = amlogic_thermal_get_temp,
+};
+
+static const struct regmap_config amlogic_thermal_regmap_config_g12 = {
+ .reg_bits = 8,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = TSENSOR_STAT9,
+};
+
+static const struct amlogic_thermal_soc_data amlogic_thermal_g12 = {
+ .A = 9411,
+ .B = 3159,
+ .m = 424,
+ .n = 324,
+};
+
+static const struct amlogic_thermal_data amlogic_thermal_g12_cpu_param = {
+ .u_efuse_off = 0x128,
+ .soc = &amlogic_thermal_g12,
+ .regmap_config = &amlogic_thermal_regmap_config_g12,
+};
+
+static const struct amlogic_thermal_data amlogic_thermal_g12_ddr_param = {
+ .u_efuse_off = 0xF0,
+ .soc = &amlogic_thermal_g12,
+ .regmap_config = &amlogic_thermal_regmap_config_g12,
+};
+
+static const struct of_device_id of_amlogic_thermal_match[] = {
+ {
+ .compatible = "amlogic,g12-ddr-thermal",
+ .data = &amlogic_thermal_g12_ddr_param,
+ },
+ {
+ .compatible = "amlogic,g12-cpu-thermal",
+ .data = &amlogic_thermal_g12_cpu_param,
+ },
+ { /* end */ }
+};
+MODULE_DEVICE_TABLE(of, of_amlogic_thermal_match);
+
+static int amlogic_thermal_probe(struct platform_device *pdev)
+{
+ struct amlogic_thermal *pdata;
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ int ret;
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdata->data = of_device_get_match_data(dev);
+ pdata->pdev = pdev;
+ platform_set_drvdata(pdev, pdata);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ pdata->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(pdata->base)) {
+ dev_err(dev, "failed to get io address\n");
+ return PTR_ERR(pdata->base);
+ }
+
+ pdata->regmap = devm_regmap_init_mmio(dev, pdata->base,
+ pdata->data->regmap_config);
+ if (IS_ERR(pdata->regmap))
+ return PTR_ERR(pdata->regmap);
+
+ pdata->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(pdata->clk)) {
+ if (PTR_ERR(pdata->clk) != -EPROBE_DEFER)
+ dev_err(dev, "failed to get clock\n");
+ return PTR_ERR(pdata->clk);
+ }
+
+ pdata->sec_ao_map = syscon_regmap_lookup_by_phandle
+ (pdev->dev.of_node, "amlogic,ao-secure");
+ if (IS_ERR(pdata->sec_ao_map)) {
+ dev_err(dev, "syscon regmap lookup failed.\n");
+ return PTR_ERR(pdata->sec_ao_map);
+ }
+
+ pdata->tzd = devm_thermal_zone_of_sensor_register
+ (&pdev->dev,
+ 0,
+ pdata,
+ &amlogic_thermal_ops);
+ if (IS_ERR(pdata->tzd)) {
+ ret = PTR_ERR(pdata->tzd);
+ dev_err(dev, "Failed to register tsensor: %d\n", ret);
+ return PTR_ERR(pdata->tzd);
+ }
+
+ ret = amlogic_thermal_initialize(pdata);
+ if (ret)
+ return ret;
+
+ ret = amlogic_thermal_enable(pdata);
+ if (ret)
+ clk_unprepare(pdata->clk);
+
+ return ret;
+}
+
+static int amlogic_thermal_remove(struct platform_device *pdev)
+{
+ struct amlogic_thermal *data = platform_get_drvdata(pdev);
+
+ return amlogic_thermal_disable(data);
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int amlogic_thermal_suspend(struct device *dev)
+{
+ struct amlogic_thermal *data = dev_get_drvdata(dev);
+
+ return amlogic_thermal_disable(data);
+}
+
+static int amlogic_thermal_resume(struct device *dev)
+{
+ struct amlogic_thermal *data = dev_get_drvdata(dev);
+
+ return amlogic_thermal_enable(data);
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(amlogic_thermal_pm_ops,
+ amlogic_thermal_suspend, amlogic_thermal_resume);
+
+static struct platform_driver amlogic_thermal_driver = {
+ .driver = {
+ .name = "amlogic_thermal",
+ .pm = &amlogic_thermal_pm_ops,
+ .of_match_table = of_amlogic_thermal_match,
+ },
+ .probe = amlogic_thermal_probe,
+ .remove = amlogic_thermal_remove,
+};
+
+module_platform_driver(amlogic_thermal_driver);
+
+MODULE_AUTHOR("Guillaume La Roque <glaroque@baylibre.com>");
+MODULE_DESCRIPTION("Amlogic thermal driver");
+MODULE_LICENSE("GPL v2");
--
2.17.1
^ permalink raw reply related
* [PATCH v2 3/6] arm64: dts: amlogic: g12: add temperature sensor
From: Guillaume La Roque @ 2019-07-31 15:35 UTC (permalink / raw)
To: daniel.lezcano, khilman
Cc: linux-pm, devicetree, linux-amlogic, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190731153529.30159-1-glaroque@baylibre.com>
Add cpu and ddr temperature sensors for G12 Socs
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
---
.../boot/dts/amlogic/meson-g12-common.dtsi | 22 +++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
index 06e186ca41e3..7f862a3490fb 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
@@ -1353,6 +1353,28 @@
};
};
+ cpu_temp: temperature-sensor@34800 {
+ compatible = "amlogic,g12-cpu-thermal",
+ "amlogic,g12-thermal";
+ reg = <0x0 0x34800 0x0 0x50>;
+ interrupts = <GIC_SPI 35 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clkc CLKID_TS>;
+ status = "okay";
+ #thermal-sensor-cells = <0>;
+ amlogic,ao-secure = <&sec_AO>;
+ };
+
+ ddr_temp: temperature-sensor@34c00 {
+ compatible = "amlogic,g12-ddr-thermal",
+ "amlogic,g12-thermal";
+ reg = <0x0 0x34c00 0x0 0x50>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clkc CLKID_TS>;
+ status = "okay";
+ #thermal-sensor-cells = <0>;
+ amlogic,ao-secure = <&sec_AO>;
+ };
+
usb2_phy0: phy@36000 {
compatible = "amlogic,g12a-usb2-phy";
reg = <0x0 0x36000 0x0 0x2000>;
--
2.17.1
^ permalink raw reply related
* [PATCH v2 4/6] arm64: dts: meson: sei510: Add minimal thermal zone
From: Guillaume La Roque @ 2019-07-31 15:35 UTC (permalink / raw)
To: daniel.lezcano, khilman
Cc: linux-pm, devicetree, linux-amlogic, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190731153529.30159-1-glaroque@baylibre.com>
Add minimal thermal zone for DDR and CPU sensor
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
---
.../boot/dts/amlogic/meson-g12a-sei510.dts | 56 +++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts b/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
index 979449968a5f..2c16a2cba0a3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12a-sei510.dts
@@ -10,6 +10,7 @@
#include <dt-bindings/input/input.h>
#include <dt-bindings/gpio/meson-g12a-gpio.h>
#include <dt-bindings/sound/meson-g12a-tohdmitx.h>
+#include <dt-bindings/thermal/thermal.h>
/ {
compatible = "seirobotics,sei510", "amlogic,g12a";
@@ -33,6 +34,53 @@
ethernet0 = ðmac;
};
+ thermal-zones {
+ cpu-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&cpu_temp>;
+
+ trips {
+ cpu_critical: cpu-critical {
+ temperature = <110000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&cpu_critical>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+
+ ddr-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&ddr_temp>;
+
+ trips {
+ ddr_critical: ddr-critical {
+ temperature = <110000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&ddr_critical>;
+ cooling-device = <&mali THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+ };
+
mono_dac: audio-codec-0 {
compatible = "maxim,max98357a";
#sound-dai-cells = <0>;
@@ -321,6 +369,7 @@
operating-points-v2 = <&cpu_opp_table>;
clocks = <&clkc CLKID_CPU_CLK>;
clock-latency = <50000>;
+ #cooling-cells = <2>;
};
&cpu1 {
@@ -328,6 +377,7 @@
operating-points-v2 = <&cpu_opp_table>;
clocks = <&clkc CLKID_CPU_CLK>;
clock-latency = <50000>;
+ #cooling-cells = <2>;
};
&cpu2 {
@@ -335,6 +385,7 @@
operating-points-v2 = <&cpu_opp_table>;
clocks = <&clkc CLKID_CPU_CLK>;
clock-latency = <50000>;
+ #cooling-cells = <2>;
};
&cpu3 {
@@ -342,6 +393,7 @@
operating-points-v2 = <&cpu_opp_table>;
clocks = <&clkc CLKID_CPU_CLK>;
clock-latency = <50000>;
+ #cooling-cells = <2>;
};
&cvbs_vdac_port {
@@ -368,6 +420,10 @@
status = "okay";
};
+&mali {
+ #cooling-cells = <2>;
+};
+
&hdmi_tx {
status = "okay";
pinctrl-0 = <&hdmitx_hpd_pins>, <&hdmitx_ddc_pins>;
--
2.17.1
^ permalink raw reply related
* [PATCH v2 5/6] arm64: dts: amlogic: odroid-n2: add minimal thermal zone
From: Guillaume La Roque @ 2019-07-31 15:35 UTC (permalink / raw)
To: daniel.lezcano, khilman
Cc: linux-pm, devicetree, linux-amlogic, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190731153529.30159-1-glaroque@baylibre.com>
Add minimal thermal zone for DDR and CPU sensor
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
---
.../boot/dts/amlogic/meson-g12b-odroid-n2.dts | 60 +++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
index 75ff8a7e373d..a7d73c0c8447 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
@@ -10,6 +10,7 @@
#include <dt-bindings/input/input.h>
#include <dt-bindings/gpio/meson-g12a-gpio.h>
#include <dt-bindings/sound/meson-g12a-tohdmitx.h>
+#include <dt-bindings/thermal/thermal.h>
/ {
compatible = "hardkernel,odroid-n2", "amlogic,g12b";
@@ -20,6 +21,55 @@
ethernet0 = ðmac;
};
+ thermal-zones {
+ cpu-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&cpu_temp>;
+
+ trips {
+ cpu_critical: cpu-critical {
+ temperature = <110000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&cpu_critical>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu100 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu101 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu102 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu103 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+
+ ddr-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&ddr_temp>;
+
+ trips {
+ ddr_critical: ddr-critical {
+ temperature = <110000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&ddr_critical>;
+ cooling-device = <&mali THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -288,6 +338,7 @@
operating-points-v2 = <&cpu_opp_table_0>;
clocks = <&clkc CLKID_CPU_CLK>;
clock-latency = <50000>;
+ #cooling-cells = <2>;
};
&cpu1 {
@@ -295,6 +346,7 @@
operating-points-v2 = <&cpu_opp_table_0>;
clocks = <&clkc CLKID_CPU_CLK>;
clock-latency = <50000>;
+ #cooling-cells = <2>;
};
&cpu100 {
@@ -302,6 +354,7 @@
operating-points-v2 = <&cpub_opp_table_1>;
clocks = <&clkc CLKID_CPUB_CLK>;
clock-latency = <50000>;
+ #cooling-cells = <2>;
};
&cpu101 {
@@ -309,6 +362,7 @@
operating-points-v2 = <&cpub_opp_table_1>;
clocks = <&clkc CLKID_CPUB_CLK>;
clock-latency = <50000>;
+ #cooling-cells = <2>;
};
&cpu102 {
@@ -316,6 +370,7 @@
operating-points-v2 = <&cpub_opp_table_1>;
clocks = <&clkc CLKID_CPUB_CLK>;
clock-latency = <50000>;
+ #cooling-cells = <2>;
};
&cpu103 {
@@ -323,6 +378,7 @@
operating-points-v2 = <&cpub_opp_table_1>;
clocks = <&clkc CLKID_CPUB_CLK>;
clock-latency = <50000>;
+ #cooling-cells = <2>;
};
&ext_mdio {
@@ -377,6 +433,10 @@
};
};
+&mali {
+ #cooling-cells = <2>;
+};
+
&hdmi_tx {
status = "okay";
pinctrl-0 = <&hdmitx_hpd_pins>, <&hdmitx_ddc_pins>;
--
2.17.1
^ permalink raw reply related
* [PATCH v2 6/6] MAINTAINERS: add entry for Amlogic Thermal driver
From: Guillaume La Roque @ 2019-07-31 15:35 UTC (permalink / raw)
To: daniel.lezcano, khilman
Cc: linux-pm, devicetree, linux-amlogic, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190731153529.30159-1-glaroque@baylibre.com>
Add myself as maintainer for Amlogic Thermal driver.
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
---
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index fb2b12f75c37..299f27d11058 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15910,6 +15910,15 @@ F: Documentation/driver-api/thermal/cpu-cooling-api.rst
F: drivers/thermal/cpu_cooling.c
F: include/linux/cpu_cooling.h
+THERMAL DRIVER FOR AMLOGIC SOCS
+M: Guillaume La Roque <glaroque@baylibre.com>
+L: linux-pm@vger.kernel.org
+L: linux-amlogic@lists.infradead.org
+W: http://linux-meson.com/
+S: Supported
+F: drivers/thermal/amlogic_thermal.c
+F: Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
+
THINKPAD ACPI EXTRAS DRIVER
M: Henrique de Moraes Holschuh <ibm-acpi@hmh.eng.br>
L: ibm-acpi-devel@lists.sourceforge.net
--
2.17.1
^ permalink raw reply related
* [PATCH 0/8] Raspberry Pi 4 DMA addressing support
From: Nicolas Saenz Julienne @ 2019-07-31 15:47 UTC (permalink / raw)
To: catalin.marinas, hch, wahrenst, marc.zyngier, Robin Murphy,
linux-arm-kernel, devicetree, iommu, linux-mm
Cc: phill, f.fainelli, will, linux-kernel, robh+dt, eric, mbrugger,
nsaenzjulienne, akpm, frowand.list, m.szyprowski,
linux-rpi-kernel, linuxppc-dev, linux-s390
Hi all,
this series attempts to address some issues we found while bringing up
the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow
up of this discussion:
https://lkml.org/lkml/2019/7/17/476
The new Raspberry Pi 4 has up to 4GB of memory but most peripherals can
only address the first GB: their DMA address range is
0xc0000000-0xfc000000 which is aliased to the first GB of physical
memory 0x00000000-0x3c000000. Note that only some peripherals have these
limitations: the ARM cores, PCIe, V3D, GENET, and 40-bit DMA channels
have a wider view of the address space.
Part of this is solved in arm32 by setting up the machine specific
'.dma_zone_size = SZ_1G', which takes care of the allocating the
coherent memory area at the right spot. Yet no buffer bouncing (needed
for dma streaming) is available at the moment, but that's a story for
another series.
Unfortunately there is no such thing as '.dma_zone_size' in arm64 also
only ZONE_DMA32 is created which is interpreted by dma-direct and the
arm64 code as if all peripherals where be able to address the first 4GB
of memory.
In the light of this, the series implements the following changes:
- Add code that parses the device-tree in oder to find the SoC's common
DMA area.
- Create a ZONE_DMA whenever that area is needed and add the rest of the
lower 4 GB of memory to ZONE_DMA32*.
- Create the CMA area in a place suitable for all peripherals.
- Inform dma-direct of the new runtime calculated min_mask*.
That's all.
Regards,
Nicolas
* These solutions where already discussed on the previous RFC (see link
above).
---
Nicolas Saenz Julienne (8):
arm64: mm: use arm64_dma_phys_limit instead of calling
max_zone_dma_phys()
arm64: rename variables used to calculate ZONE_DMA32's size
of/fdt: add function to get the SoC wide DMA addressable memory size
arm64: re-introduce max_zone_dma_phys()
arm64: use ZONE_DMA on DMA addressing limited devices
dma-direct: turn ARCH_ZONE_DMA_BITS into a variable
arm64: update arch_zone_dma_bits to fine tune dma-direct min mask
mm: comment arm64's usage of 'enum zone_type'
arch/arm64/Kconfig | 4 ++
arch/arm64/mm/init.c | 78 ++++++++++++++++++++++++++-------
arch/powerpc/include/asm/page.h | 9 ----
arch/powerpc/mm/mem.c | 14 +++++-
arch/s390/include/asm/page.h | 2 -
arch/s390/mm/init.c | 1 +
drivers/of/fdt.c | 72 ++++++++++++++++++++++++++++++
include/linux/dma-direct.h | 2 +
include/linux/mmzone.h | 21 ++++-----
include/linux/of_fdt.h | 2 +
kernel/dma/direct.c | 8 ++--
11 files changed, 168 insertions(+), 45 deletions(-)
--
2.22.0
^ permalink raw reply
* [PATCH 1/8] arm64: mm: use arm64_dma_phys_limit instead of calling max_zone_dma_phys()
From: Nicolas Saenz Julienne @ 2019-07-31 15:47 UTC (permalink / raw)
To: catalin.marinas, hch, wahrenst, marc.zyngier, Robin Murphy,
linux-arm-kernel, devicetree, iommu, linux-mm, linux-kernel
Cc: phill, f.fainelli, will, robh+dt, eric, mbrugger, nsaenzjulienne,
akpm, frowand.list, m.szyprowski, linux-rpi-kernel
In-Reply-To: <20190731154752.16557-1-nsaenzjulienne@suse.de>
By the time we call zones_sizes_init() arm64_dma_phys_limit already
contains the result of max_zone_dma_phys(). We use the variable instead
of calling the function directly to save some precious cpu time.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
arch/arm64/mm/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f3c795278def..6112d6c90fa8 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -181,7 +181,7 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
#ifdef CONFIG_ZONE_DMA32
- max_zone_pfns[ZONE_DMA32] = PFN_DOWN(max_zone_dma_phys());
+ max_zone_pfns[ZONE_DMA32] = PFN_DOWN(arm64_dma_phys_limit);
#endif
max_zone_pfns[ZONE_NORMAL] = max;
--
2.22.0
^ permalink raw reply related
* [PATCH 2/8] arm64: rename variables used to calculate ZONE_DMA32's size
From: Nicolas Saenz Julienne @ 2019-07-31 15:47 UTC (permalink / raw)
To: catalin.marinas, hch, wahrenst, marc.zyngier, Robin Murphy,
linux-arm-kernel, devicetree, iommu, linux-mm, linux-kernel
Cc: phill, f.fainelli, will, robh+dt, eric, mbrugger, nsaenzjulienne,
akpm, frowand.list, m.szyprowski, linux-rpi-kernel
In-Reply-To: <20190731154752.16557-1-nsaenzjulienne@suse.de>
Let the name indicate that they are used to calculate ZONE_DMA32's size
as opposed to ZONE_DMA.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
arch/arm64/mm/init.c | 30 +++++++++++++++---------------
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 6112d6c90fa8..8956c22634dd 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -50,7 +50,7 @@
s64 memstart_addr __ro_after_init = -1;
EXPORT_SYMBOL(memstart_addr);
-phys_addr_t arm64_dma_phys_limit __ro_after_init;
+phys_addr_t arm64_dma32_phys_limit __ro_after_init;
#ifdef CONFIG_KEXEC_CORE
/*
@@ -168,7 +168,7 @@ static void __init reserve_elfcorehdr(void)
* currently assumes that for memory starting above 4G, 32-bit devices will
* use a DMA offset.
*/
-static phys_addr_t __init max_zone_dma_phys(void)
+static phys_addr_t __init max_zone_dma32_phys(void)
{
phys_addr_t offset = memblock_start_of_DRAM() & GENMASK_ULL(63, 32);
return min(offset + (1ULL << 32), memblock_end_of_DRAM());
@@ -181,7 +181,7 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
#ifdef CONFIG_ZONE_DMA32
- max_zone_pfns[ZONE_DMA32] = PFN_DOWN(arm64_dma_phys_limit);
+ max_zone_pfns[ZONE_DMA32] = PFN_DOWN(arm64_dma32_phys_limit);
#endif
max_zone_pfns[ZONE_NORMAL] = max;
@@ -194,16 +194,16 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
{
struct memblock_region *reg;
unsigned long zone_size[MAX_NR_ZONES], zhole_size[MAX_NR_ZONES];
- unsigned long max_dma = min;
+ unsigned long max_dma32 = min;
memset(zone_size, 0, sizeof(zone_size));
/* 4GB maximum for 32-bit only capable devices */
#ifdef CONFIG_ZONE_DMA32
- max_dma = PFN_DOWN(arm64_dma_phys_limit);
- zone_size[ZONE_DMA32] = max_dma - min;
+ max_dma32 = PFN_DOWN(arm64_dma32_phys_limit);
+ zone_size[ZONE_DMA32] = max_dma32 - min;
#endif
- zone_size[ZONE_NORMAL] = max - max_dma;
+ zone_size[ZONE_NORMAL] = max - max_dma32;
memcpy(zhole_size, zone_size, sizeof(zhole_size));
@@ -215,14 +215,14 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
continue;
#ifdef CONFIG_ZONE_DMA32
- if (start < max_dma) {
- unsigned long dma_end = min(end, max_dma);
+ if (start < max_dma32) {
+ unsigned long dma_end = min(end, max_dma32);
zhole_size[ZONE_DMA32] -= dma_end - start;
}
#endif
- if (end > max_dma) {
+ if (end > max_dma32) {
unsigned long normal_end = min(end, max);
- unsigned long normal_start = max(start, max_dma);
+ unsigned long normal_start = max(start, max_dma32);
zhole_size[ZONE_NORMAL] -= normal_end - normal_start;
}
}
@@ -407,9 +407,9 @@ void __init arm64_memblock_init(void)
/* 4GB maximum for 32-bit only capable devices */
if (IS_ENABLED(CONFIG_ZONE_DMA32))
- arm64_dma_phys_limit = max_zone_dma_phys();
+ arm64_dma32_phys_limit = max_zone_dma32_phys();
else
- arm64_dma_phys_limit = PHYS_MASK + 1;
+ arm64_dma32_phys_limit = PHYS_MASK + 1;
reserve_crashkernel();
@@ -417,7 +417,7 @@ void __init arm64_memblock_init(void)
high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
- dma_contiguous_reserve(arm64_dma_phys_limit);
+ dma_contiguous_reserve(arm64_dma32_phys_limit);
}
void __init bootmem_init(void)
@@ -521,7 +521,7 @@ static void __init free_unused_memmap(void)
void __init mem_init(void)
{
if (swiotlb_force == SWIOTLB_FORCE ||
- max_pfn > (arm64_dma_phys_limit >> PAGE_SHIFT))
+ max_pfn > (arm64_dma32_phys_limit >> PAGE_SHIFT))
swiotlb_init(1);
else
swiotlb_force = SWIOTLB_NO_FORCE;
--
2.22.0
^ permalink raw reply related
* [PATCH 3/8] of/fdt: add function to get the SoC wide DMA addressable memory size
From: Nicolas Saenz Julienne @ 2019-07-31 15:47 UTC (permalink / raw)
To: catalin.marinas, hch, wahrenst, marc.zyngier, Robin Murphy,
linux-arm-kernel, devicetree, iommu, linux-mm, Rob Herring,
Frank Rowand
Cc: phill, f.fainelli, will, linux-kernel, eric, mbrugger,
nsaenzjulienne, akpm, m.szyprowski, linux-rpi-kernel
In-Reply-To: <20190731154752.16557-1-nsaenzjulienne@suse.de>
Some SoCs might have multiple interconnects each with their own DMA
addressing limitations. This function parses the 'dma-ranges' on each of
them and tries to guess the maximum SoC wide DMA addressable memory
size.
This is specially useful for arch code in order to properly setup CMA
and memory zones.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/of/fdt.c | 72 ++++++++++++++++++++++++++++++++++++++++++
include/linux/of_fdt.h | 2 ++
2 files changed, 74 insertions(+)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 9cdf14b9aaab..f2444c61a136 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -953,6 +953,78 @@ int __init early_init_dt_scan_chosen_stdout(void)
}
#endif
+/**
+ * early_init_dt_dma_zone_size - Look at all 'dma-ranges' and provide the
+ * maximum common dmable memory size.
+ *
+ * Some devices might have multiple interconnects each with their own DMA
+ * addressing limitations. For example the Raspberry Pi 4 has the following:
+ *
+ * soc {
+ * dma-ranges = <0xc0000000 0x0 0x00000000 0x3c000000>;
+ * [...]
+ * }
+ *
+ * v3dbus {
+ * dma-ranges = <0x00000000 0x0 0x00000000 0x3c000000>;
+ * [...]
+ * }
+ *
+ * scb {
+ * dma-ranges = <0x0 0x00000000 0x0 0x00000000 0xfc000000>;
+ * [...]
+ * }
+ *
+ * Here the area addressable by all devices is [0x00000000-0x3bffffff]. Hence
+ * the function will write in 'data' a size of 0x3c000000.
+ *
+ * Note that the implementation assumes all interconnects have the same physical
+ * memory view and that the mapping always start at the beginning of RAM.
+ */
+int __init early_init_dt_dma_zone_size(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+ const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
+ u64 phys_addr, dma_addr, size;
+ u64 *dma_zone_size = data;
+ int dma_addr_cells;
+ const __be32 *reg;
+ const void *prop;
+ int len;
+
+ if (depth == 0)
+ *dma_zone_size = 0;
+
+ /*
+ * We avoid pci host controllers as they have their own way of using
+ * 'dma-ranges'.
+ */
+ if (type && !strcmp(type, "pci"))
+ return 0;
+
+ reg = of_get_flat_dt_prop(node, "dma-ranges", &len);
+ if (!reg)
+ return 0;
+
+ prop = of_get_flat_dt_prop(node, "#address-cells", NULL);
+ if (prop)
+ dma_addr_cells = be32_to_cpup(prop);
+ else
+ dma_addr_cells = 1; /* arm64's default addr_cell size */
+
+ if (len < (dma_addr_cells + dt_root_addr_cells + dt_root_size_cells))
+ return 0;
+
+ dma_addr = dt_mem_next_cell(dma_addr_cells, ®);
+ phys_addr = dt_mem_next_cell(dt_root_addr_cells, ®);
+ size = dt_mem_next_cell(dt_root_size_cells, ®);
+
+ if (!*dma_zone_size || *dma_zone_size > size)
+ *dma_zone_size = size;
+
+ return 0;
+}
+
/**
* early_init_dt_scan_root - fetch the top level address and size cells
*/
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index acf820e88952..2ad36b7bd4fa 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -72,6 +72,8 @@ extern int early_init_dt_reserve_memory_arch(phys_addr_t base, phys_addr_t size,
bool no_map);
extern u64 dt_mem_next_cell(int s, const __be32 **cellp);
+extern int early_init_dt_dma_zone_size(unsigned long node, const char *uname,
+ int depth, void *data);
/* Early flat tree scan hooks */
extern int early_init_dt_scan_root(unsigned long node, const char *uname,
int depth, void *data);
--
2.22.0
^ permalink raw reply related
* [PATCH 4/8] arm64: re-introduce max_zone_dma_phys()
From: Nicolas Saenz Julienne @ 2019-07-31 15:47 UTC (permalink / raw)
To: catalin.marinas, hch, wahrenst, marc.zyngier, Robin Murphy,
linux-arm-kernel, devicetree, iommu, linux-mm, linux-kernel
Cc: phill, f.fainelli, will, robh+dt, eric, mbrugger, nsaenzjulienne,
akpm, frowand.list, m.szyprowski, linux-rpi-kernel
In-Reply-To: <20190731154752.16557-1-nsaenzjulienne@suse.de>
Some devices might have multiple interconnects with different DMA
addressing limitations. This function provides the higher physical
address accessible by all peripherals on the SoC. If such limitation
doesn't exist it'll return 0.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
arch/arm64/mm/init.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 8956c22634dd..1c4ffabbe1cb 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -174,6 +174,19 @@ static phys_addr_t __init max_zone_dma32_phys(void)
return min(offset + (1ULL << 32), memblock_end_of_DRAM());
}
+static phys_addr_t __init max_zone_dma_phys(void)
+
+{
+ u64 memory_size = memblock_end_of_DRAM() - memblock_start_of_DRAM();
+ u64 zone_dma_size;
+
+ of_scan_flat_dt(early_init_dt_dma_zone_size, &zone_dma_size);
+ if (zone_dma_size && zone_dma_size < min(memory_size, SZ_4G))
+ return memblock_start_of_DRAM() + zone_dma_size;
+
+ return 0;
+}
+
#ifdef CONFIG_NUMA
static void __init zone_sizes_init(unsigned long min, unsigned long max)
--
2.22.0
^ 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