All of lore.kernel.org
 help / color / mirror / Atom feed
From: hdegoede@redhat.com (Hans de Goede)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 0/4] ARM: sunxi: SRAM mapping support
Date: Sun, 31 May 2015 13:48:41 +0200	[thread overview]
Message-ID: <556AF519.1000209@redhat.com> (raw)
In-Reply-To: <1433063708-11726-1-git-send-email-maxime.ripard@free-electrons.com>

Hi,

On 31-05-15 11:15, Maxime Ripard wrote:
> Hi,
>
> The Allwinner SoCs all have a bunch of SRAMs (the exact number
> depending on the SoC itself) that can have various sections mapped to
> the CPU or to a bunch of devices, each section having different
> possible devices to be mapped to.
>
> Since this SRAM setup is highly SoC dependent, and that we could have
> multiple drivers trying to map a section for their own use, relying on
> syscon would put to much duplicated logic to devices that are using
> these SRAMs, among which the USB OTG and EMAC controllers, while not
> guaranteeing any kind of exclusive use of that section.
>
> To do this, we introduce a custom API to control the mapping of the
> sections in a SoC independent way, and a SoC driver to implement it.
>
> Let me know what you think,

Looks good, thanks for your work on this.

One small nitpick:

+static struct sunxi_sram_desc sun4i_a10_sram_a3_a4 = {
+	.data	= SUNXI_SRAM_DATA("A3-A4", 0x4, 0x4, 1,
+				  SUNXI_SRAM_MAP(0, "cpu"),
+				  SUNXI_SRAM_MAP(1, "emac")),
+};

According to the A10 datasheet bits 4 and 5 control the
A3-A4 mapping, with values 2 and 3 being reserved, so the
first line here should be:

+	.data	= SUNXI_SRAM_DATA("A3-A4", 0x4, 0x4, 2,

Other then that this looks good and is:

Acked-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>  (with otg no an A13 board)

Regards,

Hans



> Maxime
>
> Changes from v2:
>    - Changed the DT bindings to have an explicit relationship between
>      "client" devices, the controller, and the SRAM sections it
>      controls
>    - Changed the interface to not rely on private structures anymore
>      but only the client's struct device
>    - Fixed a bug in the claiming logic
>
> Maxime Ripard (4):
>    drivers: soc: sunxi: Introduce SoC driver to map SRAMs
>    ARM: dts: sun4i: Add A10 SRAM and SRAM controller
>    ARM: dts: sun5i: Add A10s and A13 SRAM and SRAM controller
>    ARM: dts: sun7i: Add A20 SRAM and SRAM controller
>
>   .../devicetree/bindings/soc/sunxi/sram.txt         |  72 ++++++
>   arch/arm/boot/dts/sun4i-a10-a1000.dts              |   4 +
>   arch/arm/boot/dts/sun4i-a10-ba10-tvbox.dts         |   4 +
>   arch/arm/boot/dts/sun4i-a10-cubieboard.dts         |   4 +
>   arch/arm/boot/dts/sun4i-a10-hackberry.dts          |   4 +
>   arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts         |   4 +
>   arch/arm/boot/dts/sun4i-a10-marsboard.dts          |   4 +
>   arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts     |   4 +
>   arch/arm/boot/dts/sun4i-a10-pcduino.dts            |   4 +
>   arch/arm/boot/dts/sun4i-a10.dtsi                   |  37 +++
>   arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts   |   4 +
>   arch/arm/boot/dts/sun5i-a10s.dtsi                  |   9 +
>   arch/arm/boot/dts/sun5i.dtsi                       |  30 +++
>   arch/arm/boot/dts/sun7i-a20.dtsi                   |  37 +++
>   drivers/soc/Kconfig                                |   1 +
>   drivers/soc/Makefile                               |   1 +
>   drivers/soc/sunxi/Kconfig                          |  10 +
>   drivers/soc/sunxi/Makefile                         |   1 +
>   drivers/soc/sunxi/sunxi_sram.c                     | 284 +++++++++++++++++++++
>   include/linux/soc/sunxi/sunxi_sram.h               |  19 ++
>   20 files changed, 537 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/soc/sunxi/sram.txt
>   create mode 100644 drivers/soc/sunxi/Kconfig
>   create mode 100644 drivers/soc/sunxi/Makefile
>   create mode 100644 drivers/soc/sunxi/sunxi_sram.c
>   create mode 100644 include/linux/soc/sunxi/sunxi_sram.h
>

WARNING: multiple messages have this Message-ID (diff)
From: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Maxime Ripard
	<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Subject: Re: [PATCH v3 0/4] ARM: sunxi: SRAM mapping support
Date: Sun, 31 May 2015 13:48:41 +0200	[thread overview]
Message-ID: <556AF519.1000209@redhat.com> (raw)
In-Reply-To: <1433063708-11726-1-git-send-email-maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

Hi,

On 31-05-15 11:15, Maxime Ripard wrote:
> Hi,
>
> The Allwinner SoCs all have a bunch of SRAMs (the exact number
> depending on the SoC itself) that can have various sections mapped to
> the CPU or to a bunch of devices, each section having different
> possible devices to be mapped to.
>
> Since this SRAM setup is highly SoC dependent, and that we could have
> multiple drivers trying to map a section for their own use, relying on
> syscon would put to much duplicated logic to devices that are using
> these SRAMs, among which the USB OTG and EMAC controllers, while not
> guaranteeing any kind of exclusive use of that section.
>
> To do this, we introduce a custom API to control the mapping of the
> sections in a SoC independent way, and a SoC driver to implement it.
>
> Let me know what you think,

Looks good, thanks for your work on this.

One small nitpick:

+static struct sunxi_sram_desc sun4i_a10_sram_a3_a4 = {
+	.data	= SUNXI_SRAM_DATA("A3-A4", 0x4, 0x4, 1,
+				  SUNXI_SRAM_MAP(0, "cpu"),
+				  SUNXI_SRAM_MAP(1, "emac")),
+};

According to the A10 datasheet bits 4 and 5 control the
A3-A4 mapping, with values 2 and 3 being reserved, so the
first line here should be:

+	.data	= SUNXI_SRAM_DATA("A3-A4", 0x4, 0x4, 2,

Other then that this looks good and is:

Acked-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Tested-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>  (with otg no an A13 board)

Regards,

Hans



> Maxime
>
> Changes from v2:
>    - Changed the DT bindings to have an explicit relationship between
>      "client" devices, the controller, and the SRAM sections it
>      controls
>    - Changed the interface to not rely on private structures anymore
>      but only the client's struct device
>    - Fixed a bug in the claiming logic
>
> Maxime Ripard (4):
>    drivers: soc: sunxi: Introduce SoC driver to map SRAMs
>    ARM: dts: sun4i: Add A10 SRAM and SRAM controller
>    ARM: dts: sun5i: Add A10s and A13 SRAM and SRAM controller
>    ARM: dts: sun7i: Add A20 SRAM and SRAM controller
>
>   .../devicetree/bindings/soc/sunxi/sram.txt         |  72 ++++++
>   arch/arm/boot/dts/sun4i-a10-a1000.dts              |   4 +
>   arch/arm/boot/dts/sun4i-a10-ba10-tvbox.dts         |   4 +
>   arch/arm/boot/dts/sun4i-a10-cubieboard.dts         |   4 +
>   arch/arm/boot/dts/sun4i-a10-hackberry.dts          |   4 +
>   arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts         |   4 +
>   arch/arm/boot/dts/sun4i-a10-marsboard.dts          |   4 +
>   arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts     |   4 +
>   arch/arm/boot/dts/sun4i-a10-pcduino.dts            |   4 +
>   arch/arm/boot/dts/sun4i-a10.dtsi                   |  37 +++
>   arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts   |   4 +
>   arch/arm/boot/dts/sun5i-a10s.dtsi                  |   9 +
>   arch/arm/boot/dts/sun5i.dtsi                       |  30 +++
>   arch/arm/boot/dts/sun7i-a20.dtsi                   |  37 +++
>   drivers/soc/Kconfig                                |   1 +
>   drivers/soc/Makefile                               |   1 +
>   drivers/soc/sunxi/Kconfig                          |  10 +
>   drivers/soc/sunxi/Makefile                         |   1 +
>   drivers/soc/sunxi/sunxi_sram.c                     | 284 +++++++++++++++++++++
>   include/linux/soc/sunxi/sunxi_sram.h               |  19 ++
>   20 files changed, 537 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/soc/sunxi/sram.txt
>   create mode 100644 drivers/soc/sunxi/Kconfig
>   create mode 100644 drivers/soc/sunxi/Makefile
>   create mode 100644 drivers/soc/sunxi/sunxi_sram.c
>   create mode 100644 include/linux/soc/sunxi/sunxi_sram.h
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2015-05-31 11:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-31  9:15 [PATCH v3 0/4] ARM: sunxi: SRAM mapping support Maxime Ripard
2015-05-31  9:15 ` Maxime Ripard
2015-05-31  9:15 ` [PATCH v3 1/4] drivers: soc: sunxi: Introduce SoC driver to map SRAMs Maxime Ripard
2015-05-31  9:15   ` Maxime Ripard
2015-05-31  9:15 ` [PATCH v3 2/4] ARM: dts: sun4i: Add A10 SRAM and SRAM controller Maxime Ripard
2015-05-31  9:15   ` Maxime Ripard
2015-05-31  9:15 ` [PATCH v3 3/4] ARM: dts: sun5i: Add A10s and A13 " Maxime Ripard
2015-05-31  9:15   ` Maxime Ripard
2015-05-31  9:15 ` [PATCH v3 4/4] ARM: dts: sun7i: Add A20 " Maxime Ripard
2015-05-31  9:15   ` Maxime Ripard
2015-05-31 11:48 ` Hans de Goede [this message]
2015-05-31 11:48   ` [PATCH v3 0/4] ARM: sunxi: SRAM mapping support Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=556AF519.1000209@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.