* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Sebastian Hesselbarth @ 2013-01-27 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127110857.GA23687@schnuecks.de>
On 01/27/2013 12:08 PM, Simon Baatz wrote:
> On Sun, Jan 27, 2013 at 11:52:41AM +0100, Sebastian Hesselbarth wrote:
>> Jason posted a patch set that makes mv643xx DT compatible. IMHO this
>> patch is obsolete when we have DT support for mv643xx.
>> kirkwood_ge00/01_init will not be called with DT support at all.
>
> I know. This is to fix a regression in 3.8 (which currently does not
> boot with my "modularized" config).
Well, patching kirkwood_ge00/01_init() will also affect non-DT code
so there is a great potential to break something else.
If it is a DT-only issue please move the "always enable ge clocks"
fix to kirkwood_clk_legacy_init() as it only called by DT enabled
boards.
If there is no other issue than keeping the clocks running because
of not loosing the MAC address, I prefer not to fix it at all.
Looks like modular gbe on kirkwood is just unsupported on 3.8.
Sebastian
^ permalink raw reply
* [PATCH v3 0/9] ARM: S3C24XX: rework irq handling for a later dt usage
From: Heiko Stübner @ 2013-01-27 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <016101cdfb2e$15cbd640$416382c0$@samsung.com>
Am Freitag, 25. Januar 2013, 19:59:18 schrieb Kukjin Kim:
> Heiko St?bner wrote:
> > Third version of redoing the s3c24xx irqs in a generic way by using a
> > declarative approach.
> >
> > Main change is the different approach to the init. Moved the
> > s3c24xx_init_intc function from the dt patchset here, so that both init
> > types (dt and non-dt) can use a similar init scheme.
> >
> > As in the second version, the 1st patch might be hard to read due to the
> > rewrite character, but I didn't see a way to do these changes in
> > individual steps. So it might be helpful to look at the result after
> > applying this patch.
> >
> > Runtime-tested on a s3c2416 based board and compile tested for the
> > others.
> >
> > As also written before, inclusion of the other S3C24XX SoCs to follow
> > once the general approach is acceptable.
> >
> > Applies to the most current for-next (from two hours ago) from linux-
> > samsung
> >
> > Heiko Stuebner (9):
> > ARM: S3C24XX: transform irq handling into a declarative form
> > ARM: S3C24XX: Move irq syscore-ops to irq-pm
> > ARM: S3C24XX: Modify s3c_irq_wake to use the hwirq property
> > ARM: S3C24XX: move s3c2416 irq init to common irq code
> > ARM: S3C24XX: modify s3c2416 irq init to initialize all irqs
> > ARM: S3C24XX: transform s3c2416 irqs into new structure
> > ARM: S3C24XX: move s3c2443 irq code to irq.c
> > ARM: S3C24XX: modify s3c2443 irq init to initialize all irqs
> > ARM: S3C24XX: transform s3c2443 subirqs into new structure
> >
> > arch/arm/mach-s3c24xx/Makefile | 4 +-
> > arch/arm/mach-s3c24xx/common.h | 2 +
> > arch/arm/mach-s3c24xx/irq-pm.c | 41 +-
> > arch/arm/mach-s3c24xx/irq-s3c2416.c | 348 --------
> > arch/arm/mach-s3c24xx/irq-s3c2443.c | 281 -------
> > arch/arm/mach-s3c24xx/mach-smdk2416.c | 2 +-
> > arch/arm/mach-s3c24xx/mach-smdk2443.c | 2 +-
> > arch/arm/mach-s3c24xx/s3c2410.c | 4 +-
> > arch/arm/mach-s3c24xx/s3c2412.c | 4 +-
> > arch/arm/mach-s3c24xx/s3c2416.c | 4 +-
> > arch/arm/mach-s3c24xx/s3c2440.c | 4 +-
> > arch/arm/mach-s3c24xx/s3c2442.c | 4 +-
> > arch/arm/plat-s3c24xx/Kconfig | 1 +
> > arch/arm/plat-s3c24xx/irq.c | 1110
> > +++++++++++++++----------- arch/arm/plat-samsung/include/plat/pm.h
> > | 6 -
> > arch/arm/plat-samsung/include/plat/s3c2416.h | 1 +
> > arch/arm/plat-samsung/include/plat/s3c2443.h | 2 +
> > 17 files changed, 688 insertions(+), 1132 deletions(-)
> > delete mode 100644 arch/arm/mach-s3c24xx/irq-s3c2416.c
> > delete mode 100644 arch/arm/mach-s3c24xx/irq-s3c2443.c
> >
> > --
> > 1.7.2.3
>
> Heiko, looks good to me :-)
very cool :-)
> BTW, can you rebase this against on next/cleanup-s3c24xx branch in my tree?
will try to do this today
Heiko
^ permalink raw reply
* [PATCH 6/6 v14] gpio: Add block gpio to several gpio drivers
From: Stijn Devriendt @ 2013-01-27 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510126E7.5090802@antcom.de>
On Thu, Jan 24, 2013 at 1:19 PM, Roland Stigge <stigge@antcom.de> wrote:
> On 01/24/2013 01:02 PM, Stijn Devriendt wrote:
>>> +static void lpc32xx_gpio_set_block_p3(struct gpio_chip *chip,
>>> + unsigned long mask,
>>> + unsigned long values)
>>> +{
>>> + struct lpc32xx_gpio_chip *group = to_lpc32xx_gpio(chip);
>>> + u32 set_bits = values & mask;
>>> + u32 clr_bits = ~values & mask;
>>> +
>>> + /* States of GPIO 0-5 start at bit 25 */
>>> + set_bits <<= 25;
>>> + clr_bits <<= 25;
>>> +
>>> + /* Note: On LPC32xx, GPOs can only be set at once or cleared at once,
>>> + * but not set and cleared at once
>>> + */
>>> + if (set_bits)
>>> + __raw_writel(set_bits, group->gpio_grp->outp_set);
>>> + if (clr_bits)
>>> + __raw_writel(clr_bits, group->gpio_grp->outp_clr);
>>> +}
>>> +
>>
>> In my patch, I go out of the way of this kind of thing for a simple reason:
>> You may generate incorrect timing by doing this.
>
> You are right, certain things like synchronous on+off is not really
> possible.
>
> However, the above at least supports switching on simulaneously, and
> switching off simultaneously, which is an improvement in certain cases
> (and this certain hardware part doesn't support more). Maybe this
> certain driver behaviour can be documented even better than just in the
> driver source.
>
The question here is: do you expect a user of the block-GPIO API to
go look into the base-driver code to see what will be supported?
In my version of the patch this means:
- do not provide a single GPIO-block that crosses multiple base-drivers
- only provide gpio_block_get/set for GPIO drivers that support the complete
operation in a single go. (for example, in the above example there would be
no gpio_block_set() function)
Perhaps the best approach is to make this explicit: Allow drivers to expose
their capabilities wrt timing and allow users to request strict-timing or
loose-timing. Loose-timing allows multiple gpio-drivers to be combined and
allows drivers with separate set/clear, hi/lo registers to be used.
Of course, for a first version you may as well leave it out. Perhaps the
use-cases for cross-GPIO-driver blocks are not worth the extra complexity
as of today?
Regards,
Stijn
> If there is consensus that everything else in the patch set is settled,
> and we just don't want to support behaviour like the above - well, we
> can still drop it.
>
> Thanks for the note,
>
> Roland
>
^ permalink raw reply
* [PATCH V3 8/8] ARM: kirkwood: mv643xx_eth dt conversion
From: Russell King - ARM Linux @ 2013-01-27 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130126134012.GE29973@lunn.ch>
On Sat, Jan 26, 2013 at 02:40:12PM +0100, Andrew Lunn wrote:
> On Sat, Jan 26, 2013 at 01:50:11PM +0100, Sebastian Hesselbarth wrote:
> The code here is based on dove_legacy_clk_init(). However the change
> made by Jason is in order to make a DT device work, not an non-DT
> device.
>
> The problem is the way the driver is getting the clock.
>
> mp->clk = clk_get(&pdev->dev, (pdev->id ? "1" : "0"));
>
> clk_get() then calls
>
> clk = of_clk_get_by_name(dev->of_node, con_id);
>
> * of_clk_get_by_name() - Parse and lookup a clock referenced by a device node
> * @np: pointer to clock consumer node
> * @name: name of consumer's clock input, or NULL for the first clock reference
>
> So it is looking for a clock called "0" or "1" in the node. This does
> not exist, and so it falls. Jason's change then comes into affect and
> it finds the clkdev entries added above.
This is just bollocks. Sorry, but it is. Yet again, people misunderstand
the clk API...
Look, the clk API is very simple, as it also is when using clkdev or OF.
Stop naming your bloody clocks individually - whenever anyone does that
it all breaks.
The API is designed to work as follows:
FIRST argument to clk_get() is the struct device. This _SHOULD_ be used
to determine the clock or set of clocks which the device is going to use.
In other words, it is the PRIMARY key in the lookup.
SECOND argument to clk_get() identifies the CONNECTION ON THE DEVICE
passed as the first argument. To make this point, if the device only
ever has one clock connection, convention is to pass NULL to ensure that
people do _not_ think that they can use global clock names.
So, the whole:
mp->clk = clk_get(&pdev->dev, (pdev->id ? "1" : "0"));
is absolutely ludicrous. You already know which device it is by means of
the first argument. You don't need to pass a "0" or a "1". So that should
be NULL, so:
mp->clk = clk_get(&pdev->dev, NULL);
That will get a clock from clkdev which is setup in the _matching_ tables
to correlate with the device (and a NULL connection ID _there_ too). With
OF, I believe it will get the first clock.
^ permalink raw reply
* [PATCH 5/6 v14] gpio: Add device tree support to block GPIO API
From: Stijn Devriendt @ 2013-01-27 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358856404-8975-6-git-send-email-stigge@antcom.de>
On Tue, Jan 22, 2013 at 1:06 PM, Roland Stigge <stigge@antcom.de> wrote:
> This patch adds device tree support to the block GPIO API.
>
> Signed-off-by: Roland Stigge <stigge@antcom.de>
>
> ---
> Documentation/devicetree/bindings/gpio/gpio-block.txt | 36 ++++++
> drivers/gpio/Makefile | 1
> drivers/gpio/gpioblock-of.c | 100 ++++++++++++++++++
> 3 files changed, 137 insertions(+)
>
> --- /dev/null
> +++ linux-2.6/Documentation/devicetree/bindings/gpio/gpio-block.txt
> @@ -0,0 +1,36 @@
> +Block GPIO definition
> +=====================
> +
> +This binding specifies arbitrary blocks of gpios, combining gpios from one or
> +more GPIO controllers together, to form a word for r/w access.
> +
> +Required property:
> +- compatible: must be "linux,gpio-block"
> +
> +Required subnodes:
> +- the name will be the registered name of the block
> +- property "gpios" is a list of gpios for the respective block
> +
> +Example:
> +
> + blockgpio {
> + compatible = "linux,gpio-block";
> +
> + block0 {
> + gpios = <&gpio 3 0 0>,
> + <&gpio 3 1 0>;
> + };
> + block1 {
> + gpios = <&gpio 4 1 0>,
> + <&gpio 4 3 0>,
> + <&gpio 4 2 0>,
> + <&gpio 4 4 0>,
> + <&gpio 4 5 0>,
> + <&gpio 4 6 0>,
> + <&gpio 4 7 0>,
> + <&gpio 4 8 0>,
> + <&gpio 4 9 0>,
> + <&gpio 4 10 0>,
> + <&gpio 4 19 0>;
> + };
> + };
How do you see bindings for other kinds of drivers?
In my patchset, it's possible for other drivers to use gpio-blocks.
One example we have is a power sequencer with 2 pins attached
to GPIO pins. These 2 pins form a 2bit word to select power margining.
These 2 pins need to be set synchronously (as otherwise when going
from profile 0 to profile 3 you pass either profile 1 or profile 2 which
could be bad for hardware)
In the device-tree this is specified as:
powr at 0x20 {
// other properties
gpios = <&gpio 4 0
&gpio 5 0>;
};
Is this kind of integration also possible?
Regards,
Stijn
> --- linux-2.6.orig/drivers/gpio/Makefile
> +++ linux-2.6/drivers/gpio/Makefile
> @@ -5,6 +5,7 @@ ccflags-$(CONFIG_DEBUG_GPIO) += -DDEBUG
> obj-$(CONFIG_GPIOLIB) += gpiolib.o devres.o
> obj-$(CONFIG_OF_GPIO) += gpiolib-of.o
> obj-$(CONFIG_GPIO_ACPI) += gpiolib-acpi.o
> +obj-$(CONFIG_OF_GPIO) += gpioblock-of.o
>
> # Device drivers. Generally keep list sorted alphabetically
> obj-$(CONFIG_GPIO_GENERIC) += gpio-generic.o
> --- /dev/null
> +++ linux-2.6/drivers/gpio/gpioblock-of.c
> @@ -0,0 +1,100 @@
> +/*
> + * OF implementation for Block GPIO
> + *
> + * Copyright (C) 2012 Roland Stigge <stigge@antcom.de>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/gpio.h>
> +#include <linux/of.h>
> +#include <linux/of_gpio.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/err.h>
> +
> +static int gpioblock_of_probe(struct platform_device *pdev)
> +{
> + struct device_node *block;
> + unsigned *gpios;
> + int ngpio;
> + int ret;
> + struct gpio_block *gb;
> +
> + for_each_available_child_of_node(pdev->dev.of_node, block) {
> + int i;
> +
> + ngpio = of_gpio_count(block);
> + if (ngpio < 1) {
> + ret = -ENODEV;
> + goto err1;
> + }
> +
> + gpios = kzalloc(ngpio * sizeof(*gpios), GFP_KERNEL);
> + if (!gpios) {
> + ret = -ENOMEM;
> + goto err1;
> + }
> +
> + for (i = 0; i < ngpio; i++) {
> + ret = of_get_gpio(block, i);
> + if (ret < 0)
> + goto err2; /* expect -EPROBE_DEFER */
> + gpios[i] = ret;
> + }
> + gb = gpio_block_create(gpios, ngpio, block->name);
> + if (IS_ERR(gb)) {
> + dev_err(&pdev->dev,
> + "Error creating GPIO block from device tree\n");
> + ret = PTR_ERR(gb);
> + goto err2;
> + }
> + ret = gpio_block_register(gb);
> + if (ret < 0)
> + goto err3;
> +
> + kfree(gpios);
> + dev_info(&pdev->dev, "Registered gpio block %s: %d gpios\n",
> + block->name, ngpio);
> + }
> + return 0;
> +
> +err3:
> + gpio_block_free(gb);
> +err2:
> + kfree(gpios);
> +err1:
> + of_node_put(block);
> + return ret;
> +}
> +
> +#ifdef CONFIG_OF
> +static struct of_device_id gpioblock_of_match[] = {
> + { .compatible = "linux,gpio-block", },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, gpioblock_of_match);
> +#endif
> +
> +static struct platform_driver gpioblock_of_driver = {
> + .driver = {
> + .name = "gpio-block",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(gpioblock_of_match),
> +
> + },
> + .probe = gpioblock_of_probe,
> +};
> +
> +module_platform_driver(gpioblock_of_driver);
> +
> +MODULE_DESCRIPTION("GPIO Block driver");
> +MODULE_AUTHOR("Roland Stigge <stigge@antcom.de>");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:gpioblock-of");
^ permalink raw reply
* [PATCH V3 8/8] ARM: kirkwood: mv643xx_eth dt conversion
From: Sebastian Hesselbarth @ 2013-01-27 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127122119.GF23505@n2100.arm.linux.org.uk>
On 01/27/2013 01:21 PM, Russell King - ARM Linux wrote:
> On Sat, Jan 26, 2013 at 02:40:12PM +0100, Andrew Lunn wrote:
>> On Sat, Jan 26, 2013 at 01:50:11PM +0100, Sebastian Hesselbarth wrote:
>> The code here is based on dove_legacy_clk_init(). However the change
>> made by Jason is in order to make a DT device work, not an non-DT
>> device.
>>
>> The problem is the way the driver is getting the clock.
>>
>> mp->clk = clk_get(&pdev->dev, (pdev->id ? "1" : "0"));
>>
> ...
> So, the whole:
>
> mp->clk = clk_get(&pdev->dev, (pdev->id ? "1" : "0"));
>
> is absolutely ludicrous. You already know which device it is by means of
> the first argument. You don't need to pass a "0" or a "1". So that should
> be NULL, so:
>
> mp->clk = clk_get(&pdev->dev, NULL);
>
> That will get a clock from clkdev which is setup in the _matching_ tables
> to correlate with the device (and a NULL connection ID _there_ too). With
> OF, I believe it will get the first clock.
The conid was set for mv643xx but shouldn't be set anymore - check
mach-kirkwood/common.c. From what I can tell, powerpc isn't using
common clock at all and orion5x/mv78x00 don't have any clock gates.
I guess we can just remove the conid check and rely on DT passed
clock only.
Sebastian
^ permalink raw reply
* [PATCH 1/6 v14] gpio: Add a block GPIO API to gpiolib
From: Stijn Devriendt @ 2013-01-27 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358856404-8975-2-git-send-email-stigge@antcom.de>
On Tue, Jan 22, 2013 at 1:06 PM, Roland Stigge <stigge@antcom.de> wrote:
> The recurring task of providing simultaneous access to GPIO lines (especially
> for bit banging protocols) needs an appropriate API.
>
> This patch adds a kernel internal "Block GPIO" API that enables simultaneous
> access to several GPIOs. This is done by abstracting GPIOs to an n-bit word:
> Once requested, it provides access to a group of GPIOs which can range over
> multiple GPIO chips.
>
> Signed-off-by: Roland Stigge <stigge@antcom.de>
> ---
>
> Documentation/gpio.txt | 58 +++++++++++
> drivers/gpio/gpiolib.c | 227 +++++++++++++++++++++++++++++++++++++++++++++
> include/asm-generic/gpio.h | 17 +++
> include/linux/gpio.h | 97 +++++++++++++++++++
> 4 files changed, 399 insertions(+)
>
> --- linux-2.6.orig/Documentation/gpio.txt
> +++ linux-2.6/Documentation/gpio.txt
> @@ -481,6 +481,64 @@ exact name string of pinctrl device has
> argument to this routine.
>
>
> +Block GPIO
> +----------
> +
> +The above described interface concentrates on handling single GPIOs. However,
> +in applications where it is critical to set several GPIOs at once, this
> +interface doesn't work well, e.g. bit-banging protocols via grouped GPIO lines.
> +Consider a GPIO controller that is connected via a slow I2C line. When
> +switching two or more GPIOs one after another, there can be considerable time
> +between those events. This is solved by an interface called Block GPIO:
> +
> +struct gpio_block *gpio_block_create(unsigned int *gpios, size_t size,
> + const char *name);
> +
> +This creates a new block of GPIOs as a list of GPIO numbers with the specified
> +size which are accessible via the returned struct gpio_block and the accessor
> +functions described below. Please note that you need to request the GPIOs
> +separately via gpio_request(). Similarly, the direction of the used GPIOs need
> +to be set by the user before using the block.
Is there anything holding you back from letting gpio_block_create() do
the request
for all the pins?
Also, wouldn't it make sense to have a gpio_block_direction_input()
and _output()
variant? On the other hand, for things like I2C and SPI emulation,
some pins will
naturally be always output (like clock lines) while other could be
switched between
in and output (like the i2c data line).
Regards,
Stijn
> +An arbitrary list of globally
> +valid GPIOs can be specified, even ranging over several gpio_chips. Actual
> +handling of I/O operations will be done on a best effort base, i.e.
> +simultaneous I/O only where possible by hardware and implemented in the
> +respective GPIO driver. The number of GPIOs in one block is limited to the
> +number of bits in an unsigned long, or BITS_PER_LONG, of the respective
> +platform, i.e. typically at least 32 on a 32 bit system, and at least 64 on a
> +64 bit system. However, several blocks can be defined at once.
> +
> +unsigned long gpio_block_get(struct gpio_block *block, unsigned long mask);
> +void gpio_block_set(struct gpio_block *block, unsigned long mask,
> + unsigned long values);
> +
> +With those accessor functions, setting and getting the GPIO values is possible,
> +analogous to gpio_get_value() and gpio_set_value(). Each bit in the return
> +value of gpio_block_get() and in the value argument of gpio_block_set()
> +corresponds to a bit specified on gpio_block_create(). The mask parameters
> +specify which bits in the block are acted upon. This is useful to let some bits
> +untouched when doing a set operation on the block.
> +
> +Block operations in hardware are only possible where the respective GPIO driver
> +implements it, falling back to using single GPIO operations where the driver
> +only implements single GPIO access.
> +
> +If a GPIO block includes GPIOs from several chips, the chips are handled one
> +after another in the order of first specification in the list of GPIOs defined
> +in the GPIO block, starting with bit 0. Note that in this case, you typically
> +can't assume simultaneous access.
> +
> +void gpio_block_free(struct gpio_block *block);
> +
> +After the GPIO block isn't used anymore, it should be free'd via
> +gpio_block_free().
> +
> +int gpio_block_register(struct gpio_block *block);
> +void gpio_block_unregister(struct gpio_block *block);
> +
> +These functions can be used to register a GPIO block. Blocks registered this
> +way will be available via userspace API.
> +
> +
> What do these conventions omit?
> ===============================
> One of the biggest things these conventions omit is pin multiplexing, since
> --- linux-2.6.orig/drivers/gpio/gpiolib.c
> +++ linux-2.6/drivers/gpio/gpiolib.c
> @@ -83,6 +83,8 @@ static inline void desc_set_label(struct
> #endif
> }
>
> +static LIST_HEAD(gpio_block_list);
> +
> /* Warn when drivers omit gpio_request() calls -- legal but ill-advised
> * when setting direction, and otherwise illegal. Until board setup code
> * and drivers use explicit requests everywhere (which won't happen when
> @@ -217,6 +219,16 @@ static int gpio_get_direction(unsigned g
> return status;
> }
>
> +static bool gpio_block_is_output(struct gpio_block *block)
> +{
> + int i;
> +
> + for (i = 0; i < block->ngpio; i++)
> + if (!test_bit(FLAG_IS_OUT, &gpio_desc[block->gpio[i]].flags))
> + return false;
> + return true;
> +}
> +
> #ifdef CONFIG_GPIO_SYSFS
>
> /* lock protects against unexport_gpio() being called while
> @@ -1799,6 +1811,221 @@ void __gpio_set_value(unsigned gpio, int
> }
> EXPORT_SYMBOL_GPL(__gpio_set_value);
>
> +static struct gpio_block_chip *gpio_block_chip_get(struct gpio_block *block,
> + struct gpio_chip *gc)
> +{
> + struct gpio_block_chip *i;
> +
> + list_for_each_entry(i, &block->gbc_list, list)
> + if (i->gc == gc)
> + return i;
> + return NULL;
> +}
> +
> +struct gpio_block *gpio_block_create(unsigned *gpios, size_t size,
> + const char *name)
> +{
> + struct gpio_block *block;
> + struct gpio_block_chip *gbc;
> + struct gpio_remap *remap;
> + int i;
> +
> + if (size < 1 || size > BITS_PER_LONG)
> + return ERR_PTR(-EINVAL);
> +
> + for (i = 0; i < size; i++)
> + if (!gpio_is_valid(gpios[i]))
> + return ERR_PTR(-EINVAL);
> +
> + block = kzalloc(sizeof(struct gpio_block), GFP_KERNEL);
> + if (!block)
> + return ERR_PTR(-ENOMEM);
> +
> + block->name = name;
> + block->ngpio = size;
> + INIT_LIST_HEAD(&block->gbc_list);
> + block->gpio = kzalloc(sizeof(*block->gpio) * size, GFP_KERNEL);
> + if (!block->gpio)
> + goto err;
> +
> + memcpy(block->gpio, gpios, sizeof(*block->gpio) * size);
> +
> + for (i = 0; i < size; i++) {
> + struct gpio_chip *gc = gpio_to_chip(gpios[i]);
> + int bit = gpios[i] - gc->base;
> + gbc = gpio_block_chip_get(block, gc);
> +
> + if (!gbc) {
> + gbc = kzalloc(sizeof(struct gpio_block_chip),
> + GFP_KERNEL);
> + if (!gbc)
> + goto err;
> + list_add_tail(&gbc->list, &block->gbc_list);
> + gbc->gc = gc;
> + INIT_LIST_HEAD(&gbc->remap_list);
> + }
> +
> + /*
> + * represents the mask necessary on calls to the driver's
> + * .get_block() and .set_block()
> + */
> + gbc->mask |= BIT(bit);
> +
> + /*
> + * collect gpios that are specified together, represented by
> + * neighboring bits
> + *
> + * get last element and create new element if list empty or
> + * new element necessary
> + */
> + remap = list_entry(gbc->remap_list.prev, struct gpio_remap,
> + list);
> + if (list_empty(&gbc->remap_list) ||
> + (bit - i != remap->offset)) {
> + remap = kzalloc(sizeof(struct gpio_remap), GFP_KERNEL);
> + if (!remap)
> + goto err;
> + list_add_tail(&remap->list, &gbc->remap_list);
> + remap->offset = bit - i;
> + }
> +
> + /*
> + * represents the mask necessary for bit reordering between
> + * gpio_block (i.e. as specified on gpio_block_get() and
> + * gpio_block_set()) and gpio_chip domain (i.e. as specified on
> + * the driver's .set_block() and .get_block())
> + */
> + remap->mask |= BIT(i);
> + }
> +
> + return block;
> +err:
> + gpio_block_free(block);
> + return ERR_PTR(-ENOMEM);
> +}
> +EXPORT_SYMBOL_GPL(gpio_block_create);
> +
> +void gpio_block_free(struct gpio_block *block)
> +{
> + struct list_head *i, *itmp, *j, *jtmp;
> + struct gpio_block_chip *gbc;
> + struct gpio_remap *remap;
> +
> + list_for_each_safe(i, itmp, &block->gbc_list) {
> + gbc = list_entry(i, struct gpio_block_chip, list);
> + list_del(i);
> + list_for_each_safe(j, jtmp, &gbc->remap_list) {
> + remap = list_entry(j, struct gpio_remap, list);
> + list_del(j);
> + kfree(remap);
> + }
> + kfree(gbc);
> + }
> +
> + kfree(block->gpio);
> + kfree(block);
> +}
> +EXPORT_SYMBOL_GPL(gpio_block_free);
> +
> +unsigned long gpio_block_get(const struct gpio_block *block, unsigned long mask)
> +{
> + struct gpio_block_chip *gbc;
> + unsigned long values = 0;
> +
> + list_for_each_entry(gbc, &block->gbc_list, list) {
> + struct gpio_remap *remap;
> + int i;
> + unsigned long remapped = 0;
> + unsigned long remapped_mask = 0;
> +
> + list_for_each_entry(remap, &gbc->remap_list, list)
> + remapped_mask |= (mask & remap->mask) << remap->offset;
> + remapped_mask &= gbc->mask;
> +
> + if (!remapped_mask)
> + continue;
> +
> + if (gbc->gc->get_block)
> + remapped = gbc->gc->get_block(gbc->gc, remapped_mask);
> + else
> + /* emulate */
> + for_each_set_bit(i, &remapped_mask, BITS_PER_LONG)
> + remapped |= gbc->gc->get(gbc->gc,
> + gbc->gc->base + i) << i;
> +
> + list_for_each_entry(remap, &gbc->remap_list, list)
> + values |= (remapped >> remap->offset) & remap->mask;
> + }
> +
> + return values;
> +}
> +EXPORT_SYMBOL_GPL(gpio_block_get);
> +
> +void gpio_block_set(struct gpio_block *block, unsigned long mask,
> + unsigned long values)
> +{
> + struct gpio_block_chip *gbc;
> +
> + list_for_each_entry(gbc, &block->gbc_list, list) {
> + struct gpio_remap *remap;
> + int i;
> + unsigned long remapped = 0;
> + unsigned long remapped_mask = 0;
> +
> + list_for_each_entry(remap, &gbc->remap_list, list) {
> + remapped |= (values & remap->mask) << remap->offset;
> + remapped_mask |= (mask & remap->mask) << remap->offset;
> + }
> + remapped_mask &= gbc->mask;
> +
> + if (!remapped_mask)
> + continue;
> +
> + if (gbc->gc->set_block)
> + gbc->gc->set_block(gbc->gc, remapped_mask, remapped);
> + else
> + /* emulate */
> + for_each_set_bit(i, &remapped_mask, BITS_PER_LONG)
> + gbc->gc->set(gbc->gc, gbc->gc->base + i,
> + (remapped >> i) & 1);
> + }
> +}
> +EXPORT_SYMBOL_GPL(gpio_block_set);
> +
> +struct gpio_block *gpio_block_find_by_name(const char *name)
> +{
> + struct gpio_block *i;
> +
> + list_for_each_entry(i, &gpio_block_list, list)
> + if (!strcmp(i->name, name))
> + return i;
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(gpio_block_find_by_name);
> +
> +int gpio_block_register(struct gpio_block *block)
> +{
> + if (gpio_block_find_by_name(block->name))
> + return -EBUSY;
> +
> + list_add(&block->list, &gpio_block_list);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(gpio_block_register);
> +
> +void gpio_block_unregister(struct gpio_block *block)
> +{
> + struct gpio_block *i;
> +
> + list_for_each_entry(i, &gpio_block_list, list)
> + if (i == block) {
> + list_del(&i->list);
> + break;
> + }
> +}
> +EXPORT_SYMBOL_GPL(gpio_block_unregister);
> +
> /**
> * __gpio_cansleep() - report whether gpio value access will sleep
> * @gpio: gpio in question
> --- linux-2.6.orig/include/asm-generic/gpio.h
> +++ linux-2.6/include/asm-generic/gpio.h
> @@ -44,6 +44,7 @@ static inline bool gpio_is_valid(int num
>
> struct device;
> struct gpio;
> +struct gpio_block;
> struct seq_file;
> struct module;
> struct device_node;
> @@ -109,6 +110,8 @@ struct gpio_chip {
> unsigned offset);
> int (*get)(struct gpio_chip *chip,
> unsigned offset);
> + unsigned long (*get_block)(struct gpio_chip *chip,
> + unsigned long mask);
> int (*direction_output)(struct gpio_chip *chip,
> unsigned offset, int value);
> int (*set_debounce)(struct gpio_chip *chip,
> @@ -116,6 +119,9 @@ struct gpio_chip {
>
> void (*set)(struct gpio_chip *chip,
> unsigned offset, int value);
> + void (*set_block)(struct gpio_chip *chip,
> + unsigned long mask,
> + unsigned long values);
>
> int (*to_irq)(struct gpio_chip *chip,
> unsigned offset);
> @@ -184,6 +190,17 @@ extern void gpio_set_value_cansleep(unsi
> extern int __gpio_get_value(unsigned gpio);
> extern void __gpio_set_value(unsigned gpio, int value);
>
> +extern struct gpio_block *gpio_block_create(unsigned *gpio, size_t size,
> + const char *name);
> +extern void gpio_block_free(struct gpio_block *block);
> +extern unsigned long gpio_block_get(const struct gpio_block *block,
> + unsigned long mask);
> +extern void gpio_block_set(struct gpio_block *block, unsigned long mask,
> + unsigned long values);
> +extern struct gpio_block *gpio_block_find_by_name(const char *name);
> +extern int gpio_block_register(struct gpio_block *block);
> +extern void gpio_block_unregister(struct gpio_block *block);
> +
> extern int __gpio_cansleep(unsigned gpio);
>
> extern int __gpio_to_irq(unsigned gpio);
> --- linux-2.6.orig/include/linux/gpio.h
> +++ linux-2.6/include/linux/gpio.h
> @@ -2,6 +2,8 @@
> #define __LINUX_GPIO_H
>
> #include <linux/errno.h>
> +#include <linux/types.h>
> +#include <linux/list.h>
>
> /* see Documentation/gpio.txt */
>
> @@ -39,6 +41,64 @@ struct gpio {
> const char *label;
> };
>
> +/**
> + * struct gpio_remap - a structure for describing a bit mapping
> + * @mask: a bit mask, relevant for a (partial) mapping
> + * @offset: how many bits to shift to the left (negative: to the right)
> + * @list: several remappings are internally collected in a list
> + *
> + * When we are mapping bit values from one word to another (here: from GPIO
> + * block domain to GPIO driver domain) we first mask them out with mask and
> + * shift them as specified with offset. More complicated mappings are done by
> + * grouping several of those structs and adding the results together.
> + */
> +struct gpio_remap {
> + unsigned long mask;
> + int offset;
> +
> + struct list_head list;
> +};
> +
> +/**
> + * struct gpio_block_chip - a structure representing chip specific data in a
> + * gpio block
> + * @gc: the chip
> + * @remap_list: list of remappings, there are several necessary if the bits
> + * are not consecutive
> + * @mask: chip specific mask, used for propagating to the driver's
> + * get_block() and set_block() functions
> + * @list: list collecting potentially multiple chips in one block
> + *
> + * This structure holds information about remapping and masking of gpios within
> + * one chip. There can be several of those in one block.
> + */
> +struct gpio_block_chip {
> + struct gpio_chip *gc;
> + struct list_head remap_list;
> + unsigned long mask;
> +
> + struct list_head list;
> +};
> +
> +/**
> + * struct gpio_block - a structure describing a list of GPIOs for simultaneous
> + * operations
> + * @gbc_list: list of chips in this block, typically just one
> + * @name: the name of this block
> + * @ngpio: number of gpios in this block
> + * @gpio: list of gpios in this block
> + * @list: global list of blocks, maintained by gpiolib
> + */
> +struct gpio_block {
> + struct list_head gbc_list;
> + const char *name;
> +
> + int ngpio;
> + unsigned *gpio;
> +
> + struct list_head list;
> +};
> +
> #ifdef CONFIG_GENERIC_GPIO
>
> #ifdef CONFIG_ARCH_HAVE_CUSTOM_GPIO_H
> @@ -169,6 +229,43 @@ static inline void gpio_set_value(unsign
> WARN_ON(1);
> }
>
> +static inline
> +struct gpio_block *gpio_block_create(unsigned *gpios, size_t size,
> + const char *name)
> +{
> + WARN_ON(1);
> + return NULL;
> +}
> +
> +static inline void gpio_block_free(struct gpio_block *block)
> +{
> + WARN_ON(1);
> +}
> +
> +static inline unsigned long gpio_block_get(const struct gpio_block *block,
> + unsigned long mask)
> +{
> + WARN_ON(1);
> + return 0;
> +}
> +
> +static inline void gpio_block_set(struct gpio_block *block, unsigned long mask,
> + unsigned long values)
> +{
> + WARN_ON(1);
> +}
> +
> +static inline int gpio_block_register(struct gpio_block *block)
> +{
> + WARN_ON(1);
> + return 0;
> +}
> +
> +static inline void gpio_block_unregister(struct gpio_block *block)
> +{
> + WARN_ON(1);
> +}
> +
> static inline int gpio_cansleep(unsigned gpio)
> {
> /* GPIO can never have been requested or set as {in,out}put */
^ permalink raw reply
* [PATCH V4 10/11] ARM: kirkwood: mv643xx_eth dt conversion
From: Sebastian Hesselbarth @ 2013-01-27 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6f3e1f0ee3c5fd06fb3ca918a6c3b13552f32cac.1359232975.git.jason@lakedaemon.net>
On 01/26/2013 09:50 PM, Jason Cooper wrote:
> Tested on the dreamplug:
>
> mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
> libphy: mv643xx_eth smi: probed
> libphy: mv643xx_eth smi: probed
> mv643xx_eth_port f1072000.egiga0 eth0: port 0 with MAC address XX:XX:XX...
> mv643xx_eth_port f1076000.egiga1 eth1: port 0 with MAC address XX:XX:XX...
>
> Successfully pulled an ip address and pinged through the interface
>
> ...
>
> diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
> index 2c738d9..b13a405 100644
> --- a/arch/arm/boot/dts/kirkwood.dtsi
> +++ b/arch/arm/boot/dts/kirkwood.dtsi
> @@ -201,5 +201,43 @@
> clocks =<&gate_clk 4>;
> status = "disabled";
> };
> +
> + smi0: mdio at 72000 {
> + compatible = "marvell,mdio-mv643xx";
> + reg =<0x72000 0x4000>;
> + interrupts =<46>;
> + tx_csum_limit =<1600>;
> + status = "disabled";
> + };
> +
> + smi1: mdio at 76000 {
> + compatible = "marvell,mdio-mv643xx";
> + reg =<0x76000 0x4000>;
> + interrupts =<47>;
> + tx_csum_limit =<1600>;
> + status = "disabled";
> + };
> +
> + egiga0 {
> + compatible = "marvell,mv643xx-eth";
> + reg =<0x72000 0x4000>;
> + mdio =<&smi0>;
> + port_number =<0>;
> + phy_addr =<0x80>;
Jason,
This will break phy_scan on all kirkwood boards as 0x80 is _not_ equal
MV643XX_ETH_PHY_ADDR_DEFAULT.
I suggest not to set phy_addr in kirkwood.dtsi at all and let the
board specific DT files set the phy addresses (or rely on phy_scan if not
set).
Also, you are ORing the address passed by phy_addr with 0x80 anyway. So
all phy addresses should be passed as <0> or <1> instead the ORed ones.
Sebastian
^ permalink raw reply
* [PATCH 6/6 v14] gpio: Add block gpio to several gpio drivers
From: Roland Stigge @ 2013-01-27 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOY=C6F0ExS1gtmA=4QMzXUMRjAH5o7K9KDwTjdU-dYHA1fF=g@mail.gmail.com>
On 27/01/13 13:18, Stijn Devriendt wrote:
>>> In my patch, I go out of the way of this kind of thing for a simple reason:
>>> You may generate incorrect timing by doing this.
>>
>> You are right, certain things like synchronous on+off is not really
>> possible.
>>
>> However, the above at least supports switching on simulaneously, and
>> switching off simultaneously, which is an improvement in certain cases
>> (and this certain hardware part doesn't support more). Maybe this
>> certain driver behaviour can be documented even better than just in the
>> driver source.
>>
>
> The question here is: do you expect a user of the block-GPIO API to
> go look into the base-driver code to see what will be supported?
>
> In my version of the patch this means:
> - do not provide a single GPIO-block that crosses multiple base-drivers
> - only provide gpio_block_get/set for GPIO drivers that support the complete
> operation in a single go. (for example, in the above example there would be
> no gpio_block_set() function)
>
> Perhaps the best approach is to make this explicit: Allow drivers to expose
> their capabilities wrt timing and allow users to request strict-timing or
> loose-timing. Loose-timing allows multiple gpio-drivers to be combined and
> allows drivers with separate set/clear, hi/lo registers to be used.
Interesting idea. However, it will be difficult to agree on good metrics
here. As Mark Brown pointed out, even when hardware seems to support
"simultaneousness" by registers, this doesn't actually mean that voltage
levels are switched simultaneously wrt. sub-nanosecond timing.
Also, it depends on further wiring between the actually supported GPIO
hardware chip and the integrated device's I/O connections.
Resulting in scenarios where GPIO chips (in terms of Linux drivers)
without explicit I/O set registers (e.g., set/clear regs) could be "more
simultaneous" than those having explicit I/O regs but hardware wiring
leading to bad "simultaneousness" behaviour.
Questionable if the kernel could address those details.
> Of course, for a first version you may as well leave it out. Perhaps the
> use-cases for cross-GPIO-driver blocks are not worth the extra complexity
> as of today?
I actually started the current block gpio patches to support this kind
of use case. :-)
Roland
^ permalink raw reply
* [Qemu-devel] [kvmarm] [RFC] Virtio-desktop: Virtio-based virtual desktop
From: Gleb Natapov @ 2013-01-27 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAu8pHuUfEezDEsYWTymFkuCEzdK+kr09MMFmVy-DZV8ztJbGw@mail.gmail.com>
On Sun, Jan 27, 2013 at 10:12:20AM +0000, Blue Swirl wrote:
> On Sun, Jan 27, 2013 at 8:20 AM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Fri, Jan 25, 2013 at 08:31:54PM +0100, Alexander Graf wrote:
> >>
> >> On 25.01.2013, at 20:04, Blue Swirl wrote:
> >>
> >> > On Thu, Jan 24, 2013 at 6:10 AM, Anup Patel <anup.patel@linaro.org> wrote:
> >> >> Hi All,
> >> >>
> >> >> How about having a generic Virtio-based machine for emulating a virtual
> >> >> desktop ?
> >> >
> >> > I have also thought about this, current virtio design is not very
> >> > clean. On the downside, pure no-legacy approach might not work well if
> >> > you want the host to give control of a host device to guest (VFIO like
> >> > pass through using IOMMUs).
> >> >
> >> >> I know folks have already thought about this and probably also tried
> >> >> something or other on this front but, it will be good to know the downsides.
> >> >>
> >> >> Virtio-desktop can be a separate specification describing a virtual desktop.
> >> >> Of-course we cannot avoid few architecture dependent virtual devices in but
> >> >> the Virtio-desktop specification will try to keep minimum possible
> >> >> architecture dependent devices.
> >> >>
> >> >> As per our thoughts, a Virtio-desktop will have two kinds of devices:
> >> >> 1. Architecture dependent devices: This devices will be emulated in-kernel
> >> >> by architecture specific code of KVM or Xen or Some other hypervisor.
> >> >> a) Virtualized CPU
> >> >> b) Virtualized PIC (i.e. in-kernel architecture specific emulation of
> >> >> irqchip)
> >> >> c) Virtualized Timer (i.e. in-kernel architecture specific emulation of
> >> >> timer chip)
> >> >
> >> > I think reusing PIC and timer design is not the most optimal. What a
> >> > PV aware OS really wants is to wake up because of an external event or
> >> > at some specific point of time (or after a specific delay) and easy
> >> > way to manage the VM clock without timer tick counting. With a
> >> > tickless approach, it would need the timer events as rarely as
> >> > possible.
> >> >
> >> > Perhaps a better approach would be to introduce a way for the guest to
> >> > subscribe to a list of external events (including time), which would
> >> > be fed to it via something like reverse hypercall (or just use legacy
> >> > interrupts). Preferably it should be possible to pass any events
> >> > through a stack of guests to the end consumer guest and even
> >> > applications in a guest.
> >>
> >> This approach falls apart once hardware vendors implement timer interrupts inside a guest context (which Intel and IIUC ARM are doing). At that point, it's actually more efficient to do real timer calls to real hardware.
> >>
> > Same with irq chip. Implementing PV irqchip today is going backwards.
>
> I'm not sure this should be the conclusion. Obviously throwing more
> hardware at virtualization makes it faster and the x86 host will
> probably also benefit from faster interrupt handling as a side
> benefit, so emulating the PIC etc. makes sense for now and also in
> short term (some years from now).
Moder OSes, i.e those that have a non zero chance to get virtio-desktop
support, do not use PIC on x86 after bootup, so there is not performance
gains in replacing it with something PV and I hope you do not propose
that. You probably think about using PV in place of LAPIC which,
besides have to be written and debugged, will be slower on modern x86 HW
since mode x86 HW accelerates LAPIC emulation. AFAIK arm also has irq
chip virtualization support in HW.
>
> But long term, if you could direct the hardware design efforts of
> major companies and standardization bodies to any direction, is fast
> emulation of 30 year old technology what would create the fastest
> architecture in the future? For example, maybe the PIC+LAPIC should be
> replaced in long term by something that can vector the interrupts to
> different VCPUs directly, each at different privilege levels?
>
What prevents you from doing it today with LAPIC/MSIX? PIC/IOAPIC are
legacy and not used for anything performance sensitive. And do you truly
believe that HW vendors will abandon current HW in favor of your design?
--
Gleb.
^ permalink raw reply
* [PATCH v3 3/8] input: touchscreen: ti_tsc: remove unwanted fifo flush
From: Peter Korsgaard @ 2013-01-27 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0110c0cb0cbd3c31dfd3f098f207cd5b765d247e.1358502134.git.rachna@ti.com>
>>>>> "P" == Patil, Rachna <rachna@ti.com> writes:
P> From: "Patil, Rachna" <rachna@ti.com>
P> When touchscreen and ADC are used together, this
P> unwanted fifo flush leads to loss of ADC data.
Any special reason why you're wrapping your commit messages after 50
chars, and not the more standard ~70 chars?
It would be good with some more detailed commit text. Is the flush done
somewhere else now? What happens on boards where you don't use the adc
part?
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH 1/6 v14] gpio: Add a block GPIO API to gpiolib
From: Roland Stigge @ 2013-01-27 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOY=C6ERX=2HdvmtAW-__947_-P8r=Lvp88KzZDQdf4kAuRB5Q@mail.gmail.com>
On 27/01/13 14:19, Stijn Devriendt wrote:
>> +Block GPIO
>> +----------
>> +
>> +The above described interface concentrates on handling single GPIOs. However,
>> +in applications where it is critical to set several GPIOs at once, this
>> +interface doesn't work well, e.g. bit-banging protocols via grouped GPIO lines.
>> +Consider a GPIO controller that is connected via a slow I2C line. When
>> +switching two or more GPIOs one after another, there can be considerable time
>> +between those events. This is solved by an interface called Block GPIO:
>> +
>> +struct gpio_block *gpio_block_create(unsigned int *gpios, size_t size,
>> + const char *name);
>> +
>> +This creates a new block of GPIOs as a list of GPIO numbers with the specified
>> +size which are accessible via the returned struct gpio_block and the accessor
>> +functions described below. Please note that you need to request the GPIOs
>> +separately via gpio_request(). Similarly, the direction of the used GPIOs need
>> +to be set by the user before using the block.
>
> Is there anything holding you back from letting gpio_block_create() do
> the request
> for all the pins?
It's analoguous to plain GPIOs: They exist, but are not requested (by
whom?) by default.
> Also, wouldn't it make sense to have a gpio_block_direction_input()
> and _output()
> variant? On the other hand, for things like I2C and SPI emulation,
> some pins will
> naturally be always output (like clock lines) while other could be
> switched between
> in and output (like the i2c data line).
Right. Current implementation emphasizes on switching, not direction or
other convenience functions, which could be added, nevertheless.
Roland
^ permalink raw reply
* [Qemu-devel] [RFC] Virtio-desktop: Virtio-based virtual desktop
From: Anthony Liguori @ 2013-01-27 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALrVBktEQM5D-L+60RTzdRgo7jLZ671KxWMUFGnQwQ1bzgjO2A@mail.gmail.com>
Anup Patel <anup.patel@linaro.org> writes:
> Hi All,
>
> How about having a generic Virtio-based machine for emulating a virtual
> desktop ?
>
> I know folks have already thought about this and probably also tried
> something or other on this front but, it will be good to know the downsides.
>
> Virtio-desktop can be a separate specification describing a virtual
> desktop.
> Of-course we cannot avoid few architecture dependent virtual devices in but
> the Virtio-desktop specification will try to keep minimum possible
> architecture dependent devices.
There's a lot of reasons why a pure PV machine type is a bad idea. Lots
of people have enumerated them in this thread.
But let me mention some things that I think we don't have covered today
with PV:
- Graphics. Yes, I know QXL exists but it's (a) dependent on PCI (b)
lacks the ability to gracefully degrade making it hopelessly tied to
spice.
- Input. PS/2 mouse provides relative input which sucks in guests.
For absolute input, we have VMMouse which is x86-specific, USB
tablets (which are expensive to emulate) or the spice mouse which is
intimately tied to the full Spice stack.
- Guest interaction. Copy/paste, drag and drop, etc. In theory this
is covered in spice agents but it's all again hopelessly tied to
Spice which makes it non-portable.
So there's good work todo but it's almost certainly in working with the
Spice community to try to make what they already have more accessible to
non-x86 architectures.
Regards,
Anthony Liguori
>
> As per our thoughts, a Virtio-desktop will have two kinds of devices:
> 1. Architecture dependent devices: This devices will be emulated in-kernel
> by architecture specific code of KVM or Xen or Some other hypervisor.
> a) Virtualized CPU
> b) Virtualized PIC (i.e. in-kernel architecture specific emulation of
> irqchip)
> c) Virtualized Timer (i.e. in-kernel architecture specific emulation of
> timer chip)
> 2. Architecture independent devices: This are Virtio-based devices which
> are usually required by a desktop virtual machine.
> a) Virtio-blk (storage)
> - Already available
> b) Virtio-net (network)
> - Already available
> c) Virtio-fb (display)
> - It seems some work has been already done for Virtio frame buffer but
> I did not find drivers/fb/virtio-fb.c in latest kernel
> (http://thread.gmane.org/gmane.comp.emulators.kvm.devel/42720)
> - Is Virtio-fb work still in-progress ??
> d) Virtio-input (keyboard/mouse/multi-touch)
> - Currently not available
> - It will provide keyboard input events
> - It will provide mouse input events
> - It will provide multi-touch input events
> e) Virtio-power (reset/shutdown/enumeration)
> - It can provides info about the entire virtual machine including CPU,
> PIC, Timer, available Virtio devices, etc.
> - It can also provide CPU and Virtio-device hot-plugging
> - Its primary purpose would be to provide reset and shutdown of CPU
> and Virtio devices.
> - There will be only one instance of this device and its location will
> be fixed for each architecture.
>
> The Virtio-desktop specification may also describe a recommended memory map
> of for each architecture.
>
> Right now, only missing devices seems to be Virtio-fb, Virtio-input, and
> Virtio-power, which some of us are willing to take-up.
>
> IMHO, If we have something like Virtio-desktop specification then all
> possible guest OSes can have support for it and different hypervisor can
> emulate it without worrying about guest support.
>
> Best Regards,
> Anup
^ permalink raw reply
* [PATCH v4 4/8] MFD: ti_am335x_tscadc: add device tree binding information
From: Peter Korsgaard @ 2013-01-27 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358999112-31192-5-git-send-email-rachna@ti.com>
>>>>> "P" == Patil, Rachna <rachna@ti.com> writes:
Hi,
P> From: "Patil, Rachna" <rachna@ti.com>
P> Signed-off-by: Patil, Rachna <rachna@ti.com>
P> ---
P> Changes in v4:
P> Subnodes and their properties documentation added.
P> Non-standard properties prefixed with vendor name.
P> .../devicetree/bindings/mfd/ti_am335x_tscadc.txt | 52 ++++++++++++++++++++
P> 1 file changed, 52 insertions(+)
P> create mode 100644 Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
P> diff --git a/Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt b/Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
P> new file mode 100644
P> index 0000000..0100771
P> --- /dev/null
P> +++ b/Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
P> @@ -0,0 +1,52 @@
P> +Texas Instruments - TSC / ADC multi-functional device
P> +
P> +ti_tscadc is a multi-function device with touchscreen and ADC on chip.
P> +This document describes the binding for mfd device.
P> +
P> +Required properties:
P> +- compatible: "ti,ti-tscadc"
That's a very generic name (and double ti). How about ti,am3352-tsadc
instead?
No pinmux?
P> +Sub-node device required properties:
P> +tsc:
P> +- ti,wires: 4/5/8 wire touchscreen support on the platform.
P> +- ti,x-plate-resistance: X plate resistance.
In what kind of units?
P> +- ti,steps-to-configure: A step is configured to read a single co-ordinate value,
P> + can be applied more number of times for better results.
So it is some kind of averaging? Doesn't tslib do that for you already?
Is there any limit to how many steps you can/will handle?
P> +- ti,wire-config: Order for connecting wires on touchscreen.
ti,wires seems redundant given ti,wire-config (E.G. number of elements
in array). It is not clear to me what the magic values in wire-config
mean?
P> +
P> +adc:
P> +- ti,adc-channels: Number of ADC channels used.
Is there ever any use case for this being something else than 8 -
ti,wires?
--
Bye, Peter Korsgaard
^ permalink raw reply
* [BUG] panda board locks up on boot
From: Paolo Pisati @ 2013-01-27 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0247700D01F14443B9209F90AD938CC52409708C@sestoex09.enea.se>
On Fri, Jan 25, 2013 at 08:43:15AM +0000, Mats Liljegren wrote:
> Hi Steven,
>
> Do you have CONFIG_CPU_FREQ enabled? As I posted earlier in linux-kernel forum ("Failed booting PandaBoard ES with Linux 3.8 RC4" two days ago) my PandaBoard ES hangs while booting with this option enabled. It works fine without it. I have not bisected it down to a single commit though.
glad i'm not the only one who hit this problem:
"3.8rc4+ and cpu_freq omap: hangs, oopses, etcetc"
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg83693.html
--
bye,
p.
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Sebastian Hesselbarth @ 2013-01-27 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127110857.GA23687@schnuecks.de>
On 01/27/2013 12:08 PM, Simon Baatz wrote:
> Hi Sebastian,
>
> On Sun, Jan 27, 2013 at 11:52:41AM +0100, Sebastian Hesselbarth wrote:
>> Jason posted a patch set that makes mv643xx DT compatible. IMHO this
>> patch is obsolete when we have DT support for mv643xx.
>> kirkwood_ge00/01_init will not be called with DT support at all.
>
> I know. This is to fix a regression in 3.8 (which currently does not
> boot with my "modularized" config).
Simon,
I _cannot_ confirm that gbe is loosing its MAC address on Dove. I will
post a follow-up patch to Jason's cleanup patches that will also
grab a clock for smi. With that patch insmod'ing/rmmod'ing mv643xx_eth
does work just fine here on Dove.
Sebastian
^ permalink raw reply
* [PATCH] NET: mv643xx: get smi clock from device tree
From: Sebastian Hesselbarth @ 2013-01-27 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <684d670633e771b738725b082d88fdb773002f4a.1359232975.git.jason@lakedaemon.net>
mv643xx_eth is split up into core (ethernet) and smi (mdio) driver
parts. If clock gates are introduced as for Kirkwood and Dove SoCs,
smi registers are accessed with clock gated and cause the SoC to
hang.
This patch also gets and enables a clock passed from DT for the
shared smi part of the driver. It has been tested on Dove and also
allows the driver compiled and used as a module.
DT conversion patches for mv643xx_eth on Dove will be sent on another
patch set.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Simon Baatz <gmbnomis@gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 67e5d86..c0f0671 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -296,6 +296,9 @@ struct mv643xx_eth_shared_private {
int extended_rx_coal_limit;
int tx_bw_control;
int tx_csum_limit;
+#if defined(CONFIG_HAVE_CLK)
+ struct clk *clk;
+#endif
};
@@ -2626,6 +2629,12 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
of_property_read_u32(pdev->dev.of_node,
"tx_csum_limit", &pd->tx_csum_limit);
+#if defined(CONFIG_HAVE_CLK)
+ msp->clk = of_clk_get(pdev->dev.of_node, 0);
+ if (!IS_ERR(msp->clk))
+ clk_prepare_enable(msp->clk);
+#endif
+
np = of_parse_phandle(pdev->dev.of_node, "shared_smi", 0);
if (np)
pd->shared_smi = of_find_device_by_node(np);
@@ -2695,6 +2704,12 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
out_free_mii_bus:
mdiobus_free(msp->smi_bus);
out_unmap:
+#if defined(CONFIG_HAVE_CLK)
+ if (!IS_ERR(msp->clk)) {
+ clk_disable_unprepare(msp->clk);
+ clk_put(msp->clk);
+ }
+#endif
iounmap(msp->base);
out_free:
kfree(msp);
@@ -2713,6 +2728,12 @@ static int mv643xx_eth_shared_remove(struct platform_device *pdev)
}
if (msp->err_interrupt != NO_IRQ)
free_irq(msp->err_interrupt, msp);
+#if defined(CONFIG_HAVE_CLK)
+ if (!IS_ERR(msp->clk)) {
+ clk_disable_unprepare(msp->clk);
+ clk_put(msp->clk);
+ }
+#endif
iounmap(msp->base);
kfree(msp);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 5/6 v14] gpio: Add device tree support to block GPIO API
From: Roland Stigge @ 2013-01-27 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOY=C6E-+uKQGbRDjNh5ZP9Wrmd+PNbt7djkBTzwe29=qA1_PA@mail.gmail.com>
On 27/01/13 14:07, Stijn Devriendt wrote:
>> +Example:
>> +
>> + blockgpio {
>> + compatible = "linux,gpio-block";
>> +
>> + block0 {
>> + gpios = <&gpio 3 0 0>,
>> + <&gpio 3 1 0>;
>> + };
>> + block1 {
>> + gpios = <&gpio 4 1 0>,
>> + <&gpio 4 3 0>,
>> + <&gpio 4 2 0>,
>> + <&gpio 4 4 0>,
>> + <&gpio 4 5 0>,
>> + <&gpio 4 6 0>,
>> + <&gpio 4 7 0>,
>> + <&gpio 4 8 0>,
>> + <&gpio 4 9 0>,
>> + <&gpio 4 10 0>,
>> + <&gpio 4 19 0>;
>> + };
>> + };
>
> How do you see bindings for other kinds of drivers?
>
> In my patchset, it's possible for other drivers to use gpio-blocks.
> One example we have is a power sequencer with 2 pins attached
> to GPIO pins. These 2 pins form a 2bit word to select power margining.
> These 2 pins need to be set synchronously (as otherwise when going
> from profile 0 to profile 3 you pass either profile 1 or profile 2 which
> could be bad for hardware)
>
> In the device-tree this is specified as:
>
> powr at 0x20 {
> // other properties
>
> gpios = <&gpio 4 0
> &gpio 5 0>;
> };
>
> Is this kind of integration also possible?
You can reference the gpio block via a phandle, e.g.:
blockgpio {
compatible = "linux,gpio-block";
selector1 {
gpios = <&gpio 4 0>,
<&gpio 5 0>;
};
};
powr at 0x20 {
// ...
gpios = <&selector1>;
};
In the driver, you can get the gpio block like this:
block = gpio_block_find_by_name(of_parse_phandle(powr, "gpios", 0)->name);
(Simplified by removed error/NULL handling!)
If this turns out to be a common pattern, I can add a convenience "get"
function for this.
Roland
^ permalink raw reply
* [BUG] panda board locks up on boot
From: Nishanth Menon @ 2013-01-27 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127141254.GC5714@stinkpad>
On 01/27/2013 08:12 AM, Paolo Pisati wrote:
> On Fri, Jan 25, 2013 at 08:43:15AM +0000, Mats Liljegren wrote:
>> Hi Steven,
>>
>> Do you have CONFIG_CPU_FREQ enabled? As I posted earlier in linux-kernel forum ("Failed booting PandaBoard ES with Linux 3.8 RC4" two days ago) my PandaBoard ES hangs while booting with this option enabled. It works fine without it. I have not bisected it down to a single commit though.
>
> glad i'm not the only one who hit this problem:
>
> "3.8rc4+ and cpu_freq omap: hangs, oopses, etcetc"
>
> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg83693.html
>
Support for TPS is not yet in mainline kernel. you may want to do:
you could try running 'mw.w 0x4A31E05A 0x1' before bootm in u-boot ->
This will hack the pad of panda ES pin mean for controlling TPS voltage
register (again a kernel bug where the GPIO block setup by bootloader
got reset).
CPUfreq needs both voltage and frequency scaling to work and without
support of the TPS voltage scaling on vdd_MPU, you are stuck at boot
voltage, and just scaling frequency. with the not-enough boot voltage,
moving to higher frequencies can/will result in unpredictable behavior.
---
Regards,
NM
^ permalink raw reply
* [PATCH v2 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Viresh Kumar @ 2013-01-27 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127085926.GH29973@lunn.ch>
On 27 January 2013 14:29, Andrew Lunn <andrew@lunn.ch> wrote:
> On Sun, Jan 27, 2013 at 09:21:42AM +0530, Viresh Kumar wrote:
>> > + kirkwood_cpufreq_set_cpu_state(index);
>>
>> This routine does have error cases, like: wrong value of "state"
>> variable, so returning int from it might make sense. Though i believe
>> state can't be anything else then STATE_CPU_FREQ or STATE_DDR_FREQ.
>> In which case, switch must be modified?
>
> As you say, state cannot be anything else that the two expected
> values. I've just been taught that switch statements should always
> have a default clause. I also thought that a BUG() is too strong, no
> need to kill the machine. It is better to spam the kernel log so it
> gets noticed. I can swap to a WARN_ON(1). I don't really think this is
> an error that needs to be reported back to the framework. Its an
> implementation problem, not a runtime problem. So i would prefer to
> keep to void.
Hmm. What i meant to say was, you just need an if,else instead of switch
and you really don't have to take care of anything else than these two values.
As that can't happen. Even the WARN_ON(). Its useless. Just believe on
what is returned from cpufreq_frequency_table_target(). You really don't
need to validate index returned from it, but only the return value (which
you are already doing)
>> > +static int kirkwood_cpufreq_cpu_exit(struct cpufreq_policy *policy)
>> > +{
>> > + cpufreq_frequency_table_put_attr(policy->cpu);
>> > + return 0;
>> > +}
>>
>> Hmm.. Exit is normally called in two cases. Either cpufreq driver is
>> unregistered
>> or cpu is removed. In that case i am not sure if this routine makes sense? As
>> we have a uniprocessor SoC here.
>
> The current Kconfig entry does not allow it to be compiled as a
> module. But the code does allow for it. With the current trend of
> making the ARM kernel multiplatform, its likely that cpufreq drivers
> will become modular so that only the appropriate driver gets loaded in
> a multiplatform kernel. The question then becomes, is it O.K. not
> being able to unload the module?
You got me wrong. What i wanted to say is, even if you have it as module
and "rmmod" it, then also calling this routine wouldn't make any difference.
Then i went into the code to see the effect. So, this will set freq_table for
a cpu as NULL which will be returned by calling cpufreq_frequency_get_table().
And i now feel we must have this routine because once cpufreq driver isn't
there for a cpu, we must not return any table for it. :)
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Jason Cooper @ 2013-01-27 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51053761.1020009@gmail.com>
On Sun, Jan 27, 2013 at 03:19:13PM +0100, Sebastian Hesselbarth wrote:
> On 01/27/2013 12:08 PM, Simon Baatz wrote:
> >Hi Sebastian,
> >
> >On Sun, Jan 27, 2013 at 11:52:41AM +0100, Sebastian Hesselbarth wrote:
> >>Jason posted a patch set that makes mv643xx DT compatible. IMHO this
> >>patch is obsolete when we have DT support for mv643xx.
> >>kirkwood_ge00/01_init will not be called with DT support at all.
> >
> >I know. This is to fix a regression in 3.8 (which currently does not
> >boot with my "modularized" config).
>
> Simon,
>
> I _cannot_ confirm that gbe is loosing its MAC address on Dove. I will
> post a follow-up patch to Jason's cleanup patches that will also
> grab a clock for smi. With that patch insmod'ing/rmmod'ing mv643xx_eth
> does work just fine here on Dove.
I believe Simon's issue is that the mv643xx_eth driver is not loaded at
boot, it's clocks get gated, then when he loads the driver, there is no
mac address. Is that correct Simon? I don't think unloading the driver
after boot will trigger this regression.
thx,
Jason.
^ permalink raw reply
* [PATCH v3 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Viresh Kumar @ 2013-01-27 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359281244-31455-2-git-send-email-andrew@lunn.ch>
On 27 January 2013 15:37, Andrew Lunn <andrew@lunn.ch> wrote:
> diff --git a/drivers/cpufreq/kirkwood-cpufreq.c b/drivers/cpufreq/kirkwood-cpufreq.c
> +static void kirkwood_cpufreq_set_cpu_state(unsigned int index)
> +{
> + if (freqs.old != freqs.new) {
> + switch (state) {
> + case STATE_CPU_FREQ:
> + clk_disable(priv.powersave_clk);
> + break;
> + case STATE_DDR_FREQ:
> + clk_enable(priv.powersave_clk);
> + break;
> + default:
> + WARN_ON(1);
I still don't feel this case is required :)
> + }
> +static struct cpufreq_driver kirkwood_cpufreq_driver = {
> + .get = kirkwood_cpufreq_get_cpu_frequency,
> + .verify = kirkwood_cpufreq_verify,
> + .target = kirkwood_cpufreq_target,
> + .init = kirkwood_cpufreq_cpu_init,
> + .exit = kirkwood_cpufreq_cpu_exit,
> + .name = "kirkwood_freq",
> + .owner = THIS_MODULE,
> + .attr = kirkwood_cpufreq_attr,
> +};
> +
> +static int kirkwood_cpufreq_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = of_find_compatible_node(
> + NULL, NULL, "marvell,kirkwood-core-clock");
np can be NULL here, want to check?
> + np = of_find_compatible_node(NULL, NULL,
> + "marvell,kirkwood-gating-clock");
here too.
> +}
> +static struct platform_driver kirkwood_cpufreq_platform_driver = {
> + .probe = kirkwood_cpufreq_probe,
> + .remove = kirkwood_cpufreq_remove,
> + .driver = {
> + .name = "kirkwood-cpufreq",
> + .owner = THIS_MODULE,
> + },
> +};
Two things. Any reason why you created an extra layer of platform_driver?
You could have called cpufreq_probe/remove (with names modified) from
module init/exit.
Also, in case you want to keep it (which i don't feel is required),
then would make
sense to keep same names in .name field for both structures.
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Sebastian Hesselbarth @ 2013-01-27 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127144610.GW1758@titan.lakedaemon.net>
On 01/27/2013 03:46 PM, Jason Cooper wrote:
>> I _cannot_ confirm that gbe is loosing its MAC address on Dove. I will
>> post a follow-up patch to Jason's cleanup patches that will also
>> grab a clock for smi. With that patch insmod'ing/rmmod'ing mv643xx_eth
>> does work just fine here on Dove.
>
> I believe Simon's issue is that the mv643xx_eth driver is not loaded at
> boot, it's clocks get gated, then when he loads the driver, there is no
> mac address. Is that correct Simon? I don't think unloading the driver
> after boot will trigger this regression.
Loading and unloading the driver module hangs because of the missing
clk_prepeare_enable in shared driver part. This should be fixed by the
patch I sent you.
Dove and Kirkwood have the same gbe internally and I can boot into Dove
without mv643xx_eth, load, unload, reload the module and it always finds
its MAC address.
I just want Simon to confirm that Kirkwood's gbe is really loosing the
contents of its MAC address registers during gated clocks, which is from
a HW point of view very unlikely.
Sebastian
^ permalink raw reply
* [RFC V2 PATCH 3/8] ARM: kirkwood: nsa310: cleanup includes and unneeded code
From: Sergei Shtylyov @ 2013-01-27 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130126202208.GR1758@titan.lakedaemon.net>
Hello.
On 27-01-2013 0:22, Jason Cooper wrote:
>>> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
>>> ---
>>> arch/arm/mach-kirkwood/board-nsa310.c | 9 +--------
>>> 1 file changed, 1 insertion(+), 8 deletions(-)
>>> diff --git a/arch/arm/mach-kirkwood/board-nsa310.c b/arch/arm/mach-kirkwood/board-nsa310.c
>>> index 1bd328d..0b99533 100644
>>> --- a/arch/arm/mach-kirkwood/board-nsa310.c
>>> +++ b/arch/arm/mach-kirkwood/board-nsa310.c
>>> @@ -10,11 +10,8 @@
>>>
>>> #include <linux/kernel.h>
>>> #include <linux/init.h>
>>> -#include <linux/i2c.h>
>>> -
>>> -#include <asm/mach-types.h>
>>> -#include <asm/mach/arch.h>
>>> #include <mach/kirkwood.h>
>>> +#include <linux/of.h>
>> You also add an #include and don't mention it anywhere. Or is
>> that part of the cleanup?
> After removing the unneeded linux/i2c.h, linux/of.h was needed for
> of_machine_is_compatible(). i2c.h had included of.h.
Would be worth mentioning it in the changelog.
> thanks for the review,
> Jason.
WBR, Sergei
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Jason Cooper @ 2013-01-27 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51053F81.6020904@gmail.com>
On Sun, Jan 27, 2013 at 03:53:53PM +0100, Sebastian Hesselbarth wrote:
> On 01/27/2013 03:46 PM, Jason Cooper wrote:
> >>I _cannot_ confirm that gbe is loosing its MAC address on Dove. I will
> >>post a follow-up patch to Jason's cleanup patches that will also
> >>grab a clock for smi. With that patch insmod'ing/rmmod'ing mv643xx_eth
> >>does work just fine here on Dove.
> >
> >I believe Simon's issue is that the mv643xx_eth driver is not loaded at
> >boot, it's clocks get gated, then when he loads the driver, there is no
> >mac address. Is that correct Simon? I don't think unloading the driver
> >after boot will trigger this regression.
>
> Loading and unloading the driver module hangs because of the missing
> clk_prepeare_enable in shared driver part. This should be fixed by the
> patch I sent you.
>
> Dove and Kirkwood have the same gbe internally and I can boot into Dove
> without mv643xx_eth, load, unload, reload the module and it always finds
> its MAC address.
>
> I just want Simon to confirm that Kirkwood's gbe is really loosing the
> contents of its MAC address registers during gated clocks, which is from
> a HW point of view very unlikely.
Ok, I just wanted to make sure we understood his problem correctly, and
if possible, reproduce it.
Simon, can you give us some steps to reproduce this on our side so we
can see exactly what's happening?
thx,
Jason.
^ 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