All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Kevin Hilman <khilman@baylibre.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Sekhar Nori <nsekhar@ti.com>, Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Russell King <linux@armlinux.org.uk>,
	LKML <linux-kernel@vger.kernel.org>,
	arm-soc <linux-arm-kernel@lists.infradead.org>,
	linux-drm <dri-devel@lists.freedesktop.org>,
	linux-devicetree <devicetree@vger.kernel.org>,
	Jyri Sarha <jsarha@ti.com>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	David Airlie <airlied@linux.ie>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [RFC] ARM: memory: da8xx-ddrctl: new driver
Date: Mon, 24 Oct 2016 18:00:36 +0100	[thread overview]
Message-ID: <20161024170035.GO15620@leverpostej> (raw)
In-Reply-To: <1477327596-16060-2-git-send-email-bgolaszewski@baylibre.com>

On Mon, Oct 24, 2016 at 06:46:36PM +0200, Bartosz Golaszewski wrote:
> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
> 
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
>  .../memory-controllers/ti-da8xx-ddrctl.txt         |  20 +++
>  drivers/memory/Kconfig                             |   8 +
>  drivers/memory/Makefile                            |   1 +
>  drivers/memory/da8xx-ddrctl.c                      | 187 +++++++++++++++++++++
>  4 files changed, 216 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>  create mode 100644 drivers/memory/da8xx-ddrctl.c
> 
> diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
> new file mode 100644
> index 0000000..f0eda59
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
> @@ -0,0 +1,20 @@
> +* Device tree bindings for Texas Instruments da8xx DDR2/mDDR memory controller
> +
> +The DDR2/mDDR memory controller present on Texas Instruments da8xx SoCs memory
> +maps a set of registers which allow to tweak the controller's behavior.

This is a description of the *driver*. The device itself doesn't map
some registers, it features them. Please descrive the *device*.

> +
> +Documentation:
> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
> +
> +Required properties:
> +
> +- compatible:		"ti,da850-ddrctl" - for da850 SoC based boards

Perhaps:

	"ti,da850-ddr-controller"

> +static int da8xx_ddrctl_probe(struct platform_device *pdev)
> +{
> +	const struct da8xx_ddrctl_config_knob *knob;
> +	const struct da8xx_ddrctl_setting *setting;
> +	u32 regprop[2], base, memsize, reg;
> +	struct device_node *node, *parent;
> +	void __iomem *ddrctl;
> +	const char *board;
> +	struct device *dev;
> +	int ret;
> +
> +	dev = &pdev->dev;
> +	node = dev->of_node;
> +
> +	/* Find the board name. */
> +	for (parent = node;
> +	     !of_node_is_root(parent);
> +	     parent = of_get_parent(parent));
> +
> +	ret = of_property_read_string(parent, "compatible", &board);
> +	if (ret) {
> +		dev_err(dev, "unable to read the soc model\n");
> +		return ret;
> +	}

I can see that you want to expose sysfs knobs for this, but is it really
necessary to match boards like this? It's very fragile, and commits us
to maintaining a database of board data (i.e. a board file).

I am very much not keen on that.

> +
> +	/* Check if we have settings for this board. */
> +	setting = da8xx_ddrctl_match_board(board);
> +	if (!setting) {
> +		dev_err(dev, "no settings for board '%s'\n", board);
> +		return -EINVAL;
> +	}

What's wrong with of_machine_is_compatible?

> +
> +	/* Figure out how to map the memory for the controller. */
> +	ret = of_property_read_u32_array(node, "reg", regprop, 2);
> +	if (ret) {
> +		dev_err(dev, "unable to parse 'reg' property\n");
> +		return ret;
> +	}
> +
> +	base = regprop[0];
> +	memsize = regprop[1];
> +
> +	ddrctl = ioremap(base, memsize);

NAK. Use the proper accessors for handling reg entries.

Thanks,
Mark.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
To: Bartosz Golaszewski
	<bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Cc: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
	Michael Turquette
	<mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
	Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Frank Rowand
	<frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>,
	Russell King <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	arm-soc
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	linux-drm
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	linux-devicetree
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org>,
	Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>,
	David Airlie <airlied-cv59FeDIM0c@public.gmane.org>,
	Laurent Pinchart
	<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
Subject: Re: [RFC] ARM: memory: da8xx-ddrctl: new driver
Date: Mon, 24 Oct 2016 18:00:36 +0100	[thread overview]
Message-ID: <20161024170035.GO15620@leverpostej> (raw)
In-Reply-To: <1477327596-16060-2-git-send-email-bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>

On Mon, Oct 24, 2016 at 06:46:36PM +0200, Bartosz Golaszewski wrote:
> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
> 
> Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
>  .../memory-controllers/ti-da8xx-ddrctl.txt         |  20 +++
>  drivers/memory/Kconfig                             |   8 +
>  drivers/memory/Makefile                            |   1 +
>  drivers/memory/da8xx-ddrctl.c                      | 187 +++++++++++++++++++++
>  4 files changed, 216 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>  create mode 100644 drivers/memory/da8xx-ddrctl.c
> 
> diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
> new file mode 100644
> index 0000000..f0eda59
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
> @@ -0,0 +1,20 @@
> +* Device tree bindings for Texas Instruments da8xx DDR2/mDDR memory controller
> +
> +The DDR2/mDDR memory controller present on Texas Instruments da8xx SoCs memory
> +maps a set of registers which allow to tweak the controller's behavior.

This is a description of the *driver*. The device itself doesn't map
some registers, it features them. Please descrive the *device*.

> +
> +Documentation:
> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
> +
> +Required properties:
> +
> +- compatible:		"ti,da850-ddrctl" - for da850 SoC based boards

Perhaps:

	"ti,da850-ddr-controller"

> +static int da8xx_ddrctl_probe(struct platform_device *pdev)
> +{
> +	const struct da8xx_ddrctl_config_knob *knob;
> +	const struct da8xx_ddrctl_setting *setting;
> +	u32 regprop[2], base, memsize, reg;
> +	struct device_node *node, *parent;
> +	void __iomem *ddrctl;
> +	const char *board;
> +	struct device *dev;
> +	int ret;
> +
> +	dev = &pdev->dev;
> +	node = dev->of_node;
> +
> +	/* Find the board name. */
> +	for (parent = node;
> +	     !of_node_is_root(parent);
> +	     parent = of_get_parent(parent));
> +
> +	ret = of_property_read_string(parent, "compatible", &board);
> +	if (ret) {
> +		dev_err(dev, "unable to read the soc model\n");
> +		return ret;
> +	}

I can see that you want to expose sysfs knobs for this, but is it really
necessary to match boards like this? It's very fragile, and commits us
to maintaining a database of board data (i.e. a board file).

I am very much not keen on that.

> +
> +	/* Check if we have settings for this board. */
> +	setting = da8xx_ddrctl_match_board(board);
> +	if (!setting) {
> +		dev_err(dev, "no settings for board '%s'\n", board);
> +		return -EINVAL;
> +	}

What's wrong with of_machine_is_compatible?

> +
> +	/* Figure out how to map the memory for the controller. */
> +	ret = of_property_read_u32_array(node, "reg", regprop, 2);
> +	if (ret) {
> +		dev_err(dev, "unable to parse 'reg' property\n");
> +		return ret;
> +	}
> +
> +	base = regprop[0];
> +	memsize = regprop[1];
> +
> +	ddrctl = ioremap(base, memsize);

NAK. Use the proper accessors for handling reg entries.

Thanks,
Mark.
--
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

WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] ARM: memory: da8xx-ddrctl: new driver
Date: Mon, 24 Oct 2016 18:00:36 +0100	[thread overview]
Message-ID: <20161024170035.GO15620@leverpostej> (raw)
In-Reply-To: <1477327596-16060-2-git-send-email-bgolaszewski@baylibre.com>

On Mon, Oct 24, 2016 at 06:46:36PM +0200, Bartosz Golaszewski wrote:
> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
> 
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
>  .../memory-controllers/ti-da8xx-ddrctl.txt         |  20 +++
>  drivers/memory/Kconfig                             |   8 +
>  drivers/memory/Makefile                            |   1 +
>  drivers/memory/da8xx-ddrctl.c                      | 187 +++++++++++++++++++++
>  4 files changed, 216 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>  create mode 100644 drivers/memory/da8xx-ddrctl.c
> 
> diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
> new file mode 100644
> index 0000000..f0eda59
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
> @@ -0,0 +1,20 @@
> +* Device tree bindings for Texas Instruments da8xx DDR2/mDDR memory controller
> +
> +The DDR2/mDDR memory controller present on Texas Instruments da8xx SoCs memory
> +maps a set of registers which allow to tweak the controller's behavior.

This is a description of the *driver*. The device itself doesn't map
some registers, it features them. Please descrive the *device*.

> +
> +Documentation:
> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
> +
> +Required properties:
> +
> +- compatible:		"ti,da850-ddrctl" - for da850 SoC based boards

Perhaps:

	"ti,da850-ddr-controller"

> +static int da8xx_ddrctl_probe(struct platform_device *pdev)
> +{
> +	const struct da8xx_ddrctl_config_knob *knob;
> +	const struct da8xx_ddrctl_setting *setting;
> +	u32 regprop[2], base, memsize, reg;
> +	struct device_node *node, *parent;
> +	void __iomem *ddrctl;
> +	const char *board;
> +	struct device *dev;
> +	int ret;
> +
> +	dev = &pdev->dev;
> +	node = dev->of_node;
> +
> +	/* Find the board name. */
> +	for (parent = node;
> +	     !of_node_is_root(parent);
> +	     parent = of_get_parent(parent));
> +
> +	ret = of_property_read_string(parent, "compatible", &board);
> +	if (ret) {
> +		dev_err(dev, "unable to read the soc model\n");
> +		return ret;
> +	}

I can see that you want to expose sysfs knobs for this, but is it really
necessary to match boards like this? It's very fragile, and commits us
to maintaining a database of board data (i.e. a board file).

I am very much not keen on that.

> +
> +	/* Check if we have settings for this board. */
> +	setting = da8xx_ddrctl_match_board(board);
> +	if (!setting) {
> +		dev_err(dev, "no settings for board '%s'\n", board);
> +		return -EINVAL;
> +	}

What's wrong with of_machine_is_compatible?

> +
> +	/* Figure out how to map the memory for the controller. */
> +	ret = of_property_read_u32_array(node, "reg", regprop, 2);
> +	if (ret) {
> +		dev_err(dev, "unable to parse 'reg' property\n");
> +		return ret;
> +	}
> +
> +	base = regprop[0];
> +	memsize = regprop[1];
> +
> +	ddrctl = ioremap(base, memsize);

NAK. Use the proper accessors for handling reg entries.

Thanks,
Mark.

  reply	other threads:[~2016-10-24 17:01 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-24 16:46 [RFC] da850: DDR2/mDDR memory controller driver Bartosz Golaszewski
2016-10-24 16:46 ` Bartosz Golaszewski
2016-10-24 16:46 ` Bartosz Golaszewski
2016-10-24 16:46 ` [RFC] ARM: memory: da8xx-ddrctl: new driver Bartosz Golaszewski
2016-10-24 16:46   ` Bartosz Golaszewski
2016-10-24 16:46   ` Bartosz Golaszewski
2016-10-24 17:00   ` Mark Rutland [this message]
2016-10-24 17:00     ` Mark Rutland
2016-10-24 17:00     ` Mark Rutland
2016-10-24 17:35     ` Kevin Hilman
2016-10-24 17:35       ` Kevin Hilman
2016-10-24 17:35       ` Kevin Hilman
2016-10-24 17:42       ` Mark Rutland
2016-10-24 17:42         ` Mark Rutland
2016-10-24 17:42         ` Mark Rutland
2016-10-24 18:41         ` Kevin Hilman
2016-10-24 18:41           ` Kevin Hilman
2016-10-24 18:41           ` Kevin Hilman
2016-10-24 18:52           ` Kevin Hilman
2016-10-24 18:52             ` Kevin Hilman
2016-10-24 18:52             ` Kevin Hilman
2016-10-25 10:17     ` Bartosz Golaszewski
2016-10-25 10:17       ` Bartosz Golaszewski
2016-10-25 10:17       ` Bartosz Golaszewski

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=20161024170035.GO15620@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=airlied@linux.ie \
    --cc=bgolaszewski@baylibre.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=frowand.list@gmail.com \
    --cc=jsarha@ti.com \
    --cc=khilman@baylibre.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mturquette@baylibre.com \
    --cc=nsekhar@ti.com \
    --cc=peter.ujfalusi@ti.com \
    --cc=robh+dt@kernel.org \
    --cc=tomi.valkeinen@ti.com \
    /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.