* [PATCH v6 4/5] ARM: multi_v7: enable VGA bridge
From: Maxime Ripard @ 2016-10-06 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.2ec28e2292f37131839babc08427ef9f1aece26a.1475740611.git-series.maxime.ripard@free-electrons.com>
Enable the RGB to VGA bridge driver in the defconfig
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+), 0 deletions(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 2c8665cd9dc5..ae1879a61bbe 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -567,6 +567,7 @@ CONFIG_DRM=y
CONFIG_DRM_I2C_ADV7511=m
# CONFIG_DRM_I2C_CH7006 is not set
# CONFIG_DRM_I2C_SIL164 is not set
+CONFIG_DRM_SIMPLE_VGA_DAC=m
CONFIG_DRM_NXP_PTN3460=m
CONFIG_DRM_PARADE_PS8622=m
CONFIG_DRM_NOUVEAU=m
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH v6 3/5] ARM: sun5i: a13-olinuxino: Enable VGA bridge
From: Maxime Ripard @ 2016-10-06 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.2ec28e2292f37131839babc08427ef9f1aece26a.1475740611.git-series.maxime.ripard@free-electrons.com>
Now that we have support for the VGA bridges using our DRM driver, enable
the display engine for the Olimex A13-Olinuxino.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 54 ++++++++++++++++++++++++-
1 file changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
index b3c234c65ea1..c69e0b0b7b55 100644
--- a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
+++ b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
@@ -72,6 +72,47 @@
default-state = "on";
};
};
+
+ bridge {
+ compatible = "simple-vga-dac";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ remote-endpoint = <&tcon0_out_vga>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+ };
+
+ vga {
+ compatible = "vga-connector";
+
+ port {
+ vga_con_in: endpoint {
+ remote-endpoint = <&vga_bridge_out>;
+ };
+ };
+ };
+};
+
+&be0 {
+ status = "okay";
};
&ehci0 {
@@ -211,6 +252,19 @@
status = "okay";
};
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_rgb666_pins>;
+ status = "okay";
+};
+
+&tcon0_out {
+ tcon0_out_vga: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&vga_bridge_in>;
+ };
+};
+
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&uart1_pins_b>;
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH v6 2/5] drm/bridge: Add RGB to VGA bridge support
From: Maxime Ripard @ 2016-10-06 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.2ec28e2292f37131839babc08427ef9f1aece26a.1475740611.git-series.maxime.ripard@free-electrons.com>
Some boards have an entirely passive RGB to VGA bridge, based on either
DACs or resistor ladders.
Those might or might not have an i2c bus routed to the VGA connector in
order to access the screen EDIDs.
Add a bridge that doesn't do anything but expose the modes available on the
screen, either based on the EDIDs if available, or based on the XGA
standards.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
Documentation/devicetree/bindings/display/bridge/simple-vga-dac.txt | 48 +++++++++++++++-
drivers/gpu/drm/bridge/Kconfig | 7 ++-
drivers/gpu/drm/bridge/Makefile | 1 +-
drivers/gpu/drm/bridge/simple-vga-dac.c | 229 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
4 files changed, 285 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/bridge/simple-vga-dac.txt
create mode 100644 drivers/gpu/drm/bridge/simple-vga-dac.c
diff --git a/Documentation/devicetree/bindings/display/bridge/simple-vga-dac.txt b/Documentation/devicetree/bindings/display/bridge/simple-vga-dac.txt
new file mode 100644
index 000000000000..7143c54ea88c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/simple-vga-dac.txt
@@ -0,0 +1,48 @@
+Dumb RGB to VGA bridge
+----------------------
+
+This binding is aimed for dumb RGB to VGA bridges that do not require
+any configuration.
+
+Required properties:
+
+- compatible: Must be "simple-vga-dac"
+
+Required nodes:
+
+This device has two video ports. Their connections are modeled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for RGB input
+- Video port 1 for VGA output
+
+
+Example
+-------
+
+bridge {
+ compatible = "simple-vga-dac";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ remote-endpoint = <&tcon0_out_vga>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+};
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index b590e678052d..5fe8c7829052 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -58,6 +58,13 @@ config DRM_SII902X
---help---
Silicon Image sii902x bridge chip driver.
+config DRM_SIMPLE_VGA_DAC
+ tristate "Simple VGA DAC support"
+ depends on OF
+ select DRM_KMS_HELPER
+ ---help---
+ Support for RGB to VGA bridges
+
config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index efdb07e878f5..2cdd99035f38 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
obj-$(CONFIG_DRM_SII902X) += sii902x.o
+obj-$(CONFIG_DRM_SIMPLE_VGA_DAC) += simple-vga-dac.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/simple-vga-dac.c b/drivers/gpu/drm/bridge/simple-vga-dac.c
new file mode 100644
index 000000000000..c81a25ab0b0d
--- /dev/null
+++ b/drivers/gpu/drm/bridge/simple-vga-dac.c
@@ -0,0 +1,229 @@
+/*
+ * Copyright (C) 2015-2016 Free Electrons
+ * Copyright (C) 2015-2016 NextThing Co
+ *
+ * Maxime Ripard <maxime.ripard@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/of_graph.h>
+
+#include <drm/drmP.h>
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc.h>
+#include <drm/drm_crtc_helper.h>
+
+struct simple_vga {
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+
+ struct i2c_adapter *ddc;
+};
+
+static inline struct simple_vga *
+drm_bridge_to_simple_vga(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct simple_vga, bridge);
+}
+
+static inline struct simple_vga *
+drm_connector_to_simple_vga(struct drm_connector *connector)
+{
+ return container_of(connector, struct simple_vga, connector);
+}
+
+static int simple_vga_get_modes(struct drm_connector *connector)
+{
+ struct simple_vga *vga = drm_connector_to_simple_vga(connector);
+ struct edid *edid;
+ int ret;
+
+ if (IS_ERR(vga->ddc))
+ goto fallback;
+
+ edid = drm_get_edid(connector, vga->ddc);
+ if (!edid) {
+ DRM_INFO("EDID readout failed, falling back to standard modes\n");
+ goto fallback;
+ }
+
+ drm_mode_connector_update_edid_property(connector, edid);
+ return drm_add_edid_modes(connector, edid);
+
+fallback:
+ /*
+ * In case we cannot retrieve the EDIDs (broken or missing i2c
+ * bus), fallback on the XGA standards
+ */
+ ret = drm_add_modes_noedid(connector, 1920, 1200);
+
+ /* And prefer a mode pretty much anyone can handle */
+ drm_set_preferred_mode(connector, 1024, 768);
+
+ return ret;
+}
+
+static const struct drm_connector_helper_funcs simple_vga_con_helper_funcs = {
+ .get_modes = simple_vga_get_modes,
+};
+
+static enum drm_connector_status
+simple_vga_connector_detect(struct drm_connector *connector, bool force)
+{
+ struct simple_vga *vga = drm_connector_to_simple_vga(connector);
+
+ /*
+ * Even if we have an I2C bus, we can't assume that the cable
+ * is disconnected if drm_probe_ddc fails. Some cables don't
+ * wire the DDC pins, or the I2C bus might not be working at
+ * all.
+ */
+ if (!IS_ERR(vga->ddc) && drm_probe_ddc(vga->ddc))
+ return connector_status_connected;
+
+ return connector_status_unknown;
+}
+
+static void
+simple_vga_connector_destroy(struct drm_connector *connector)
+{
+ drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs simple_vga_con_funcs = {
+ .dpms = drm_atomic_helper_connector_dpms,
+ .detect = simple_vga_connector_detect,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .destroy = simple_vga_connector_destroy,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int simple_vga_attach(struct drm_bridge *bridge)
+{
+ struct simple_vga *vga = drm_bridge_to_simple_vga(bridge);
+ int ret;
+
+ if (!bridge->encoder) {
+ DRM_ERROR("Missing encoder\n");
+ return -ENODEV;
+ }
+
+ drm_connector_helper_add(&vga->connector,
+ &simple_vga_con_helper_funcs);
+ ret = drm_connector_init(bridge->dev, &vga->connector,
+ &simple_vga_con_funcs, DRM_MODE_CONNECTOR_VGA);
+ if (ret) {
+ DRM_ERROR("Failed to initialize connector\n");
+ return ret;
+ }
+
+ drm_mode_connector_attach_encoder(&vga->connector,
+ bridge->encoder);
+
+ return 0;
+}
+
+static const struct drm_bridge_funcs simple_vga_bridge_funcs = {
+ .attach = simple_vga_attach,
+};
+
+static struct i2c_adapter *simple_vga_retrieve_ddc(struct device *dev)
+{
+ struct device_node *end_node, *phandle, *remote;
+ struct i2c_adapter *ddc;
+
+ end_node = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
+ if (!end_node) {
+ dev_err(dev, "Missing connector endpoint\n");
+ return ERR_PTR(-ENODEV);
+ }
+
+ remote = of_graph_get_remote_port_parent(end_node);
+ of_node_put(end_node);
+ if (!remote) {
+ dev_err(dev, "Enable to parse remote node\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ phandle = of_parse_phandle(remote, "ddc-i2c-bus", 0);
+ of_node_put(remote);
+ if (!phandle)
+ return ERR_PTR(-ENODEV);
+
+ ddc = of_get_i2c_adapter_by_node(phandle);
+ of_node_put(phandle);
+ if (!ddc)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ return ddc;
+}
+
+static int simple_vga_probe(struct platform_device *pdev)
+{
+ struct simple_vga *vga;
+ int ret;
+
+ vga = devm_kzalloc(&pdev->dev, sizeof(*vga), GFP_KERNEL);
+ if (!vga)
+ return -ENOMEM;
+ platform_set_drvdata(pdev, vga);
+
+ vga->ddc = simple_vga_retrieve_ddc(&pdev->dev);
+ if (IS_ERR(vga->ddc)) {
+ if (PTR_ERR(vga->ddc) == -ENODEV) {
+ dev_info(&pdev->dev,
+ "No i2c bus specified... Disabling EDID readout\n");
+ } else {
+ dev_err(&pdev->dev, "Couldn't retrieve i2c bus\n");
+ return PTR_ERR(vga->ddc);
+ }
+ }
+
+ vga->bridge.funcs = &simple_vga_bridge_funcs;
+ vga->bridge.of_node = pdev->dev.of_node;
+
+ ret = drm_bridge_add(&vga->bridge);
+ if (ret && !IS_ERR(vga->ddc))
+ i2c_put_adapter(vga->ddc);
+
+ return ret;
+}
+
+static int simple_vga_remove(struct platform_device *pdev)
+{
+ struct simple_vga *vga = platform_get_drvdata(pdev);
+
+ drm_bridge_remove(&vga->bridge);
+
+ if (!IS_ERR(vga->ddc))
+ i2c_put_adapter(vga->ddc);
+
+ return 0;
+}
+
+static const struct of_device_id simple_vga_match[] = {
+ { .compatible = "simple-vga-dac" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, simple_vga_match);
+
+struct platform_driver simple_vga_driver = {
+ .probe = simple_vga_probe,
+ .remove = simple_vga_remove,
+ .driver = {
+ .name = "simple-vga-dac",
+ .of_match_table = simple_vga_match,
+ },
+};
+module_platform_driver(simple_vga_driver);
+
+MODULE_AUTHOR("Maxime Ripard <maxime.ripard@free-electrons.com>");
+MODULE_DESCRIPTION("Simple VGA DAC driver");
+MODULE_LICENSE("GPL");
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH v6 1/5] drm/sun4i: rgb: Remove the bridge enable/disable functions
From: Maxime Ripard @ 2016-10-06 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.2ec28e2292f37131839babc08427ef9f1aece26a.1475740611.git-series.maxime.ripard@free-electrons.com>
The atomic helpers already call the drm_bridge_enable on our behalf,
there's no need to do it a second time.
Reported-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 6 ------
1 file changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index 4e4bea6f395c..d198ad7e5323 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -155,9 +155,6 @@ static void sun4i_rgb_encoder_enable(struct drm_encoder *encoder)
if (!IS_ERR(tcon->panel))
drm_panel_prepare(tcon->panel);
- /* encoder->bridge can be NULL; drm_bridge_enable checks for it */
- drm_bridge_enable(encoder->bridge);
-
sun4i_tcon_channel_enable(tcon, 0);
if (!IS_ERR(tcon->panel))
@@ -177,9 +174,6 @@ static void sun4i_rgb_encoder_disable(struct drm_encoder *encoder)
sun4i_tcon_channel_disable(tcon, 0);
- /* encoder->bridge can be NULL; drm_bridge_disable checks for it */
- drm_bridge_disable(encoder->bridge);
-
if (!IS_ERR(tcon->panel))
drm_panel_unprepare(tcon->panel);
}
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH v6 0/5] drm: Add Support for Passive RGB to VGA bridges
From: Maxime Ripard @ 2016-10-06 7:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This serie is about adding support for the RGB to VGA bridge found in
the A13-Olinuxino and the CHIP VGA adapter.
Both these boards rely on an entirely passive bridge made out of
resitor ladders that do not require any initialisation. The only thing
needed is to get the timings from the screen if available (and if not,
fall back on XGA standards), set up the display pipeline to output on
the RGB bus with the proper timings, and you're done.
This serie also fixes a bunch of bugs uncovered when trying to
increase the resolution, and hence the pixel clock, of our
pipeline. It also fixes a few bugs in the DRM driver itself that went
unnoticed before.
Let me know what you think,
Maxime
Changes from v5:
- Renamed to simple-vga-dac
Changes from v4:
- Removed unused functions
Changes from v3:
- Depends on OF in Kconfig
- Fixed typos in the driver comments
- Removed the mention of a "passive" bridge in the bindings doc
- Made the strcuture const
- Removed the nops and best_encoders implementations
- Removed the call to drm_bridge_enable in the sun4i driver
Changes from v2:
- Changed the compatible as suggested
- Rebased on top 4.8
Changes from v1:
- Switch to using a vga-connector
- Use drm_encoder bridge pointer instead of doing our own
- Report the connector status as unknown instead of connected by
default, and as connected only if we can retrieve the EDID.
- Switch to of_i2c_get_adapter by node, and put the reference when done
- Rebased on linux-next
Maxime Ripard (5):
drm/sun4i: rgb: Remove the bridge enable/disable functions
drm/bridge: Add RGB to VGA bridge support
ARM: sun5i: a13-olinuxino: Enable VGA bridge
ARM: multi_v7: enable VGA bridge
ARM: sunxi: Enable VGA bridge
.../bindings/display/bridge/rgb-to-vga-bridge.txt | 48 +++++
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 54 +++++
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/configs/sunxi_defconfig | 1 +
drivers/gpu/drm/bridge/Kconfig | 7 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/rgb-to-vga.c | 229 +++++++++++++++++++++
drivers/gpu/drm/sun4i/sun4i_rgb.c | 6 -
8 files changed, 341 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
--
2.9.3
Maxime Ripard (5):
drm/sun4i: rgb: Remove the bridge enable/disable functions
drm/bridge: Add RGB to VGA bridge support
ARM: sun5i: a13-olinuxino: Enable VGA bridge
ARM: multi_v7: enable VGA bridge
ARM: sunxi: Enable VGA bridge
Documentation/devicetree/bindings/display/bridge/simple-vga-dac.txt | 48 +++++++++++++++-
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 54 +++++++++++++++++-
arch/arm/configs/multi_v7_defconfig | 1 +-
arch/arm/configs/sunxi_defconfig | 1 +-
drivers/gpu/drm/bridge/Kconfig | 7 ++-
drivers/gpu/drm/bridge/Makefile | 1 +-
drivers/gpu/drm/bridge/simple-vga-dac.c | 229 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
drivers/gpu/drm/sun4i/sun4i_rgb.c | 6 +--
8 files changed, 341 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/bridge/simple-vga-dac.txt
create mode 100644 drivers/gpu/drm/bridge/simple-vga-dac.c
--
git-series 0.8.10
^ permalink raw reply
* [PATCH v5 2/5] drm/bridge: Add RGB to VGA bridge support
From: Maxime Ripard @ 2016-10-06 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8795dc49-26f9-0505-f442-2ca74b51872f@codeaurora.org>
Hi Archit,
On Mon, Oct 03, 2016 at 04:40:57PM +0530, Archit Taneja wrote:
> Hi Maxime,
>
> On 09/30/2016 08:07 PM, Maxime Ripard wrote:
> >Some boards have an entirely passive RGB to VGA bridge, based on either
> >DACs or resistor ladders.
> >
> >Those might or might not have an i2c bus routed to the VGA connector in
> >order to access the screen EDIDs.
> >
> >Add a bridge that doesn't do anything but expose the modes available on the
> >screen, either based on the EDIDs if available, or based on the XGA
> >standards.
> >
> >Acked-by: Rob Herring <robh@kernel.org>
> >Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >---
> > .../bindings/display/bridge/rgb-to-vga-bridge.txt | 48 +++++
> > drivers/gpu/drm/bridge/Kconfig | 7 +
> > drivers/gpu/drm/bridge/Makefile | 1 +
> > drivers/gpu/drm/bridge/rgb-to-vga.c | 229 +++++++++++++++++++++
> > 4 files changed, 285 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> > create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
> >
> >diff --git a/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> >new file mode 100644
> >index 000000000000..a8375bc1f9cb
> >--- /dev/null
> >+++ b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> >@@ -0,0 +1,48 @@
> >+Dumb RGB to VGA bridge
> >+----------------------
> >+
> >+This binding is aimed for dumb RGB to VGA bridges that do not require
> >+any configuration.
> >+
> >+Required properties:
> >+
> >+- compatible: Must be "rgb-to-vga-bridge"
>
> I'd talked to Laurent on IRC if he's okay with this. And I guess you to
> had discussed it during XDC too. He's suggested that it'd be better to
> have the compatible string as "simple-vga-dac".
I just wished this bikeshedding had taken place publicly and be
actually part of that discussion, but yeah, ok.
> Some of the reasons behind having this:
>
> - We don't need to specify "rgb" in the compatible string since most
> simple VGA DACs can only work with an RGB input.
Ok.
> - Also, with "dac" specified in the string, we don't need to
> specifically mention "bridge" in the string. Also, bridge is a drm
> specific term.
>
> - "simple" is considered because it's an unconfigurable bridge, and it
> might be misleading for other VGA DACs to not use "vga-dac".
All those "simple" bindings are just the biggest lie we ever
told. It's simple when you introduce it, and then grows into something
much more complicated than a non-simple implementation.
> What do you think about this? If you think it's good, would it be
> possible for you to change this? I guess it's okay for the rest of
> the patch to stay the same.
I'll update and respin the serie.
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161006/701c158a/attachment.sig>
^ permalink raw reply
* linux-next: manual merge of the gpio tree with the arm-soc tree
From: Linus Walleij @ 2016-10-06 6:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006094114.764d2f34@canb.auug.org.au>
On Thu, Oct 6, 2016 at 12:41 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Tue, 27 Sep 2016 15:05:42 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the gpio tree got a conflict in:
>>
>> arch/arm/mach-omap2/board-rx51-peripherals.c
>>
>> between commit:
>>
>> 9b7141d01a76 ("ARM: OMAP2+: Drop legacy board file for n900")
>>
>> from the arm-soc tree and commit:
>>
>> 9132ce450bd1 ("ARM: omap2: fix missing include")
>>
>> from the gpio tree.
>>
>> I fixed it up (the former removed the file, so I did that) and can
>> carry the fix as necessary. This is now fixed as far as linux-next is
>> concerned, but any non trivial conflicts should be mentioned to your
>> upstream maintainer when your tree is submitted for merging. You may
>> also want to consider cooperating with the maintainer of the conflicting
>> tree to minimise any particularly complex conflicts.
>
> Since Linus (Torvalds) has merged the gpio tree, this conflict (and
> file removal) now affects the merge of the arm-soc tree).
Yup and I also informed him in my pull request about this conflict
so shouldn't be a problem.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] pwm: core: Use pwm->args.polarity to setup PWM_POLARITY_INVERSED
From: Lukasz Majewski @ 2016-10-06 6:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161001101235.24598-3-bhuvanchandra.dv@toradex.com>
The pwm_set_polarity() function finally calls pwm_apply_state(), which
in turn requires state->duty_cycle and state->period properly set.
In the moment when polarity is set, the PWM is disabled and not configured.
For that reason both above variables are set to 0 and the polarity is not
set.
To be sure that polarity is setup, one needs to set pwm->args.polarity, which
controls MX3_PWMCR_POUTC bit setting at imx_pwm_config_v2().
Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
---
This patch should be applied on top of:
"[v2,2/6] pwm: core: make the PWM_POLARITY flag in DTB optional"
http://patchwork.ozlabs.org/patch/677330/
---
drivers/pwm/core.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 1f62668..6cd6004 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -153,13 +153,11 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct of_phandle_args *args)
return pwm;
pwm->args.period = args->args[1];
+ pwm->args.polarity = PWM_POLARITY_NORMAL;
- if (args->args_count > 2) {
+ if (args->args_count > 2)
if (args->args[2] & PWM_POLARITY_INVERTED)
- pwm_set_polarity(pwm, PWM_POLARITY_INVERSED);
- else
- pwm_set_polarity(pwm, PWM_POLARITY_NORMAL);
- }
+ pwm->args.polarity = PWM_POLARITY_INVERSED;
return pwm;
}
--
2.1.4
^ permalink raw reply related
* [PATCH v2 5/6] arm: dts: imx7-colibri: Use pwm polarity control
From: Lukasz Majewski @ 2016-10-06 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161001101235.24598-6-bhuvanchandra.dv@toradex.com>
On Sat, 1 Oct 2016 15:42:34 +0530
Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> wrote:
> Configure PWM polarity control.
>
> Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
> ---
> arch/arm/boot/dts/imx7-colibri.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi
> b/arch/arm/boot/dts/imx7-colibri.dtsi index a9cc657..2af5e3e 100644
> --- a/arch/arm/boot/dts/imx7-colibri.dtsi
> +++ b/arch/arm/boot/dts/imx7-colibri.dtsi
> @@ -43,7 +43,7 @@
> / {
> bl: backlight {
> compatible = "pwm-backlight";
> - pwms = <&pwm1 0 5000000>;
> + pwms = <&pwm1 0 5000000 0>;
My recommendation would be to add:
#include <dt-bindings/pwm/pwm.h>
and then define pwms as:
pwms = <&pwm1 0 5000000 PWM_POLARITY_NORMAL>;
It would be more readable
Best regards,
?ukasz Majewski
> };
>
> reg_module_3v3: regulator-module-3v3 {
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161006/124c447f/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/6] pwm: core: make the PWM_POLARITY flag in DTB optional
From: Lukasz Majewski @ 2016-10-06 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161001101235.24598-3-bhuvanchandra.dv@toradex.com>
Hi Bhuvanchandra,
> From: Lothar Wassmann <LW@KARO-electronics.de>
>
> Change the pwm chip driver registration, so that a chip driver that
> supports polarity inversion can still be used with DTBs that don't
> provide the 'PWM_POLARITY' flag.
>
> This is done to provide polarity inversion support for the pwm-imx
> driver without having to modify all existing DTS files.
>
> Signed-off-by: Lothar Wassmann <LW@KARO-electronics.de>
> Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
> Suggested-by: Thierry Reding <thierry.reding@gmail.com>
> ---
> drivers/pwm/core.c | 27 ++++++++++++++++-----------
> 1 file changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index 195373e..aae8db3 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -137,9 +137,14 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc,
> const struct of_phandle_args *args) {
> struct pwm_device *pwm;
>
> + /* check, whether the driver supports a third cell for flags
> */ if (pc->of_pwm_n_cells < 3)
> return ERR_PTR(-EINVAL);
>
> + /* flags in the third cell are optional */
> + if (args->args_count < 2)
> + return ERR_PTR(-EINVAL);
> +
> if (args->args[0] >= pc->npwm)
> return ERR_PTR(-EINVAL);
>
> @@ -149,10 +154,12 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc,
> const struct of_phandle_args *args)
> pwm->args.period = args->args[1];
>
> - if (args->args[2] & PWM_POLARITY_INVERTED)
> - pwm->args.polarity = PWM_POLARITY_INVERSED;
> - else
> - pwm->args.polarity = PWM_POLARITY_NORMAL;
> + if (args->args_count > 2) {
> + if (args->args[2] & PWM_POLARITY_INVERTED)
> + pwm_set_polarity(pwm, PWM_POLARITY_INVERSED);
^^^^^^^^^^^^^^^^
here we should set pwm->args.polarity, since
the pwm_set_polarity() calls pwm_apply_state()
which requires duty_cycle and period to be set.
In this particular moment it is not yet set and
polarity is not properly configured.
Patch fixing this will be sent as a reply to this e-mail. Please just
squash it and test on your platform.
Best regards,
?ukasz Majewski
> + else
> + pwm_set_polarity(pwm, PWM_POLARITY_NORMAL);
> + }
>
> return pwm;
> }
> @@ -163,9 +170,14 @@ of_pwm_simple_xlate(struct pwm_chip *pc, const
> struct of_phandle_args *args) {
> struct pwm_device *pwm;
>
> + /* sanity check driver support */
> if (pc->of_pwm_n_cells < 2)
> return ERR_PTR(-EINVAL);
>
> + /* all cells are required */
> + if (args->args_count != pc->of_pwm_n_cells)
> + return ERR_PTR(-EINVAL);
> +
> if (args->args[0] >= pc->npwm)
> return ERR_PTR(-EINVAL);
>
> @@ -672,13 +684,6 @@ struct pwm_device *of_pwm_get(struct device_node
> *np, const char *con_id) goto put;
> }
>
> - if (args.args_count != pc->of_pwm_n_cells) {
> - pr_debug("%s: wrong #pwm-cells for %s\n",
> np->full_name,
> - args.np->full_name);
> - pwm = ERR_PTR(-EINVAL);
> - goto put;
> - }
> -
> pwm = pc->of_xlate(pc, &args);
> if (IS_ERR(pwm))
> goto put;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161006/743020b3/attachment.sig>
^ permalink raw reply
* [PATCH v2 0/6] Support PWM polarity control
From: Lukasz Majewski @ 2016-10-06 6:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <be9c9f6b22788ca4d9c9243a46932945@agner.ch>
Hi Stefan,
> Hi Lukasz,
>
> On 2016-10-04 00:48, Lukasz Majewski wrote:
> > Dear Bhuvanchandra,
> >
> > Thank you for your effort to send those patches to ML.
> >
> >> Changes since v2:
> >>
> >> - Picked the stalled patchset[1] from Lothar Wassmann which adds
> >> the basic support for polarity control on imx-pwm driver and adds
> >> backward compatibility support for devices which does not have
> >> polarity control feature.
> >>
> >> Changes since Lothars v6:
> >>
> >> - Squash Lukasz patch[2].
> >>
> >> [1] http://thread.gmane.org/gmane.linux.pwm/1621
> >> [2] https://www.spinics.net/lists/arm-kernel/msg530818.html
> >>
> >> Bhuvanchandra DV (3):
> >> arm: dts: imx7: Update #pwm-cells for PWM polarity control
> >> arm: dts: imx7-colibri: Use pwm polarity control
> >> arm: dts: imx7-colibri: Use enable-gpios for BL_ON
> >>
> >> Lothar Wassmann (3):
> >> pwm: print error messages with pr_err() instead of pr_debug()
> >> pwm: core: make the PWM_POLARITY flag in DTB optional
> >> pwm: imx: support output polarity inversion
> >
> > For some reason this patchset works differently than the one
> > developed by Lothar.
> >
> > The difference is with the brightness level control.
> >
> > My brightness definition in DTS:
> >
> > pwms = <&pwm2 0 5000000 PWM_POLARITY_INVERTED>;
> >
> > brightness-levels = < 0 1 2 3 4 5 6
> > 7 8 9
> >
> > .. ............
> > 250 251 252 253 254 255>;
> > default-brightness-level = <50>;
> > enable-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
> >
>
> If you are using something else than i.MX 7 you also want to update
> the SoC level device tree, specifically change the pwm-cells property:
> #pwm-cells = <3>;
Good point. However, it is declared elsewhere (with pwm2 node)
&pwm2 {
#pwm-cells = <3>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm2>;
status = "okay";
};
>
>
> > When I go to the backlight sysfs entry:
> >
> > cd /sys/devices/soc0/backlight/backlight/backlight
> >
> > It seems like the brightness level control is inverted - i.e.
> > 'echo 20 > brightness" makes picture on the screen very bright, and
> > 'echo 200 > brightness' makes the picture diminish.
> >
> > With my "internal" patches the situation is opposite (and I've
> > checked it with my HW connections).
>
> Just to check whether the driver actually applies the polarity you can
> add a #define DEBUG at the top of the driver (drivers/pwm/pwm-imx.c)
> and pass ignore_loglevel as kernel command line. This should give you
> "PWM supports output inversion" at startup and a "... polarity set
> to .." message whenever the polarity is set.
The problem is with the Bhuvanchandra original patch.
I will point it out when replying to original patch.
Thanks for support,
?ukasz Majewski
>
> --
> Stefan
>
> >
> > Could you check on your setup if similar situation takes place? I
> > mean if the brightness control works as expected?
> >
> > Thanks in advance,
> > ?ukasz Majewski
> >
> >>
> >> Documentation/devicetree/bindings/pwm/imx-pwm.txt | 6 +--
> >> arch/arm/boot/dts/imx7-colibri.dtsi | 12 +++++-
> >> arch/arm/boot/dts/imx7s.dtsi | 8 ++--
> >> drivers/pwm/core.c | 31
> >> ++++++++------ drivers/pwm/pwm-imx.c |
> >> 51 +++++++++++++++++++++-- 5 files changed, 83 insertions(+), 25
> >> deletions(-)
> >>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161006/67f38538/attachment-0001.sig>
^ permalink raw reply
* Coresight ETF trace dump failed in Juno r1 with 4.8-rc8
From: Venkatesh Vivekanandan @ 2016-10-06 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <81bf19a4-5716-1a68-77c2-a0a98f19ecc0@arm.com>
On Wed, Oct 5, 2016 at 10:47 PM, Suzuki K Poulose
<Suzuki.Poulose@arm.com> wrote:
> On 05/10/16 06:27, Venkatesh Vivekanandan wrote:
>>
>> On Tue, Oct 4, 2016 at 7:59 PM, Suzuki K Poulose <Suzuki.Poulose@arm.com>
>> wrote:
>>>
>>> On 04/10/16 06:37, Venkatesh Vivekanandan wrote:
>>>>
>>>>
>>>> On Mon, Oct 3, 2016 at 6:44 PM, Sudeep Holla <sudeep.holla@arm.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> Hi Venkatesh,
>>>>>
>>>>> On 03/10/16 12:36, Venkatesh Vivekanandan wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I am trying to collect ETF trace from Juno R1 and could see "cpu
>>>>>> stall" while dumping the trace. Attached is the log of sequence
>>>>>> followed. Was trying to collect the trace data from hardware and see
>>>>>> if it is any valid data. Am I missing anything here?.
>>>>>>
>>>>>
>>>>> There are few fixes from me and Suzuki queued for v4.9.
>>>>> Can you check if this issue persists even on linux-next ?
>>>>
>>>>
>>>>
>>>> Issue is the same in linux-next as well. Please find the attached log.
>>>>
>>>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>>>> [ 120.009698] INFO: rcu_preempt detected stalls on CPUs/tasks:
>>>> [ 120.015307] 2-...: (1 GPs behind) idle=f11/140000000000000/0
>>>> softirq=224/224 fqs=1903
>>>> [ 120.023226] (detected by 1, t=5255 jiffies, g=-1, c=-2, q=19)
>>>> [ 120.029001] Task dump for CPU 2:
>>>> [ 120.032190] dd R running task 0 1270 1267
>>>> 0x00000002
>>>> [ 120.039172] Call trace:
>>>> [ 120.041594] [<ffff000008085534>] __switch_to+0xc8/0xd4
>>>> [ 120.046675] [<0000000000020000>] 0x20000
>>>>
>>>> Steps followed,
>>>> # git clone
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>>>> linux-next
>>>> # cd linux-next
>>>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
>>>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig <---
>>>> enable coresight
>>>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 Image
>>>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs
>>>> # arch/arm64/boot/Image <--- copied this kernel
>>>> # arch/arm64/boot/dts/arm/juno-r1.dtb <--- copied this dtb
>>>>
>>>> Top commit in linux-next is,
>>>>
>>>> commit c7d3b912180a9bb0733e5cfab84e5a7493dd3599
>>>> Author: Stephen Rothwell <sfr@canb.auug.org.au>
>>>> Date: Tue Oct 4 14:52:03 2016 +1100
>>>>
>>>> Add linux-next specific files for 20161004
>>>
>>>
>>>
>>> Can't reproduce it here either.
>>>
>>> root at localhost:/sys/bus/coresight/devices# echo 1 >
>>> 20010000.etf/enable_sink
>>> root at localhost:/sys/bus/coresight/devices# echo 1 >
>>> 22140000.etm/enable_source
>>> root at localhost:/sys/bus/coresight/devices# dd if=/dev/20010000.etf bs=1
>>> of=/root/etr.bin
>>> 65536+0 records in
>>> 65536+0 records out
>>> 65536 bytes (66 kB) copied, 0.227546 s, 288 kB/s
>>> root at localhost:/sys/bus/coresight/devices# dd if=/dev/20010000.etf bs=1
>>> of=/root/etr.bin
>>> 65536+0 records in
>>> 65536+0 records out
>>> 65536 bytes (66 kB) copied, 0.233527 s, 281 kB/s
>>> root at localhost:/sys/bus/coresight/devices# echo 0 >
>>> 20010000.etf/enable_sink
>>> root at localhost:/sys/bus/coresight/devices# dd if=/dev/20010000.etf bs=1
>>> of=/root/etr.bin
>>> 65536+0 records in
>>> 65536+0 records out
>>> 65536 bytes (66 kB) copied, 0.474943 s, 138 kB/s
>>>
>>> FWIW, here is my firmware version :
>>>
>>> NOTICE: Booting Trusted Firmware
>>> NOTICE: BL1: v1.1(release):e04723e21362
>>> NOTICE: BL1: Built : 15:39:56, Sep 1 2015
>>> NOTICE: BL1: Booting BL2
>>> NOTICE: BL2: v1.1(release):e04723e21362
>>> NOTICE: BL2: Built : 15:42:30, Sep 1 2015
>>> NOTICE: BL1: Booting BL3-1
>>> NOTICE: BL3-1: v1.1(release):604d5da6f2aa
>>> NOTICE: BL3-1: Built : 14:50:36, Sep 10 2015
>>> UEFI firmware (version ea31f8e built at 16:35:17 on Aug 5 2015)
>>>
>>
>> Hang is seen while trying to dump trace _after_ disabling the ETM
>> source. Is it not supposed to work?.
>> It works fine, when dumped before disabling ETM source. Please find
>> the log below.
>>
>> linaro-test [rc=0]# echo 1 > 20010000.etf/enable_sink
>> linaro-test [rc=0]# echo 1 > 22140000.etm/enable_source
>> [ 91.792145] coresight-tmc 20010000.etf: TMC-ETB/ETF enabled
>> [ 91.797719] coresight-funnel 20040000.main-funnel: FUNNEL inport 0
>> enabled
>> [ 91.804552] coresight-funnel 220c0000.cluster0-funnel: FUNNEL
>> inport 1 enabled
>> [ 91.815990] coresight-etm4x 22140000.etm: ETM tracing enabled
>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>> [ 108.105492] coresight-tmc 20010000.etf: TMC read start
>> [ 108.404335] coresight-tmc 20010000.etf: TMC read end
>> 65536+0 records in
>> 65536+0 records out
>> linaro-test [rc=0]# echo 0 > 20010000.etf/enable_sink
>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>> [ 125.069740] coresight-tmc 20010000.etf: TMC read start
>> [ 125.184370] coresight-tmc 20010000.etf: TMC read end
>> 65536+0 records in
>> 65536+0 records out
>> linaro-test [rc=0]# echo 0 > 22140000.etm/enable_source
>> [ 140.271163] coresight-etm4x 22140000.etm: ETM tracing disabled
>> [ 140.276964] coresight-funnel 220c0000.cluster0-funnel: FUNNEL
>> inport 1 disabled
>> [ 140.284211] coresight-funnel 20040000.main-funnel: FUNNEL inport 0
>> disabled
>> [ 140.291128] coresight-tmc 20010000.etf: TMC-ETB/ETF disabled
>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>> <---- It hangs here...
>
>
> The point is once you disable the source, which eventually disables
> all the components upto the sink, the data in the ETF is already captured
> into a buffer, so there is no coresight hardware access involved.
>
> Also, looks like the open(/dev/20010000.etf,..) from the dd didn't
> complete,
> as we don't see a "TMC read start" line.
>
> Could you please :
>
> a) Try the patch [0] and see if it helps ?
> b) If a doesn't help, after disabling the source, run any other command
> instead of the trace collection. e.g,
>
> dd if=/dev/zero of=/dev/null
>
> and see if it hangs the system in a similar way ?
Applied the patch(fixed unused variable warning) and tested. System
hangs the same way as before
with one extra print. dd to /dev/null works fine. Please find the log below.
linaro-test [rc=0]# echo 0 > 20010000.etf/enable_sink
linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
[ 60.519034] coresight-tmc 20010000.etf: TMC read start
[ 60.635825] coresight-tmc 20010000.etf: TMC read end
65536+0 records in
65536+0 records out
linaro-test [rc=0]# echo 0 > 22140000.etm/enable_source
[ 78.394169] coresight-etm4x 22140000.etm: ETM tracing disabled
[ 78.399977] coresight-funnel 220c0000.cluster0-funnel: FUNNEL
inport 1 disabled
[ 78.407225] coresight-funnel 20040000.main-funnel: FUNNEL inport 0 disabled
[ 78.414140] coresight-tmc 20010000.etf: TMC-ETB/ETF disabled
linaro-test [rc=0]# dd if=/dev/zero of=/dev/null bs=1 count=100
100+0 records in
100+0 records out
linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
[ 104.673413] coresight-tmc 20010000.etf: TMC read start
==== it just hangs here====
>
>
> Thanks
> Suzuki
>
> [0] test patch
>
> ----8>----
>
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c
> b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> index 1ffdab8..ef72ed8 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> @@ -511,13 +511,6 @@ int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
> goto out;
> }
> - /* There is no point in reading a TMC in HW FIFO mode */
> - mode = readl_relaxed(drvdata->base + TMC_MODE);
> - if (mode != TMC_MODE_CIRCULAR_BUFFER) {
> - ret = -EINVAL;
> - goto out;
> - }
> -
> /* Don't interfere if operated from Perf */
> if (drvdata->mode == CS_MODE_PERF) {
> ret = -EINVAL;
>
>
>
^ permalink raw reply
* Coresight ETF trace dump failed in Juno r1 with 4.8-rc8
From: Venkatesh Vivekanandan @ 2016-10-06 5:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7e1e514b-fc3b-ca96-4631-88d537019e08@arm.com>
On Wed, Oct 5, 2016 at 4:12 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On 05/10/16 06:27, Venkatesh Vivekanandan wrote:
>
> [...]
>
>
>>
>> Hang is seen while trying to dump trace _after_ disabling the ETM
>> source. Is it not supposed to work?.
>> It works fine, when dumped before disabling ETM source. Please find
>> the log below.
>>
>> linaro-test [rc=0]# echo 1 > 20010000.etf/enable_sink
>> linaro-test [rc=0]# echo 1 > 22140000.etm/enable_source
>> [ 91.792145] coresight-tmc 20010000.etf: TMC-ETB/ETF enabled
>> [ 91.797719] coresight-funnel 20040000.main-funnel: FUNNEL inport 0
>> enabled
>> [ 91.804552] coresight-funnel 220c0000.cluster0-funnel: FUNNEL
>> inport 1 enabled
>> [ 91.815990] coresight-etm4x 22140000.etm: ETM tracing enabled
>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>> [ 108.105492] coresight-tmc 20010000.etf: TMC read start
>> [ 108.404335] coresight-tmc 20010000.etf: TMC read end
>> 65536+0 records in
>> 65536+0 records out
>> linaro-test [rc=0]# echo 0 > 20010000.etf/enable_sink
>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>> [ 125.069740] coresight-tmc 20010000.etf: TMC read start
>> [ 125.184370] coresight-tmc 20010000.etf: TMC read end
>> 65536+0 records in
>> 65536+0 records out
>> linaro-test [rc=0]# echo 0 > 22140000.etm/enable_source
>> [ 140.271163] coresight-etm4x 22140000.etm: ETM tracing disabled
>> [ 140.276964] coresight-funnel 220c0000.cluster0-funnel: FUNNEL
>> inport 1 disabled
>> [ 140.284211] coresight-funnel 20040000.main-funnel: FUNNEL inport 0
>> disabled
>> [ 140.291128] coresight-tmc 20010000.etf: TMC-ETB/ETF disabled
>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>> <---- It hangs here...
>>
>
> I get dd: failed to open '/dev/20010000.etf': Invalid argument
> once all the data is read.
>
It hangs in my board.
>> My firmware version,
>>
>> NOTICE: Booting Trusted Firmware
>> NOTICE: BL1: v1.1(debug):4a1dcde
>> NOTICE: BL1: Built : 17:54:40, Nov 24 2015
>> NOTICE: BL1: Booting BL2
>> NOTICE: BL2: v1.1(debug):4a1dcde
>> NOTICE: BL2: Built : 17:54:40, Nov 24 2015
>> NOTICE: BL1: Booting BL3-1
>> NOTICE: BL3-1: v1.1(debug):4a1dcde
>> NOTICE: BL3-1: Built : 17:54:40, Nov 24 2015
>> UEFI firmware (version 9ed6f7e built at 17:54:28 on Nov 24 2015)
>>
>
> OK, this looks as good as what Suzuki has, so should be fine.
> But it doesn't list SCP version, can you see that from the Linux boot
> logs ?(something like below)
>
> "scpi_protocol scpi: SCP Protocol 1.2 Firmware 1.17.0 version"
[ 2.537096] scpi_protocol scpi: SCP Protocol 1.0 Firmware 1.11.0 version
>
> --
> Regards,
> Sudeep
^ permalink raw reply
* [PATCH v3 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay
From: Mugunthan V N @ 2016-10-06 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006051355.15947-1-mugunthanvnm@ti.com>
The current delay settings of the phy are not the optimal value,
fix it with correct values.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/dra72-evm-revc.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index aafb594..01e1f39 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -59,16 +59,16 @@
&davinci_mdio {
dp83867_0: ethernet-phy at 2 {
reg = <2>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-impedance;
};
dp83867_1: ethernet-phy at 3 {
reg = <3>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-imepdance;
};
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH v3 3/4] ARM: dts: dra72-evm-revc: add phy impedance settings
From: Mugunthan V N @ 2016-10-06 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006051355.15947-1-mugunthanvnm@ti.com>
The default impedance settings of the phy is not the optimal
value, due to this the second ethernet is not working. Fix it
with correct values which makes the second ethernet port to work.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index f9cfd3b..aafb594 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -62,6 +62,7 @@
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,min-output-impedance;
};
dp83867_1: ethernet-phy at 3 {
@@ -69,5 +70,6 @@
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,min-output-imepdance;
};
};
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH v3 2/4] net: phy: dp83867: add support for MAC impedance configuration
From: Mugunthan V N @ 2016-10-06 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006051355.15947-1-mugunthanvnm@ti.com>
Add support for programmable MAC impedance configuration
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 91177a4..1b63924 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -33,6 +33,7 @@
/* Extended Registers */
#define DP83867_RGMIICTL 0x0032
#define DP83867_RGMIIDCTL 0x0086
+#define DP83867_IO_MUX_CFG 0x0170
#define DP83867_SW_RESET BIT(15)
#define DP83867_SW_RESTART BIT(14)
@@ -62,10 +63,17 @@
/* RGMIIDCTL bits */
#define DP83867_RGMII_TX_CLK_DELAY_SHIFT 4
+/* IO_MUX_CFG bits */
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL 0x1f
+
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX 0x0
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN 0x1f
+
struct dp83867_private {
int rx_id_delay;
int tx_id_delay;
int fifo_depth;
+ int io_impedance;
};
static int dp83867_ack_interrupt(struct phy_device *phydev)
@@ -111,6 +119,14 @@ static int dp83867_of_init(struct phy_device *phydev)
if (!of_node)
return -ENODEV;
+ dp83867->io_impedance = -EINVAL;
+
+ /* Optional configuration */
+ if (of_property_read_bool(of_node, "ti,max-output-impedance"))
+ dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
+ else if (of_property_read_bool(of_node, "ti,min-output-impedance"))
+ dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
+
ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
&dp83867->rx_id_delay);
if (ret)
@@ -184,6 +200,18 @@ static int dp83867_config_init(struct phy_device *phydev)
phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
DP83867_DEVADDR, delay);
+
+ if (dp83867->io_impedance >= 0) {
+ val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+ DP83867_DEVADDR);
+
+ val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+ val |= dp83867->io_impedance &
+ DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+
+ phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+ DP83867_DEVADDR, val);
+ }
}
return 0;
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH v3 1/4] net: phy: dp83867: Add documentation for optional impedance control
From: Mugunthan V N @ 2016-10-06 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006051355.15947-1-mugunthanvnm@ti.com>
Add documention of ti,impedance-control which can be used to
correct MAC impedance mismatch using phy extended registers.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt
index 5d21141..85bf945 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
@@ -9,6 +9,18 @@ Required properties:
- ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
for applicable values
+Optional property:
+ - ti,min-output-impedance - MAC Interface Impedance control to set
+ the programmable output impedance to
+ minimum value (35 ohms).
+ - ti,max-output-impedance - MAC Interface Impedance control to set
+ the programmable output impedance to
+ maximum value (70 ohms).
+
+Note: ti,min-output-impedance and ti,max-output-impedance are mutually
+ exclusive. When both properties are present ti,max-output-impedance
+ takes precedence.
+
Default child nodes are standard Ethernet PHY device
nodes as described in Documentation/devicetree/bindings/net/phy.txt
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH v3 0/4] add support for impedance control for TI dp83867 phy and fix 2nd ethernet on dra72 rev C evm
From: Mugunthan V N @ 2016-10-06 5:13 UTC (permalink / raw)
To: linux-arm-kernel
Add support for configurable impedance control for TI dp83867
phy via devicetree. More documentation in [1].
CPSW second ethernet is not working, fix it by enabling
impedance configuration on the phy.
Verified the patch on DRA72 Rev C evm, logs at [2]. Also pushed
a branch [3] for others to test.
Changes from v2:
* Fixed a typo in dts and driver.
Changes from initial version:
* As per Sekhar's comment, instead of passing impedance values,
change to max and min impedance from DT
* Adopted phy_read_mmd_indirect() to cunnrent implementation.
* Corrected the phy delay timings to the optimal value.
[1] - http://www.ti.com/lit/ds/symlink/dp83867ir.pdf
[2] - http://pastebin.ubuntu.com/23283056/
[3] - git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git dp83867-v3
Mugunthan V N (4):
net: phy: dp83867: Add documentation for optional impedance control
net: phy: dp83867: add support for MAC impedance configuration
ARM: dts: dra72-evm-revc: add phy impedance settings
ARM: dts: dra72-evm-revc: fix correct phy delay
.../devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++
arch/arm/boot/dts/dra72-evm-revc.dts | 10 ++++----
drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++
3 files changed, 46 insertions(+), 4 deletions(-)
--
2.10.0.372.g6fe1b14
^ permalink raw reply
* [PATCH] ARM: fix delays
From: Nicolas Pitre @ 2016-10-06 4:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1brv6h-0003j7-7J@rmk-PC.armlinux.org.uk>
On Wed, 5 Oct 2016, Russell King wrote:
> Commit 215e362dafed ("ARM: 8306/1: loop_udelay: remove bogomips value
> limitation") tried to increase the bogomips limitation, but in doing
> so messed up udelay such that it always gives about a 5% error in the
> delay, even if we use a timer.
>
> The calculation is:
>
> loops = UDELAY_MULT * us_delay * ticks_per_jiffy >> UDELAY_SHIFT
>
> Originally, UDELAY_MULT was ((UL(2199023) * HZ) >> 11) and UDELAY_SHIFT
> 30. Assuming HZ=100, us_delay of 1000 and ticks_per_jiffy of 1660000
> (eg, 166MHz timer, 1ms delay) this would calculate:
>
> ((UL(2199023) * HZ) >> 11) * 1000 * 1660000 >> 30
> => 165999
>
> With the new values of 2047 * HZ + 483648 * HZ / 1000000 and 31, we get:
>
> (2047 * HZ + 483648 * HZ / 1000000) * 1000 * 1660000 >> 31
> => 158269
>
> which is incorrect. This is due to a typo - correcting it gives:
>
> (2147 * HZ + 483648 * HZ / 1000000) * 1000 * 1660000 >> 31
> => 165999
>
> i.o.w, the original value.
WTF!
I don't know what kind of drugs I was on to make such a typo. It's not
like if the 0 and 1 keys were close together.
For those who might wonder where the UDELAY_MULT magic value comes from:
loops = loops_per_jiffy * jiffies_per_sec * us_delay / us_per_sec
where:
jiffies_per_sec = HZ
us_per_sec = 1000000
therefore the constant part is HZ / 1000000 which is a small fractional
number. To make this usable with integer math, we scale up this
constant by 2^31, do the actual multiplication, and scale the result
back down by 2^31 with a simple shift. That means:
UDELAY_MULT = 2^31 * HZ / 1000000
= (2^31 / 1000000) * HZ
= 2147.483648 * HZ
= 2147 * HZ + 483648 * HZ / 1000000
Maybe I should make a patch documenting this directly in the code.
While at it, why 2^31? Because we assume HZ <= 1000 and us_delay <=
2000. The result of UDELAY_MULT * us_delay must not overflow 32 bits as
we let loops_per_jiffy span the whole 32 bits range and the final
product must fit in 64 bits. Therefore:
2000 * (2^31 * 1000 / 1000000) = 4294966000
This could be optimized even further by assuming that lpj will never
reach 32 bits of magnitude, limiting it to 31 bits. In this case the
scale factor could be 2^32, making a down shift by 32 bits even faster
than a shift by 31 bits.
> Fixes: 215e362dafed ("ARM: 8306/1: loop_udelay: remove bogomips value limitation")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
> ---
> arch/arm/include/asm/delay.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/delay.h b/arch/arm/include/asm/delay.h
> index b7a428154355..b1ce037e4380 100644
> --- a/arch/arm/include/asm/delay.h
> +++ b/arch/arm/include/asm/delay.h
> @@ -10,7 +10,7 @@
> #include <asm/param.h> /* HZ */
>
> #define MAX_UDELAY_MS 2
> -#define UDELAY_MULT UL(2047 * HZ + 483648 * HZ / 1000000)
> +#define UDELAY_MULT UL(2147 * HZ + 483648 * HZ / 1000000)
> #define UDELAY_SHIFT 31
>
> #ifndef __ASSEMBLY__
> --
> 2.1.0
>
>
^ permalink raw reply
* [GIT PULL] Mailbox changes for v4.9
From: Jassi Brar @ 2016-10-06 3:43 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
The following changes since commit d060e0f603a4156087813d221d818bb39ec91429:
Merge tag 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma
(2016-09-06 12:33:12 -0700)
are available in the git repository at:
git://git.linaro.org/landing-teams/working/fujitsu/integration.git
mailbox-for-next
for you to fetch changes up to a649244de727b87d38fe46d86ef98c8d1fc49551:
dt-bindings: mailbox: Add Amlogic Meson MHU Bindings (2016-09-07
13:07:18 +0530)
----------------------------------------------------------------
- New driver and DT bindings for MHU controller integrated
on Amlogic Meson platform.
----------------------------------------------------------------
Neil Armstrong (2):
mailbox: Add Platform Message-Handling-Unit variant driver
dt-bindings: mailbox: Add Amlogic Meson MHU Bindings
.../devicetree/bindings/mailbox/meson-mhu.txt | 34 ++++
drivers/mailbox/Kconfig | 10 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/platform_mhu.c | 205 +++++++++++++++++++++
4 files changed, 251 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/meson-mhu.txt
create mode 100644 drivers/mailbox/platform_mhu.c
^ permalink raw reply
* [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06
From: Benjamin Herrenschmidt @ 2016-10-06 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6bbfeb57-7a55-6a3e-60b2-3f44525e5882@huawei.com>
On Tue, 2016-10-04 at 13:02 +0100, John Garry wrote:
> Right, so I think Zhichang can make the necessary generic changes to?
> 8250 OF driver to support IO port as well as MMIO-based.
>
> However an LPC-based earlycon driver is still required.
>
> A note on hip07-based D05 (for those unaware): this does not use?
> LPC-based uart. It uses PL011. The hardware guys have managed some?
> trickery where they loopback the serial line around the BMC/CPLD. But we?
> still need it for hip06 D03 and any other boards which want to use LPC?
> bus for uart.
>
> A question on SBSA: does it propose how to provide serial via BMC for SOL?
Probably another reason to keep 8250 as a legal option ... The (very
popular) Aspeed BMCs tend to do this via a 8250-looking virtual UART on
LPC.
Cheers,
Ben,
^ permalink raw reply
* [PATCH 3/3] mtd: s3c2410: parse the device configuration from OF node
From: Sergio Prado @ 2016-10-05 23:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475711217-974-1-git-send-email-sergio.prado@e-labworks.com>
Allows configuring Samsung's s3c2410 memory controller using a
devicetree.
Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
---
drivers/mtd/nand/s3c2410.c | 171 ++++++++++++++++++++++---
include/linux/platform_data/mtd-nand-s3c2410.h | 1 +
2 files changed, 156 insertions(+), 16 deletions(-)
diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
index 174ac9dc4265..352cf2656bc8 100644
--- a/drivers/mtd/nand/s3c2410.c
+++ b/drivers/mtd/nand/s3c2410.c
@@ -39,6 +39,8 @@
#include <linux/slab.h>
#include <linux/clk.h>
#include <linux/cpufreq.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/nand.h>
@@ -185,6 +187,26 @@ struct s3c2410_nand_info {
#endif
};
+struct s3c24XX_nand_devtype_data {
+ enum s3c_cpu_type type;
+};
+
+struct s3c24XX_nand_devtype_data s3c2410_nand_devtype_data = {
+ .type = TYPE_S3C2410,
+};
+
+struct s3c24XX_nand_devtype_data s3c2412_nand_devtype_data = {
+ .type = TYPE_S3C2412,
+};
+
+struct s3c24XX_nand_devtype_data s3c2440_nand_devtype_data = {
+ .type = TYPE_S3C2440,
+};
+
+struct s3c24XX_nand_devtype_data s3c6400_nand_devtype_data = {
+ .type = TYPE_S3C2412,
+};
+
/* conversion functions */
static struct s3c2410_nand_mtd *s3c2410_nand_mtd_toours(struct mtd_info *mtd)
@@ -811,6 +833,8 @@ static void s3c2410_nand_init_chip(struct s3c2410_nand_info *info,
struct nand_chip *chip = &nmtd->chip;
void __iomem *regs = info->regs;
+ nand_set_flash_node(chip, set->of_node);
+
chip->write_buf = s3c2410_nand_write_buf;
chip->read_buf = s3c2410_nand_read_buf;
chip->select_chip = s3c2410_nand_select_chip;
@@ -859,12 +883,35 @@ static void s3c2410_nand_init_chip(struct s3c2410_nand_info *info,
chip->ecc.mode = info->platform->ecc_mode;
/* If you use u-boot BBT creation code, specifying this flag will
- * let the kernel fish out the BBT from the NAND, and also skip the
- * full NAND scan that can take 1/2s or so. Little things... */
- if (set->flash_bbt) {
+ * let the kernel fish out the BBT from the NAND */
+ if (set->flash_bbt)
chip->bbt_options |= NAND_BBT_USE_FLASH;
- chip->options |= NAND_SKIP_BBTSCAN;
- }
+}
+
+static int s3c2410_nand_init_timings(struct s3c2410_nand_info *info,
+ struct nand_chip *chip)
+{
+ struct s3c2410_platform_nand *pdata = info->platform;
+ const struct nand_sdr_timings *t;
+ int tacls, mode;
+
+ mode = onfi_get_async_timing_mode(chip);
+ if (mode == ONFI_TIMING_MODE_UNKNOWN)
+ mode = chip->onfi_timing_mode_default;
+
+ t = onfi_async_timing_mode_to_sdr_timings(mode);
+ if (IS_ERR(t))
+ return PTR_ERR(t);
+
+ tacls = t->tCLS_min - t->tWP_min;
+ if (tacls < 0)
+ tacls = 0;
+
+ pdata->tacls = DIV_ROUND_UP(tacls, 1000);
+ pdata->twrph0 = DIV_ROUND_UP(t->tWP_min, 1000);
+ pdata->twrph1 = DIV_ROUND_UP(t->tCLH_min, 1000);
+
+ return 0;
}
/**
@@ -881,7 +928,9 @@ static void s3c2410_nand_init_chip(struct s3c2410_nand_info *info,
static int s3c2410_nand_update_chip(struct s3c2410_nand_info *info,
struct s3c2410_nand_mtd *nmtd)
{
+ struct device_node *np = info->device->of_node;
struct nand_chip *chip = &nmtd->chip;
+ int ret;
switch (chip->ecc.mode) {
@@ -943,6 +992,90 @@ static int s3c2410_nand_update_chip(struct s3c2410_nand_info *info,
return -EINVAL;
}
+ if (chip->bbt_options & NAND_BBT_USE_FLASH)
+ chip->options |= NAND_SKIP_BBTSCAN;
+
+ /* read timings from nand_sdr_timings when booting with a device tree */
+ if (np) {
+ ret = s3c2410_nand_init_timings(info, chip);
+ if (ret) {
+ dev_err(info->device,
+ "could not configure chip timings: %d\n", ret);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static const struct of_device_id s3c24xx_nand_dt_ids[] = {
+ {
+ .compatible = "samsung,s3c2410-nand",
+ .data = &s3c2410_nand_devtype_data,
+ }, {
+ .compatible = "samsung,s3c2412-nand",
+ .data = &s3c2412_nand_devtype_data,
+ }, {
+ .compatible = "samsung,s3c2440-nand",
+ .data = &s3c2440_nand_devtype_data,
+ }, {
+ .compatible = "samsung,s3c6400-nand",
+ .data = &s3c6400_nand_devtype_data,
+ },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, s3c24xx_nand_dt_ids);
+
+static int s3c24xx_nand_probe_dt(struct platform_device *pdev)
+{
+ const struct s3c24XX_nand_devtype_data *devtype_data;
+ struct s3c2410_platform_nand *pdata;
+ struct s3c2410_nand_info *info = platform_get_drvdata(pdev);
+ struct device_node *np = pdev->dev.of_node, *child;
+ struct s3c2410_nand_set *sets;
+
+ devtype_data = of_device_get_match_data(&pdev->dev);
+ if (!devtype_data)
+ return -ENODEV;
+
+ info->cpu_type = devtype_data->type;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdev->dev.platform_data = pdata;
+
+ pdata->nr_sets = of_get_child_count(np);
+ if (!pdata->nr_sets)
+ return 0;
+
+ sets = devm_kzalloc(&pdev->dev, sizeof(*sets) * pdata->nr_sets, GFP_KERNEL);
+ if (!sets)
+ return -ENOMEM;
+
+ pdata->sets = sets;
+
+ for_each_available_child_of_node(np, child) {
+
+ sets->name = (char *)child->name;
+ sets->of_node = child;
+ sets->nr_chips = 1;
+
+ of_node_get(child);
+
+ sets++;
+ }
+
+ return 0;
+}
+
+static int s3c24xx_nand_probe_pdata(struct platform_device *pdev)
+{
+ struct s3c2410_nand_info *info = platform_get_drvdata(pdev);
+
+ info->cpu_type = platform_get_device_id(pdev)->driver_data;
+
return 0;
}
@@ -955,8 +1088,7 @@ static int s3c2410_nand_update_chip(struct s3c2410_nand_info *info,
*/
static int s3c24xx_nand_probe(struct platform_device *pdev)
{
- struct s3c2410_platform_nand *plat = to_nand_plat(pdev);
- enum s3c_cpu_type cpu_type;
+ struct s3c2410_platform_nand *plat;
struct s3c2410_nand_info *info;
struct s3c2410_nand_mtd *nmtd;
struct s3c2410_nand_set *sets;
@@ -966,8 +1098,6 @@ static int s3c24xx_nand_probe(struct platform_device *pdev)
int nr_sets;
int setno;
- cpu_type = platform_get_device_id(pdev)->driver_data;
-
info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
if (info == NULL) {
err = -ENOMEM;
@@ -990,6 +1120,16 @@ static int s3c24xx_nand_probe(struct platform_device *pdev)
s3c2410_nand_clk_set_state(info, CLOCK_ENABLE);
+ if (pdev->dev.of_node)
+ err = s3c24xx_nand_probe_dt(pdev);
+ else
+ err = s3c24xx_nand_probe_pdata(pdev);
+
+ if (err)
+ goto exit_error;
+
+ plat = to_nand_plat(pdev);
+
/* allocate and map the resource */
/* currently we assume we have the one resource */
@@ -998,7 +1138,6 @@ static int s3c24xx_nand_probe(struct platform_device *pdev)
info->device = &pdev->dev;
info->platform = plat;
- info->cpu_type = cpu_type;
info->regs = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(info->regs)) {
@@ -1008,12 +1147,6 @@ static int s3c24xx_nand_probe(struct platform_device *pdev)
dev_dbg(&pdev->dev, "mapped registers at %p\n", info->regs);
- /* initialise the hardware */
-
- err = s3c2410_nand_inithw(info);
- if (err != 0)
- goto exit_error;
-
sets = (plat != NULL) ? plat->sets : NULL;
nr_sets = (plat != NULL) ? plat->nr_sets : 1;
@@ -1057,6 +1190,11 @@ static int s3c24xx_nand_probe(struct platform_device *pdev)
sets++;
}
+ /* initialise the hardware */
+ err = s3c2410_nand_inithw(info);
+ if (err != 0)
+ goto exit_error;
+
err = s3c2410_nand_cpufreq_register(info);
if (err < 0) {
dev_err(&pdev->dev, "failed to init cpufreq support\n");
@@ -1157,6 +1295,7 @@ static struct platform_driver s3c24xx_nand_driver = {
.id_table = s3c24xx_driver_ids,
.driver = {
.name = "s3c24xx-nand",
+ .of_match_table = s3c24xx_nand_dt_ids,
},
};
diff --git a/include/linux/platform_data/mtd-nand-s3c2410.h b/include/linux/platform_data/mtd-nand-s3c2410.h
index 729af13d1773..f01659026b26 100644
--- a/include/linux/platform_data/mtd-nand-s3c2410.h
+++ b/include/linux/platform_data/mtd-nand-s3c2410.h
@@ -40,6 +40,7 @@ struct s3c2410_nand_set {
char *name;
int *nr_map;
struct mtd_partition *partitions;
+ struct device_node *of_node;
};
struct s3c2410_platform_nand {
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: mtd: add DT binding for s3c2410 flash controller
From: Sergio Prado @ 2016-10-05 23:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475711217-974-1-git-send-email-sergio.prado@e-labworks.com>
Adds the device tree bindings description for Samsung S3C2410 and
compatible NAND flash controller.
Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
---
.../devicetree/bindings/mtd/samsung-s3c2410.txt | 57 ++++++++++++++++++++++
1 file changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
diff --git a/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt b/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
new file mode 100644
index 000000000000..1cc8e84479ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
@@ -0,0 +1,57 @@
+* Samsung S3C2410 and compatible NAND flash controller
+
+Required properties:
+- compatible : The possible values are:
+ "samsung,s3c2410-nand"
+ "samsung,s3c2412-nand"
+ "samsung,s3c2440-nand"
+ "samsung,s3c6400-nand"
+- reg : register's location and length.
+- #address-cells, #size-cells : see nand.txt
+- clocks : phandle to the nand controller clock
+- clock-names : must contain "nand"
+
+Optional child nodes:
+Child nodes representing the available nand chips.
+
+Optional child properties:
+- nand-ecc-mode : see nand.txt
+- nand-on-flash-bbt : see nand.txt
+
+Each child device node may optionally contain a 'partitions' sub-node,
+which further contains sub-nodes describing the flash partition mapping.
+See partition.txt for more detail.
+
+Example:
+
+nand-controller at 4e000000 {
+ compatible = "samsung,s3c2440-nand";
+ reg = <0x4e000000 0x40>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clocks = <&clocks HCLK_NAND>;
+ clock-names = "nand";
+
+ nand {
+ nand-ecc-mode = "soft";
+ nand-on-flash-bbt;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition at 0 {
+ label = "u-boot";
+ reg = <0 0x040000>;
+ };
+
+ partition at 40000 {
+ label = "kernel";
+ reg = <0x040000 0x500000>;
+ };
+ };
+ };
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 1/3] mtd: s3c2410: make ecc mode configurable via platform data
From: Sergio Prado @ 2016-10-05 23:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475711217-974-1-git-send-email-sergio.prado@e-labworks.com>
Removing CONFIG_MTD_NAND_S3C2410_HWECC option and adding a ecc_mode
field in the drivers's platform data structure so it can be selectable
via platform data.
Also setting this field to NAND_ECC_SOFT in all boards using this
driver since none of them had CONFIG_MTD_NAND_S3C2410_HWECC enabled.
Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
---
arch/arm/mach-s3c24xx/common-smdk.c | 1 +
arch/arm/mach-s3c24xx/mach-anubis.c | 1 +
arch/arm/mach-s3c24xx/mach-at2440evb.c | 1 +
arch/arm/mach-s3c24xx/mach-bast.c | 1 +
arch/arm/mach-s3c24xx/mach-gta02.c | 1 +
arch/arm/mach-s3c24xx/mach-jive.c | 1 +
arch/arm/mach-s3c24xx/mach-mini2440.c | 1 +
arch/arm/mach-s3c24xx/mach-osiris.c | 1 +
arch/arm/mach-s3c24xx/mach-qt2410.c | 1 +
arch/arm/mach-s3c24xx/mach-rx1950.c | 1 +
arch/arm/mach-s3c24xx/mach-rx3715.c | 1 +
arch/arm/mach-s3c24xx/mach-vstms.c | 1 +
arch/arm/mach-s3c64xx/mach-hmt.c | 1 +
arch/arm/mach-s3c64xx/mach-mini6410.c | 1 +
arch/arm/mach-s3c64xx/mach-real6410.c | 1 +
drivers/mtd/nand/Kconfig | 9 --
drivers/mtd/nand/s3c2410.c | 119 +++++++++++++------------
include/linux/platform_data/mtd-nand-s3c2410.h | 6 +-
18 files changed, 79 insertions(+), 70 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/common-smdk.c b/arch/arm/mach-s3c24xx/common-smdk.c
index e9fbcc91c5c0..9e0bc46e90ec 100644
--- a/arch/arm/mach-s3c24xx/common-smdk.c
+++ b/arch/arm/mach-s3c24xx/common-smdk.c
@@ -171,6 +171,7 @@ static struct s3c2410_platform_nand smdk_nand_info = {
.twrph1 = 20,
.nr_sets = ARRAY_SIZE(smdk_nand_sets),
.sets = smdk_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
/* devices we initialise */
diff --git a/arch/arm/mach-s3c24xx/mach-anubis.c b/arch/arm/mach-s3c24xx/mach-anubis.c
index d03df0df01fa..029ef1b58925 100644
--- a/arch/arm/mach-s3c24xx/mach-anubis.c
+++ b/arch/arm/mach-s3c24xx/mach-anubis.c
@@ -223,6 +223,7 @@ static struct s3c2410_platform_nand __initdata anubis_nand_info = {
.nr_sets = ARRAY_SIZE(anubis_nand_sets),
.sets = anubis_nand_sets,
.select_chip = anubis_nand_select,
+ .ecc_mode = NAND_ECC_SOFT,
};
/* IDE channels */
diff --git a/arch/arm/mach-s3c24xx/mach-at2440evb.c b/arch/arm/mach-s3c24xx/mach-at2440evb.c
index 9ae170fef2a7..7b28eb623fc1 100644
--- a/arch/arm/mach-s3c24xx/mach-at2440evb.c
+++ b/arch/arm/mach-s3c24xx/mach-at2440evb.c
@@ -114,6 +114,7 @@ static struct s3c2410_platform_nand __initdata at2440evb_nand_info = {
.twrph1 = 40,
.nr_sets = ARRAY_SIZE(at2440evb_nand_sets),
.sets = at2440evb_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
/* DM9000AEP 10/100 ethernet controller */
diff --git a/arch/arm/mach-s3c24xx/mach-bast.c b/arch/arm/mach-s3c24xx/mach-bast.c
index ed07cf392d4b..5185036765db 100644
--- a/arch/arm/mach-s3c24xx/mach-bast.c
+++ b/arch/arm/mach-s3c24xx/mach-bast.c
@@ -299,6 +299,7 @@ static struct s3c2410_platform_nand __initdata bast_nand_info = {
.nr_sets = ARRAY_SIZE(bast_nand_sets),
.sets = bast_nand_sets,
.select_chip = bast_nand_select,
+ .ecc_mode = NAND_ECC_SOFT,
};
/* DM9000 */
diff --git a/arch/arm/mach-s3c24xx/mach-gta02.c b/arch/arm/mach-s3c24xx/mach-gta02.c
index 27ae6877550f..b0ed401da3a3 100644
--- a/arch/arm/mach-s3c24xx/mach-gta02.c
+++ b/arch/arm/mach-s3c24xx/mach-gta02.c
@@ -443,6 +443,7 @@ static struct s3c2410_platform_nand __initdata gta02_nand_info = {
.twrph1 = 15,
.nr_sets = ARRAY_SIZE(gta02_nand_sets),
.sets = gta02_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
diff --git a/arch/arm/mach-s3c24xx/mach-jive.c b/arch/arm/mach-s3c24xx/mach-jive.c
index 7d99fe8f6157..895aca225952 100644
--- a/arch/arm/mach-s3c24xx/mach-jive.c
+++ b/arch/arm/mach-s3c24xx/mach-jive.c
@@ -232,6 +232,7 @@ static struct s3c2410_platform_nand __initdata jive_nand_info = {
.twrph1 = 40,
.sets = jive_nand_sets,
.nr_sets = ARRAY_SIZE(jive_nand_sets),
+ .ecc_mode = NAND_ECC_SOFT,
};
static int __init jive_mtdset(char *options)
diff --git a/arch/arm/mach-s3c24xx/mach-mini2440.c b/arch/arm/mach-s3c24xx/mach-mini2440.c
index bbf41322d726..97edcc12a9e6 100644
--- a/arch/arm/mach-s3c24xx/mach-mini2440.c
+++ b/arch/arm/mach-s3c24xx/mach-mini2440.c
@@ -287,6 +287,7 @@ static struct s3c2410_platform_nand mini2440_nand_info __initdata = {
.nr_sets = ARRAY_SIZE(mini2440_nand_sets),
.sets = mini2440_nand_sets,
.ignore_unset_ecc = 1,
+ .ecc_mode = NAND_ECC_SOFT,
};
/* DM9000AEP 10/100 ethernet controller */
diff --git a/arch/arm/mach-s3c24xx/mach-osiris.c b/arch/arm/mach-s3c24xx/mach-osiris.c
index 2f6fdc326835..70b0eb7d3134 100644
--- a/arch/arm/mach-s3c24xx/mach-osiris.c
+++ b/arch/arm/mach-s3c24xx/mach-osiris.c
@@ -238,6 +238,7 @@ static struct s3c2410_platform_nand __initdata osiris_nand_info = {
.nr_sets = ARRAY_SIZE(osiris_nand_sets),
.sets = osiris_nand_sets,
.select_chip = osiris_nand_select,
+ .ecc_mode = NAND_ECC_SOFT,
};
/* PCMCIA control and configuration */
diff --git a/arch/arm/mach-s3c24xx/mach-qt2410.c b/arch/arm/mach-s3c24xx/mach-qt2410.c
index 984516e8307a..868c82087403 100644
--- a/arch/arm/mach-s3c24xx/mach-qt2410.c
+++ b/arch/arm/mach-s3c24xx/mach-qt2410.c
@@ -284,6 +284,7 @@ static struct s3c2410_platform_nand __initdata qt2410_nand_info = {
.twrph1 = 20,
.nr_sets = ARRAY_SIZE(qt2410_nand_sets),
.sets = qt2410_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
/* UDC */
diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c b/arch/arm/mach-s3c24xx/mach-rx1950.c
index 25a139bb9826..e86ad6a68a0b 100644
--- a/arch/arm/mach-s3c24xx/mach-rx1950.c
+++ b/arch/arm/mach-s3c24xx/mach-rx1950.c
@@ -611,6 +611,7 @@ static struct s3c2410_platform_nand rx1950_nand_info = {
.twrph1 = 15,
.nr_sets = ARRAY_SIZE(rx1950_nand_sets),
.sets = rx1950_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
static struct s3c2410_udc_mach_info rx1950_udc_cfg __initdata = {
diff --git a/arch/arm/mach-s3c24xx/mach-rx3715.c b/arch/arm/mach-s3c24xx/mach-rx3715.c
index cf55196f89ca..a39fb9780dd3 100644
--- a/arch/arm/mach-s3c24xx/mach-rx3715.c
+++ b/arch/arm/mach-s3c24xx/mach-rx3715.c
@@ -164,6 +164,7 @@ static struct s3c2410_platform_nand __initdata rx3715_nand_info = {
.twrph1 = 15,
.nr_sets = ARRAY_SIZE(rx3715_nand_sets),
.sets = rx3715_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
static struct platform_device *rx3715_devices[] __initdata = {
diff --git a/arch/arm/mach-s3c24xx/mach-vstms.c b/arch/arm/mach-s3c24xx/mach-vstms.c
index b4460d5f7011..f5e6322145fa 100644
--- a/arch/arm/mach-s3c24xx/mach-vstms.c
+++ b/arch/arm/mach-s3c24xx/mach-vstms.c
@@ -117,6 +117,7 @@ static struct s3c2410_platform_nand __initdata vstms_nand_info = {
.twrph1 = 20,
.nr_sets = ARRAY_SIZE(vstms_nand_sets),
.sets = vstms_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
static struct platform_device *vstms_devices[] __initdata = {
diff --git a/arch/arm/mach-s3c64xx/mach-hmt.c b/arch/arm/mach-s3c64xx/mach-hmt.c
index bc7dc1fcbf7d..59b5531f1987 100644
--- a/arch/arm/mach-s3c64xx/mach-hmt.c
+++ b/arch/arm/mach-s3c64xx/mach-hmt.c
@@ -204,6 +204,7 @@ static struct s3c2410_platform_nand hmt_nand_info = {
.twrph1 = 40,
.nr_sets = ARRAY_SIZE(hmt_nand_sets),
.sets = hmt_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
static struct gpio_led hmt_leds[] = {
diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c b/arch/arm/mach-s3c64xx/mach-mini6410.c
index ae999fb3fe6d..a3e3e25728b4 100644
--- a/arch/arm/mach-s3c64xx/mach-mini6410.c
+++ b/arch/arm/mach-s3c64xx/mach-mini6410.c
@@ -142,6 +142,7 @@ static struct s3c2410_platform_nand mini6410_nand_info = {
.twrph1 = 40,
.nr_sets = ARRAY_SIZE(mini6410_nand_sets),
.sets = mini6410_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
static struct s3c_fb_pd_win mini6410_lcd_type0_fb_win = {
diff --git a/arch/arm/mach-s3c64xx/mach-real6410.c b/arch/arm/mach-s3c64xx/mach-real6410.c
index 4e240ffa7ac7..d6b3ffd7704b 100644
--- a/arch/arm/mach-s3c64xx/mach-real6410.c
+++ b/arch/arm/mach-s3c64xx/mach-real6410.c
@@ -194,6 +194,7 @@ static struct s3c2410_platform_nand real6410_nand_info = {
.twrph1 = 40,
.nr_sets = ARRAY_SIZE(real6410_nand_sets),
.sets = real6410_nand_sets,
+ .ecc_mode = NAND_ECC_SOFT,
};
static struct platform_device *real6410_devices[] __initdata = {
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 21ff58099f3b..f2737229f506 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -179,15 +179,6 @@ config MTD_NAND_S3C2410_DEBUG
help
Enable debugging of the S3C NAND driver
-config MTD_NAND_S3C2410_HWECC
- bool "Samsung S3C NAND Hardware ECC"
- depends on MTD_NAND_S3C2410
- help
- Enable the use of the controller's internal ECC generator when
- using NAND. Early versions of the chips have had problems with
- incorrect ECC generation, and if using these, the default of
- software ECC is preferable.
-
config MTD_NAND_NDFC
tristate "NDFC NanD Flash Controller"
depends on 4xx
diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
index d9309cf0ce2e..174ac9dc4265 100644
--- a/drivers/mtd/nand/s3c2410.c
+++ b/drivers/mtd/nand/s3c2410.c
@@ -497,7 +497,6 @@ static int s3c2412_nand_devready(struct mtd_info *mtd)
/* ECC handling functions */
-#ifdef CONFIG_MTD_NAND_S3C2410_HWECC
static int s3c2410_nand_correct_data(struct mtd_info *mtd, u_char *dat,
u_char *read_ecc, u_char *calc_ecc)
{
@@ -649,7 +648,6 @@ static int s3c2440_nand_calculate_ecc(struct mtd_info *mtd, const u_char *dat,
return 0;
}
-#endif
/* over-ride the standard functions for a little more speed. We can
* use read/write block to move the data buffers to/from the controller
@@ -858,50 +856,7 @@ static void s3c2410_nand_init_chip(struct s3c2410_nand_info *info,
nmtd->info = info;
nmtd->set = set;
-#ifdef CONFIG_MTD_NAND_S3C2410_HWECC
- chip->ecc.calculate = s3c2410_nand_calculate_ecc;
- chip->ecc.correct = s3c2410_nand_correct_data;
- chip->ecc.mode = NAND_ECC_HW;
- chip->ecc.strength = 1;
-
- switch (info->cpu_type) {
- case TYPE_S3C2410:
- chip->ecc.hwctl = s3c2410_nand_enable_hwecc;
- chip->ecc.calculate = s3c2410_nand_calculate_ecc;
- break;
-
- case TYPE_S3C2412:
- chip->ecc.hwctl = s3c2412_nand_enable_hwecc;
- chip->ecc.calculate = s3c2412_nand_calculate_ecc;
- break;
-
- case TYPE_S3C2440:
- chip->ecc.hwctl = s3c2440_nand_enable_hwecc;
- chip->ecc.calculate = s3c2440_nand_calculate_ecc;
- break;
- }
-#else
- chip->ecc.mode = NAND_ECC_SOFT;
- chip->ecc.algo = NAND_ECC_HAMMING;
-#endif
-
- if (set->disable_ecc)
- chip->ecc.mode = NAND_ECC_NONE;
-
- switch (chip->ecc.mode) {
- case NAND_ECC_NONE:
- dev_info(info->device, "NAND ECC disabled\n");
- break;
- case NAND_ECC_SOFT:
- dev_info(info->device, "NAND soft ECC\n");
- break;
- case NAND_ECC_HW:
- dev_info(info->device, "NAND hardware ECC\n");
- break;
- default:
- dev_info(info->device, "NAND ECC UNKNOWN\n");
- break;
- }
+ chip->ecc.mode = info->platform->ecc_mode;
/* If you use u-boot BBT creation code, specifying this flag will
* let the kernel fish out the BBT from the NAND, and also skip the
@@ -923,28 +878,72 @@ static void s3c2410_nand_init_chip(struct s3c2410_nand_info *info,
*
* The internal state is currently limited to the ECC state information.
*/
-static void s3c2410_nand_update_chip(struct s3c2410_nand_info *info,
+static int s3c2410_nand_update_chip(struct s3c2410_nand_info *info,
struct s3c2410_nand_mtd *nmtd)
{
struct nand_chip *chip = &nmtd->chip;
- dev_dbg(info->device, "chip %p => page shift %d\n",
- chip, chip->page_shift);
+ switch (chip->ecc.mode) {
- if (chip->ecc.mode != NAND_ECC_HW)
- return;
+ case NAND_ECC_NONE:
+ dev_info(info->device, "ECC disabled\n");
+ break;
+
+ case NAND_ECC_SOFT:
+ /*
+ * This driver expects Hamming based ECC when ecc_mode is set
+ * to NAND_ECC_SOFT. Force ecc.algo to NAND_ECC_HAMMING to
+ * avoid adding an extra ecc_algo field to s3c2410_platform_nand.
+ */
+ chip->ecc.algo = NAND_ECC_HAMMING;
+ dev_info(info->device, "soft ECC\n");
+ break;
+
+ case NAND_ECC_HW:
+ chip->ecc.calculate = s3c2410_nand_calculate_ecc;
+ chip->ecc.correct = s3c2410_nand_correct_data;
+ chip->ecc.strength = 1;
+
+ switch (info->cpu_type) {
+ case TYPE_S3C2410:
+ chip->ecc.hwctl = s3c2410_nand_enable_hwecc;
+ chip->ecc.calculate = s3c2410_nand_calculate_ecc;
+ break;
+
+ case TYPE_S3C2412:
+ chip->ecc.hwctl = s3c2412_nand_enable_hwecc;
+ chip->ecc.calculate = s3c2412_nand_calculate_ecc;
+ break;
+
+ case TYPE_S3C2440:
+ chip->ecc.hwctl = s3c2440_nand_enable_hwecc;
+ chip->ecc.calculate = s3c2440_nand_calculate_ecc;
+ break;
+ }
+
+ dev_dbg(info->device, "chip %p => page shift %d\n",
+ chip, chip->page_shift);
/* change the behaviour depending on whether we are using
* the large or small page nand device */
+ if (chip->page_shift > 10) {
+ chip->ecc.size = 256;
+ chip->ecc.bytes = 3;
+ } else {
+ chip->ecc.size = 512;
+ chip->ecc.bytes = 3;
+ mtd_set_ooblayout(nand_to_mtd(chip), &s3c2410_ooblayout_ops);
+ }
- if (chip->page_shift > 10) {
- chip->ecc.size = 256;
- chip->ecc.bytes = 3;
- } else {
- chip->ecc.size = 512;
- chip->ecc.bytes = 3;
- mtd_set_ooblayout(nand_to_mtd(chip), &s3c2410_ooblayout_ops);
+ dev_info(info->device, "hardware ECC\n");
+ break;
+
+ default:
+ dev_err(info->device, "invalid ECC mode!\n");
+ return -EINVAL;
}
+
+ return 0;
}
/* s3c24xx_nand_probe
@@ -1047,7 +1046,9 @@ static int s3c24xx_nand_probe(struct platform_device *pdev)
NULL);
if (nmtd->scan_res == 0) {
- s3c2410_nand_update_chip(info, nmtd);
+ err = s3c2410_nand_update_chip(info, nmtd);
+ if (err < 0)
+ goto exit_error;
nand_scan_tail(mtd);
s3c2410_nand_add_partition(info, nmtd, sets);
}
diff --git a/include/linux/platform_data/mtd-nand-s3c2410.h b/include/linux/platform_data/mtd-nand-s3c2410.h
index c55e42ee57fa..729af13d1773 100644
--- a/include/linux/platform_data/mtd-nand-s3c2410.h
+++ b/include/linux/platform_data/mtd-nand-s3c2410.h
@@ -12,9 +12,10 @@
#ifndef __MTD_NAND_S3C2410_H
#define __MTD_NAND_S3C2410_H
+#include <linux/mtd/nand.h>
+
/**
* struct s3c2410_nand_set - define a set of one or more nand chips
- * @disable_ecc: Entirely disable ECC - Dangerous
* @flash_bbt: Openmoko u-boot can create a Bad Block Table
* Setting this flag will allow the kernel to
* look for it at boot time and also skip the NAND
@@ -31,7 +32,6 @@
* a warning at boot time.
*/
struct s3c2410_nand_set {
- unsigned int disable_ecc:1;
unsigned int flash_bbt:1;
unsigned int options;
@@ -51,6 +51,8 @@ struct s3c2410_platform_nand {
unsigned int ignore_unset_ecc:1;
+ nand_ecc_modes_t ecc_mode;
+
int nr_sets;
struct s3c2410_nand_set *sets;
--
1.9.1
^ permalink raw reply related
* [PATCH 0/3] mtd: s3c2410: add device tree support
From: Sergio Prado @ 2016-10-05 23:46 UTC (permalink / raw)
To: linux-arm-kernel
This series adds support for configuring Samsung's s3c2410 and
compatible flash memory controller via devicetree.
Tested on FriendlyARM mini2440, based on s3c2440 SoC.
Patch 3 depends on patch 1.
Changes since v1:
- read timings from nand_sdr_timings when booting with a device tree
- naming improvements in the device tree binding
(s/nand/nand-controller/, s/_/-, s/children/child)
- dropped property samsung,ignore_unset_ecc
- remove @0 from nand device node
- checking pdev->dev.of_node instead of using ifdef CONFIG_OF_MTD
- preventing from parsing device tree properties twice
- increment the nand controller child node refcount, since we
maintain a reference to it and its name field
- using of_device_get_match_data() instead of of_match_device()
to make the code simpler
- remove CONFIG_MTD_NAND_S3C2410_HWECC compile option so we can
select ECC mode using nand-ecc-mode property in the device tree
Sergio Prado (3):
mtd: s3c2410: make ecc mode configurable via platform data
dt-bindings: mtd: add DT binding for s3c2410 flash controller
mtd: s3c2410: parse the device configuration from OF node
.../devicetree/bindings/mtd/samsung-s3c2410.txt | 57 +++++
arch/arm/mach-s3c24xx/common-smdk.c | 1 +
arch/arm/mach-s3c24xx/mach-anubis.c | 1 +
arch/arm/mach-s3c24xx/mach-at2440evb.c | 1 +
arch/arm/mach-s3c24xx/mach-bast.c | 1 +
arch/arm/mach-s3c24xx/mach-gta02.c | 1 +
arch/arm/mach-s3c24xx/mach-jive.c | 1 +
arch/arm/mach-s3c24xx/mach-mini2440.c | 1 +
arch/arm/mach-s3c24xx/mach-osiris.c | 1 +
arch/arm/mach-s3c24xx/mach-qt2410.c | 1 +
arch/arm/mach-s3c24xx/mach-rx1950.c | 1 +
arch/arm/mach-s3c24xx/mach-rx3715.c | 1 +
arch/arm/mach-s3c24xx/mach-vstms.c | 1 +
arch/arm/mach-s3c64xx/mach-hmt.c | 1 +
arch/arm/mach-s3c64xx/mach-mini6410.c | 1 +
arch/arm/mach-s3c64xx/mach-real6410.c | 1 +
drivers/mtd/nand/Kconfig | 9 -
drivers/mtd/nand/s3c2410.c | 284 +++++++++++++++------
include/linux/platform_data/mtd-nand-s3c2410.h | 7 +-
19 files changed, 289 insertions(+), 83 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
--
1.9.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox