* [PATCH] arm: plat-orion: fix printing of "MPP config unavailable on this hardware"
From: Jason Cooper @ 2013-01-23 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358949059-10803-1-git-send-email-gerlando.falauto@keymile.com>
On Wed, Jan 23, 2013 at 02:50:59PM +0100, Gerlando Falauto wrote:
> Commit 3cff484d4b264ff467a3b45c544cbbbab69f0bf8
> ARM: dove: Consolidate mpp code with platform mpp.
>
> refactored printing of the kernel warning
> "orion_mpp_conf: requested MPP%u config unavailable on this hardware\n"
> which is not to be printed in case of variant_mask = 0 (unknown variant).
> This check should be performed using a logical AND (&&) as opposed
> to a bitwise AND (&).
> Otherwise, test would fail (and message would be printed) if variant_mask != 1
>
> Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Nicolas Pitre <nico@linaro.org>
> Cc: Holger Brunck <holger.brunck@keymile.com>
> ---
> arch/arm/plat-orion/mpp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to mvebu/fixes with some minor cleanup of the commit message
thx,
Jason.
^ permalink raw reply
* [PATCH 1/2] misc/at24: Add at24c512b eeprom support
From: Liu Ying @ 2013-01-23 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123141445.GA2758@pengutronix.de>
2013/1/23 Wolfram Sang <w.sang@pengutronix.de>:
>
>> The names of the two entries are not the same, one is "24c512", the
>> other is "24c512b".
>
> I do understand that. There are TONS of 24c512 variants out there.
>
>> My original idea to add the new entry is to count on the name
>> difference to do different system reset operations.
>
> Your devicetree may have both names, but at24 doesn't need it since
> there is no code involved handling the difference.
>
>> The commit message of the patch which adds 24c32 support for MX28EVK
>> tells that "mx28evk has a free slot U50 that can be used to populate
>> an I2C EEPROM.".
>
> I do know that, too. You can put other things there, too. But well, not
> worth the hazzle...
I accept your comments on this patch. Thanks for your review!
>
> --
> Pengutronix e.K. | Wolfram Sang |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAlD/8FUACgkQD27XaX1/VRsmGgCeJZCaByj0gw37lr753wxW0npY
> 06oAn0WAmYiUabRNgQ6eAmcO7Ky3f1U4
> =JSKP
> -----END PGP SIGNATURE-----
>
--
Best Regards,
Liu Ying
^ permalink raw reply
* [PATCH 1/2] misc/at24: Add at24c512b eeprom support
From: Wolfram Sang @ 2013-01-23 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+8Hj83n+pC+a6bYOOH1b61DTqSjpKsxyKDgDL2pCRKxTq4EXg@mail.gmail.com>
> The names of the two entries are not the same, one is "24c512", the
> other is "24c512b".
I do understand that. There are TONS of 24c512 variants out there.
> My original idea to add the new entry is to count on the name
> difference to do different system reset operations.
Your devicetree may have both names, but at24 doesn't need it since
there is no code involved handling the difference.
> The commit message of the patch which adds 24c32 support for MX28EVK
> tells that "mx28evk has a free slot U50 that can be used to populate
> an I2C EEPROM.".
I do know that, too. You can put other things there, too. But well, not
worth the hazzle...
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130123/f1167045/attachment.sig>
^ permalink raw reply
* [PATCH 3.9] arm: mvebu: add button for OpenBlocks AX3-4
From: Jason Cooper @ 2013-01-23 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357576198-24574-1-git-send-email-thomas.petazzoni@free-electrons.com>
On Mon, Jan 07, 2013 at 05:29:58PM +0100, Thomas Petazzoni wrote:
> The OpenBlocks AX3-4 board has one software-controlled button on the
> front side, labeled "INIT", so we add minimal support for this button
> in the kernel.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
Applied to mvebu/dt
thx,
Jason.
^ permalink raw reply
* [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)
From: Rob Clark @ 2013-01-23 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123133607.GE2637@n2100.arm.linux.org.uk>
On Wed, Jan 23, 2013 at 7:36 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Jan 23, 2013 at 07:24:33AM -0600, Rob Clark wrote:
>> On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine <moinejf@free.fr> wrote:
>> > Hi Rob,
>> >
>> > As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
>> > I had a look at your IT LCD driver. Comments below.
>>
>> Just fyi, you can re-use the nxp-tda998x part independently of tilcdc
>> (just in case that wasn't clear).
>
> Great, this chip is also used on the cubox too.
cool, it would be great if other platforms could benefit from this as
well.. the out-of-tree nxp driver is just horrid ;-)
> The one thing I wonder is how you deal with the VSYNC/HSYNC polarities
> that are provided to the TDA9988x chip. On the cubox, I have to adjust
> the mode parameters such that the polarities are fixed up thusly:
>
> adjusted->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NHSYNC |
> DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC |
> DRM_MODE_FLAG_PCSYNC | DRM_MODE_FLAG_NCSYNC);
>
> /* The TDA19988 always requires negative VSYNC? */
> adjusted->flags |= DRM_MODE_FLAG_NVSYNC;
>
> /* The TDA19988 requires positive HSYNC on 1080p or 720p */
> if ((adjusted->hdisplay == 1920 && adjusted->vdisplay == 1080) ||
> (adjusted->hdisplay == 1280 && adjusted->vdisplay == 720))
> adjusted->flags |= DRM_MODE_FLAG_PHSYNC;
> else
> adjusted->flags |= DRM_MODE_FLAG_NHSYNC;
>
> return true;
>
> for these resolutions to be displayed correctly.
hmm, I didn't come across this. Although 1080p seems to be a bit more
than what the little board I'm working on can drive. I didn't have to
do any special fixup for 720p..
I wonder if you are having to do that with the nxp out of tree driver?
Maybe it is related to how that driver it is configuring the hw? It
would be interesting if you hit the same issue w/ the i2c encoder
slave version.
At any rate, if it turns out to be needed, we can add this in
tda998x_encoder_mode_fixup().
> Also, when the only output is the HDMI device, reporting the display
> "disconnected" and without any modes seems to cause problems - I have to
> report "unknown" status when there's nothing connected, and also provide
> a default (720p) mode when no EDID is received.
hmm, also did not run into any issues here on my end. What sort of
problems did you hit?
BR,
-R
^ permalink raw reply
* [PATCH 1/2] misc/at24: Add at24c512b eeprom support
From: Liu Ying @ 2013-01-23 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123134936.GH16264@pengutronix.de>
2013/1/23 Wolfram Sang <w.sang@pengutronix.de>:
> Hi,
>
>> There are some difference between 24c512 and 24c512b about the system
>> reset procedure, according to the two devices' spec:
>> 24c512b:(a) Create a start bit condition, (b)clock 9 cycles, (c)
>> create another start bit followed by stop bit condition.
>> 24c512:(a) Clock up to 9 cycles, (b) look for SDA high in each cycle
>> while SCL is high and then, (c) create a start condition as SDA is
>> high.
>> Could this be a reason to add an entry for 24c512b?
>
> Since the entries in at24_ids[] are the same, no. If they would differ,
> that is a reason.
The names of the two entries are not the same, one is "24c512", the
other is "24c512b".
My original idea to add the new entry is to count on the name
difference to do different system reset operations.
>
>> Now, I think the correct vendor name should be "at" or "atmel".
>
> "atmel" would be better, but the MX28EVK doesn't even have an I2C eeprom
> by default IIRC? But that is unrelated to your patch.
The commit message of the patch which adds 24c32 support for MX28EVK
tells that "mx28evk has a free slot U50 that can be used to populate
an I2C EEPROM.".
>
> --
> Pengutronix e.K. | Wolfram Sang |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
--
Best Regards,
Liu Ying
^ permalink raw reply
* [PATCH] arm: plat-orion: fix printing of "MPP config unavailable on this hardware"
From: Andrew Lunn @ 2013-01-23 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358949059-10803-1-git-send-email-gerlando.falauto@keymile.com>
On Wed, Jan 23, 2013 at 02:50:59PM +0100, Gerlando Falauto wrote:
> Commit 3cff484d4b264ff467a3b45c544cbbbab69f0bf8
> ARM: dove: Consolidate mpp code with platform mpp.
>
> refactored printing of the kernel warning
> "orion_mpp_conf: requested MPP%u config unavailable on this hardware\n"
> which is not to be printed in case of variant_mask = 0 (unknown variant).
> This check should be performed using a logical AND (&&) as opposed
> to a bitwise AND (&).
> Otherwise, test would fail (and message would be printed) if variant_mask != 1
>
> Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Nicolas Pitre <nico@linaro.org>
> Cc: Holger Brunck <holger.brunck@keymile.com>
> ---
> arch/arm/plat-orion/mpp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/plat-orion/mpp.c b/arch/arm/plat-orion/mpp.c
> index 3b1e17b..78ea76c 100644
> --- a/arch/arm/plat-orion/mpp.c
> +++ b/arch/arm/plat-orion/mpp.c
> @@ -48,7 +48,7 @@ void __init orion_mpp_conf(unsigned int *mpp_list, unsigned int variant_mask,
> "number (%u)\n", num);
> continue;
> }
> - if (variant_mask & !(*mpp_list & variant_mask)) {
> + if (variant_mask && !(*mpp_list & variant_mask)) {
> printk(KERN_WARNING
> "orion_mpp_conf: requested MPP%u config "
> "unavailable on this hardware\n", num);
> --
> 1.7.10.1
>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Looks like it should only affect dove, but interesting, there are no
users of dove_mpp_conf(), so we can probably throw away
mach-dove/mpp.[ch].
Andrew
^ permalink raw reply
* [PATCH v2] clk: Add axi-clkgen driver
From: Lars-Peter Clausen @ 2013-01-23 14:04 UTC (permalink / raw)
To: linux-arm-kernel
This driver adds support for the AXI clkgen pcore to the common clock framework.
The AXI clkgen pcore is a AXI front-end to the MMCM_ADV frequency synthesizer
commonly found in Xilinx FPGAs.
The AXI clkgen pcore is used in Analog Devices' reference designs targeting
Xilinx FPGAs.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
---
Changes since v1:
* Fix error in the filter coef lookup table
* Use unsigend long long arithmetic to avoid overflow when calculating the
current clock frequency.
* Use readl/writel instead of ioread32/iowrite32
---
.../devicetree/bindings/clock/axi-clkgen.txt | 22 ++
drivers/clk/Kconfig | 8 +
drivers/clk/Makefile | 1 +
drivers/clk/clk-axi-clkgen.c | 331 +++++++++++++++++++++
4 files changed, 362 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/axi-clkgen.txt
create mode 100644 drivers/clk/clk-axi-clkgen.c
diff --git a/Documentation/devicetree/bindings/clock/axi-clkgen.txt b/Documentation/devicetree/bindings/clock/axi-clkgen.txt
new file mode 100644
index 0000000..028b493
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/axi-clkgen.txt
@@ -0,0 +1,22 @@
+Binding for the axi-clkgen clock generator
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "adi,axi-clkgen".
+- #clock-cells : from common clock binding; Should always be set to 0.
+- reg : Address and length of the axi-clkgen register set.
+- clocks : Phandle and clock specifier for the parent clock.
+
+Optional properties:
+- clock-output-names : From common clock binding.
+
+Example:
+ clock at 0xff000000 {
+ compatible = "adi,axi-clkgen";
+ #clock-cells = <0>;
+ reg = <0xff000000 0x1000>;
+ clocks = <&osc 1>;
+ };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index a47e6ee..36df007 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -63,6 +63,14 @@ config CLK_TWL6040
McPDM. McPDM module is using the external bit clock on the McPDM bus
as functional clock.
+config COMMON_CLK_AXI_CLKGEN
+ tristate "AXI clkgen driver"
+ depends on ARCH_ZYNQ || MICROBLAZE
+ help
+ ---help---
+ Support for the Analog Device axi-clkgen pcore clock generator for Xilinx
+ FPGAs. It is commonly used in Analog Devices reference designs.
+
endmenu
source "drivers/clk/mvebu/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index ee90e87..a3617b2 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_ARCH_SUNXI) += clk-sunxi.o
obj-$(CONFIG_ARCH_ZYNQ) += clk-zynq.o
# Chip specific
+obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN) += clk-axi-clkgen.o
obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
obj-$(CONFIG_CLK_TWL6040) += clk-twl6040.o
diff --git a/drivers/clk/clk-axi-clkgen.c b/drivers/clk/clk-axi-clkgen.c
new file mode 100644
index 0000000..a956ed8
--- /dev/null
+++ b/drivers/clk/clk-axi-clkgen.c
@@ -0,0 +1,331 @@
+/*
+ * AXI clkgen driver
+ *
+ * Copyright 2012-2013 Analog Device Inc.
+ * Author: Lars-Peter Clausen <lars@metafoo.de>
+ *
+ * Licensed under the GPL-2.
+ *
+ */
+
+#include <linux/platform_device.h>
+#include <linux/clk-provider.h>
+#include <linux/clk.h>
+#include <linux/slab.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/module.h>
+#include <linux/err.h>
+
+#define AXI_CLKGEN_REG_UPDATE_ENABLE 0x04
+#define AXI_CLKGEN_REG_CLK_OUT1 0x08
+#define AXI_CLKGEN_REG_CLK_OUT2 0x0c
+#define AXI_CLKGEN_REG_CLK_DIV 0x10
+#define AXI_CLKGEN_REG_CLK_FB1 0x14
+#define AXI_CLKGEN_REG_CLK_FB2 0x18
+#define AXI_CLKGEN_REG_LOCK1 0x1c
+#define AXI_CLKGEN_REG_LOCK2 0x20
+#define AXI_CLKGEN_REG_LOCK3 0x24
+#define AXI_CLKGEN_REG_FILTER1 0x28
+#define AXI_CLKGEN_REG_FILTER2 0x2c
+
+struct axi_clkgen {
+ void __iomem *base;
+ struct clk_hw clk_hw;
+};
+
+static uint32_t axi_clkgen_lookup_filter(unsigned int m)
+{
+ switch (m) {
+ case 0:
+ return 0x01001990;
+ case 1:
+ return 0x01001190;
+ case 2:
+ return 0x01009890;
+ case 3:
+ return 0x01001890;
+ case 4:
+ return 0x01008890;
+ case 5 ... 8:
+ return 0x01009090;
+ case 9 ... 11:
+ return 0x01000890;
+ case 12:
+ return 0x08009090;
+ case 13 ... 22:
+ return 0x01001090;
+ case 23 ... 36:
+ return 0x01008090;
+ case 37 ... 46:
+ return 0x08001090;
+ default:
+ return 0x08008090;
+ }
+}
+
+static const uint32_t axi_clkgen_lock_table[] = {
+ 0x060603e8, 0x060603e8, 0x080803e8, 0x0b0b03e8,
+ 0x0e0e03e8, 0x111103e8, 0x131303e8, 0x161603e8,
+ 0x191903e8, 0x1c1c03e8, 0x1f1f0384, 0x1f1f0339,
+ 0x1f1f02ee, 0x1f1f02bc, 0x1f1f028a, 0x1f1f0271,
+ 0x1f1f023f, 0x1f1f0226, 0x1f1f020d, 0x1f1f01f4,
+ 0x1f1f01db, 0x1f1f01c2, 0x1f1f01a9, 0x1f1f0190,
+ 0x1f1f0190, 0x1f1f0177, 0x1f1f015e, 0x1f1f015e,
+ 0x1f1f0145, 0x1f1f0145, 0x1f1f012c, 0x1f1f012c,
+ 0x1f1f012c, 0x1f1f0113, 0x1f1f0113, 0x1f1f0113,
+};
+
+static uint32_t axi_clkgen_lookup_lock(unsigned int m)
+{
+ if (m < ARRAY_SIZE(axi_clkgen_lock_table))
+ return axi_clkgen_lock_table[m];
+ return 0x1f1f00fa;
+}
+
+static const unsigned int fpfd_min = 10000;
+static const unsigned int fpfd_max = 300000;
+static const unsigned int fvco_min = 600000;
+static const unsigned int fvco_max = 1200000;
+
+static void axi_clkgen_calc_params(unsigned long fin, unsigned long fout,
+ unsigned int *best_d, unsigned int *best_m, unsigned int *best_dout)
+{
+ unsigned long d, d_min, d_max, _d_min, _d_max;
+ unsigned long m, m_min, m_max;
+ unsigned long f, dout, best_f, fvco;
+
+ fin /= 1000;
+ fout /= 1000;
+
+ best_f = UINT_MAX;
+ *best_d = 0;
+ *best_m = 0;
+ *best_dout = 0;
+
+ d_min = max_t(unsigned long, DIV_ROUND_UP(fin, fpfd_max), 1);
+ d_max = min_t(unsigned long, fin / fpfd_min, 80);
+
+ m_min = max_t(unsigned long, DIV_ROUND_UP(fvco_min, fin) * d_min, 1);
+ m_max = min_t(unsigned long, fvco_max * d_max / fin, 64);
+
+ for (m = m_min; m <= m_max; m++) {
+ _d_min = max(d_min, DIV_ROUND_UP(fin * m, fvco_max));
+ _d_max = min(d_max, fin * m / fvco_min);
+
+ for (d = _d_min; d <= _d_max; d++) {
+ fvco = fin * m / d;
+
+ dout = DIV_ROUND_CLOSEST(fvco, fout);
+ dout = clamp_t(unsigned long, dout, 1, 128);
+ f = fvco / dout;
+ if (abs(f - fout) < abs(best_f - fout)) {
+ best_f = f;
+ *best_d = d;
+ *best_m = m;
+ *best_dout = dout;
+ if (best_f == fout)
+ return;
+ }
+ }
+ }
+}
+
+static void axi_clkgen_calc_clk_params(unsigned int divider, unsigned int *low,
+ unsigned int *high, unsigned int *edge, unsigned int *nocount)
+{
+ if (divider == 1)
+ *nocount = 1;
+ else
+ *nocount = 0;
+
+ *high = divider / 2;
+ *edge = divider % 2;
+ *low = divider - *high;
+}
+
+static void axi_clkgen_write(struct axi_clkgen *axi_clkgen,
+ unsigned int reg, unsigned int val)
+{
+ writel(val, axi_clkgen->base + reg);
+}
+
+static void axi_clkgen_read(struct axi_clkgen *axi_clkgen,
+ unsigned int reg, unsigned int *val)
+{
+ *val = readl(axi_clkgen->base + reg);
+}
+
+static struct axi_clkgen *clk_hw_to_axi_clkgen(struct clk_hw *clk_hw)
+{
+ return container_of(clk_hw, struct axi_clkgen, clk_hw);
+}
+
+static int axi_clkgen_set_rate(struct clk_hw *clk_hw,
+ unsigned long rate, unsigned long parent_rate)
+{
+ struct axi_clkgen *axi_clkgen = clk_hw_to_axi_clkgen(clk_hw);
+ unsigned int d, m, dout;
+ unsigned int nocount;
+ unsigned int high;
+ unsigned int edge;
+ unsigned int low;
+ uint32_t filter;
+ uint32_t lock;
+
+ if (parent_rate == 0 || rate == 0)
+ return -EINVAL;
+
+ axi_clkgen_calc_params(parent_rate, rate, &d, &m, &dout);
+
+ if (d == 0 || dout == 0 || m == 0)
+ return -EINVAL;
+
+ filter = axi_clkgen_lookup_filter(m - 1);
+ lock = axi_clkgen_lookup_lock(m - 1);
+
+ axi_clkgen_write(axi_clkgen, AXI_CLKGEN_REG_UPDATE_ENABLE, 0);
+
+ axi_clkgen_calc_clk_params(dout, &low, &high, &edge, &nocount);
+ axi_clkgen_write(axi_clkgen, AXI_CLKGEN_REG_CLK_OUT1,
+ (high << 6) | low);
+ axi_clkgen_write(axi_clkgen, AXI_CLKGEN_REG_CLK_OUT2,
+ (edge << 7) | (nocount << 6));
+
+ axi_clkgen_calc_clk_params(d, &low, &high, &edge, &nocount);
+ axi_clkgen_write(axi_clkgen, AXI_CLKGEN_REG_CLK_DIV,
+ (edge << 13) | (nocount << 12) | (high << 6) | low);
+
+ axi_clkgen_calc_clk_params(m, &low, &high, &edge, &nocount);
+ axi_clkgen_write(axi_clkgen, AXI_CLKGEN_REG_CLK_FB1,
+ (high << 6) | low);
+ axi_clkgen_write(axi_clkgen, AXI_CLKGEN_REG_CLK_FB2,
+ (edge << 7) | (nocount << 6));
+
+ axi_clkgen_write(axi_clkgen, AXI_CLKGEN_REG_LOCK1, lock & 0x3ff);
+ axi_clkgen_write(axi_clkgen, AXI_CLKGEN_REG_LOCK2,
+ (((lock >> 16) & 0x1f) << 10) | 0x1);
+ axi_clkgen_write(axi_clkgen, AXI_CLKGEN_REG_LOCK3,
+ (((lock >> 24) & 0x1f) << 10) | 0x3e9);
+ axi_clkgen_write(axi_clkgen, AXI_CLKGEN_REG_FILTER1, filter >> 16);
+ axi_clkgen_write(axi_clkgen, AXI_CLKGEN_REG_FILTER2, filter);
+
+ axi_clkgen_write(axi_clkgen, AXI_CLKGEN_REG_UPDATE_ENABLE, 1);
+
+ return 0;
+}
+
+static long axi_clkgen_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+{
+ unsigned int d, m, dout;
+
+ axi_clkgen_calc_params(*parent_rate, rate, &d, &m, &dout);
+
+ if (d == 0 || dout == 0 || m == 0)
+ return -EINVAL;
+
+ return *parent_rate / d * m / dout;
+}
+
+static unsigned long axi_clkgen_recalc_rate(struct clk_hw *clk_hw,
+ unsigned long parent_rate)
+{
+ struct axi_clkgen *axi_clkgen = clk_hw_to_axi_clkgen(clk_hw);
+ unsigned int d, m, dout;
+ unsigned int reg;
+ unsigned long long tmp;
+
+ axi_clkgen_read(axi_clkgen, AXI_CLKGEN_REG_CLK_OUT1, ®);
+ dout = (reg & 0x3f) + ((reg >> 6) & 0x3f);
+ axi_clkgen_read(axi_clkgen, AXI_CLKGEN_REG_CLK_DIV, ®);
+ d = (reg & 0x3f) + ((reg >> 6) & 0x3f);
+ axi_clkgen_read(axi_clkgen, AXI_CLKGEN_REG_CLK_FB1, ®);
+ m = (reg & 0x3f) + ((reg >> 6) & 0x3f);
+
+ if (d == 0 || dout == 0)
+ return 0;
+
+ tmp = (unsigned long long)(parent_rate / d) * m;
+ do_div(tmp, dout);
+
+ if (tmp > ULONG_MAX)
+ return ULONG_MAX;
+
+ return tmp;
+}
+
+static const struct clk_ops axi_clkgen_ops = {
+ .recalc_rate = axi_clkgen_recalc_rate,
+ .round_rate = axi_clkgen_round_rate,
+ .set_rate = axi_clkgen_set_rate,
+};
+
+static int axi_clkgen_probe(struct platform_device *pdev)
+{
+ struct axi_clkgen *axi_clkgen;
+ struct clk_init_data init;
+ const char *parent_name;
+ const char *clk_name;
+ struct resource *mem;
+ struct clk *clk;
+
+ axi_clkgen = devm_kzalloc(&pdev->dev, sizeof(*axi_clkgen),
+ GFP_KERNEL);
+ if (!axi_clkgen)
+ return -ENOMEM;
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ axi_clkgen->base = devm_request_and_ioremap(&pdev->dev, mem);
+ if (!axi_clkgen->base)
+ return -ENXIO;
+
+ parent_name = of_clk_get_parent_name(pdev->dev.of_node, 0);
+ clk_name = pdev->dev.of_node->name;
+
+ of_property_read_string(pdev->dev.of_node, "clock-output-names",
+ &clk_name);
+
+ init.name = clk_name;
+ init.ops = &axi_clkgen_ops;
+ init.flags = 0;
+ init.parent_names = &parent_name;
+ init.num_parents = 1;
+
+ axi_clkgen->clk_hw.init = &init;
+ clk = devm_clk_register(&pdev->dev, &axi_clkgen->clk_hw);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ of_clk_add_provider(pdev->dev.of_node, of_clk_src_simple_get, clk);
+
+ return 0;
+}
+
+static int axi_clkgen_remove(struct platform_device *pdev)
+{
+ of_clk_del_provider(pdev->dev.of_node);
+
+ return 0;
+}
+
+static const struct of_device_id axi_clkgen_ids[] = {
+ { .compatible = "adi,axi-clkgen-1.00.a" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, axi_clkgen_ids);
+
+static struct platform_driver axi_clkgen_driver = {
+ .driver = {
+ .name = "adi-axi-clkgen",
+ .owner = THIS_MODULE,
+ .of_match_table = axi_clkgen_ids,
+ },
+ .probe = axi_clkgen_probe,
+ .remove = axi_clkgen_remove,
+};
+module_platform_driver(axi_clkgen_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Lars-Peter Clausen <lars@metafoo.de>");
+MODULE_DESCRIPTION("Driver for the Analog Devices AXI clkgen pcore clock generator");
--
1.8.0
^ permalink raw reply related
* [GIT PULL] clockevents: decouple broadcast mechanism from drivers
From: Will Deacon @ 2013-01-23 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130118171545.GB15707@e106331-lin.cambridge.arm.com>
On Fri, Jan 18, 2013 at 05:15:46PM +0000, Mark Rutland wrote:
> Hello,
>
> As has been pointed out elsewhere, in my haste to fix this up I made a
> typo in the first patch, preventing it from building.
>
> Apologies for the confusion. I've created a new branch with a corrected
> and tested version. Please see the pull request below.
>
> Thanks,
> Mark.
>
> The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20:
>
> Linux 3.8-rc3 (2013-01-09 18:59:55 -0800)
>
> are available in the git repository at:
>
> git://linux-arm.org/linux-mr.git for-tglx/timer-broadcast-v2
Can you pull this please Thomas? I need a stable branch so I can pull in the
ARM-specific changes, which are in turn required for the KVM patch series.
Cheers,
Will
^ permalink raw reply
* [PATCH v1 0/6] USB: Add support for multiple PHYs of same type
From: Mohammed, Afzal @ 2013-01-23 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B9531499-0746-44DA-BDBB-999D4CA31E63@dominion.thruhere.net>
Hi Koen,
On Tue, Jan 22, 2013 at 22:32:56, Koen Kooi wrote:
> Actually it uses nop-phy as a phy, which is missing from arch/arm/boot/dts/am33xx.dtsi, so mainline is already broken. But adding the nop-phy to the DT is easy enough to patch in locally.
USB first instance of am335x works in mainline as of now.
Regards
Afzal
^ permalink raw reply
* [PATCH] ARM: dts: specify all the per-cpu interrupts of arch timer for exynos5440
From: Rob Herring @ 2013-01-23 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123103614.GD32237@e106331-lin.cambridge.arm.com>
On 01/23/2013 04:36 AM, Mark Rutland wrote:
> On Tue, Jan 22, 2013 at 10:05:18PM +0000, Kukjin Kim wrote:
>> Mark Rutland wrote:
>>>
>> + devicetree-discuss, Grant Likely, Rob Herring and Tony Lindgren
>>
>>> On Tue, Jan 22, 2013 at 01:41:27AM +0000, Kukjin Kim wrote:
>>>> From: Thomas Abraham <thomas.ab@samsung.com>
>>>>
>>>> Need to be changed requirements in the 'cpus' node for exynos5440
>>>> to specify all the per-cpu interrupts of arch timer.
>>>
>>> The node(s) for the arch timer should not be in the cpus/cpu at N nodes.
>>> Instead, there should be one node (in the root of the tree).
>>>
>> Well, I don't think so. As per my understanding, the local timers are
>> attached to every ARM cores (cpus) and it generates certain interrupt to the
>> GIC. So the correct representation for this in device tree is to include the
>> interrupts in the cpu nodes in dts file. Your comments refer to a
>> limitation in the Linux kernel implementation of the arch_timer and it
>> should not result in representing the hardware details incorrectly in the
>> dts file.
>
> I disagree. The "correct representation" is whatever the devicetree binding
> documentation describes. It does not describe placing timer nodes in the cpu
> nodes.
I don't think we should add other nodes to /cpus besides cpu nodes.
The presence of architected timers is defined by the cpu being a
Cortex-A15. So you don't really need a timer node at all. All that is
really needed is the interrupt. You could add interrupts property
directly to each cpu node. The location of PMU nodes has come up
recently as well, and the PMU interrupt could be added as well.
Whether we should change the binding at this point is questionable.
Normally, we wouldn't want to do that, but as this is all pretty new it
may be okay to make an exception here. However, I don't see anything
that is fundamentally broken with the current binding. Multi-cluster
could introduce some issues.
>>
>>> If this works currently it's only because the driver picks up one of the
>> nodes,
>>> and luckily it's the same as the others. This is not guaranteed to work in
>>> future, and will likely break.
>>>
>> It is up to the Linux kernel implementation of arch_timer to handle the
>> hardware details in dts file accordingly.
>
> The binding specification does not specify that there should be multiple timer
> nodes, nor does it specify that they should be under cpu nodes. The timers,
> being a banked resource, can be described with one node.
>
> It is not up to the Linux kernel to handle undocumented variations of bindings.
Except things done before documentation was enforced.
Rob
^ permalink raw reply
* [PATCH] arm: plat-orion: fix printing of "MPP config unavailable on this hardware"
From: Gerlando Falauto @ 2013-01-23 13:50 UTC (permalink / raw)
To: linux-arm-kernel
Commit 3cff484d4b264ff467a3b45c544cbbbab69f0bf8
ARM: dove: Consolidate mpp code with platform mpp.
refactored printing of the kernel warning
"orion_mpp_conf: requested MPP%u config unavailable on this hardware\n"
which is not to be printed in case of variant_mask = 0 (unknown variant).
This check should be performed using a logical AND (&&) as opposed
to a bitwise AND (&).
Otherwise, test would fail (and message would be printed) if variant_mask != 1
Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Olof Johansson <olof@lixom.net>
Cc: Nicolas Pitre <nico@linaro.org>
Cc: Holger Brunck <holger.brunck@keymile.com>
---
arch/arm/plat-orion/mpp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/plat-orion/mpp.c b/arch/arm/plat-orion/mpp.c
index 3b1e17b..78ea76c 100644
--- a/arch/arm/plat-orion/mpp.c
+++ b/arch/arm/plat-orion/mpp.c
@@ -48,7 +48,7 @@ void __init orion_mpp_conf(unsigned int *mpp_list, unsigned int variant_mask,
"number (%u)\n", num);
continue;
}
- if (variant_mask & !(*mpp_list & variant_mask)) {
+ if (variant_mask && !(*mpp_list & variant_mask)) {
printk(KERN_WARNING
"orion_mpp_conf: requested MPP%u config "
"unavailable on this hardware\n", num);
--
1.7.10.1
^ permalink raw reply related
* [PATCH 1/2] misc/at24: Add at24c512b eeprom support
From: Wolfram Sang @ 2013-01-23 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+8Hj80=Mk1gMSC9gcRT_XPFrEdRxifaB9FNMtkn3BkUkv9bGA@mail.gmail.com>
Hi,
> There are some difference between 24c512 and 24c512b about the system
> reset procedure, according to the two devices' spec:
> 24c512b:(a) Create a start bit condition, (b)clock 9 cycles, (c)
> create another start bit followed by stop bit condition.
> 24c512:(a) Clock up to 9 cycles, (b) look for SDA high in each cycle
> while SCL is high and then, (c) create a start condition as SDA is
> high.
> Could this be a reason to add an entry for 24c512b?
Since the entries in at24_ids[] are the same, no. If they would differ,
that is a reason.
> Now, I think the correct vendor name should be "at" or "atmel".
"atmel" would be better, but the MX28EVK doesn't even have an I2C eeprom
by default IIRC? But that is unrelated to your patch.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130123/dab379ec/attachment.sig>
^ permalink raw reply
* [PATCH 1/2 net-next] net: fec: add napi support to improve proformance
From: Eric Dumazet @ 2013-01-23 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHrpEqTqSfBCpoMZ9S81VoXWgVK1iOR+e2OasARgbTD8m_RRvw@mail.gmail.com>
On Wed, 2013-01-23 at 15:37 +0800, Frank Li wrote:
> 2013/1/23 Eric Dumazet <eric.dumazet@gmail.com>:
> > On Wed, 2013-01-23 at 12:12 +0800, Frank Li wrote:
> >> Add napi support
> >>
> >> Before this patch
> >>
> >> iperf -s -i 1
> >> ------------------------------------------------------------
> >> Server listening on TCP port 5001
> >> TCP window size: 85.3 KByte (default)
> >> ------------------------------------------------------------
> >> [ 4] local 10.192.242.153 port 5001 connected with 10.192.242.138 port 50004
> >> [ ID] Interval Transfer Bandwidth
> >> [ 4] 0.0- 1.0 sec 41.2 MBytes 345 Mbits/sec
> >> [ 4] 1.0- 2.0 sec 43.7 MBytes 367 Mbits/sec
> >> [ 4] 2.0- 3.0 sec 42.8 MBytes 359 Mbits/sec
> >> [ 4] 3.0- 4.0 sec 43.7 MBytes 367 Mbits/sec
> >> [ 4] 4.0- 5.0 sec 42.7 MBytes 359 Mbits/sec
> >> [ 4] 5.0- 6.0 sec 43.8 MBytes 367 Mbits/sec
> >> [ 4] 6.0- 7.0 sec 43.0 MBytes 361 Mbits/sec
> >>
> >> After this patch
> >> [ 4] 2.0- 3.0 sec 51.6 MBytes 433 Mbits/sec
> >> [ 4] 3.0- 4.0 sec 51.8 MBytes 435 Mbits/sec
> >> [ 4] 4.0- 5.0 sec 52.2 MBytes 438 Mbits/sec
> >> [ 4] 5.0- 6.0 sec 52.1 MBytes 437 Mbits/sec
> >> [ 4] 6.0- 7.0 sec 52.1 MBytes 437 Mbits/sec
> >> [ 4] 7.0- 8.0 sec 52.3 MBytes 439 Mbits/sec
> >
> > Strange, as you still call netif_rx()
> >
> > NAPI should call netif_receive_skb() instead
> >
>
> Thank you point out.
> After re-test, I found performance is almost no change if use netif_receive_skb.
> I am not sure if it is my NAPI implement problem.
>
> napi_gro_received is better than netif_receive_skb, but worse than netif_rx.
>
> From performance point view,
>
> netif_rx --- fastest
> napi_gro_received --- middle, near to netif_rx
> netif_receive_skb --- slowest, almost the same as original no-napi version.
>
> Do you have any idea about this phenomena?
No idea, you'll have to find out using perf tool if available.
Is your machine SMP, and the application running on another cpu than the
softirq handler for your device ?
A NAPI driver must call netif_receive_skb(), especially if
the RX path does a full copy of the frame : Its hot in cpu cache and
should be processed at once.
Escaping to netif_rx() is only adding an extra softirq and risk of data
being evicted from cpu caches.
Here your performance increase only comes from hw_lock being not anymore
locked in RX path.
^ permalink raw reply
* [PATCH 1/2] misc/at24: Add at24c512b eeprom support
From: Liu Ying @ 2013-01-23 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123125001.GG16264@pengutronix.de>
2013/1/23 Wolfram Sang <w.sang@pengutronix.de>:
> On Wed, Jan 23, 2013 at 01:24:52PM +0100, Linus Walleij wrote:
>> On Wed, Jan 23, 2013 at 7:32 AM, Liu Ying <Ying.Liu@freescale.com> wrote:
>>
>> > This patch adds at24c512b eeprom support.
>> > The datasheet of at24c512b can be found at:
>> > http://www.alldatasheet.com/datasheet-pdf/pdf/
>> > 256958/ATMEL/AT24C512B-TH-B.html
>> >
>> > Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
>>
>> Arnd Bergmann is the misc maintainer, route this by him.
>
> I usually take at24 patches via my I2C tree.
>
> But not this one, though. The 512b can equally use the 512 entry. The
> devicetree should contain both entries, the 512 one as a fallback. (And
> the vendor is not "at24"!)
There are some difference between 24c512 and 24c512b about the system
reset procedure, according to the two devices' spec:
24c512b:(a) Create a start bit condition, (b)clock 9 cycles, (c)
create another start bit followed by stop bit condition.
24c512:(a) Clock up to 9 cycles, (b) look for SDA high in each cycle
while SCL is high and then, (c) create a start condition as SDA is
high.
Could this be a reason to add an entry for 24c512b?
About the vendor name, I took the at24c32 node in
arch/arm/boot/dts/imx28-evk.dts as a reference:
at24 at 51 {
compatible = "at24,24c32";
pagesize = <32>;
reg = <0x51>;
};
Now, I think the correct vendor name should be "at" or "atmel".
Thanks.
>
> Regards,
>
> Wolfram
>
> --
> Pengutronix e.K. | Wolfram Sang |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
--
Best Regards,
Liu Ying
^ permalink raw reply
* [PATCH 3.8-rc] arm: mvebu: add LEDs support to defconfig file
From: Jason Cooper @ 2013-01-23 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357576034-24193-1-git-send-email-thomas.petazzoni@free-electrons.com>
On Mon, Jan 07, 2013 at 05:27:14PM +0100, Thomas Petazzoni wrote:
> The OpenBlocks AX3-4 platform has several LEDs, so it sounds wise to
> enable LED support in mvebu_defconfig. We anticipate that more
> platforms using Marvell EBU SoCs will have LEDs in the future.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> This is 3.8-rc material.
> ---
> arch/arm/configs/mvebu_defconfig | 5 +++++
> 1 file changed, 5 insertions(+)
Applied to mvebu/boards
thx,
Jason.
^ permalink raw reply
* [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)
From: Russell King - ARM Linux @ 2013-01-23 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAF6AEGsDq8AW1-8uYmgc7DNvVU-eF=emWw24nTDHWBMwM_wUDA@mail.gmail.com>
On Wed, Jan 23, 2013 at 07:24:33AM -0600, Rob Clark wrote:
> On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine <moinejf@free.fr> wrote:
> > Hi Rob,
> >
> > As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
> > I had a look at your IT LCD driver. Comments below.
>
> Just fyi, you can re-use the nxp-tda998x part independently of tilcdc
> (just in case that wasn't clear).
Great, this chip is also used on the cubox too.
The one thing I wonder is how you deal with the VSYNC/HSYNC polarities
that are provided to the TDA9988x chip. On the cubox, I have to adjust
the mode parameters such that the polarities are fixed up thusly:
adjusted->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NHSYNC |
DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_PCSYNC | DRM_MODE_FLAG_NCSYNC);
/* The TDA19988 always requires negative VSYNC? */
adjusted->flags |= DRM_MODE_FLAG_NVSYNC;
/* The TDA19988 requires positive HSYNC on 1080p or 720p */
if ((adjusted->hdisplay == 1920 && adjusted->vdisplay == 1080) ||
(adjusted->hdisplay == 1280 && adjusted->vdisplay == 720))
adjusted->flags |= DRM_MODE_FLAG_PHSYNC;
else
adjusted->flags |= DRM_MODE_FLAG_NHSYNC;
return true;
for these resolutions to be displayed correctly.
Also, when the only output is the HDMI device, reporting the display
"disconnected" and without any modes seems to cause problems - I have to
report "unknown" status when there's nothing connected, and also provide
a default (720p) mode when no EDID is received.
^ permalink raw reply
* [PATCH 1/5] ARM: Kirkwood: Convert NS2 to gpio-poweroff.
From: Jason Cooper @ 2013-01-23 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1356704050-5047-1-git-send-email-andrew@lunn.ch>
On Fri, Dec 28, 2012 at 03:14:10PM +0100, Andrew Lunn wrote:
> Remove C code and add a Device Tree node in its place.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
>
> This is untested. I've been known to get the active hi/low the wrong
> way around so that the board powers off as the driver loads at boot
> time. So it would be very good to have a tested-by: sign off.
>
>
> arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 6 ++++++
> arch/arm/mach-kirkwood/board-ns2.c | 14 --------------
> 2 files changed, 6 insertions(+), 14 deletions(-)
Applied to mvebu/dt with a remove/remove resolution against Simon
Guinot's patch in mvebu/fixes:
4ea931e ARM: Kirkwood: fix ns2 gpios by converting to pinctrl
thx,
Jason.
^ permalink raw reply
* [PATCH 2/4] drm/i2c: nxp-tda998x (v2)
From: Rob Clark @ 2013-01-23 13:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123104230.38cfc515@armhf>
On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine <moinejf@free.fr> wrote:
> On Tue, 22 Jan 2013 16:36:23 -0600
> Rob Clark <robdclark@gmail.com> wrote:
>
>> Driver for the NXP TDA998X i2c hdmi encoder slave.
>>
>> v1: original
>> v2: fix npix/nline programming
>>
>> Signed-off-by: Rob Clark <robdclark@gmail.com>
>> ---
>> drivers/gpu/drm/i2c/Makefile | 3 +
>> drivers/gpu/drm/i2c/tda998x_drv.c | 908 ++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 911 insertions(+)
>> create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c
> [snip]
>> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
>> new file mode 100644
>> index 0000000..02054e8
>> --- /dev/null
>> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
>> @@ -0,0 +1,908 @@
> [snip]
>> +static void __exit
>> +tda998x_exit(void)
>> +{
>> + DBG("");
>> + drm_i2c_encoder_unregister(&tda998x_driver);
>> +}
>> +
>> +MODULE_DESCRIPTION("NXP Semiconductors TDA998X TMDS transmitter driver");
>> +
>> +MODULE_AUTHOR("Rob Clark <robdclark@gmail.com");
>> +MODULE_DESCRIPTION("NXP Semiconductors TDA998X HDMI Encoder");
>> +MODULE_LICENSE("GPL");
>> +
>> +module_init(tda998x_init);
>> +module_exit(tda998x_exit);
>
> There are 2 MODULE_DESCRIPTION().
oh, whoops.. I'll fix that
BR,
-R
> --
> Ken ar c'henta? | ** Breizh ha Linux atav! **
> Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)
From: Rob Clark @ 2013-01-23 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123104216.1de2eee1@armhf>
On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine <moinejf@free.fr> wrote:
> Hi Rob,
>
> As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
> I had a look at your IT LCD driver. Comments below.
Just fyi, you can re-use the nxp-tda998x part independently of tilcdc
(just in case that wasn't clear).
It may be that we need to add some configuration info struct, if for
example there are some differences in video signal mux on the dove
board, but that shouldn't be a big deal. I figure we can see what is
needed as others start to use it and add as needed.
> On Tue, 22 Jan 2013 16:36:22 -0600
> Rob Clark <robdclark@gmail.com> wrote:
>
>> A simple DRM/KMS driver for the TI LCD Controller found in various
>> smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the
>> CMA helpers. Currently only the TFP410 DVI encoder is supported
>> (tested with beaglebone + DVI cape). There are also various LCD
>> displays, for which support can be added (as I get hw to test on),
>> and an external i2c HDMI encoder found on some boards.
>>
>> The display controller supports a single CRTC. And the encoder+
>> connector are split out into sub-devices. Depending on which LCD
>> or external encoder is actually present, the appropriate output
>> module(s) will be loaded.
>>
>> v1: original
>> v2: fix fb refcnting and few other cleanups
>> v3: get +/- vsync/hsync from timings rather than panel-info, add
>> option DT max-bandwidth field so driver doesn't attempt to
>> pick a display mode with too high memory bandwidth, and other
>> small cleanups
>>
>> Signed-off-by: Rob Clark <robdclark@gmail.com>
>> ---
>> drivers/gpu/drm/Kconfig | 2 +
>> drivers/gpu/drm/Makefile | 1 +
>> drivers/gpu/drm/tilcdc/Kconfig | 10 +
>> drivers/gpu/drm/tilcdc/Makefile | 8 +
>> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 597 ++++++++++++++++++++++++++++++++
>> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 605 +++++++++++++++++++++++++++++++++
>> drivers/gpu/drm/tilcdc/tilcdc_drv.h | 159 +++++++++
>> drivers/gpu/drm/tilcdc/tilcdc_regs.h | 154 +++++++++
>> drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 423 +++++++++++++++++++++++
>> drivers/gpu/drm/tilcdc/tilcdc_tfp410.h | 26 ++
>> 10 files changed, 1985 insertions(+)
>> create mode 100644 drivers/gpu/drm/tilcdc/Kconfig
>> create mode 100644 drivers/gpu/drm/tilcdc/Makefile
>> create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_crtc.c
>> create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.c
>> create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.h
>> create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_regs.h
>> create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
>> create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h
> [snip]
>> diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
>> new file mode 100644
>> index 0000000..ee9b592
>> --- /dev/null
>> +++ b/drivers/gpu/drm/tilcdc/Kconfig
>> @@ -0,0 +1,10 @@
>> +config DRM_TILCDC
>> + tristate "DRM Support for TI LCDC Display Controller"
>> + depends on DRM && OF
>> + select DRM_KMS_HELPER
>> + select DRM_KMS_CMA_HELPER
>> + select DRM_GEM_CMA_HELPER
>> + help
>> + Choose this option if you have an TI SoC with LCDC display
>> + controller, for example AM33xx in beagle-bone, DA8xx, or
>> + OMAP-L1xx. This driver replaces the FB_DA8XX fbdev driver.
>> diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
>> new file mode 100644
>> index 0000000..1359cc2
>> --- /dev/null
>> +++ b/drivers/gpu/drm/tilcdc/Makefile
>> @@ -0,0 +1,8 @@
>> +ccflags-y := -Iinclude/drm -Werror
>> +
>> +tilcdc-y := \
>> + tilcdc_crtc.o \
>> + tilcdc_tfp410.o \
>> + tilcdc_drv.o
>
> As I understand, this means that the 3 objects will go into the
> resident kernel.
>
> I though that the device tree was created for Linux distributors who
> might generate generic ARM kernels, the choice of the drivers being
> done according the local device tree.
>
> From this point of vue, it would be nicer to have 2 separate modules:
> tilcdc and tfp410, tilcdc_crtc being included in one of these ones
> (I did not look deep enough at the code to know which).
drv and crtc are the "core" driver... arguably the tfp410 part could
be optional. I'd prefer *not* as a separate module, as this implies
some independence of module lifetime, which is not true. I generally
prefer to start simple and add complexity later if someone really
thinks they need it, which is why I avoided adding a bunch of kconfig
options to start with.
> [snip]
>> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
>> new file mode 100644
>> index 0000000..cf1fddc
>> --- /dev/null
>> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
>> @@ -0,0 +1,605 @@
> [snip]
>> +static struct drm_driver tilcdc_driver = {
>> + .driver_features = DRIVER_HAVE_IRQ | DRIVER_GEM | DRIVER_MODESET,
>> + .load = tilcdc_load,
>> + .unload = tilcdc_unload,
>> + .preclose = tilcdc_preclose,
>> + .lastclose = tilcdc_lastclose,
>> + .irq_handler = tilcdc_irq,
>> + .irq_preinstall = tilcdc_irq_preinstall,
>> + .irq_postinstall = tilcdc_irq_postinstall,
>> + .irq_uninstall = tilcdc_irq_uninstall,
>> + .get_vblank_counter = drm_vblank_count,
>> + .enable_vblank = tilcdc_enable_vblank,
>> + .disable_vblank = tilcdc_disable_vblank,
>> + .gem_free_object = drm_gem_cma_free_object,
>> + .gem_vm_ops = &drm_gem_cma_vm_ops,
>> + .dumb_create = drm_gem_cma_dumb_create,
>> + .dumb_map_offset = drm_gem_cma_dumb_map_offset,
>> + .dumb_destroy = drm_gem_cma_dumb_destroy,
>> +#ifdef CONFIG_DEBUG_FS
>> + .debugfs_init = tilcdc_debugfs_init,
>> + .debugfs_cleanup = tilcdc_debugfs_cleanup,
>> +#endif
>> + .fops = &fops,
>> + .name = "tilcdc",
>> + .desc = "TI LCD Controller DRM",
>> + .date = "20121205",
>> + .major = 1,
>> + .minor = 0,
>> +};
>> +
>> +/*
>> + * Power management:
>> + */
>> +
>> +#if CONFIG_PM_SLEEP
>
> Should be:
>
> #ifdef CONFIG_PM_SLEEP
>
> [snip]
>> +static struct of_device_id tilcdc_of_match[] = {
>> + { .compatible = "ti,am33xx-tilcdc", },
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(of, tilcdc_of_match);
>> +
>> +static struct platform_driver tilcdc_platform_driver = {
>> + .probe = tilcdc_pdev_probe,
>> + .remove = tilcdc_pdev_remove,
>> + .driver = {
>> + .owner = THIS_MODULE,
>> + .name = "tilcdc",
>> + .pm = &tilcdc_pm_ops,
>> + .of_match_table = tilcdc_of_match,
>> + },
>> +};
>> +
>> +static int __init tilcdc_drm_init(void)
>> +{
>> + DBG("init");
>> + tilcdc_tfp410_init();
>
> This function may be called twice if "tilcdc,tfp410" is in the DT.
hmm, I don't think it was but I'll have to double check that. At
least if it was it wasn't seeming to cause anything bad, because I did
have "tilcdc,tfp410" in DT..
BR,
-R
>> + return platform_driver_register(&tilcdc_platform_driver);
>> +}
>> +
>> +static void __exit tilcdc_drm_fini(void)
>> +{
>> + DBG("fini");
>> + tilcdc_tfp410_fini();
>> + platform_driver_unregister(&tilcdc_platform_driver);
>> +}
>> +
>> +module_init(tilcdc_drm_init);
>> +module_exit(tilcdc_drm_fini);
>> +
>> +MODULE_AUTHOR("Rob Clark <robdclark@gmail.com");
>> +MODULE_DESCRIPTION("TI LCD Controller DRM Driver");
>> +MODULE_LICENSE("GPL");
>
>
> --
> Ken ar c'henta? | ** Breizh ha Linux atav! **
> Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH 0/3] Convert more of NSA310 to DT.
From: Jason Cooper @ 2013-01-23 13:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1356703730-4926-1-git-send-email-andrew@lunn.ch>
On Fri, Dec 28, 2012 at 03:08:47PM +0100, Andrew Lunn wrote:
> This patchset converts more of the NSA310 into device tree.
>
> Currently untested.
>
> Andrew Lunn (3):
> ARM: Kirkwood: Convert NSA310 to DT based regulators.
> ARM: Kirkwood: Convert NSA310 to use gpio-poweroff driver
> ARM: Kirkwood: Convert NSA310 I2C to device tree
>
> arch/arm/boot/dts/kirkwood-nsa310.dts | 27 +++++++++++++++++++++
> arch/arm/mach-kirkwood/board-nsa310.c | 43 ---------------------------------
> 2 files changed, 27 insertions(+), 43 deletions(-)
Whole series applied to mvebu/dt
thx,
Jason.
^ permalink raw reply
* [PATCH 2/6] clocksource: time-armada-370-xp: add local timer support
From: Gregory CLEMENT @ 2013-01-23 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358790842-2986-3-git-send-email-gregory.clement@free-electrons.com>
On 01/21/2013 06:53 PM, Gregory CLEMENT wrote:
> On the SOCs Armada 370 and Armada XP, each CPU comes with two private
> timers. This patch use the timer 0 of each CPU as local timer for the
> clockevent if CONFIG_LOCAL_TIMER is selected. In the other case, use
> only the private Timer 0 of CPU 0.
John,
Do you have any comments on this patch before I send a second patch set
to take into account the remarks I got on the other patches ?
Thanks,
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> drivers/clocksource/time-armada-370-xp.c | 150 ++++++++++++++++++++++--------
> 1 file changed, 112 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/clocksource/time-armada-370-xp.c b/drivers/clocksource/time-armada-370-xp.c
> index a4605fd..757f034 100644
> --- a/drivers/clocksource/time-armada-370-xp.c
> +++ b/drivers/clocksource/time-armada-370-xp.c
> @@ -27,8 +27,10 @@
> #include <linux/of_address.h>
> #include <linux/irq.h>
> #include <linux/module.h>
> -#include <asm/sched_clock.h>
>
> +#include <asm/sched_clock.h>
> +#include <asm/localtimer.h>
> +#include <linux/percpu.h>
> /*
> * Timer block registers.
> */
> @@ -49,6 +51,7 @@
> #define TIMER1_RELOAD_OFF 0x0018
> #define TIMER1_VAL_OFF 0x001c
>
> +#define LCL_TIMER_EVENTS_STATUS 0x0028
> /* Global timers are connected to the coherency fabric clock, and the
> below divider reduces their incrementing frequency. */
> #define TIMER_DIVIDER_SHIFT 5
> @@ -57,14 +60,17 @@
> /*
> * SoC-specific data.
> */
> -static void __iomem *timer_base;
> -static int timer_irq;
> +static void __iomem *timer_base, *local_base;
> +static unsigned int timer_clk;
> +static bool timer25Mhz = true;
>
> /*
> * Number of timer ticks per jiffy.
> */
> static u32 ticks_per_jiffy;
>
> +struct clock_event_device __percpu **percpu_armada_370_xp_evt;
> +
> static u32 notrace armada_370_xp_read_sched_clock(void)
> {
> return ~readl(timer_base + TIMER0_VAL_OFF);
> @@ -78,24 +84,23 @@ armada_370_xp_clkevt_next_event(unsigned long delta,
> struct clock_event_device *dev)
> {
> u32 u;
> -
> /*
> * Clear clockevent timer interrupt.
> */
> - writel(TIMER1_CLR_MASK, timer_base + TIMER_EVENTS_STATUS);
> + writel(TIMER0_CLR_MASK, local_base + LCL_TIMER_EVENTS_STATUS);
>
> /*
> * Setup new clockevent timer value.
> */
> - writel(delta, timer_base + TIMER1_VAL_OFF);
> + writel(delta, local_base + TIMER0_VAL_OFF);
>
> /*
> * Enable the timer.
> */
> - u = readl(timer_base + TIMER_CTRL_OFF);
> - u = ((u & ~TIMER1_RELOAD_EN) | TIMER1_EN |
> - TIMER1_DIV(TIMER_DIVIDER_SHIFT));
> - writel(u, timer_base + TIMER_CTRL_OFF);
> + u = readl(local_base + TIMER_CTRL_OFF);
> + u = ((u & ~TIMER0_RELOAD_EN) | TIMER0_EN |
> + TIMER0_DIV(TIMER_DIVIDER_SHIFT));
> + writel(u, local_base + TIMER_CTRL_OFF);
>
> return 0;
> }
> @@ -107,37 +112,38 @@ armada_370_xp_clkevt_mode(enum clock_event_mode mode,
> u32 u;
>
> if (mode == CLOCK_EVT_MODE_PERIODIC) {
> +
> /*
> * Setup timer to fire at 1/HZ intervals.
> */
> - writel(ticks_per_jiffy - 1, timer_base + TIMER1_RELOAD_OFF);
> - writel(ticks_per_jiffy - 1, timer_base + TIMER1_VAL_OFF);
> + writel(ticks_per_jiffy - 1, local_base + TIMER0_RELOAD_OFF);
> + writel(ticks_per_jiffy - 1, local_base + TIMER0_VAL_OFF);
>
> /*
> * Enable timer.
> */
> - u = readl(timer_base + TIMER_CTRL_OFF);
>
> - writel((u | TIMER1_EN | TIMER1_RELOAD_EN |
> - TIMER1_DIV(TIMER_DIVIDER_SHIFT)),
> - timer_base + TIMER_CTRL_OFF);
> + u = readl(local_base + TIMER_CTRL_OFF);
> +
> + writel((u | TIMER0_EN | TIMER0_RELOAD_EN |
> + TIMER0_DIV(TIMER_DIVIDER_SHIFT)),
> + local_base + TIMER_CTRL_OFF);
> } else {
> /*
> * Disable timer.
> */
> - u = readl(timer_base + TIMER_CTRL_OFF);
> - writel(u & ~TIMER1_EN, timer_base + TIMER_CTRL_OFF);
> + u = readl(local_base + TIMER_CTRL_OFF);
> + writel(u & ~TIMER0_EN, local_base + TIMER_CTRL_OFF);
>
> /*
> * ACK pending timer interrupt.
> */
> - writel(TIMER1_CLR_MASK, timer_base + TIMER_EVENTS_STATUS);
> -
> + writel(TIMER0_CLR_MASK, local_base + LCL_TIMER_EVENTS_STATUS);
> }
> }
>
> static struct clock_event_device armada_370_xp_clkevt = {
> - .name = "armada_370_xp_tick",
> + .name = "armada_370_xp_per_cpu_tick",
> .features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
> .shift = 32,
> .rating = 300,
> @@ -150,32 +156,78 @@ static irqreturn_t armada_370_xp_timer_interrupt(int irq, void *dev_id)
> /*
> * ACK timer interrupt and call event handler.
> */
> + struct clock_event_device *evt = *(struct clock_event_device **)dev_id;
>
> - writel(TIMER1_CLR_MASK, timer_base + TIMER_EVENTS_STATUS);
> - armada_370_xp_clkevt.event_handler(&armada_370_xp_clkevt);
> + writel(TIMER0_CLR_MASK, local_base + LCL_TIMER_EVENTS_STATUS);
> + evt->event_handler(evt);
>
> return IRQ_HANDLED;
> }
>
> -static struct irqaction armada_370_xp_timer_irq = {
> - .name = "armada_370_xp_tick",
> - .flags = IRQF_DISABLED | IRQF_TIMER,
> - .handler = armada_370_xp_timer_interrupt
> +/*
> + * Setup the local clock events for a CPU.
> + */
> +static int __cpuinit armada_370_xp_timer_setup(struct clock_event_device *evt)
> +{
> + u32 u;
> + int cpu = smp_processor_id();
> +
> + /* Use existing clock_event for cpu 0 */
> + if (!smp_processor_id())
> + return 0;
> +
> + u = readl(local_base + TIMER_CTRL_OFF);
> + if (timer25Mhz)
> + writel(u | TIMER0_25MHZ, local_base + TIMER_CTRL_OFF);
> + else
> + writel(u & ~TIMER0_25MHZ, local_base + TIMER_CTRL_OFF);
> +
> + evt->name = armada_370_xp_clkevt.name;
> + evt->irq = armada_370_xp_clkevt.irq;
> + evt->features = armada_370_xp_clkevt.features;
> + evt->shift = armada_370_xp_clkevt.shift;
> + evt->rating = armada_370_xp_clkevt.rating,
> + evt->set_next_event = armada_370_xp_clkevt_next_event,
> + evt->set_mode = armada_370_xp_clkevt_mode,
> + evt->cpumask = cpumask_of(cpu);
> +
> + *__this_cpu_ptr(percpu_armada_370_xp_evt) = evt;
> +
> + clockevents_config_and_register(evt, timer_clk, 1, 0xfffffffe);
> + enable_percpu_irq(evt->irq, 0);
> +
> + return 0;
> +}
> +
> +static void armada_370_xp_timer_stop(struct clock_event_device *evt)
> +{
> + evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
> + disable_percpu_irq(evt->irq);
> +}
> +
> +static struct local_timer_ops armada_370_xp_local_timer_ops __cpuinitdata = {
> + .setup = armada_370_xp_timer_setup,
> + .stop = armada_370_xp_timer_stop,
> };
>
> void __init armada_370_xp_timer_init(void)
> {
> u32 u;
> struct device_node *np;
> - unsigned int timer_clk;
> + int res;
> +
> np = of_find_compatible_node(NULL, NULL, "marvell,armada-370-xp-timer");
> timer_base = of_iomap(np, 0);
> WARN_ON(!timer_base);
> + local_base = of_iomap(np, 1);
>
> if (of_find_property(np, "marvell,timer-25Mhz", NULL)) {
> /* The fixed 25MHz timer is available so let's use it */
> + u = readl(local_base + TIMER_CTRL_OFF);
> + writel(u | TIMER0_25MHZ,
> + local_base + TIMER_CTRL_OFF);
> u = readl(timer_base + TIMER_CTRL_OFF);
> - writel(u | TIMER0_25MHZ | TIMER1_25MHZ,
> + writel(u | TIMER0_25MHZ,
> timer_base + TIMER_CTRL_OFF);
> timer_clk = 25000000;
> } else {
> @@ -183,15 +235,23 @@ void __init armada_370_xp_timer_init(void)
> struct clk *clk = of_clk_get(np, 0);
> WARN_ON(IS_ERR(clk));
> rate = clk_get_rate(clk);
> + u = readl(local_base + TIMER_CTRL_OFF);
> + writel(u & ~(TIMER0_25MHZ),
> + local_base + TIMER_CTRL_OFF);
> +
> u = readl(timer_base + TIMER_CTRL_OFF);
> - writel(u & ~(TIMER0_25MHZ | TIMER1_25MHZ),
> + writel(u & ~(TIMER0_25MHZ),
> timer_base + TIMER_CTRL_OFF);
> +
> timer_clk = rate / TIMER_DIVIDER;
> + timer25Mhz = false;
> }
>
> - /* We use timer 0 as clocksource, and timer 1 for
> - clockevents */
> - timer_irq = irq_of_parse_and_map(np, 1);
> + /*
> + * We use timer 0 as clocksource, and private(local) timer 0
> + * for clockevents
> + */
> + armada_370_xp_clkevt.irq = irq_of_parse_and_map(np, 4);
>
> ticks_per_jiffy = (timer_clk + HZ / 2) / HZ;
>
> @@ -216,12 +276,26 @@ void __init armada_370_xp_timer_init(void)
> "armada_370_xp_clocksource",
> timer_clk, 300, 32, clocksource_mmio_readl_down);
>
> - /*
> - * Setup clockevent timer (interrupt-driven).
> - */
> - setup_irq(timer_irq, &armada_370_xp_timer_irq);
> + /* Register the clockevent on the private timer of CPU 0 */
> armada_370_xp_clkevt.cpumask = cpumask_of(0);
> clockevents_config_and_register(&armada_370_xp_clkevt,
> timer_clk, 1, 0xfffffffe);
> -}
>
> + percpu_armada_370_xp_evt = alloc_percpu(struct clock_event_device *);
> +
> +
> + /*
> + * Setup clockevent timer (interrupt-driven).
> + */
> + *__this_cpu_ptr(percpu_armada_370_xp_evt) = &armada_370_xp_clkevt;
> + res = request_percpu_irq(armada_370_xp_clkevt.irq,
> + armada_370_xp_timer_interrupt,
> + armada_370_xp_clkevt.name,
> + percpu_armada_370_xp_evt);
> + if (!res) {
> + enable_percpu_irq(armada_370_xp_clkevt.irq, 0);
> +#ifdef CONFIG_LOCAL_TIMERS
> + local_timer_register(&armada_370_xp_local_timer_ops);
> +#endif
> + }
> +}
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2] cpuidle: kirkwood: Move out of mach directory
From: Jason Cooper @ 2013-01-23 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357734135-3985-1-git-send-email-andrew@lunn.ch>
On Wed, Jan 09, 2013 at 01:22:15PM +0100, Andrew Lunn wrote:
> Move the Kirkwood cpuidle driver out of arch/arm/mach-kirkwood and
> into drivers/cpuidle. Convert the driver into a platform driver.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> arch/arm/configs/kirkwood_defconfig | 1 +
> arch/arm/mach-kirkwood/Makefile | 1 -
> arch/arm/mach-kirkwood/board-dt.c | 2 +
> arch/arm/mach-kirkwood/common.c | 23 +++++
> arch/arm/mach-kirkwood/common.h | 1 +
> arch/arm/mach-kirkwood/cpuidle.c | 73 ----------------
> arch/arm/mach-kirkwood/include/mach/kirkwood.h | 3 +-
> drivers/cpuidle/Kconfig | 6 ++
> drivers/cpuidle/Makefile | 1 +
> drivers/cpuidle/cpuidle-kirkwood.c | 106 ++++++++++++++++++++++++
> 10 files changed, 142 insertions(+), 75 deletions(-)
> delete mode 100644 arch/arm/mach-kirkwood/cpuidle.c
> create mode 100644 drivers/cpuidle/cpuidle-kirkwood.c
Applied to mvebu/drivers
thx,
Jason.
^ permalink raw reply
* [PATCH 0/4] Power off drivers for QNAP and LSXL.
From: Jason Cooper @ 2013-01-23 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1356697512-3950-1-git-send-email-andrew@lunn.ch>
On Fri, Dec 28, 2012 at 01:25:08PM +0100, Andrew Lunn wrote:
> This patchset contains two power off driver, moving existing code
> out of mach-kirkwood into drivers/power/reset.
>
> QNAP NAS boards have a microcontroller connected to a UART. Sending
> the command to it turns the power off. There are Orion5x QNAP boards
> which can later use this driver, once they are converted to DT.
>
> Kirkwood Buffalo Linkstation LSXL devices power off by restarting and
> letting the boot loader idle until the user hits a switch. There are
> again Orion5x devices which could use this driver in the future, once
> they are converted to DT. It also looks like some PXA devices could
> use it.
>
> Patches #1 and #3 are the drivers, and #2 and #4 make use of the
> driver, removing C code and adding DT nodes.
>
> The QNAP driver has been tested on a QNAP TS119+. The LSXL driver is
> currently untested.
>
> git://github.com/lunn/linux.git v3.8-rc1-qnap-poweroff
>
> Andrew Lunn (4):
> Power: Reset: Driver to turn QNAP board power off.
> ARM: Kirkwood: Make use of the QNAP Power off driver.
> Power: Reset: Power off by restarting
> ARM: Kirkwood: Convert LSXL to restart-poweroff driver.
>
> .../bindings/power_supply/qnap-poweroff.txt | 14 +++
> .../bindings/power_supply/restart-poweroff.txt | 9 ++
> arch/arm/boot/dts/kirkwood-lsxl.dtsi | 4 +
> arch/arm/boot/dts/kirkwood-ts219.dtsi | 5 +
> arch/arm/mach-kirkwood/Kconfig | 2 +
> arch/arm/mach-kirkwood/board-lsxl.c | 16 ---
> arch/arm/mach-kirkwood/board-ts219.c | 3 -
> drivers/power/reset/Kconfig | 17 +++
> drivers/power/reset/Makefile | 2 +
> drivers/power/reset/qnap-poweroff.c | 124 ++++++++++++++++++++
> drivers/power/reset/restart-poweroff.c | 67 +++++++++++
> 11 files changed, 244 insertions(+), 19 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
> create mode 100644 Documentation/devicetree/bindings/power_supply/restart-poweroff.txt
> create mode 100644 drivers/power/reset/qnap-poweroff.c
> create mode 100644 drivers/power/reset/restart-poweroff.c
patches 2 and 4 applied to mvebu/dt with a dependency on:
git://git.infradead.org/battery-2.6.git master
up to:
ffd8f9a power/reset: Add a new driver implementing 'power off by restarting'
in order to pull in patches 1 and 3:
ffd8f9a power/reset: Add a new driver implementing 'power off by restarting'
e8fc721 power/reset: Add a new driver to turn QNAP board power off
thx,
Jason.
^ permalink raw reply
* [PATCH 1/2] misc/at24: Add at24c512b eeprom support
From: Wolfram Sang @ 2013-01-23 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbQcyO82Z7+v61VmJBOHuPVT2ZphQQT7OpZ9edYbho5YQ@mail.gmail.com>
On Wed, Jan 23, 2013 at 01:24:52PM +0100, Linus Walleij wrote:
> On Wed, Jan 23, 2013 at 7:32 AM, Liu Ying <Ying.Liu@freescale.com> wrote:
>
> > This patch adds at24c512b eeprom support.
> > The datasheet of at24c512b can be found at:
> > http://www.alldatasheet.com/datasheet-pdf/pdf/
> > 256958/ATMEL/AT24C512B-TH-B.html
> >
> > Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
>
> Arnd Bergmann is the misc maintainer, route this by him.
I usually take at24 patches via my I2C tree.
But not this one, though. The 512b can equally use the 512 entry. The
devicetree should contain both entries, the 512 one as a fallback. (And
the vendor is not "at24"!)
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130123/86f5b0b3/attachment.sig>
^ 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