* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Mark Brown @ 2012-10-30 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121029194901.GA30152@arwen.pp.htv.fi>
On Mon, Oct 29, 2012 at 09:49:01PM +0200, Felipe Balbi wrote:
> On Fri, Oct 26, 2012 at 05:03:16PM +0100, Mark Brown wrote:
> > You could have the driver explicitly set the flag, it would just be one
> > extra line, but it seems marginally nicer to just do it.
> You didn't get the whole picture I'm afraid. Consider the situation
> where the same e.g. keypad driver is being used on OMAP4 and OMAP5 and
> those have different requirements towards pinctrl.
No, I'm pretty certain that I do.
> Now, we need to add OMAP5 support *to the same keypad driver*.
> Unfortunately, OMAP5 needs to handle pinctrl explicitly for whatever
> reason (SW-controlled sleep mode, errata fix, whatever).
> This will mean that we will have to remove the flag from the keypad
> driver because that's not valid anymore for OMAP5.
This isn't a problem; either the pinctrl code for OMAP5 will do
something sensible for OMAP4 in which case there's no difference to the
resulting code or you're going to have to have conditional code for the
two devices anyway and you're no worse off.
> This is why I think hiding things from drivers makes no sense. Also
> consider the situations Linus W exposed on another subthread. If you
> change ordering of certain calls, you will really break the
> functionality of the IP. Because we can't make sure this won't work
> automagically in all cases (just like we can't make sure $size memory
> allocation is enough for all drivers) we don't hide that from the
> driver. We require driver to manage its resources properly.
We need some place to put the SoC integration; power domains seem like
the obvious place to me but YMMV. Nothing about having this out of the
drivers requires that this be done by individual subsystems in isolation
from each other. Half the point here is that for the reusable IPs this
stuff often isn't driver specific at all, it's often more about the SoC
integration than it is about the driver and so you'll get a consistent
pattern for most IPs on the SoC.
> How can you make sure that this will work for at least 50% of the
> drivers ? You just can't. We don't know the implementation details of
> every arch/soc/platform supported by Linux today to make that decision.
Well, we've managed to get along for rather a long time with essentially
all architectures implementing this stuff by doing static setup for the
pins on boot. That does suggest we can get a reasonably long way with
something simple, and it does seem to match up with how things usually
look at an electrical level too.
It seems fairly obvious that if we need to add identical bolier plate
code to lots of drivers we're doing something wrong, it's just churn for
little practical gain and a problem if we ever decide to change how this
stuff works in the future.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/89953e6b/attachment.sig>
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Paul Walmsley @ 2012-10-30 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAORVsuWt22yRy9cHAU1u+9K7Fy4Zi95UN4wOh2DeVe61S-u5Cg@mail.gmail.com>
Hi Jean,
On Tue, 30 Oct 2012, Jean Pihet wrote:
> On Tue, Oct 30, 2012 at 5:16 AM, Paul Walmsley <paul@pwsan.com> wrote:
> > On Tue, 23 Oct 2012, Jean Pihet wrote:
> >
> >> Let me try with the same setup as yours (bootloader images,
> >> omap2pus_defconfig, angstrom roots).
> >
> > Had any luck reproducing this one that Aaro & I are seeing?
> Unfortunately not. I could not reproduce the issue on my side, using
> an ES2.1 Beagleboard with the latest l-o kernel and your bootloader
> and rootfs images.
> Is there some specific to enable in order to reproduce the issue?
Could you please post a bootlog from your terminal program, similar to
http://www.pwsan.com/omap/testlogs/test_v3.7-rc3/20121028162003/boot/3530es3beagle/3530es3beagle_log.txt
?
- Paul
^ permalink raw reply
* [PATCH V2] ARM: mx28: Skip OCOTP FEC MAC setup if in DT
From: Shawn Guo @ 2012-10-30 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210301146.34506.marex@denx.de>
On Tue, Oct 30, 2012 at 11:46:34AM +0100, Marek Vasut wrote:
> Dear Shawn Guo,
>
> > On Fri, Oct 26, 2012 at 12:01:58PM +0200, Marek Vasut wrote:
> > > Can we apply this for 3.7?
> >
> > You meant for 3.8?
>
> 3.7 would be nice, but it's too late now.
>
Applied for 3.8.
^ permalink raw reply
* [PATCH 2/2] ARM: OMAP: omap_device: Correct resource handling for DT boot
From: Péter Ujfalusi @ 2012-10-30 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351593205-13590-3-git-send-email-peter.ujfalusi@ti.com>
On 10/30/2012 11:33 AM, Peter Ujfalusi wrote:
> When booting with DT the OF core can fill up the resources provided within
> the DT blob.
> The current way of handling the DT boot prevents us from removing hwmod data
> for platforms only suppose to boot with DT (OMAP5 for example) since we need
> to keep the whole hwmod database intact in order to have more resources in
> hwmod than in DT (to be able to append the DMA resource from hwmod).
>
> To fix this issue we just examine the OF provided resources:
> If we do not have resources we use hwmod to fill them.
> If we have resources we check if we already able to recive DMA resource, if
> no we only append the DMA resurce from hwmod to the OF provided ones.
>
> In this way we can start removing hwmod data for devices which have their
> resources correctly configured in DT without regressions.
>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
> arch/arm/plat-omap/omap_device.c | 80 +++++++++++++++++++++++-----------------
> 1 file changed, 47 insertions(+), 33 deletions(-)
>
> diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
> index 915cf68..a8a9d08 100644
> --- a/arch/arm/plat-omap/omap_device.c
> +++ b/arch/arm/plat-omap/omap_device.c
> @@ -560,55 +560,69 @@ struct omap_device *omap_device_alloc(struct platform_device *pdev,
> od->hwmods = hwmods;
> od->pdev = pdev;
>
> - /* Count all resources for the device */
> - res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
> - IORESOURCE_DMA |
> - IORESOURCE_MEM);
> /*
> + * Non-DT Boot:
> + * Here, pdev->num_resources = 0, and we should get all the
> + * resources from hwmod.
> + *
> * DT Boot:
> * OF framework will construct the resource structure (currently
> * does for MEM & IRQ resource) and we should respect/use these
> * resources, killing hwmod dependency.
> * If pdev->num_resources > 0, we assume that MEM & IRQ resources
> * have been allocated by OF layer already (through DTB).
> - *
> - * Non-DT Boot:
> - * Here, pdev->num_resources = 0, and we should get all the
> - * resources from hwmod.
> + * As preparation for the future we examine the OF provided resources
> + * to see if we have DMA resources provided already. In this case
> + * there is no need to update the resources for the device, we use the
> + * OF provided ones.
> *
> * TODO: Once DMA resource is available from OF layer, we should
> * kill filling any resources from hwmod.
> */
> - if (res_count > pdev->num_resources) {
> - /* Allocate resources memory to account for new resources */
> - res = kzalloc(sizeof(struct resource) * res_count, GFP_KERNEL);
> - if (!res)
> - goto oda_exit3;
> -
> - /*
> - * If pdev->num_resources > 0, then assume that,
> - * MEM and IRQ resources will only come from DT and only
> - * fill DMA resource from hwmod layer.
> - */
> - if (pdev->num_resources && pdev->resource) {
> - dev_dbg(&pdev->dev, "%s(): resources already allocated %d\n",
> - __func__, res_count);
> - memcpy(res, pdev->resource,
> - sizeof(struct resource) * pdev->num_resources);
> - _od_fill_dma_resources(od, &res[pdev->num_resources]);
> - } else {
> - dev_dbg(&pdev->dev, "%s(): using resources from hwmod %d\n",
> - __func__, res_count);
> - omap_device_fill_resources(od, res);
> + if (!pdev->num_resources) {
> + /* Count all resources for the device */
> + res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
> + IORESOURCE_DMA |
> + IORESOURCE_MEM);
> + } else {
> + /* Take a look if we already have DMA resource via DT */
> + for (i = 0; i < pdev->num_resources; i++) {
> + struct resource *r = &pdev->resource[i];
> +
> + /* We have it, no need to touch the resources */
> + if (r->flags == IORESOURCE_DMA)
> + goto have_everything;
> }
> + /* Count only DMA resources for the device */
> + res_count = omap_device_count_resources(od, IORESOURCE_DMA);
We have devices without DMA channel so we can skip the resource recreation for
them.
I'll resend the series with this update.
> + res_count += pdev->num_resources;
> + }
>
> - ret = platform_device_add_resources(pdev, res, res_count);
> - kfree(res);
> + /* Allocate resources memory to account for new resources */
> + res = kzalloc(sizeof(struct resource) * res_count, GFP_KERNEL);
> + if (!res)
> + goto oda_exit3;
>
> - if (ret)
> - goto oda_exit3;
> + if (!pdev->num_resources) {
> + dev_dbg(&pdev->dev, "%s: using %d resources from hwmod\n",
> + __func__, res_count);
> + omap_device_fill_resources(od, res);
> + } else {
> + dev_dbg(&pdev->dev,
> + "%s: appending %d DMA resources from hwmod\n",
> + __func__, res_count - pdev->num_resources);
> + memcpy(res, pdev->resource,
> + sizeof(struct resource) * pdev->num_resources);
> + _od_fill_dma_resources(od, &res[pdev->num_resources]);
> }
>
> + ret = platform_device_add_resources(pdev, res, res_count);
> + kfree(res);
> +
> + if (ret)
> + goto oda_exit3;
> +
> +have_everything:
> if (!pm_lats) {
> pm_lats = omap_default_latency;
> pm_lats_cnt = ARRAY_SIZE(omap_default_latency);
>
--
P?ter
^ permalink raw reply
* [PATCH V2 1/3] clk: mvebu: add armada-370-xp specific clocks
From: Mike Turquette @ 2012-10-30 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349125926-16144-2-git-send-email-gregory.clement@free-electrons.com>
Quoting Gregory CLEMENT (2012-10-01 14:12:04)
> Add Armada 370/XP specific clocks: core clocks and CPU clocks.
>
> The CPU clocks are only for Armada XP for the SMP mode.
>
> The core clocks are clocks which have their rate set during reset. The
> code was written with the other SoCs of the mvebu family in
> mind. Adding them should be pretty straight forward. For a new
> SoC, only 3 binding have to be added:
> - one to provide the tclk frequency
> - one to provde the pclk frequency
> - and one to provide the ratio between the pclk and the children
> clocks
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Thanks for sending v2 Gregory. Functionally this series looks good but
unfortunately there are a few style and white space nitpicks below.
> diff --git a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
> new file mode 100644
> index 0000000..c524618
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
> @@ -0,0 +1,21 @@
> +Device Tree Clock bindings for cpu clock of Marvell EBU platforms
> +
> +Required properties:
> +- compatible : shall be one of the following:
> + "marvell,armada-xp-cpu-clockctrl" - cpu clocks for Armada XP
> +- reg : Address and length of the clock complex register set
> +- #clock-cells : should be set to 1.
> +- clocks : shall be the input parent clock phandle for the clock.
> +
> +cpuclk: clock-complex at d0018700 {
> + #clock-cells = <1>;
> + compatible = "marvell,armada-xp-cpu-clockctrl";
> + reg = <0xd0018700 0xA0>;
> + clocks = <&coreclk 1>;
> +}
> +
> +cpu at 0 {
> + compatible = "marvell,sheeva-v7";
Unnecessary white space before the tab in the line above.
> diff --git a/drivers/clk/mvebu/clk-core.c b/drivers/clk/mvebu/clk-core.c
> new file mode 100644
> index 0000000..5792cb5
> --- /dev/null
> +++ b/drivers/clk/mvebu/clk-core.c
> @@ -0,0 +1,312 @@
> +/*
> + * Marvell EBU clock core handling defined at reset
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +#include <linux/kernel.h>
> +#include <linux/clk.h>
> +#include <linux/clkdev.h>
> +#include <linux/clk-provider.h>
> +#include <linux/of_address.h>
> +#include <linux/io.h>
> +#include <linux/of.h>
> +
> +/* Sample At Reset is a 64 bit bitfiled split in two register of 32
> + * bits*/
Can you make this proper comment block style per CodingStyle convention?
> +
> +#define SARL 0 /* Low part [0:31] */
> +#define SARL_AXP_PCLK_FREQ_OPT 21
> +#define SARL_AXP_PCLK_FREQ_OPT_MASK 0x7
> +#define SARL_A370_PCLK_FREQ_OPT 11
> +#define SARL_A370_PCLK_FREQ_OPT_MASK 0xF
> +#define SARL_AXP_FAB_FREQ_OPT 24
> +#define SARL_AXP_FAB_FREQ_OPT_MASK 0xF
> +#define SARL_A370_FAB_FREQ_OPT 15
> +#define SARL_A370_FAB_FREQ_OPT_MASK 0x1F
> +#define SARL_A370_TCLK_FREQ_OPT 20
> +#define SARL_A370_TCLK_FREQ_OPT_MASK 0x1
> +#define SARH 4 /* High part [32:63] */
> +#define SARH_AXP_PCLK_FREQ_OPT (52-32)
> +#define SARH_AXP_PCLK_FREQ_OPT_MASK 0x1
> +#define SARH_AXP_PCLK_FREQ_OPT_SHIFT 3
> +#define SARH_AXP_FAB_FREQ_OPT (51-32)
> +#define SARH_AXP_FAB_FREQ_OPT_MASK 0x1
> +#define SARH_AXP_FAB_FREQ_OPT_SHIFT 4
> +
> +u32 *sar_reg;
> +int sar_reg_size;
> +
> +enum core_clk {
> + tclk, pclk, nbclk, hclk, dramclk, clk_max
> +};
> +
> +struct core_clk_fn {
> + u32(*get_tclk_freq) (void);
> + u32(*get_pck_freq) (void);
> + const int *(*get_fab_freq_opt) (void);
> +};
> +
> +/* Ratio between VCO and each of the member in the following order:
> + CPU clock, L2 clock, DRAM controler clock, DDR clcok */
ditto
> +static const int reset_core_ratio[32][4] = {
> + [0x01] = {1, 2, 2, 2},
> + [0x02] = {2, 2, 6, 3},
> + [0x03] = {2, 2, 3, 3},
> + [0x04] = {1, 2, 3, 3},
> + [0x05] = {1, 2, 4, 2},
> + [0x06] = {1, 1, 2, 2},
> + [0x07] = {2, 3, 6, 6},
> + [0x09] = {1, 2, 6, 3},
> + [0x0A] = {2, 4, 10, 5},
> + [0x0C] = {1, 2, 4, 4},
> + [0x0F] = {2, 2, 5, 5},
> + [0x13] = {1, 1, 2, 1},
> + [0x14] = {2, 3, 6, 3},
> + [0x1B] = {1, 1, 1, 1},
> +};
> +
> +static struct clk *clks[clk_max];
> +
> +static struct clk_onecell_data clk_data;
> +
> +/* Frequency in MHz*/
> +static u32 armada_370_pclk[] = { 400, 533, 667, 800, 1000, 1067, 1200 };
> +
> +static u32 armada_xp_pclk[] = { 1000, 1066, 1200, 1333, 1500, 1666,
> + 1800, 2000, 667, 0, 800, 1600
> +};
> +
> +static u32 armada_370_tclk[] = { 166, 200 };
> +
> +static const int *__init armada_370_get_fab_freq_opt(void)
> +{
> + u8 fab_freq_opt = 0;
> +
> + fab_freq_opt = ((sar_reg[0] >> SARL_A370_FAB_FREQ_OPT) &
> + SARL_A370_FAB_FREQ_OPT_MASK);
> +
> + if (reset_core_ratio[fab_freq_opt][0] == 0)
> + return NULL;
> + else
> + return reset_core_ratio[fab_freq_opt];
> +}
> +
> +static u32 __init armada_370_get_pck_freq(void)
> +{
> + u32 cpu_freq;
> + u8 cpu_freq_select = 0;
> +
> + cpu_freq_select = ((sar_reg[0] >> SARL_A370_PCLK_FREQ_OPT) &
> + SARL_A370_PCLK_FREQ_OPT_MASK);
> + if (cpu_freq_select > ARRAY_SIZE(armada_370_pclk)) {
> + pr_err("CPU freq select unsuported %d\n", cpu_freq_select);
> + cpu_freq = 0;
> + } else
> + cpu_freq = armada_370_pclk[cpu_freq_select];
> +
> + return cpu_freq * 1000 * 1000;
> +}
> +
> +static u32 __init armada_370_get_tclk_freq(void)
> +{
> + u32 tclk_freq;
> + u8 tclk_freq_select = 0;
> +
> + tclk_freq_select = ((sar_reg[0] >> SARL_A370_TCLK_FREQ_OPT) &
> + SARL_A370_TCLK_FREQ_OPT_MASK);
> + if (tclk_freq_select > ARRAY_SIZE(armada_370_tclk)) {
> + pr_err("TCLK freq select unsuported %d\n", tclk_freq_select);
> + tclk_freq = 0;
> + } else
> + tclk_freq = armada_370_tclk[tclk_freq_select];
> +
> + return tclk_freq * 1000 * 1000;
> +}
> +
> +static const int *__init armada_xp_get_fab_freq_opt(void)
> +{
> + u8 fab_freq_opt = 0;
> +
> + fab_freq_opt = ((sar_reg[0] >> SARL_AXP_FAB_FREQ_OPT) &
> + SARL_AXP_FAB_FREQ_OPT_MASK);
> + /* The upper bit is not contiguous to the other ones
> + * and located in the high part of the SAR
> + * registers */
ditto
> + fab_freq_opt |= (((sar_reg[1] >> SARH_AXP_FAB_FREQ_OPT) &
> + SARH_AXP_FAB_FREQ_OPT_MASK)
> + << SARH_AXP_FAB_FREQ_OPT_SHIFT);
> +
> + if (reset_core_ratio[fab_freq_opt][0] == 0)
> + return NULL;
> + else
> + return reset_core_ratio[fab_freq_opt];
> +}
> +
> +static u32 __init armada_xp_get_pck_freq(void)
> +{
> + u32 cpu_freq;
> + u8 cpu_freq_select = 0;
> +
> + cpu_freq_select = ((sar_reg[0] >> SARL_AXP_PCLK_FREQ_OPT) &
> + SARL_AXP_PCLK_FREQ_OPT_MASK);
> + /* The upper bit is not contiguous to the other ones
> + * and located in the high part of the SAR
> + * registers */
ditto
> + cpu_freq_select |= (((sar_reg[1] >> SARH_AXP_PCLK_FREQ_OPT) &
> + SARH_AXP_PCLK_FREQ_OPT_MASK)
> + << SARH_AXP_PCLK_FREQ_OPT_SHIFT);
> + if (cpu_freq_select > ARRAY_SIZE(armada_xp_pclk)) {
> + pr_err("CPU freq select unsuported: %d\n", cpu_freq_select);
> + cpu_freq = 0;
> + } else
> + cpu_freq = armada_xp_pclk[cpu_freq_select];
> +
> + return cpu_freq * 1000 * 1000;
> +}
> +
> +/* For Armada XP TCLK frequency is fix: 250MHz */
> +static u32 __init armada_xp_get_tclk_freq(void)
> +{
> + return 250 * 1000 * 1000;
> +}
> +
> +void __init of_core_clk_setup(struct device_node *node,
> + struct core_clk_fn clk_fn)
> +{
> + struct clk *clk;
> + unsigned long rate;
> + const char *clk_name;
> + int i;
> +
> + /* clock 0 is tclk */
> + of_property_read_string_index(node, "clock-output-names", tclk,
> + &clk_name);
> + rate = clk_fn.get_tclk_freq();
> + if (rate != 0)
> + clk = clk_register_fixed_rate(NULL, clk_name, NULL,
> + CLK_IS_ROOT, rate);
> + else {
> + pr_err("Invalid freq for %s\n", clk_name);
> + return;
> + }
> +
> + if (WARN_ON(IS_ERR(clk)))
> + return;
> + clks[tclk] = clk;
> +
> + /* clock 1 is pclk */
> + of_property_read_string_index(node, "clock-output-names", pclk,
> + &clk_name);
> + rate = clk_fn.get_pck_freq();
> + if (rate != 0)
> + clk = clk_register_fixed_rate(NULL, clk_name, NULL,
> + CLK_IS_ROOT, rate);
> + else {
> + pr_err("Invalid freq for %s\n", clk_name);
> + return;
> + }
> + if (WARN_ON(IS_ERR(clk)))
> + return;
> + clks[pclk] = clk;
> +
> + /* the clocks 2 to 4 are nbclk, hclk and dramclk and are all
> + * derivated from the clock 1: pclk */
ditto
> +
> + for (i = nbclk; i <= dramclk; i++) {
> + const int *ratio = clk_fn.get_fab_freq_opt();
> + const char *parent_clk_name;
> +
> + of_property_read_string_index(node, "clock-output-names",
> + i, &clk_name);
> + of_property_read_string_index(node, "clock-output-names",
> + pclk, &parent_clk_name);
> +
> + if (ratio != NULL)
> + clk = clk_register_fixed_factor(NULL, clk_name,
> + parent_clk_name, 0,
> + ratio[0],
> + ratio[i - nbclk + 1]);
> + else {
> + pr_err("Invalid clk ratio for %s\n", clk_name);
> + return;
> + }
> +
> + if (WARN_ON(IS_ERR(clk)))
> + return;
> + clks[i] = clk;
> + }
> + clk_data.clk_num = ARRAY_SIZE(clks);
> + clk_data.clks = clks;
> + of_clk_add_provider(node, of_clk_src_onecell_get, &clk_data);
> +}
> +
> +static struct core_clk_fn armada_370_clk_fn = {
> + .get_tclk_freq = armada_370_get_tclk_freq,
> + .get_pck_freq = armada_370_get_pck_freq,
> + .get_fab_freq_opt = armada_370_get_fab_freq_opt,
> +};
> +
> +static struct core_clk_fn armada_xp_clk_fn = {
> + .get_tclk_freq = armada_xp_get_tclk_freq,
> + .get_pck_freq = armada_xp_get_pck_freq,
> + .get_fab_freq_opt = armada_xp_get_fab_freq_opt,
> +};
> +
> +static const __initconst struct of_device_id clk_match[] = {
> + {
> + .compatible = "marvell,armada-370-core-clockctrl",
> + .data = &armada_370_clk_fn,
> + },
Indention is a bit weird here. The members are just indented with one
space and there is an extra white space in front of the closing bracket.
Can you re-align?
> +
> + {
> + .compatible = "marvell,armada-xp-core-clockctrl",
> + .data = &armada_xp_clk_fn,
> + },
ditto
> + {
> + /* sentinel */
> + }
ditto
> +};
> +
> +void __init mvebu_core_clocks_init(void)
> +{
> + struct device_node *np;
> + struct resource res;
> + void __iomem *sar_base;
> + int i;
> +
> + np = of_find_node_by_name(NULL, "mvebu-sar");
> +
> + if (!np)
> + goto err;
> +
> + if (of_address_to_resource(np, 0, &res))
> + goto err;
> +
> + sar_reg_size = resource_size(&res);
> + sar_reg = kmalloc(sar_reg_size, GFP_KERNEL);
> +
> + sar_base = ioremap(res.start, sar_reg_size);
> + if (sar_base == NULL)
> + goto err;
> + for (i = 0; i < sar_reg_size; i += sizeof(*sar_reg))
> + sar_reg[i] = readl(sar_base + i);
> +
> + iounmap(sar_base);
> +
> + for_each_matching_node(np, clk_match) {
> + const struct of_device_id *match = of_match_node(clk_match, np);
> + struct core_clk_fn *clk_fn = match->data;
> + of_core_clk_setup(np, *clk_fn);
> + }
> +
> + return;
> +err:
> + pr_err("%s:SAR base adresse not set in DT\n", __func__);
> + return;
> +}
> diff --git a/drivers/clk/mvebu/clk-core.h b/drivers/clk/mvebu/clk-core.h
> new file mode 100644
> index 0000000..a04f80b
> --- /dev/null
> +++ b/drivers/clk/mvebu/clk-core.h
> @@ -0,0 +1,19 @@
> +/*
> + * * Marvell EBU clock core handling defined at reset
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __MVEBU_CLK_CORE_H
> +#define __MVEBU_CLK_CORE_H
> +
> +void __init of_core_clk_setup(struct device_node *node);
> +void __init mvebu_core_clocks_init(void);
> +
> +#endif
> diff --git a/drivers/clk/mvebu/clk-cpu.c b/drivers/clk/mvebu/clk-cpu.c
> new file mode 100644
> index 0000000..6b5c841
> --- /dev/null
> +++ b/drivers/clk/mvebu/clk-cpu.c
> @@ -0,0 +1,155 @@
> +/*
> + * Marvell MVEBU CPU clock handling.
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +#include <linux/kernel.h>
> +#include <linux/clk.h>
clk-provider.h includes clk.h, so this is redundant.
Regards,
Mike
^ permalink raw reply
* [PATCH v3 06/10] net/macb: clean up ring buffer logic
From: David Laight @ 2012-10-30 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <75eb5df193c504e68ebff7d6a6a88d9a1cc678cb.1351591858.git.nicolas.ferre@atmel.com>
> Instead of masking head and tail every time we increment them, just let them
> wrap through UINT_MAX and mask them when subscripting. Add simple accessor
> functions to do the subscripting properly to minimize the chances of messing
> this up.
...
> +static unsigned int macb_tx_ring_avail(struct macb *bp)
> +{
> + return TX_RING_SIZE - (bp->tx_head - bp->tx_tail);
> +}
That one doesn't look quite right to me.
Surely it should be masking with 'TX_RING_SIZE - 1'
David
^ permalink raw reply
* ARM: Add PI/robust mutexes support for SMP kernels
From: ashish yadav @ 2012-10-30 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKbuCZT+5nkXWXEA7h54Rw2Ss94Co=q9YU3PT+WcNmn-QGC1g@mail.gmail.com>
Hi ,
This is for information that , I am using 2.6.35.14 Kernel Version.
Thanks & Regards
Ashish
On Tue, Oct 30, 2012 at 4:34 PM, ashish yadav <ashishyadav78@gmail.com>wrote:
> Hi ,
>
> I am using patch "ARM: Add PI/robust mutexes support for SMP kernels"
> for Arm Cortex-A9 from :
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/017374.html
>
> But still I can see mutex multiple lock/unlock error with PI mutex in my
> application.
>
> Seeing the mailing chain of this patch , its seems that this patch is not
> complete.
>
> Could any one please update full patch for same.
>
> Thanks & Regards
> Ashish
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/669e7149/attachment.html>
^ permalink raw reply
* ARM: Add PI/robust mutexes support for SMP kernels
From: ashish yadav @ 2012-10-30 11:04 UTC (permalink / raw)
To: linux-arm-kernel
Hi ,
I am using patch "ARM: Add PI/robust mutexes support for SMP kernels" for
Arm Cortex-A9 from :
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/017374.html
But still I can see mutex multiple lock/unlock error with PI mutex in my
application.
Seeing the mailing chain of this patch , its seems that this patch is not
complete.
Could any one please update full patch for same.
Thanks & Regards
Ashish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/e2e46e90/attachment.html>
^ permalink raw reply
* OMAP baseline test results for v3.7-rc3
From: Mark Jackson @ 2012-10-30 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210300229590.12697@utopia.booyaka.com>
On 30/10/12 02:36, Paul Walmsley wrote:
>
> Here are some basic OMAP test results for Linux v3.7-rc3.
> Logs and other details at:
>
> http://www.pwsan.com/omap/testlogs/test_v3.7-rc3/20121028162003/
>
>
> Passing tests
> -------------
>
> Boot to userspace: 2420n800, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm,
> 4430es2panda, 5912osk, am335xbone
>
> PM ret/off, suspend + dynamic idle: (none)
>
>
> Failing tests: fixed by posted patches
> --------------------------------------
>
> Boot tests:
>
> * 2430sdp: vfp_reload_hw oops during MMC initialization
> - Kernel attempts to save FP registers that don't exist; fix posted:
> - http://www.spinics.net/lists/arm-kernel/msg200646.html
> - added to rmk's patch system as 7566/1
>
> * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
> - Due to GPMC missing support for DT
> - Temporary workaround at http://www.spinics.net/lists/arm-kernel/msg200787.html
> - May be fixed now, pending retest:
> - http://marc.info/?l=linux-omap&m=135082257727502&w=2
At what point is booting from MMC on the BeagleBone going to start working ?
I only ask, since, by default, a new BeagleBone is setup to boot from MMC, so anyone testing a new
kernel will probably expect the same setup to work.
Cheers
Mark JACKSON
^ permalink raw reply
* Representation of external memory-mapped devices in DT (gpmc)
From: Afzal Mohammed @ 2012-10-30 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508EBB47.8070405@gmail.com>
Hi Daniel,
On Monday 29 October 2012 10:52 PM, Daniel Mack wrote:
> On 29.10.2012 16:09, Rob Herring wrote:
>> You may want a CS0 node with nand as a child node of that.
> Hmm, I don't see what that would buy us. The question is which way is
> feasible for storing both the memory region and the cs number in the
> device tree. The CS number should certainly go to the child node, no?
>
> IOW, would it be a good idea to have something like the following layout?
>
> gpmc: gpmc at 50000000 {
> compatible = "ti,gpmc";
> ti,hwmods = "gpmc";
> reg =<0x50000000 0x2000>;
>
> /* cs-reg stores the setup of the controller's
> memory map */
>
> /* offset size */
> cs-reg =<0x0 0x1000000
> .... .....
> .... .....>;
>
> nand: child at 0 {
> /* timings */
> /* peripheral specifics */
> };
> };
>
> I would actually much prefer that approach.
>
> Afzal, because because that way, we can leave the code as-is for now and
> add the "cs-reg" property once the code is switched to dynamic handling.
> What do you think?
I don't know what to say, don't have a good grasp on DT to give
right suggestion.
It seems offset field may not be necessary. memory for connected
peripherals is not fixed, only CS is fixed (as CS pin is hard-wired).
Physical memory can be anywhere between 0-512MB (with
alignment constraints depending on size, refer GPMC_CONFIG7
register), even though right now memory region for peripheral
seems to be fixed (for boards supported in mainline it will be
what bootloader configures), it is possible to have it in a different
region for those peripherals.
And this memory should be presented to child device as resource,
say for smsc911x ethernet driver.
I see some similarity with PCI - BAR's, where address space
is configured (here a difference would be that size needs to
be known while configuring). Size here would be based on
connected peripheral (but no auto detection)
Regards
Afzal
^ permalink raw reply
* [PATCH 1/3] ARM: mvebu: Add support I2C controller
From: Thomas Petazzoni @ 2012-10-30 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351593685-19663-1-git-send-email-iwamatsu@nigauri.org>
Dear Nobuhiro Iwamatsu,
On Tue, 30 Oct 2012 19:41:23 +0900, Nobuhiro Iwamatsu wrote:
> The mvebu arch has the same I2C controller as mv64xxx-i2c.
> This support mv64xxx-i2c on mvebu.
>
> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Thanks, looks good to me, but we have to wait for the Armada 370/XP
clock patch set to get merged before merging this.
I'll give it a test on the OpenBlocks hardware and report.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/1] net: macb: add pinctrl consumer support
From: Nicolas Ferre @ 2012-10-30 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351352997-31116-1-git-send-email-plagnioj@jcrosoft.com>
On 10/27/2012 05:49 PM, Jean-Christophe PLAGNIOL-VILLARD :
> If no pinctrl available just report a warning as some architecture may not
> need to do anything.
>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: netdev at vger.kernel.org
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> ---
> drivers/net/ethernet/cadence/macb.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> index 033064b..e5fdf8a 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -26,6 +26,9 @@
> #include <linux/of.h>
> #include <linux/of_device.h>
> #include <linux/of_net.h>
> +#include <linux/of_gpio.h>
> +#include <linux/gpio.h>
> +#include <linux/pinctrl/consumer.h>
>
> #include "macb.h"
>
> @@ -1306,6 +1309,7 @@ static int __init macb_probe(struct platform_device *pdev)
> struct phy_device *phydev;
> u32 config;
> int err = -ENXIO;
> + struct pinctrl *pinctrl;
>
> regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!regs) {
> @@ -1313,6 +1317,15 @@ static int __init macb_probe(struct platform_device *pdev)
> goto err_out;
> }
>
> + pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
> + if (IS_ERR(pinctrl)) {
> + err = PTR_ERR(pinctrl);
> + if (err == -EPROBE_DEFER)
> + return err;
I will modify this to be consistent with error path before and after
this change => goto err_out.
Do not bother to re-submit a patch, I will include this one in my
upcoming patch series.
Thanks,
> +
> + dev_warn(&pdev->dev, "No pinctrl provided\n");
> + }
> +
> err = -ENOMEM;
> dev = alloc_etherdev(sizeof(*bp));
> if (!dev)
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH V2] ARM: mx28: Skip OCOTP FEC MAC setup if in DT
From: Marek Vasut @ 2012-10-30 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030013111.GD9921@S2101-09.ap.freescale.net>
Dear Shawn Guo,
> On Fri, Oct 26, 2012 at 12:01:58PM +0200, Marek Vasut wrote:
> > Can we apply this for 3.7?
>
> You meant for 3.8?
3.7 would be nice, but it's too late now.
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH] i2c: mv64xxx: Add support Armada-XP SoC
From: Thomas Petazzoni @ 2012-10-30 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351593581-19555-1-git-send-email-iwamatsu@nigauri.org>
Dear Nobuhiro Iwamatsu,
On Tue, 30 Oct 2012 19:39:41 +0900, Nobuhiro Iwamatsu wrote:
> The Armada-XP SoC has the same I2C controller as mv64xxxi-i2c.
> This validates to use mv64xxx in this SoC.
>
> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> ---
> drivers/i2c/busses/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 65dd599..ff53cf4 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -474,7 +474,7 @@ config I2C_MPC
>
> config I2C_MV64XXX
> tristate "Marvell mv64xxx I2C Controller"
> - depends on (MV64X60 || PLAT_ORION)
> + depends on (MV64X60 || PLAT_ORION || MACH_ARMADA_370_XP)
> help
> If you say yes to this option, support will be included for the
> built-in I2C interface on the Marvell 64xxx line of host bridges.
This is not needed: ARCH_MVEBU already selects PLAT_ORION.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 3/3] ARM: mvebu: Add support RTC for OpenBlockS AX3
From: Nobuhiro Iwamatsu @ 2012-10-30 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351593685-19663-1-git-send-email-iwamatsu@nigauri.org>
From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
OpenBlockS AX3 has Seiko Instruments S-35390A as RTC controller.
This validates RTC controller.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
---
arch/arm/boot/dts/openblocks-ax3-4.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/openblocks-ax3-4.dts b/arch/arm/boot/dts/openblocks-ax3-4.dts
index c42b9a5..61c2f2c 100644
--- a/arch/arm/boot/dts/openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/openblocks-ax3-4.dts
@@ -74,6 +74,11 @@
i2c at d0011100 {
status = "okay";
clock-frequency = <400000>;
+
+ s35390a: s35390a at 30 {
+ compatible = "s35390a";
+ reg = <0x30>;
+ };
};
};
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/3] ARM: mvebu: Add support I2C for OpenBlockS AX3
From: Nobuhiro Iwamatsu @ 2012-10-30 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351593685-19663-1-git-send-email-iwamatsu@nigauri.org>
OpenBlockS AX3 uses the I2C controller on the mvebu.
This validates I2C controller and clock-frequency.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
---
arch/arm/boot/dts/openblocks-ax3-4.dts | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/openblocks-ax3-4.dts b/arch/arm/boot/dts/openblocks-ax3-4.dts
index 7ef8052..c42b9a5 100644
--- a/arch/arm/boot/dts/openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/openblocks-ax3-4.dts
@@ -65,5 +65,15 @@
linux,default-trigger = "heartbeat";
};
};
+
+ i2c at d0011000 {
+ status = "okay";
+ clock-frequency = <400000>;
+ };
+
+ i2c at d0011100 {
+ status = "okay";
+ clock-frequency = <400000>;
+ };
};
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/3] ARM: mvebu: Add support I2C controller
From: Nobuhiro Iwamatsu @ 2012-10-30 10:41 UTC (permalink / raw)
To: linux-arm-kernel
The mvebu arch has the same I2C controller as mv64xxx-i2c.
This support mv64xxx-i2c on mvebu.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
---
arch/arm/boot/dts/armada-370-xp.dtsi | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index d0ea4a6..5da85c2 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -83,6 +83,29 @@
interrupts = <10>;
status = "disabled";
};
+
+
+ i2c0: i2c at d0011000 {
+ compatible = "marvell,mv64xxx-i2c";
+ reg = <0xd0011000 0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <31>;
+ timeout-ms = <1000>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
+ i2c1: i2c at d0011100 {
+ compatible = "marvell,mv64xxx-i2c";
+ reg = <0xd0011100 0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <32>;
+ timeout-ms = <1000>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
};
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH] i2c: mv64xxx: Add support Armada-XP SoC
From: Nobuhiro Iwamatsu @ 2012-10-30 10:39 UTC (permalink / raw)
To: linux-arm-kernel
The Armada-XP SoC has the same I2C controller as mv64xxxi-i2c.
This validates to use mv64xxx in this SoC.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
---
drivers/i2c/busses/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 65dd599..ff53cf4 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -474,7 +474,7 @@ config I2C_MPC
config I2C_MV64XXX
tristate "Marvell mv64xxx I2C Controller"
- depends on (MV64X60 || PLAT_ORION)
+ depends on (MV64X60 || PLAT_ORION || MACH_ARMADA_370_XP)
help
If you say yes to this option, support will be included for the
built-in I2C interface on the Marvell 64xxx line of host bridges.
--
1.7.10.4
^ permalink raw reply related
* linux-next: manual merge of the clk tree with the arm-soc tree
From: Pawel Moll @ 2012-10-30 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030101140.18780.69840@nucleus>
On Tue, 2012-10-30 at 10:11 +0000, Mike Turquette wrote:
> > diff --cc arch/arm/include/asm/hardware/sp810.h
> > index 2cdcf44,afd7e91..0000000
> > --- a/arch/arm/include/asm/hardware/sp810.h
> > +++ b/arch/arm/include/asm/hardware/sp810.h
> > @@@ -50,6 -50,14 +50,8 @@@
> > #define SCPCELLID2 0xFF8
> > #define SCPCELLID3 0xFFC
> >
> > -#define SCCTRL_TIMEREN0SEL_REFCLK (0 << 15)
> > -#define SCCTRL_TIMEREN0SEL_TIMCLK (1 << 15)
> > -
> > -#define SCCTRL_TIMEREN1SEL_REFCLK (0 << 17)
> > -#define SCCTRL_TIMEREN1SEL_TIMCLK (1 << 17)
> > -
> > + #define SCCTRL_TIMERENnSEL_SHIFT(n) (15 + ((n) * 2))
> > +
> > static inline void sysctl_soft_reset(void __iomem *base)
> > {
> > /* switch to slow mode */
>
> Pawel,
>
> Does this look OK for you?
Yes, it's correct.
Thanks!
Pawe?
^ permalink raw reply
* [PATCH 2/2] ARM: OMAP: omap_device: Correct resource handling for DT boot
From: Peter Ujfalusi @ 2012-10-30 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351593205-13590-1-git-send-email-peter.ujfalusi@ti.com>
When booting with DT the OF core can fill up the resources provided within
the DT blob.
The current way of handling the DT boot prevents us from removing hwmod data
for platforms only suppose to boot with DT (OMAP5 for example) since we need
to keep the whole hwmod database intact in order to have more resources in
hwmod than in DT (to be able to append the DMA resource from hwmod).
To fix this issue we just examine the OF provided resources:
If we do not have resources we use hwmod to fill them.
If we have resources we check if we already able to recive DMA resource, if
no we only append the DMA resurce from hwmod to the OF provided ones.
In this way we can start removing hwmod data for devices which have their
resources correctly configured in DT without regressions.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/plat-omap/omap_device.c | 80 +++++++++++++++++++++++-----------------
1 file changed, 47 insertions(+), 33 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 915cf68..a8a9d08 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -560,55 +560,69 @@ struct omap_device *omap_device_alloc(struct platform_device *pdev,
od->hwmods = hwmods;
od->pdev = pdev;
- /* Count all resources for the device */
- res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
- IORESOURCE_DMA |
- IORESOURCE_MEM);
/*
+ * Non-DT Boot:
+ * Here, pdev->num_resources = 0, and we should get all the
+ * resources from hwmod.
+ *
* DT Boot:
* OF framework will construct the resource structure (currently
* does for MEM & IRQ resource) and we should respect/use these
* resources, killing hwmod dependency.
* If pdev->num_resources > 0, we assume that MEM & IRQ resources
* have been allocated by OF layer already (through DTB).
- *
- * Non-DT Boot:
- * Here, pdev->num_resources = 0, and we should get all the
- * resources from hwmod.
+ * As preparation for the future we examine the OF provided resources
+ * to see if we have DMA resources provided already. In this case
+ * there is no need to update the resources for the device, we use the
+ * OF provided ones.
*
* TODO: Once DMA resource is available from OF layer, we should
* kill filling any resources from hwmod.
*/
- if (res_count > pdev->num_resources) {
- /* Allocate resources memory to account for new resources */
- res = kzalloc(sizeof(struct resource) * res_count, GFP_KERNEL);
- if (!res)
- goto oda_exit3;
-
- /*
- * If pdev->num_resources > 0, then assume that,
- * MEM and IRQ resources will only come from DT and only
- * fill DMA resource from hwmod layer.
- */
- if (pdev->num_resources && pdev->resource) {
- dev_dbg(&pdev->dev, "%s(): resources already allocated %d\n",
- __func__, res_count);
- memcpy(res, pdev->resource,
- sizeof(struct resource) * pdev->num_resources);
- _od_fill_dma_resources(od, &res[pdev->num_resources]);
- } else {
- dev_dbg(&pdev->dev, "%s(): using resources from hwmod %d\n",
- __func__, res_count);
- omap_device_fill_resources(od, res);
+ if (!pdev->num_resources) {
+ /* Count all resources for the device */
+ res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
+ IORESOURCE_DMA |
+ IORESOURCE_MEM);
+ } else {
+ /* Take a look if we already have DMA resource via DT */
+ for (i = 0; i < pdev->num_resources; i++) {
+ struct resource *r = &pdev->resource[i];
+
+ /* We have it, no need to touch the resources */
+ if (r->flags == IORESOURCE_DMA)
+ goto have_everything;
}
+ /* Count only DMA resources for the device */
+ res_count = omap_device_count_resources(od, IORESOURCE_DMA);
+ res_count += pdev->num_resources;
+ }
- ret = platform_device_add_resources(pdev, res, res_count);
- kfree(res);
+ /* Allocate resources memory to account for new resources */
+ res = kzalloc(sizeof(struct resource) * res_count, GFP_KERNEL);
+ if (!res)
+ goto oda_exit3;
- if (ret)
- goto oda_exit3;
+ if (!pdev->num_resources) {
+ dev_dbg(&pdev->dev, "%s: using %d resources from hwmod\n",
+ __func__, res_count);
+ omap_device_fill_resources(od, res);
+ } else {
+ dev_dbg(&pdev->dev,
+ "%s: appending %d DMA resources from hwmod\n",
+ __func__, res_count - pdev->num_resources);
+ memcpy(res, pdev->resource,
+ sizeof(struct resource) * pdev->num_resources);
+ _od_fill_dma_resources(od, &res[pdev->num_resources]);
}
+ ret = platform_device_add_resources(pdev, res, res_count);
+ kfree(res);
+
+ if (ret)
+ goto oda_exit3;
+
+have_everything:
if (!pm_lats) {
pm_lats = omap_default_latency;
pm_lats_cnt = ARRAY_SIZE(omap_default_latency);
--
1.7.12.4
^ permalink raw reply related
* [PATCH 1/2] ARM: OMAP: hwmod: Add possibility to count hwmod resources based on type
From: Peter Ujfalusi @ 2012-10-30 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351593205-13590-1-git-send-email-peter.ujfalusi@ti.com>
Add flags parameter for omap_hwmod_count_resources() so users can tell which
type of resources they are interested when counting them in hwmod database.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/mach-omap2/omap_hwmod.c | 27 ++++++++++++++++-----------
arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +-
arch/arm/plat-omap/omap_device.c | 11 ++++++++---
3 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index b969ab1..a79c941 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3337,7 +3337,7 @@ int omap_hwmod_reset(struct omap_hwmod *oh)
/**
* omap_hwmod_count_resources - count number of struct resources needed by hwmod
* @oh: struct omap_hwmod *
- * @res: pointer to the first element of an array of struct resource to fill
+ * @flags: Type of resources to include when counting (IRQ/DMA/MEM)
*
* Count the number of struct resource array elements necessary to
* contain omap_hwmod @oh resources. Intended to be called by code
@@ -3350,20 +3350,25 @@ int omap_hwmod_reset(struct omap_hwmod *oh)
* resource IDs.
*
*/
-int omap_hwmod_count_resources(struct omap_hwmod *oh)
+int omap_hwmod_count_resources(struct omap_hwmod *oh, unsigned long flags)
{
- struct omap_hwmod_ocp_if *os;
- struct list_head *p;
- int ret;
- int i = 0;
+ int ret = 0;
- ret = _count_mpu_irqs(oh) + _count_sdma_reqs(oh);
+ if (flags & IORESOURCE_IRQ)
+ ret += _count_mpu_irqs(oh);
- p = oh->slave_ports.next;
+ if (flags & IORESOURCE_DMA)
+ ret += _count_sdma_reqs(oh);
- while (i < oh->slaves_cnt) {
- os = _fetch_next_ocp_if(&p, &i);
- ret += _count_ocp_if_addr_spaces(os);
+ if (flags & IORESOURCE_MEM) {
+ int i = 0;
+ struct omap_hwmod_ocp_if *os;
+ struct list_head *p = oh->slave_ports.next;
+
+ while (i < oh->slaves_cnt) {
+ os = _fetch_next_ocp_if(&p, &i);
+ ret += _count_ocp_if_addr_spaces(os);
+ }
}
return ret;
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index b3349f7..48a6f5d 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -628,7 +628,7 @@ void omap_hwmod_write(u32 v, struct omap_hwmod *oh, u16 reg_offs);
u32 omap_hwmod_read(struct omap_hwmod *oh, u16 reg_offs);
int omap_hwmod_softreset(struct omap_hwmod *oh);
-int omap_hwmod_count_resources(struct omap_hwmod *oh);
+int omap_hwmod_count_resources(struct omap_hwmod *oh, unsigned long flags);
int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource *res);
int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource *res);
int omap_hwmod_get_resource_byname(struct omap_hwmod *oh, unsigned int type,
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 7a7d1f2..915cf68 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -442,19 +442,21 @@ int omap_device_get_context_loss_count(struct platform_device *pdev)
/**
* omap_device_count_resources - count number of struct resource entries needed
* @od: struct omap_device *
+ * @flags: Type of resources to include when counting (IRQ/DMA/MEM)
*
* Count the number of struct resource entries needed for this
* omap_device @od. Used by omap_device_build_ss() to determine how
* much memory to allocate before calling
* omap_device_fill_resources(). Returns the count.
*/
-static int omap_device_count_resources(struct omap_device *od)
+static int omap_device_count_resources(struct omap_device *od,
+ unsigned long flags)
{
int c = 0;
int i;
for (i = 0; i < od->hwmods_cnt; i++)
- c += omap_hwmod_count_resources(od->hwmods[i]);
+ c += omap_hwmod_count_resources(od->hwmods[i], flags);
pr_debug("omap_device: %s: counted %d total resources across %d hwmods\n",
od->pdev->name, c, od->hwmods_cnt);
@@ -558,7 +560,10 @@ struct omap_device *omap_device_alloc(struct platform_device *pdev,
od->hwmods = hwmods;
od->pdev = pdev;
- res_count = omap_device_count_resources(od);
+ /* Count all resources for the device */
+ res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
+ IORESOURCE_DMA |
+ IORESOURCE_MEM);
/*
* DT Boot:
* OF framework will construct the resource structure (currently
--
1.7.12.4
^ permalink raw reply related
* [PATCH 0/2] ARM: OMAP: hwmod/omapd_device: Fix for resource handling in DT boot
From: Peter Ujfalusi @ 2012-10-30 10:33 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This series resolves the issue we currently have with the resource handling when
booting with DT.
In short: at the moment the omap_device_alloc() decides if it needs to update the
OF filled resources based on the number of resources on the device and in the
hwmod database.
This prevents us from removing hwmod data for platforms (OMAP5) which does not
support non DT boot anymore.
With this series we can make sure that the DT provided resources are used and we
only append the DMA resources to the device from hwmod.
I have added extra check to prepare us when the DMA resource can be filled via
OF. In this case we do not update the resources at all.
Tony, Benoit, Paul: Not sure if this qualify for 3.7 inclusion, but for sure
going to help us to clean up the OMAP5 hwmod database.
Regards,
Peter
---
Peter Ujfalusi (2):
ARM: OMAP: hwmod: Add possibility to count hwmod resources based on
type
ARM: OMAP: omap_device: Correct resource handling for DT boot
arch/arm/mach-omap2/omap_hwmod.c | 27 +++++----
arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +-
arch/arm/plat-omap/omap_device.c | 83 +++++++++++++++++-----------
3 files changed, 68 insertions(+), 44 deletions(-)
--
1.7.12.4
^ permalink raw reply
* [PATCH v3 10/10] net/macb: add pinctrl consumer support
From: Nicolas Ferre @ 2012-10-30 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351591858.git.nicolas.ferre@atmel.com>
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
If no pinctrl available just report a warning as some architecture may not
need to do anything.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
[nicolas.ferre at atmel.com: adapt the error path]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: netdev at vger.kernel.org
---
drivers/net/ethernet/cadence/macb.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 4d51877..eae3d74 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -26,6 +26,9 @@
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/of_net.h>
+#include <linux/of_gpio.h>
+#include <linux/gpio.h>
+#include <linux/pinctrl/consumer.h>
#include "macb.h"
@@ -1472,6 +1475,7 @@ static int __init macb_probe(struct platform_device *pdev)
struct phy_device *phydev;
u32 config;
int err = -ENXIO;
+ struct pinctrl *pinctrl;
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!regs) {
@@ -1479,6 +1483,15 @@ static int __init macb_probe(struct platform_device *pdev)
goto err_out;
}
+ pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+ if (IS_ERR(pinctrl)) {
+ err = PTR_ERR(pinctrl);
+ if (err == -EPROBE_DEFER)
+ goto err_out;
+
+ dev_warn(&pdev->dev, "No pinctrl provided\n");
+ }
+
err = -ENOMEM;
dev = alloc_etherdev(sizeof(*bp));
if (!dev)
--
1.8.0
^ permalink raw reply related
* [PATCH v3 09/10] net/macb: Offset first RX buffer by two bytes
From: Nicolas Ferre @ 2012-10-30 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351591858.git.nicolas.ferre@atmel.com>
From: Havard Skinnemoen <havard@skinnemoen.net>
Make the ethernet frame payload word-aligned, possibly making the
memcpy into the skb a bit faster. This will be even more important
after we eliminate the copy altogether.
Also eliminate the redundant RX_OFFSET constant -- it has the same
definition and purpose as NET_IP_ALIGN.
Signed-off-by: Havard Skinnemoen <havard@skinnemoen.net>
[nicolas.ferre at atmel.com: adapt to newer kernel]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/net/ethernet/cadence/macb.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 83aa834..4d51877 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -33,9 +33,6 @@
#define RX_RING_SIZE 512
#define RX_RING_BYTES (sizeof(struct macb_dma_desc) * RX_RING_SIZE)
-/* Make the IP header word-aligned (the ethernet header is 14 bytes) */
-#define RX_OFFSET 2
-
#define TX_RING_SIZE 128
#define TX_RING_BYTES (sizeof(struct macb_dma_desc) * TX_RING_SIZE)
@@ -498,7 +495,7 @@ static int macb_rx_frame(struct macb *bp, unsigned int first_frag,
{
unsigned int len;
unsigned int frag;
- unsigned int offset = 0;
+ unsigned int offset;
struct sk_buff *skb;
struct macb_dma_desc *desc;
@@ -509,7 +506,16 @@ static int macb_rx_frame(struct macb *bp, unsigned int first_frag,
macb_rx_ring_wrap(first_frag),
macb_rx_ring_wrap(last_frag), len);
- skb = netdev_alloc_skb(bp->dev, len + RX_OFFSET);
+ /*
+ * The ethernet header starts NET_IP_ALIGN bytes into the
+ * first buffer. Since the header is 14 bytes, this makes the
+ * payload word-aligned.
+ *
+ * Instead of calling skb_reserve(NET_IP_ALIGN), we just copy
+ * the two padding bytes into the skb so that we avoid hitting
+ * the slowpath in memcpy(), and pull them off afterwards.
+ */
+ skb = netdev_alloc_skb(bp->dev, len + NET_IP_ALIGN);
if (!skb) {
bp->stats.rx_dropped++;
for (frag = first_frag; ; frag++) {
@@ -525,7 +531,8 @@ static int macb_rx_frame(struct macb *bp, unsigned int first_frag,
return 1;
}
- skb_reserve(skb, RX_OFFSET);
+ offset = 0;
+ len += NET_IP_ALIGN;
skb_checksum_none_assert(skb);
skb_put(skb, len);
@@ -549,10 +556,11 @@ static int macb_rx_frame(struct macb *bp, unsigned int first_frag,
/* Make descriptor updates visible to hardware */
wmb();
+ __skb_pull(skb, NET_IP_ALIGN);
skb->protocol = eth_type_trans(skb, bp->dev);
bp->stats.rx_packets++;
- bp->stats.rx_bytes += len;
+ bp->stats.rx_bytes += skb->len;
netdev_vdbg(bp->dev, "received skb of length %u, csum: %08x\n",
skb->len, skb->csum);
netif_receive_skb(skb);
@@ -1012,6 +1020,7 @@ static void macb_init_hw(struct macb *bp)
__macb_set_hwaddr(bp);
config = macb_mdc_clk_div(bp);
+ config |= MACB_BF(RBOF, NET_IP_ALIGN); /* Make eth data aligned */
config |= MACB_BIT(PAE); /* PAuse Enable */
config |= MACB_BIT(DRFCS); /* Discard Rx FCS */
config |= MACB_BIT(BIG); /* Receive oversized frames */
--
1.8.0
^ permalink raw reply related
* [PATCH v3 08/10] net/macb: better manage tx errors
From: Nicolas Ferre @ 2012-10-30 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351591858.git.nicolas.ferre@atmel.com>
Handle all TX errors, not only underruns. TX error management is
deferred to a dedicated workqueue.
Reinitialize the TX ring after treating all remaining frames, and
restart the controller when everything has been cleaned up properly.
Napi is not stopped during this task as the driver only handles
napi for RX for now.
With this sequence, we do not need a special check during the xmit
method as the packets will be caught by TX disable during workqueue
execution.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/net/ethernet/cadence/macb.c | 166 ++++++++++++++++++++++++------------
drivers/net/ethernet/cadence/macb.h | 1 +
2 files changed, 113 insertions(+), 54 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index ce29741..83aa834 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -44,6 +44,16 @@
#define MACB_RX_INT_FLAGS (MACB_BIT(RCOMP) | MACB_BIT(RXUBR) \
| MACB_BIT(ISR_ROVR))
+#define MACB_TX_ERR_FLAGS (MACB_BIT(ISR_TUND) \
+ | MACB_BIT(ISR_RLE) \
+ | MACB_BIT(TXERR))
+#define MACB_TX_INT_FLAGS (MACB_TX_ERR_FLAGS | MACB_BIT(TCOMP))
+
+/*
+ * Graceful stop timeouts in us. We should allow up to
+ * 1 frame time (10 Mbits/s, full-duplex, ignoring collisions)
+ */
+#define MACB_HALT_TIMEOUT 1230
/* Ring buffer accessors */
static unsigned int macb_tx_ring_wrap(unsigned int index)
@@ -339,66 +349,113 @@ static void macb_update_stats(struct macb *bp)
*p += __raw_readl(reg);
}
-static void macb_tx(struct macb *bp)
+static int macb_halt_tx(struct macb *bp)
{
- unsigned int tail;
- unsigned int head;
- u32 status;
+ unsigned long halt_time, timeout;
+ u32 status;
- status = macb_readl(bp, TSR);
- macb_writel(bp, TSR, status);
+ macb_writel(bp, NCR, macb_readl(bp, NCR) | MACB_BIT(THALT));
- netdev_vdbg(bp->dev, "macb_tx status = 0x%03lx\n", (unsigned long)status);
+ timeout = jiffies + usecs_to_jiffies(MACB_HALT_TIMEOUT);
+ do {
+ halt_time = jiffies;
+ status = macb_readl(bp, TSR);
+ if (!(status & MACB_BIT(TGO)))
+ return 0;
- if (status & (MACB_BIT(UND) | MACB_BIT(TSR_RLE))) {
- int i;
- netdev_err(bp->dev, "TX %s, resetting buffers\n",
- status & MACB_BIT(UND) ?
- "underrun" : "retry limit exceeded");
+ usleep_range(10, 250);
+ } while (time_before(halt_time, timeout));
- /* Transfer ongoing, disable transmitter, to avoid confusion */
- if (status & MACB_BIT(TGO))
- macb_writel(bp, NCR, macb_readl(bp, NCR) & ~MACB_BIT(TE));
+ return -ETIMEDOUT;
+}
- head = bp->tx_head;
+static void macb_tx_error_task(struct work_struct *work)
+{
+ struct macb *bp = container_of(work, struct macb, tx_error_task);
+ struct macb_tx_skb *tx_skb;
+ struct sk_buff *skb;
+ unsigned int tail;
- /*Mark all the buffer as used to avoid sending a lost buffer*/
- for (i = 0; i < TX_RING_SIZE; i++)
- bp->tx_ring[i].ctrl = MACB_BIT(TX_USED);
+ netdev_vdbg(bp->dev, "macb_tx_error_task: t = %u, h = %u\n",
+ bp->tx_tail, bp->tx_head);
- /* Add wrap bit */
- bp->tx_ring[TX_RING_SIZE - 1].ctrl |= MACB_BIT(TX_WRAP);
+ /* Make sure nobody is trying to queue up new packets */
+ netif_stop_queue(bp->dev);
- /* free transmit buffer in upper layer*/
- for (tail = bp->tx_tail; tail != head; tail++) {
- struct macb_tx_skb *tx_skb;
- struct sk_buff *skb;
+ /*
+ * Stop transmission now
+ * (in case we have just queued new packets)
+ */
+ if (macb_halt_tx(bp))
+ /* Just complain for now, reinitializing TX path can be good */
+ netdev_err(bp->dev, "BUG: halt tx timed out\n");
- rmb();
+ /* No need for the lock here as nobody will interrupt us anymore */
- tx_skb = macb_tx_skb(bp, tail);
- skb = tx_skb->skb;
+ /*
+ * Treat frames in TX queue including the ones that caused the error.
+ * Free transmit buffers in upper layer.
+ */
+ for (tail = bp->tx_tail; tail != bp->tx_head; tail++) {
+ struct macb_dma_desc *desc;
+ u32 ctrl;
- dma_unmap_single(&bp->pdev->dev, tx_skb->mapping,
- skb->len, DMA_TO_DEVICE);
- tx_skb->skb = NULL;
- dev_kfree_skb_irq(skb);
- }
+ desc = macb_tx_desc(bp, tail);
+ ctrl = desc->ctrl;
+ tx_skb = macb_tx_skb(bp, tail);
+ skb = tx_skb->skb;
- bp->tx_head = bp->tx_tail = 0;
+ if (ctrl & MACB_BIT(TX_USED)) {
+ netdev_vdbg(bp->dev, "txerr skb %u (data %p) TX complete\n",
+ macb_tx_ring_wrap(tail), skb->data);
+ bp->stats.tx_packets++;
+ bp->stats.tx_bytes += skb->len;
+ } else {
+ /*
+ * "Buffers exhausted mid-frame" errors may only happen
+ * if the driver is buggy, so complain loudly about those.
+ * Statistics are updated by hardware.
+ */
+ if (ctrl & MACB_BIT(TX_BUF_EXHAUSTED))
+ netdev_err(bp->dev,
+ "BUG: TX buffers exhausted mid-frame\n");
- /* Enable the transmitter again */
- if (status & MACB_BIT(TGO))
- macb_writel(bp, NCR, macb_readl(bp, NCR) | MACB_BIT(TE));
+ desc->ctrl = ctrl | MACB_BIT(TX_USED);
+ }
+
+ dma_unmap_single(&bp->pdev->dev, tx_skb->mapping, skb->len,
+ DMA_TO_DEVICE);
+ tx_skb->skb = NULL;
+ dev_kfree_skb(skb);
}
- if (!(status & MACB_BIT(COMP)))
- /*
- * This may happen when a buffer becomes complete
- * between reading the ISR and scanning the
- * descriptors. Nothing to worry about.
- */
- return;
+ /* Make descriptor updates visible to hardware */
+ wmb();
+
+ /* Reinitialize the TX desc queue */
+ macb_writel(bp, TBQP, bp->tx_ring_dma);
+ /* Make TX ring reflect state of hardware */
+ bp->tx_head = bp->tx_tail = 0;
+
+ /* Now we are ready to start transmission again */
+ netif_wake_queue(bp->dev);
+
+ /* Housework before enabling TX IRQ */
+ macb_writel(bp, TSR, macb_readl(bp, TSR));
+ macb_writel(bp, IER, MACB_TX_INT_FLAGS);
+}
+
+static void macb_tx_interrupt(struct macb *bp)
+{
+ unsigned int tail;
+ unsigned int head;
+ u32 status;
+
+ status = macb_readl(bp, TSR);
+ macb_writel(bp, TSR, status);
+
+ netdev_vdbg(bp->dev, "macb_tx_interrupt status = 0x%03lx\n",
+ (unsigned long)status);
head = bp->tx_head;
for (tail = bp->tx_tail; tail != head; tail++) {
@@ -638,9 +695,14 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)
}
}
- if (status & (MACB_BIT(TCOMP) | MACB_BIT(ISR_TUND) |
- MACB_BIT(ISR_RLE)))
- macb_tx(bp);
+ if (unlikely(status & (MACB_TX_ERR_FLAGS))) {
+ macb_writel(bp, IDR, MACB_TX_INT_FLAGS);
+ schedule_work(&bp->tx_error_task);
+ break;
+ }
+
+ if (status & MACB_BIT(TCOMP))
+ macb_tx_interrupt(bp);
/*
* Link change detection isn't possible with RMII, so we'll
@@ -970,13 +1032,8 @@ static void macb_init_hw(struct macb *bp)
macb_writel(bp, NCR, MACB_BIT(RE) | MACB_BIT(TE) | MACB_BIT(MPE));
/* Enable interrupts */
- macb_writel(bp, IER, (MACB_BIT(RCOMP)
- | MACB_BIT(RXUBR)
- | MACB_BIT(ISR_TUND)
- | MACB_BIT(ISR_RLE)
- | MACB_BIT(TXERR)
- | MACB_BIT(TCOMP)
- | MACB_BIT(ISR_ROVR)
+ macb_writel(bp, IER, (MACB_RX_INT_FLAGS
+ | MACB_TX_INT_FLAGS
| MACB_BIT(HRESP)));
}
@@ -1428,6 +1485,7 @@ static int __init macb_probe(struct platform_device *pdev)
bp->dev = dev;
spin_lock_init(&bp->lock);
+ INIT_WORK(&bp->tx_error_task, macb_tx_error_task);
bp->pclk = clk_get(&pdev->dev, "pclk");
if (IS_ERR(bp->pclk)) {
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 232dca6..4235ab8 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -538,6 +538,7 @@ struct macb {
struct clk *hclk;
struct net_device *dev;
struct napi_struct napi;
+ struct work_struct tx_error_task;
struct net_device_stats stats;
union {
struct macb_stats macb;
--
1.8.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox