Re: [PATCH v2 3/7] tty/serial: convert 8250 to generic earlycon
On Fri, Apr 18, 2014 at 3:19 PM, Rob Herring wrote: > From: Rob Herring > > With the generic earlycon infrastructure in place, convert the 8250 > early console to use it. > > Signed-off-by: Rob Herring > Cc: Greg Kroah-Hartman > Cc: Jiri Slaby > --- > drivers/tty/serial/8250/8250_early.c | 138 > --- > drivers/tty/serial/8250/Kconfig | 1 + > 2 files changed, 16 insertions(+), 123 deletions(-) > > diff --git a/drivers/tty/serial/8250/8250_early.c > b/drivers/tty/serial/8250/8250_early.c > index c100d63..e83c9db 100644 > --- a/drivers/tty/serial/8250/8250_early.c > +++ b/drivers/tty/serial/8250/8250_early.c > @@ -35,18 +35,8 @@ ... > - > -int __init setup_early_serial8250_console(char *cmdline) You removed global function, but still left declaration and calling... arch/mips/mti-malta/malta-init.c: setup_early_serial8250_console(console_string); drivers/firmware/pcdp.c:return setup_early_serial8250_console(options); include/linux/serial_8250.h:extern int setup_early_serial8250_console(char *cmdline); Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/7] tty/serial: convert 8250 to generic earlycon
On Fri, Apr 18, 2014 at 3:19 PM, Rob Herring wrote: > From: Rob Herring > > With the generic earlycon infrastructure in place, convert the 8250 > early console to use it. > > Signed-off-by: Rob Herring > Cc: Greg Kroah-Hartman > Cc: Jiri Slaby > --- > drivers/tty/serial/8250/8250_early.c | 138 > --- > drivers/tty/serial/8250/Kconfig | 1 + > 2 files changed, 16 insertions(+), 123 deletions(-) Hi Greg, Rob This one in tty-next breaks booting: "console=uart8250,io,0x3f8,115200". No early console and regular console anymore. It should produce "early con and regular con". Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] sched: idle: Add sched balance option
* Rafael J. Wysocki wrote: > > > Well, so now the question is whether or not we relly want to > > > always go to the "power" (or "energy efficiency" if you will) > > > mode if the system is on battery. That arguably may not be a > > > good thing even for energy efficiency depending on how exactly > > > the modes are defined. > > > > Nobody is talking about always. But in general it seems a good > > enough approach. Hell, many of the AC/BAT switches in todays power > > management crap things are not always right. > > > > Do I want it to dim the LCD further when I unplug the laptop -- > > mostly no, but still it does. And the most annoying one is that it > > reduces the screen blank time to something near 5 seconds or so. > > > > Why would this be any different? > > And why do we have to do things that we hate it when they are done > by others? He replied to your question of 'do we want to act on power events'. The answer is: yes, from the scheduler point of view we want to act on power events by default, and if a user does not want that default behavior, it's not an unprecedented request and GUIs offer various ways to tweak screen dimming and other power saving details. So "trying to save power" is the default everywhere, and the scheduler wants to do the same. The main reason we couldn't do this before was that the scheduler's 'power saving mode' was dysfunctional. That is being fixed. So lets try this, it's high time. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] X86: Hook apic vector allocation domain only when interrupt routing are set to ignore
* Oren Twaig wrote: > On 4/25/2014 11:01 AM, Ingo Molnar wrote: > > > > * Oren Twaig wrote: > > > >> vSMP Foundation provides locality based interrupt routing which needed > >> vector_allocation_domain to allow all online cpus can handle all > possible > >> vectors. > >> > >> Enforcing Interrupt Routing Comply (IRC) mode requires us to > unplug this hook as > >> otherwise the IOAPIC, MSI and MSIX destination selectors to > always select the > >> lowest online cpu as the destination. I.e affinity of HW > interrupts cannot be > >> controled by kernel and/or userspace code. > >> > >> The purpose of the patch is to fix the code to set override > vector allocation > >> domain only when IRC is set to ignore to allow the kernel and > userspace to > >> effectively control the destination of the HW interrupts. > >> > >> Signed-off-by: Oren Twaig > >> Acked-by: Shai Fultheim > > > > So what was the behavior before the change - certain IRQs did not get > > routed, they just ended up on CPU0 or on some other undesirable CPU? > > Or was IRQ distribution random? It's not clear from the changelog. > > It all depends on the IRC flag. When set to "ignore" by the linux > kernel, vSMP Foundation knew that it can deliver the IRQ to the CPU > which would result in less virtualization overhead. For example, we > could deliver the HW interrupt to the CPU which got it or any other > CPU in the system. We couldn't have done it without the kernel > making sure that each vector can be passed to all CPUs. This is why > we override the verctor allocation domain to signal all CPUs. > > But, when the IRC is set to "comply" we, before this patch, still > efected the allocation domains alltough it wasn't needed. It wasn't > needed because when in "comply" mode, we always pass the HW > interrupt to the CPU the kernel requested (by setting the IOAPIC > entry, MSI/X entry or IR entry) I still don't see a clear explanation of what the _user_ saw and sees before and after the change. What is the effect of the patch: correct IRQ routing (i.e. before the change IRQs would end up on the wrong CPU), lower overhead IRQ routing (i.e. before the change IRQ routing overhead was more expensive), or something else? You don't spell this out clearly and it's a crucial piece of information that comes before every other explanation. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] x86/gart: Tidy messages and add bridge device info
* Bjorn Helgaas wrote:
> Print the AGP bridge info the same way as the rest of the kernel, e.g.,
> ":00:04.0" instead of "00:04:00".
>
> Also print the AGP aperture address range the same way we print resources,
> and label it explicitly as a bus address range.
>
> No functional change.
>
> Signed-off-by: Bjorn Helgaas
> ---
> arch/x86/kernel/aperture_64.c | 20
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
> index 9fa8aa051f54..4dd76d3df056 100644
> --- a/arch/x86/kernel/aperture_64.c
> +++ b/arch/x86/kernel/aperture_64.c
> @@ -126,10 +126,12 @@ static u32 __init read_agp(int bus, int slot, int func,
> int cap, u32 *order)
> u64 aper;
> u32 old_order;
>
> - printk(KERN_INFO "AGP bridge at %02x:%02x:%02x\n", bus, slot, func);
> + printk(KERN_INFO "pci :%02x:%02x.%d: AGP bridge\n", bus, slot,
> +func);
Please leave it on a single line - checkpatch warning nonwithstanding.
pr_info() is also useful.
> apsizereg = read_pci_config_16(bus, slot, func, cap + 0x14);
> if (apsizereg == 0x) {
> - printk(KERN_ERR "APSIZE in AGP bridge unreadable\n");
> + printk(KERN_ERR "pci :%02x:%02x.%d: APSIZE unreadable\n",
> +bus, slot, func);
Here too you can also use pr_err() to shorten the line.
> return 0;
> }
>
> @@ -153,16 +155,18 @@ static u32 __init read_agp(int bus, int slot, int func,
> int cap, u32 *order)
>* On some sick chips, APSIZE is 0. It means it wants 4G
>* so let double check that order, and lets trust AMD NB settings:
>*/
> - printk(KERN_INFO "Aperture from AGP @ %Lx old size %u MB\n",
> - aper, 32 << old_order);
> + printk(KERN_INFO "pci :%02x:%02x.%d: AGP aperture [bus %Lx-%Lx] old
> size %u MB\n",
> +bus, slot, func, aper, aper + (32 << old_order) - 1,
> +32 << old_order);
> if (aper + (32ULL<<(20 + *order)) > 0x1ULL) {
> - printk(KERN_INFO "Aperture size %u MB (APSIZE %x) is not right,
> using settings from NB\n",
> - 32 << *order, apsizereg);
> + printk(KERN_INFO "pci :%02x:%02x.%d: AGP aperture size %u
> MB (APSIZE %x) is not right, using settings from NB\n",
> +bus, slot, func, 32 << *order, apsizereg);
> *order = old_order;
> }
>
> - printk(KERN_INFO "Aperture from AGP @ %Lx size %u MB (APSIZE %x)\n",
> - aper, 32 << *order, apsizereg);
> + printk(KERN_INFO "pci :%02x:%02x.%d: AGP aperture [bus %Lx-%Lx]
> size %u MB (APSIZE %x)\n",
> +bus, slot, func, aper, aper + (32 << *order) - 1, 32 << *order,
> +apsizereg);
>
> if (!aperture_valid(aper, (32*1024*1024) << *order, 32<<20))
> return 0;
Also, you could add:
#define PREFIX "PCI/gart: "
or something like that, to define a standard prefix for these
messages.
Btw., this file could be moved to arch/x86/pci/?
Otherwise:
Acked-by: Ingo Molnar
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm] intel-iommu: add missing include of dma-contiguous.h
This patch fixes build error on ia64, that is introduced by the patch intel-iommu-integrate-dma-cma.patch in -mm tree, and this change should be folded into it. Reported-by: Fengguang Wu Signed-off-by: Akinobu Mita Cc: Fengguang Wu Cc: Marek Szyprowski Cc: Konrad Rzeszutek Wilk Cc: David Woodhouse Cc: Don Dutile Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Andi Kleen Cc: x...@kernel.org Cc: io...@lists.linux-foundation.org --- drivers/iommu/intel-iommu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 8659352..6b1c33a 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -39,6 +39,7 @@ #include #include #include +#include #include #include #include -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/3] Input: gpio_keys - convert to use devm_*
On Fri, Apr 25, 2014 at 07:22:16PM +0300, Andy Shevchenko wrote:
> This makes the error handling much more simpler than open-coding everything
> and
> in addition makes the probe function smaller an tidier.
>
> Signed-off-by: Andy Shevchenko
> Acked-by: Linus Walleij
> ---
> drivers/input/keyboard/gpio_keys.c | 75
> +-
> 1 file changed, 25 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/input/keyboard/gpio_keys.c
> b/drivers/input/keyboard/gpio_keys.c
> index 209d4c6..8791d94 100644
> --- a/drivers/input/keyboard/gpio_keys.c
> +++ b/drivers/input/keyboard/gpio_keys.c
> @@ -47,7 +47,7 @@ struct gpio_keys_drvdata {
> const struct gpio_keys_platform_data *pdata;
> struct input_dev *input;
> struct mutex disable_lock;
> - struct gpio_button_data data[0];
> + struct gpio_button_data *data;
> };
>
> /*
> @@ -577,25 +577,22 @@ gpio_keys_get_devtree_pdata(struct device *dev)
> int i;
>
> node = dev->of_node;
> - if (!node) {
> - error = -ENODEV;
> - goto err_out;
> - }
> + if (!node)
> + return ERR_PTR(-ENODEV);
>
> nbuttons = of_get_child_count(node);
> - if (nbuttons == 0) {
> - error = -ENODEV;
> - goto err_out;
> - }
> + if (nbuttons == 0)
> + return ERR_PTR(-ENODEV);
>
> - pdata = kzalloc(sizeof(*pdata) + nbuttons * (sizeof *button),
> - GFP_KERNEL);
> - if (!pdata) {
> - error = -ENOMEM;
> - goto err_out;
> - }
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return ERR_PTR(-ENOMEM);
> +
> + pdata->buttons = devm_kcalloc(dev, nbuttons, sizeof (*button),
> + GFP_KERNEL);
> + if (!pdata->buttons)
> + return ERR_PTR(-ENOMEM);
Why are we splitting the allocation in 2?
>
> - pdata->buttons = (struct gpio_keys_button *)(pdata + 1);
> pdata->nbuttons = nbuttons;
>
> pdata->rep = !!of_get_property(node, "autorepeat", NULL);
> @@ -618,7 +615,7 @@ gpio_keys_get_devtree_pdata(struct device *dev)
> dev_err(dev,
> "Failed to get gpio flags, error: %d\n",
> error);
> - goto err_free_pdata;
> + return ERR_PTR(error);
> }
>
> button = &pdata->buttons[i++];
> @@ -629,8 +626,7 @@ gpio_keys_get_devtree_pdata(struct device *dev)
> if (of_property_read_u32(pp, "linux,code", &button->code)) {
> dev_err(dev, "Button without keycode: 0x%x\n",
> button->gpio);
> - error = -EINVAL;
> - goto err_free_pdata;
> + return ERR_PTR(-EINVAL);
> }
>
> button->desc = of_get_property(pp, "label", NULL);
> @@ -645,17 +641,10 @@ gpio_keys_get_devtree_pdata(struct device *dev)
> button->debounce_interval = 5;
> }
>
> - if (pdata->nbuttons == 0) {
> - error = -EINVAL;
> - goto err_free_pdata;
> - }
> + if (pdata->nbuttons == 0)
> + return ERR_PTR(-EINVAL);
>
> return pdata;
> -
> -err_free_pdata:
> - kfree(pdata);
> -err_out:
> - return ERR_PTR(error);
> }
>
> static struct of_device_id gpio_keys_of_match[] = {
> @@ -699,16 +688,18 @@ static int gpio_keys_probe(struct platform_device *pdev)
> return PTR_ERR(pdata);
> }
>
> - ddata = kzalloc(sizeof(struct gpio_keys_drvdata) +
> - pdata->nbuttons * sizeof(struct gpio_button_data),
> - GFP_KERNEL);
> - input = input_allocate_device();
> + ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
> + input = devm_input_allocate_device(dev);
> if (!ddata || !input) {
> dev_err(dev, "failed to allocate state\n");
> - error = -ENOMEM;
> - goto fail1;
> + return -ENOMEM;
> }
>
> + ddata->data = devm_kcalloc(dev, pdata->nbuttons, sizeof(*ddata->data),
> +GFP_KERNEL);
> + if (!ddata->data)
> + return -ENOMEM;
> +
Same here. I dropped the separate allocations and applied.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/10] ARM: EXYNOS: Make exynos machine_ops as static
HI Tomasz,
Thanks for review and suggestions.
On Sat, Apr 26, 2014 at 6:05 AM, Tomasz Figa wrote:
> Hi Pankaj,
>
>
> On 25.04.2014 14:32, Pankaj Dubey wrote:
>>
>> As machine function ops are used only in this file let's make
>> them static.
>>
>> Signed-off-by: Pankaj Dubey
>> ---
>> arch/arm/mach-exynos/exynos.c |6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
>> index b32a907..2388ee4 100644
>> --- a/arch/arm/mach-exynos/exynos.c
>> +++ b/arch/arm/mach-exynos/exynos.c
>> @@ -198,7 +198,7 @@ static struct map_desc exynos5_iodesc[] __initdata = {
>> },
>> };
>>
>> -void exynos_restart(enum reboot_mode mode, const char *cmd)
>> +static void exynos_restart(enum reboot_mode mode, const char *cmd)
>> {
>> struct device_node *np;
>> u32 val = 0x1;
>> @@ -235,7 +235,7 @@ void __init exynos_cpufreq_init(void)
>> platform_device_register_simple("exynos-cpufreq", -1, NULL, 0);
>> }
>>
>> -void __init exynos_init_late(void)
>> +static void __init exynos_init_late(void)
>> {
>> if (of_machine_is_compatible("samsung,exynos5440"))
>> /* to be supported later */
>> @@ -296,7 +296,7 @@ static void __init exynos_map_io(void)
>> iotable_init(exynos5250_iodesc,
>> ARRAY_SIZE(exynos5250_iodesc));
>> }
>>
>> -void __init exynos_init_io(void)
>> +static void __init exynos_init_io(void)
>> {
>> debug_ll_io_init();
>>
>>
>
> This patch seems to be irrelevant to the rest of this series. Anyway, the
> changes itself are fine, except that I can see more functions that could be
> made static as well:
> - exynos_cpuidle_init(),
> - exynos_cpufreq_init().
>
> In fact, they both could be probably eliminated, as they are just oneliners
> doing things that could be done in exynos_dt_machine_init() directly.
>
> So, if you are doing this kind of cleanup, you could do this as well and
> probably also replace platform_device + platform_device_register() with
> platform_device_register_simple() for cpuidle, to reduce line count and make
> it consistent with cpufreq.
>
OK, I will take care of this.
Also will separate these patches from PMU series.
Thanks,
Pankaj Dubey
> Best regards,
> Tomasz
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] Input: gpio_keys - convert struct descriptions to kernel-doc
On Fri, Apr 25, 2014 at 07:22:17PM +0300, Andy Shevchenko wrote:
> This patch converts descriptions of the structures defined in
> linux/gpio_keys.h
> to follow kernel-doc format.
>
> There is no functional change.
>
> Signed-off-by: Andy Shevchenko
> Acked-by: Linus Walleij
Applied, thank you.
> ---
> include/linux/gpio_keys.h | 45 +
> 1 file changed, 33 insertions(+), 12 deletions(-)
>
> diff --git a/include/linux/gpio_keys.h b/include/linux/gpio_keys.h
> index a7e977f..997134a 100644
> --- a/include/linux/gpio_keys.h
> +++ b/include/linux/gpio_keys.h
> @@ -3,29 +3,50 @@
>
> struct device;
>
> +/**
> + * struct gpio_keys_button - configuration parameters
> + * @code:input event code (KEY_*, SW_*)
> + * @gpio:%-1 if this key does not support gpio
> + * @active_low:
> + * @desc:
> + * @type:input event type (%EV_KEY, %EV_SW, %EV_ABS)
> + * @wakeup: configure the button as a wake-up source
> + * @debounce_interval: debounce ticks interval in msecs
> + * @can_disable:
> + * @value: axis value for %EV_ABS
> + * @irq: Irq number in case of interrupt keys
> + */
> struct gpio_keys_button {
> - /* Configuration parameters */
> - unsigned int code; /* input event code (KEY_*, SW_*) */
> - int gpio; /* -1 if this key does not support gpio */
> + unsigned int code;
> + int gpio;
> int active_low;
> const char *desc;
> - unsigned int type; /* input event type (EV_KEY, EV_SW, EV_ABS) */
> - int wakeup; /* configure the button as a wake-up source */
> - int debounce_interval; /* debounce ticks interval in msecs */
> + unsigned int type;
> + int wakeup;
> + int debounce_interval;
> bool can_disable;
> - int value; /* axis value for EV_ABS */
> - unsigned int irq; /* Irq number in case of interrupt keys */
> + int value;
> + unsigned int irq;
> };
>
> +/**
> + * struct gpio_keys_platform_data - platform data for gpio_keys driver
> + * @buttons:
> + * @nbuttons:
> + * @poll_interval: polling interval in msecs - for polling driver only
> + * @rep: enable input subsystem auto repeat
> + * @enable:
> + * @disable:
> + * @name:input device name
> + */
> struct gpio_keys_platform_data {
> struct gpio_keys_button *buttons;
> int nbuttons;
> - unsigned int poll_interval; /* polling interval in msecs -
> -for polling driver only */
> - unsigned int rep:1; /* enable input subsystem auto repeat */
> + unsigned int poll_interval;
> + unsigned int rep:1;
> int (*enable)(struct device *dev);
> void (*disable)(struct device *dev);
> - const char *name; /* input device name */
> + const char *name;
> };
>
> #endif
> --
> 1.9.2
>
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 10/10] ARM: EXYNOS: Add device tree based initialization support for PMU.
HI Tomasz,
Thanks for review.
On Sat, Apr 26, 2014 at 7:40 AM, Tomasz Figa wrote:
> Hi,
>
>
> On 25.04.2014 14:32, Pankaj Dubey wrote:
>>
>> This patch adds device tree based initialization for PMU and modifies
>> PMU initialization implementation in following way:
>>
>> 1: Let's initialize PMU based on device tree compatibility string.
>> 2: Obtain PMU regmap handle using "syscon_early_regmap_lookup_by_phandle"
>> so that we can reduce dependency over machine header files.
>> 3: Separate each SoC's PMU initialization function and bind this
>> initialization
>> function with PMU compatibility string.
>> 4 : It also removes uses of soc_is_exynos() thus making PMU
>> implementation
>> independent of "plat/cpu.h".
>>
>> Signed-off-by: Pankaj Dubey
>> Signed-off-by: Young-Gun Jang
>> ---
>> arch/arm/mach-exynos/pmu.c | 182
>> +---
>> 1 file changed, 138 insertions(+), 44 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
>> index 67116a5..abcf753 100644
>> --- a/arch/arm/mach-exynos/pmu.c
>> +++ b/arch/arm/mach-exynos/pmu.c
>> @@ -9,17 +9,31 @@
>>* published by the Free Software Foundation.
>>*/
>>
>> -#include
>> #include
>> #include
>> -
>> -#include
>> +#include
>> +#include
>> +#include
>> +#include
>>
>> #include "common.h"
>> #include "regs-pmu.h"
>>
>> +enum exynos_pmu_id {
>> + PMU_EXYNOS4210,
>> + PMU_EXYNOS4X12,
>> + PMU_EXYNOS4412,
>> + PMU_EXYNOS5250,
>> +};
>> +
>> +struct exynos_pmu_data {
>> + enum exynos_pmu_id pmu_id;
>> + struct regmap *pmu_regmap;
>
>
> Again, since this uses the PMU node directly and doesn't seem to access any
> registers shared with other drivers (or at least not at the time most the
> functions from this file are called) I don't think there is any reason why
> not to use of_iomap() and access the registers directly.
>
Regarding using PMU base address as regmap handle or base address I
have replied to your comments in this thread [1], so let's decide
which way is the best. So I will update accordingly.
[1]: https://lkml.org/lkml/2014/4/25/751
> What about adding more fields to this struct? For example .pmu_config,
> .pmu_config_extra (for model-specific settings, like for Exynos4412, see my
> comment below) and (*pmu_init)? Of course the regmap (or base address) would
> have to be moved outside, as it isn't const data.
>
> Then for each PMU variant there would be a static const struct will all
> those fields already filled in and entries in OF match table would already
> point to appropriate structure.
>
Thanks for suggestion. I will take care in next version.
>
>> +};
>> +
>> +struct exynos_pmu_data *pmu_data;
>> static const struct exynos_pmu_conf *exynos_pmu_config;
>> -static struct regmap *pmu_regmap;
>> +typedef void (*exynos_pmu_init_t)(void);
>>
>> static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
>> /* { .reg = address, .val = { AFTR, LPA, SLEEP } */
>> @@ -348,28 +362,31 @@ static void exynos5_init_pmu(void)
>> * Enable both SC_FEEDBACK and SC_COUNTER
>> */
>> for (i = 0 ; i < ARRAY_SIZE(exynos5_list_both_cnt_feed) ; i++) {
>> - regmap_read(pmu_regmap, exynos5_list_both_cnt_feed[i],
>> &tmp);
>> + regmap_read(pmu_data->pmu_regmap,
>> + exynos5_list_both_cnt_feed[i], &tmp);
>> tmp |= (EXYNOS5_USE_SC_FEEDBACK |
>> EXYNOS5_USE_SC_COUNTER);
>> - regmap_write(pmu_regmap, exynos5_list_both_cnt_feed[i],
>> tmp);
>> + regmap_write(pmu_data->pmu_regmap,
>> + exynos5_list_both_cnt_feed[i], tmp);
>> }
>>
>> /*
>> * SKIP_DEACTIVATE_ACEACP_IN_PWDN_BITFIELD Enable
>> */
>> - regmap_read(pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, &tmp);
>> + regmap_read(pmu_data->pmu_regmap, EXYNOS5_ARM_COMMON_OPTION,
>> &tmp);
>> tmp |= EXYNOS5_SKIP_DEACTIVATE_ACEACP_IN_PWDN;
>> - regmap_write(pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
>> + regmap_write(pmu_data->pmu_regmap, EXYNOS5_ARM_COMMON_OPTION,
>> tmp);
>>
>> /*
>> * Disable WFI/WFE on XXX_OPTION
>> */
>> for (i = 0 ; i < ARRAY_SIZE(exynos5_list_diable_wfi_wfe) ; i++) {
>> - tmp = regmap_read(pmu_regmap,
>> exynos5_list_diable_wfi_wfe[i],
>> - &tmp);
>> + tmp = regmap_read(pmu_data->pmu_regmap,
>> + exynos5_list_diable_wfi_wfe[i], &tmp);
>> tmp &= ~(EXYNOS5_OPTION_USE_STANDBYWFE |
>> EXYNOS5_OPTION_USE_STANDBYWFI);
>> - regmap_write(pmu_regmap, exynos5_list_diable_wfi_wfe[i],
>> tmp);
>> + regmap_write(pmu_data->pmu_regmap,
>> + exynos5_list_diable_wfi_wfe[i], tmp);
>>
Re: [PATCH] pinctrl-baytrail: fix for irq descriptor conflict on ASUS T100TA
On 2014/4/26 11:04, Jin, Yao wrote:
>
>
> On 2014/4/25 23:13, Adam Williamson wrote:
>> On Fri, 2014-04-25 at 11:32 +0200, Linus Walleij wrote:
>>> On Thu, Apr 24, 2014 at 11:33 PM, Adam Williamson
>>> wrote:
>>>
Well, I just ran another test too. I built a kernel (3.15rc2) with both
v3 of Doug's SDIO device enumeration patch -
http://dougvj.net/baytrail_gpio_quirk_v3.patch - and the new patch for
the IRQ allocation issue by Thomas Gleixner,
https://patchwork.kernel.org/patch/4051581/ . That kernel gives me a
working touchscreen. Note that
http://dougvj.net/baytrail_gpio_quirk_v3.patch includes both the blocks
you mention (i.e. it adds INT33FC in both places).
So, it really seems like for me at least, it's the combination of Doug's
patch and your approach to fixing the IRQ allocation issue that breaks
the touchscreen. Thomas' approach, even combined with Doug's patch,
seems to work fine.
>>>
>>> Please make sure to provide a Tested-by: tag to Thomas so he
>>> knows this is merge material.
>>
>> Well, I'd rather someone test on the box that's actually affected by the
>> IRQ allocation conflict lockups so we can confirm it actually fixes
>> them :)
>>
>
> I have tried the Thomas Gleixner's patch on 3.14.0 with i915 loading,
> the irq conflict disappears.
> --
I think we still need a small modification on pinctrl-baytrail.c, that
is moving gpiochip_add forward, otherwise the to_irq method is not set.
diff --git a/drivers/pinctrl/pinctrl-baytrail.c
b/drivers/pinctrl/pinctrl-baytrail.c
index e599834..fdfb84b 100644
--- a/drivers/pinctrl/pinctrl-baytrail.c
+++ b/drivers/pinctrl/pinctrl-baytrail.c
@@ -491,12 +491,6 @@ static int byt_gpio_probe(struct platform_device *pdev)
gc->can_sleep = false;
gc->dev = dev;
- ret = gpiochip_add(gc);
- if (ret) {
- dev_err(&pdev->dev, "failed adding byt-gpio chip\n");
- return ret;
- }
-
/* set up interrupts */
irq_rc = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (irq_rc && irq_rc->start) {
@@ -514,6 +508,12 @@ static int byt_gpio_probe(struct platform_device *pdev)
irq_set_chained_handler(hwirq, byt_gpio_irq_handler);
}
+ ret = gpiochip_add(gc);
+ if (ret) {
+ dev_err(&pdev->dev, "failed adding byt-gpio chip\n");
+ return ret;
+ }
+
pm_runtime_enable(dev);
return 0;
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 05/10] ARM: EXYNOS: Remove regs-pmu.h header dependency from pm_domain
HI Tomasz, On Sat, Apr 26, 2014 at 6:19 AM, Tomasz Figa wrote: > Hi, > > > On 25.04.2014 14:32, Pankaj Dubey wrote: >> >> From: Young-Gun Jang >> >> Current "pm_domain.c" file uses "S5P_INT_LOCAL_PWR_EN" definition from >> "regs-pmu.h" and hence needs to include this header file. As there is >> no other user of "S5P_INT_LOCAL_PWR_EN" definition other than pm_domain, >> to remove "regs-pmu.h" header file dependency from "pm_domain.c" it's >> better we define this definition in "pm_domain.c" file itself and thus it >> will help in removing header file inclusion from "pm_domain.c". >> >> Signed-off-by: Young-Gun Jang >> --- >> arch/arm/mach-exynos/pm_domains.c |2 +- >> arch/arm/mach-exynos/regs-pmu.h |1 - >> 2 files changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/arch/arm/mach-exynos/pm_domains.c >> b/arch/arm/mach-exynos/pm_domains.c >> index fe6570e..f676b0a 100644 >> --- a/arch/arm/mach-exynos/pm_domains.c >> +++ b/arch/arm/mach-exynos/pm_domains.c >> @@ -22,7 +22,7 @@ >> #include >> #include >> >> -#include "regs-pmu.h" >> +#define S5P_INT_LOCAL_PWR_EN 0x7 > > > nit: You could indent the value a bit more in case of adding any new macros > in future. While at it, you could probably also drop the S5P_ prefix. > Thanks for review. Will take care of both suggestions. Thanks, Pankaj Dubey > With these fixed, feel free to add my > > Reviewed-by: Tomasz Figa > > Best regards, > Tomasz > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 08/10] ARM: EXYNOS: Refactored code for using PMU address via DT
Hi Tomasz,
Thanks for review.
On Sat, Apr 26, 2014 at 7:19 AM, Tomasz Figa wrote:
> Hi,
>
>
> On 25.04.2014 14:32, Pankaj Dubey wrote:
>>
>> Under "arm/mach-exynos" many files are using PMU register offsets.
>> Since we have added support for accessing PMU base address via DT,
>> now we can remove PMU mapping from exynosX_iodesc.
>> Let's convert all these access using either of "get_exynos_pmuaddr"
>> or "get_exynos_regmap".
>> This will help us in removing static mapping of PMU base address
>> as well as help in reducing dependency over machine header files.
>> Thus helping for migration of PMU implementation from machine to driver
>> folder which can be reused for ARM64 bsed SoC.
>>
>> Signed-off-by: Pankaj Dubey
>> ---
>> arch/arm/mach-exynos/common.h |4 +-
>> arch/arm/mach-exynos/cpuidle.c | 37 ++-
>> arch/arm/mach-exynos/exynos.c | 19 +-
>> arch/arm/mach-exynos/hotplug.c |4 +-
>> arch/arm/mach-exynos/include/mach/map.h |3 -
>> arch/arm/mach-exynos/platsmp.c | 13 +-
>> arch/arm/mach-exynos/pm.c | 60 ++--
>> arch/arm/mach-exynos/pmu.c | 40 +--
>> arch/arm/mach-exynos/regs-pmu.h | 506
>> +++
>> 9 files changed, 348 insertions(+), 338 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
>> index ecfd0fc..ad5128e 100644
>> --- a/arch/arm/mach-exynos/common.h
>> +++ b/arch/arm/mach-exynos/common.h
>> @@ -40,7 +40,7 @@ extern void exynos_cpu_die(unsigned int cpu);
>>
>> /* PMU(Power Management Unit) support */
>>
>> -#define PMU_TABLE_END NULL
>> +#define PMU_TABLE_END 0x
>
>
> IMHO (-1U) would be more appropriate.
>
OK.
>
>>
>> enum sys_powerdown {
>> SYS_AFTR,
>> @@ -51,7 +51,7 @@ enum sys_powerdown {
>>
>> extern unsigned long l2x0_regs_phys;
>> struct exynos_pmu_conf {
>> - void __iomem *reg;
>> + unsigned int offset;
>> unsigned int val[NUM_SYS_POWERDOWN];
>> };
>>
>> diff --git a/arch/arm/mach-exynos/cpuidle.c
>> b/arch/arm/mach-exynos/cpuidle.c
>> index c57cae0..5dcdd46 100644
>> --- a/arch/arm/mach-exynos/cpuidle.c
>> +++ b/arch/arm/mach-exynos/cpuidle.c
>> @@ -17,6 +17,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -34,10 +35,10 @@
>>
>> #define REG_DIRECTGO_ADDR (samsung_rev() == EXYNOS4210_REV_1_1 ? \
>> S5P_INFORM7 : (samsung_rev() == EXYNOS4210_REV_1_0
>> ? \
>> - (S5P_VA_SYSRAM + 0x24) : S5P_INFORM0))
>> + 0x24 : S5P_INFORM0))
>> #define REG_DIRECTGO_FLAG (samsung_rev() == EXYNOS4210_REV_1_1 ? \
>> S5P_INFORM6 : (samsung_rev() == EXYNOS4210_REV_1_0
>> ? \
>> - (S5P_VA_SYSRAM + 0x20) : S5P_INFORM1))
>> + 0x20 : S5P_INFORM1))
>
>
> This patch seems to be based on old code, before Daniel Lezcano's Exynos
> cpuidle refactor [1] and it should be rebased on top of that series.
>
> [1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/29085
>
>
OK, I will rebase on top of it along with addressing all other review comments.
>>
>> #define S5P_CHECK_AFTR0xFCBA0D10
>>
>> @@ -60,6 +61,8 @@
>> #define PWR_CTRL2_CORE2_UP_RATIO (1 << 4)
>> #define PWR_CTRL2_CORE1_UP_RATIO (1 << 0)
>>
>> +static struct regmap *pmu_regmap;
>> +
>> static int exynos4_enter_lowpower(struct cpuidle_device *dev,
>> struct cpuidle_driver *drv,
>> int index);
>> @@ -87,7 +90,7 @@ static struct cpuidle_driver exynos4_idle_driver = {
>> /* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
>> static void exynos4_set_wakeupmask(void)
>> {
>> - __raw_writel(0xff3e, S5P_WAKEUP_MASK);
>> + regmap_write(pmu_regmap, S5P_WAKEUP_MASK, 0xff3e);
>> }
>>
>> static unsigned int g_pwr_ctrl, g_diag_reg;
>> @@ -120,22 +123,28 @@ static int exynos4_enter_core0_aftr(struct
>> cpuidle_device *dev,
>> struct cpuidle_driver *drv,
>> int index)
>> {
>> - unsigned long tmp;
>> + unsigned int tmp;
>>
>> exynos4_set_wakeupmask();
>>
>> /* Set value of power down register for aftr mode */
>> exynos_sys_powerdown_conf(SYS_AFTR);
>> -
>> - __raw_writel(virt_to_phys(exynos_cpu_resume), REG_DIRECTGO_ADDR);
>> - __raw_writel(S5P_CHECK_AFTR, REG_DIRECTGO_FLAG);
>> -
>> +
>> + if (samsung_rev() == EXYNOS4210_REV_1_0) {
>> + __raw_writel(virt_to_phys(exynos_cpu_resume),
>> + S5P_VA_SYSRAM + REG_DIRECTGO_ADDR);
>> + __raw_writel(S5P_CHECK_AFTR, S5P_VA_SYSRAM +
>> REG_DIRECTGO_FLAG);
>> + } else {
>> + regmap_write(pmu_regmap, REG_DIRECTGO_ADDR,
>> + vir
[rfc PATCH] checkpatch: allow multiple const * types
On Fri, 2014-04-25 at 10:50 +0300, Dan Carpenter wrote:
> On Fri, Apr 25, 2014 at 01:06:44AM -0300, Nicolas Del Piano wrote:
> > diff --git a/drivers/staging/comedi/drivers.c
> > b/drivers/staging/comedi/drivers.c
[]
> > @@ -439,6 +439,7 @@ static void *comedi_recognize(struct comedi_driver
> > *driv, const char *name)
> > static void comedi_report_boards(struct comedi_driver *driv)
> > {
> > unsigned int i;
> > +
> > const char *const *name_ptr;
>
> The original code was correct. This is a bug in checkpatch.pl. The
> missing line check should count any lines starting with "const" or
> "static" as declarations.
Right, thanks for the report.
I'm not around for a couple weeks.
I'll fix it properly later.
It looks like the $Type test in checkpatch
should allow multiple pointer declarations like
"const foo * const *"
instead of just
"const foo * const"
but it takes awhile to test that it doesn't stuff up
something else.
Andy? Any opinion of this?
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 89f44f1..daa4767 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -433,7 +433,7 @@ sub build_types {
}x;
$Type = qr{
$NonptrType
-
(?:(?:\s|\*|\[\])+\s*const|(?:\s|\*|\[\])+|(?:\s*\[\s*\])+)?
+
(?:(?:\s|\*|\[\])+\s*const|(?:\s|\*|\[\])+|(?:\s*\[\s*\])+)*
(?:\s+$Inline|\s+$Modifier)*
}x;
$Declare= qr{(?:$Storage\s+(?:$Inline\s+)?)?$Type};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] Add support for flag status register on Micron chips.
On Sat, Apr 26, 2014 at 12:12:24AM +0200, Marek Vasut wrote: > > > > the drivers may fills this hook itself, so the code should like this: > > > >-- > > > > > > > > if ((info->flags & USE_FSR) && > > > > > > > > nor->wait_till_ready == spi_nor_wait_till_fsr_ready) > > > > > > > > nor->wait_till_ready = spi_nor_wait_till_fsr_ready; > > > > > > > >-- > > > > > > I sense a misdesign of the SPI NOR subsystem here. The subsystem and the > > > driver compete for a function pointer here ? I guess one should have > > > precedence in some way then ... and also, they should be two different > > > pointers, where the subsystem decides which to use. > > > > the subsystem do not decides which one to use, the driver decides which one > > to use. > > > > If driver has its own @wait_till_ready , it means the driver knows the > > feature, and has implemented it in its own @wait_till_ready. > > > > If the driver does not fill any wait_till_ready, it means the driver will > > use the default @wait_till_ready. We can treat the > > spi_nor_wait_till_fsr_ready as a default hook too. > > I see the driver overwriting a hook previously set by the subsystem. This not sure ;) The driver set the hooks before the subsystem set these hooks. If the driver has already set the @wait_till_ready hook before it calls the spi_nor_scan, the subsystem will not set the hook anymore. Please see the spi_nor_check(). thanks Huang Shijie -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl-baytrail: fix for irq descriptor conflict on ASUS T100TA
On 2014/4/25 23:13, Adam Williamson wrote: > On Fri, 2014-04-25 at 11:32 +0200, Linus Walleij wrote: >> On Thu, Apr 24, 2014 at 11:33 PM, Adam Williamson >> wrote: >> >>> Well, I just ran another test too. I built a kernel (3.15rc2) with both >>> v3 of Doug's SDIO device enumeration patch - >>> http://dougvj.net/baytrail_gpio_quirk_v3.patch - and the new patch for >>> the IRQ allocation issue by Thomas Gleixner, >>> https://patchwork.kernel.org/patch/4051581/ . That kernel gives me a >>> working touchscreen. Note that >>> http://dougvj.net/baytrail_gpio_quirk_v3.patch includes both the blocks >>> you mention (i.e. it adds INT33FC in both places). >>> >>> So, it really seems like for me at least, it's the combination of Doug's >>> patch and your approach to fixing the IRQ allocation issue that breaks >>> the touchscreen. Thomas' approach, even combined with Doug's patch, >>> seems to work fine. >> >> Please make sure to provide a Tested-by: tag to Thomas so he >> knows this is merge material. > > Well, I'd rather someone test on the box that's actually affected by the > IRQ allocation conflict lockups so we can confirm it actually fixes > them :) > I have tried the Thomas Gleixner's patch on 3.14.0 with i915 loading, the irq conflict disappears. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 RESEND 0/5] clk: bcm21664: add common clock support
On Fri, Apr 25, 2014 at 05:09:15PM -0700, Mike Turquette wrote: > Quoting Alex Elder (2014-04-21 14:26:22) > > This is series has two parts. The first two patches are changes > > to the existing Broadcom Kona family clock code to prepare for the > > addition of support for another SoC, bcm21664. > > > > The remaining three define the binding and code for bcm21664, and > > replace the use of "fake" clocks in the device tree with the real > > ones. This ends up being a fairly straightforward definition of > > the clocks on this SoC; the rest of the clock code is shared with > > other SoCs that use the Kona style clock system. > > Hi Alex, > > I'm happy to take only the clk patches or I can take the DT stuff as > well if it gets some Acks. Let me know how you want it handled. Hi Mike, Since there's a strict ordering requirement in this series (due to shared use of a DT include by the driver and dts) I'd like it if you could take the entire series through your tree to keep these together. I've acked the dts patch. Thanks, Matt > > This series depends on the following patch, which has been taken > > into the clk-fixes tree: > > clk: bcm281xx: don't use unnamed structs or unions > > https://lkml.org/lkml/2014/4/7/322 > > > > In addition, it depends on the version 4 of the following series, > > just (re)posted for review: > > clk: bcm281xx: updates > > https://lkml.org/lkml/2014/4/8/485 > > > > The patches in this series--based on the current linus/master branch > > plus the patches mentioned above--are available here: > > http://git.linaro.org/git/landing-teams/working/broadcom/kernel.git > > Branch review/bcm21664-clock-v2 > > > > Alex Elder (5): > > clk: bcm281xx: move compatible string definitions > > ARM: dts: revise kona clock binding document > > ARM: dts: define clock binding for bcm21664 > > clk: bcm21664: use common clock framework > > ARM: dts: use real clocks for bcm21664 > > > > .../devicetree/bindings/clock/bcm-kona-clock.txt | 116 ++--- > > arch/arm/boot/dts/bcm21664.dtsi| 190 +- > > drivers/clk/bcm/Kconfig| 2 +- > > drivers/clk/bcm/Makefile | 1 + > > drivers/clk/bcm/clk-bcm21664.c | 290 > > + > > drivers/clk/bcm/clk-bcm281xx.c | 12 - > > include/dt-bindings/clock/bcm21664.h | 62 + > > include/dt-bindings/clock/bcm281xx.h | 12 + > > 8 files changed, 565 insertions(+), 120 deletions(-) > > create mode 100644 drivers/clk/bcm/clk-bcm21664.c > > create mode 100644 include/dt-bindings/clock/bcm21664.h > > > > -- > > 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V1 net-next 1/1] hyperv: Properly handle checksum offload
Do checksum offload only if the client of the driver wants checksum to be offloaded. In this version of the patch, I have addressed comments from Stephen Hemminger and Eric Dumazet . This patch fixes a bug that is exposed in gateway scenarios. Signed-off-by: K. Y. Srinivasan Reviewed-by: Haiyang Zhang Cc: sta...@kernel.org --- drivers/net/hyperv/netvsc_drv.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c index 939e3af..7ca9daa 100644 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -467,6 +467,9 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net) if (skb_is_gso(skb)) goto do_lso; + if (skb->ip_summed != CHECKSUM_PARTIAL) + goto do_send; + rndis_msg_size += NDIS_CSUM_PPI_SIZE; ppi = init_ppi_data(rndis_msg, NDIS_CSUM_PPI_SIZE, TCPIP_CHKSUM_PKTINFO); -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 RESEND 5/5] ARM: dts: use real clocks for bcm21664
On Mon, Apr 21, 2014 at 04:26:27PM -0500, Alex Elder wrote:
> Replace the "fake" fixed-rate clocks used previously for the
> bcm21664 family with "real" ones.
>
> Signed-off-by: Alex Elder
Acked-by: Matt Porter
> ---
> arch/arm/boot/dts/bcm21664.dtsi | 190
> +---
> 1 file changed, 118 insertions(+), 72 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm21664.dtsi b/arch/arm/boot/dts/bcm21664.dtsi
> index 08a44d4..8b36682 100644
> --- a/arch/arm/boot/dts/bcm21664.dtsi
> +++ b/arch/arm/boot/dts/bcm21664.dtsi
> @@ -14,6 +14,8 @@
> #include
> #include
>
> +#include "dt-bindings/clock/bcm21664.h"
> +
> #include "skeleton.dtsi"
>
> / {
> @@ -43,7 +45,7 @@
> compatible = "brcm,bcm21664-dw-apb-uart", "snps,dw-apb-uart";
> status = "disabled";
> reg = <0x3e00 0x118>;
> - clocks = <&uartb_clk>;
> + clocks = <&slave_ccu BCM21664_SLAVE_CCU_UARTB>;
> interrupts = ;
> reg-shift = <2>;
> reg-io-width = <4>;
> @@ -53,7 +55,7 @@
> compatible = "brcm,bcm21664-dw-apb-uart", "snps,dw-apb-uart";
> status = "disabled";
> reg = <0x3e001000 0x118>;
> - clocks = <&uartb2_clk>;
> + clocks = <&slave_ccu BCM21664_SLAVE_CCU_UARTB2>;
> interrupts = ;
> reg-shift = <2>;
> reg-io-width = <4>;
> @@ -63,7 +65,7 @@
> compatible = "brcm,bcm21664-dw-apb-uart", "snps,dw-apb-uart";
> status = "disabled";
> reg = <0x3e002000 0x118>;
> - clocks = <&uartb3_clk>;
> + clocks = <&slave_ccu BCM21664_SLAVE_CCU_UARTB3>;
> interrupts = ;
> reg-shift = <2>;
> reg-io-width = <4>;
> @@ -85,7 +87,7 @@
> compatible = "brcm,kona-timer";
> reg = <0x35006000 0x1c>;
> interrupts = ;
> - clocks = <&hub_timer_clk>;
> + clocks = <&aon_ccu BCM21664_AON_CCU_HUB_TIMER>;
> };
>
> gpio: gpio@35003000 {
> @@ -106,7 +108,7 @@
> compatible = "brcm,kona-sdhci";
> reg = <0x3f18 0x801c>;
> interrupts = ;
> - clocks = <&sdio1_clk>;
> + clocks = <&master_ccu BCM21664_MASTER_CCU_SDIO1>;
> status = "disabled";
> };
>
> @@ -114,7 +116,7 @@
> compatible = "brcm,kona-sdhci";
> reg = <0x3f19 0x801c>;
> interrupts = ;
> - clocks = <&sdio2_clk>;
> + clocks = <&master_ccu BCM21664_MASTER_CCU_SDIO2>;
> status = "disabled";
> };
>
> @@ -122,7 +124,7 @@
> compatible = "brcm,kona-sdhci";
> reg = <0x3f1a 0x801c>;
> interrupts = ;
> - clocks = <&sdio3_clk>;
> + clocks = <&master_ccu BCM21664_MASTER_CCU_SDIO3>;
> status = "disabled";
> };
>
> @@ -130,7 +132,7 @@
> compatible = "brcm,kona-sdhci";
> reg = <0x3f1b 0x801c>;
> interrupts = ;
> - clocks = <&sdio4_clk>;
> + clocks = <&master_ccu BCM21664_MASTER_CCU_SDIO4>;
> status = "disabled";
> };
>
> @@ -140,7 +142,7 @@
> interrupts = ;
> #address-cells = <1>;
> #size-cells = <0>;
> - clocks = <&bsc1_clk>;
> + clocks = <&slave_ccu BCM21664_SLAVE_CCU_BSC1>;
> status = "disabled";
> };
>
> @@ -150,7 +152,7 @@
> interrupts = ;
> #address-cells = <1>;
> #size-cells = <0>;
> - clocks = <&bsc2_clk>;
> + clocks = <&slave_ccu BCM21664_SLAVE_CCU_BSC2>;
> status = "disabled";
> };
>
> @@ -160,7 +162,7 @@
> interrupts = ;
> #address-cells = <1>;
> #size-cells = <0>;
> - clocks = <&bsc3_clk>;
> + clocks = <&slave_ccu BCM21664_SLAVE_CCU_BSC3>;
> status = "disabled";
> };
>
> @@ -170,105 +172,149 @@
> interrupts = ;
> #address-cells = <1>;
> #size-cells = <0>;
> - clocks = <&bsc4_clk>;
> + clocks = <&slave_ccu BCM21664_SLAVE_CCU_BSC4>;
> status = "disabled";
> };
>
> clocks {
> - bsc1_clk: bsc1 {
> - compatible = "fixed-clock";
> - clock-frequency = <1300>;
> - #clock-cells = <0>;
> - };
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
>
> - bsc2_clk: bsc2 {
> - compatible = "fixed-clock";
> - clock-frequency = <1300>;
> + /*
> + * Fixed clocks are defined before CCUs whose
> +
Re: [PATCH 00/13] Refactor pci_is_brdige() to simplify code
On 2014/4/25 17:42, David Laight wrote:
> From: Yijing Wang
>> This patchset rename the current pci_is_bridge() to pci_has_subordinate(),
>> and introduce a new pci_is_bridge() which determine pci bridge by check
>> dev->hdr_type. The new one is more accurate. PCIe Spec define the pci
>> device is a bridge by the dev->hdr_type = 0x01 || 0x02.
>
> That is a dangerous rename and is likely to cause difficult to
Hi David,
I renamed pci_is_bridge() to pci_has_subordinate() because
static inline bool pci_is_bridge(struct pci_dev *pci_dev)
{
return !!(pci_dev->subordinate);
}
which always check dev->subordinate.
> identify bugs in any code you've missed.
What are you referring to ?
Thanks!
Yijing.
>
> David
>
> �{.n�+���+%��lzwm��b�맲��r��zX�� �w��{ay� ʇڙ�,j��f���h���z� �w���
> ���j:+v���w�j�mzZ+�ݢj"��!�iO��z��v�^�m nƊ��Y&�
>
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH net-next 1/1] hyperv: Properly handle checksum offload
> -Original Message- > From: driverdev-devel-boun...@linuxdriverproject.org [mailto:driverdev- > devel-boun...@linuxdriverproject.org] On Behalf Of KY Srinivasan > Sent: Friday, April 25, 2014 7:24 PM > To: Eric Dumazet; Stephen Hemminger > Cc: o...@aepfle.de; net...@vger.kernel.org; jasow...@redhat.com; linux- > ker...@vger.kernel.org; sta...@kernel.org; a...@canonical.com; > de...@linuxdriverproject.org; da...@davemloft.net > Subject: RE: [PATCH net-next 1/1] hyperv: Properly handle checksum offload > > > > > -Original Message- > > From: Eric Dumazet [mailto:eric.duma...@gmail.com] > > Sent: Friday, April 25, 2014 6:15 PM > > To: Stephen Hemminger > > Cc: KY Srinivasan; da...@davemloft.net; net...@vger.kernel.org; linux- > > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > > a...@canonical.com; jasow...@redhat.com; sta...@kernel.org > > Subject: Re: [PATCH net-next 1/1] hyperv: Properly handle checksum > > offload > > > > On Fri, 2014-04-25 at 17:43 -0700, Stephen Hemminger wrote: > > > On Fri, 25 Apr 2014 11:45:14 -0700 > > > "K. Y. Srinivasan" wrote: > > > > > > > @@ -474,6 +477,9 @@ static int netvsc_start_xmit(struct sk_buff > > > > *skb, > > struct net_device *net) > > > > csum_info = (struct ndis_tcp_ip_checksum_info *)((void *)ppi + > > > > ppi->ppi_offset); > > > > > > > > + ip_hdr(skb)->check = 0; > > > > + csum_info->transmit.ip_header_checksum = 1; > > > > + > > > > if (net_trans_info & (INFO_IPV4 << 16)) > > > > csum_info->transmit.is_ipv4 = 1; > > > > else > > > > > > Linux doesn't need or want IP checksum offload. > > > It will not have any performance gain. > > > > > > BTW, was this patch even tested with IPv6 packets ??? > > No; I only tested this on ipv4. Oops; this would not work on ipv6. I am going to resend this patch. K. Y > > K. Y > > > > ___ > devel mailing list > de...@linuxdriverproject.org > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: dgap: implement error handling in dgap_tty_register()
Hi, please check below my comments. 2014-04-25 23:41 GMT+09:00 Mark Hounschell : > On 04/25/2014 08:59 AM, Dan Carpenter wrote: >> On Fri, Apr 25, 2014 at 08:29:41AM -0400, Mark Hounschell wrote: >>> On 04/25/2014 07:02 AM, DaeSeok Youn wrote: Hi, Dan. 2014-04-25 18:26 GMT+09:00 Dan Carpenter : > Mark, maybe you should add yourself to the MAINTAINERS entry for this > driver? > >>> >>> I'll look into this. I am clueless on what that would actually mean. >>> >> >> Just add your name with Lidza in the MAINTAINERS file so that people >> will CC you on all the patches. >> >> DIGI EPCA PCI PRODUCTS >> M: Lidza Louina >> L: driverdev-de...@linuxdriverproject.org >> S: Maintained >> F: drivers/staging/dgap/ >> >> You don't have to do it if you don't want to, but you seem to be working >> on this driver and I'm going to refer questions to you either way. :P >> > On Fri, Apr 25, 2014 at 04:04:59PM +0900, Daeseok Youn wrote: >> @@ -1263,7 +1277,8 @@ static int dgap_tty_register(struct board_t *brd) >> /* Register tty devices */ >> rc = tty_register_driver(brd->SerialDriver); >> if (rc < 0) >> - return rc; >> + goto free_print_ttys; >> + >> brd->dgap_Major_Serial_Registered = TRUE; >> dgap_BoardsByMajor[brd->SerialDriver->major] = brd; >> brd->dgap_Serial_Major = brd->SerialDriver->major; >> @@ -1273,13 +1288,29 @@ static int dgap_tty_register(struct board_t *brd) >> /* Register Transparent Print devices */ >> rc = tty_register_driver(brd->PrintDriver); >> if (rc < 0) >> - return rc; >> + goto unregister_serial_drv; >> + >> brd->dgap_Major_TransparentPrint_Registered = TRUE; >> dgap_BoardsByMajor[brd->PrintDriver->major] = brd; >> brd->dgap_TransparentPrint_Major = brd->PrintDriver->major; >> } >> >> return rc; >> + >> +unregister_serial_drv: >> + tty_unregister_driver(brd->SerialDriver); > > We only register the ->SerialDriver if someone else hasn't registered it > first? So this should be: > > if (we_were_the_ones_who_registered_the_serial_driver) > tty_unregister_driver(brd->SerialDriver); > > I haven't followed looked at this. Who else is registering the serial > driver? You have looked at this, what do you think? Or Mark. >>> >>> registering the brd->XDriver is only done when a board is detected >>> and only during the firmware_load process. If we fail to >>> tty_register_driver do we _need_ to tty_unregister_driver? Isn't that >>> like freeing after an alloc failure? >> >> The allocation is conditional so the free should be conditional. If we >> didn't allocate it, then we shouldn't free it. >> >> It wouldn't have even been a question except I'm not sure the allocation >> is *really* conditional because brd->dgap_Major_Serial_Registered might >> always be "false" like you guys seem to be saying. >> >>> I think brd struct is from dgap_Board array as global static variable when this function is called. So brd->dgap_Major_Serial_Registered is always "false". If dgap_NumBoards is less than MAXBOARDS, brd->SerialDriver should be registered. I'm not sure.. >>> >>> I don't see any check for (dgap_NumBoards < MAXBOARDS), which I think I >>> probably should, but I do see we are calling dgap_tty_register, which >>> can fail, without actually checking the return value. Also, yes, >>> dgap_Major_Xxxx_Registered seems to be always "false" until registered, >>> and it looks like dgap_Major_X_Registered flags could be removed >>> because the only places we can unregister is at module_cleanup or >>> "after" it is already registered. >>> >>> What is the driver _supposed_ to do if we fail something on the second >>> or later board? Is the driver supposed to cleanup and exit or are we >>> supposed to stay loaded for the board/boards that are usable? >> >> Stay loaded. >> > > Then these tests on brd->dgap_Major_Serial_Registered need to stay in > there. If I have 3 boards and the second fails in some way, if I rmmod > the driver they will protect from unregistering a never registered one. > At least in the unregister code path. There is probably no need for them > in the register code path. I'll work up a patch for this. Should I update my patch? I think "if (!brd->dgap_Major_XXX_Registered)" line can be removed in this function, because if tty_register_driver() is failed just set "false" to "dgap_Major_XXX_Registered". dgap_Major_XXX_Registered only is used in cleaup function, right? So code like below rc = tty_register_driver(brd->PrintDriver); if (rc < 0)
RE: [PATCH net-next 1/1] hyperv: Properly handle checksum offload
> -Original Message- > From: Eric Dumazet [mailto:eric.duma...@gmail.com] > Sent: Friday, April 25, 2014 6:15 PM > To: Stephen Hemminger > Cc: KY Srinivasan; da...@davemloft.net; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > a...@canonical.com; jasow...@redhat.com; sta...@kernel.org > Subject: Re: [PATCH net-next 1/1] hyperv: Properly handle checksum offload > > On Fri, 2014-04-25 at 17:43 -0700, Stephen Hemminger wrote: > > On Fri, 25 Apr 2014 11:45:14 -0700 > > "K. Y. Srinivasan" wrote: > > > > > @@ -474,6 +477,9 @@ static int netvsc_start_xmit(struct sk_buff *skb, > struct net_device *net) > > > csum_info = (struct ndis_tcp_ip_checksum_info *)((void *)ppi + > > > ppi->ppi_offset); > > > > > > + ip_hdr(skb)->check = 0; > > > + csum_info->transmit.ip_header_checksum = 1; > > > + > > > if (net_trans_info & (INFO_IPV4 << 16)) > > > csum_info->transmit.is_ipv4 = 1; > > > else > > > > Linux doesn't need or want IP checksum offload. > > It will not have any performance gain. > > > BTW, was this patch even tested with IPv6 packets ??? No; I only tested this on ipv4. K. Y >
RE: [PATCH net-next 1/1] hyperv: Properly handle checksum offload
> -Original Message- > From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Friday, April 25, 2014 5:43 PM > To: KY Srinivasan > Cc: da...@davemloft.net; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > a...@canonical.com; jasow...@redhat.com; sta...@kernel.org > Subject: Re: [PATCH net-next 1/1] hyperv: Properly handle checksum offload > > On Fri, 25 Apr 2014 11:45:14 -0700 > "K. Y. Srinivasan" wrote: > > > @@ -474,6 +477,9 @@ static int netvsc_start_xmit(struct sk_buff *skb, > struct net_device *net) > > csum_info = (struct ndis_tcp_ip_checksum_info *)((void *)ppi + > > ppi->ppi_offset); > > > > + ip_hdr(skb)->check = 0; > > + csum_info->transmit.ip_header_checksum = 1; > > + > > if (net_trans_info & (INFO_IPV4 << 16)) > > csum_info->transmit.is_ipv4 = 1; > > else > > Linux doesn't need or want IP checksum offload. > It will not have any performance gain. Thanks Stephen; I will re-spin the patch and re-submit. K. Y -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] ARM: Exynos: PMU cleanup and refactoring for using DT
Hi Tomasz, On Sat, Apr 26, 2014 at 7:43 AM, Tomasz Figa wrote: > > Hi Pankaj, > > Just a small note - please refrain from sending next versions of series in > reply to previous version. With threading applied, it gets hard to notice > that a new version was posted, because the first message of the thread is > always v1. Also it makes threads unnecessarily long. > OK. I will take care in future. > > Best regards, > Tomasz > > > On 25.04.2014 14:32, Pankaj Dubey wrote: >> >> This patch series, does some minor cleanup and modifies Exynos PMU related >> code for mapping and initialization of Exynos Power Management Unit (PMU) >> base address from device tree. This is also preparation for moving PMU >> related code out of machine folder and moving into a "drivers/mfd", so that >> ARM64 based SoC can utilize common piece of code. These patches require >> change >> in Exynos4210, Exynos4212 and Exynos4412 dtsi files, which has been posted >> as separate patch series [2] >> >> These patches are created on top of Kukjin Kim's for-next (v3.15-rc1 tag) >> branch. >> >> These patches depends on following two patch series: >> 1) mfd: syscon: Support early initialization >> https://lkml.org/lkml/2014/4/8/239 >> 2) Add PMU node for Exynos SoCs >> >> http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg29329.html >> >> We have tested these patches on SMDK5250 and Arndale (Exynos5250) boards for >> System boot and PMU initialization and S2R. >> >> For testing on Arndale (Exynos5250) board: >> Tested-by: Pankaj Dubey >> >> Changes Since v1: >> - Rebased on latest for-next of Kukjin Kim's tree. >> - Added patch: "Make exynos machine_ops as static". >> For making more cleanup in "mach-exynos/common.h" >> as suggested by Tomasz Figa. >> - Addressed comments of Tomasz Figa for cleaning "mach-exynos/common.h". >> - Updated patch: Remove file path from comment section >> As suggested by Michel Simek, instead of updating file path >> lets remove them from each file under "mach-exynos". >> Even though Kukjin pointed out that there is similar patch pending >> from >> Sachin/Tushar but since I could not find I have included this here. >> If >> I have missed something please point to any existing such patch. >> - Updated patch: Add support for mapping PMU base address via DT >> - Removed __initdata from declaration of "exynos_pmu_base", as it >> caused >> kernel crash as pointed out by Vikas Sajjan. >> - Added support for Syscon initialization and getting PMU regmap >> handle >> as suggested by Sylwester. Since current implementation of early >> intialization [1] has limitation that "early_syscon_init" requires >> DT to be unflattened and system should be able to allocate memory, >> we can't use regmap handles for platsmp.c file as >> "smp_secondary_init" >> will be called before DT unflattening. So I have kept both method for >> accessing PMU base address. platsmp.c will use ioremmaped address >> where >> as rest other files can use regmap handle. >> - Added patch: Remove "linux/bug.h" from pmu.c. >> - Updated patch: Refactored code for PMU register mapping via DT >> - Modified to use regmap_read/write when using regmap handle. >> - Added patch: Move "mach/map.h" inclusion from regs-pmu.h to platsmp.c >> - Added patch: Add device tree based initialization support for PMU. >> - Convert existing PMU implementation to be a device tree based >> before moving it to "drivers/mfd" folder. As suggested by >> Bartlomiej. >> - Dropped making a platform_driver for PMU, as currently PMU binding >> has two compatibility strings as "samsung, exynosxxx-pmu", "syscon", >> once we enable MFD_SYSCON config option, current "syscon" driver >> probe >> gets called and PMU probe never gets called. So modified PMU >> initialization code to scan DT and match against supported >> compatiblity >> string in driver code, and once we get matching node use that for >> accessing PMU regmap handle using >> "syscon_early_regmap_lookup_by_phandle". >> If there is any better solution please suggest. >> >> Pankaj Dubey (6): >>ARM: EXYNOS: Make exynos machine_ops as static >>ARM: EXYNOS: Cleanup "mach-exynos/common.h" file >>ARM: EXYNOS: Remove file path from comment section >>ARM: EXYNOS: Refactored code for using PMU address via DT >>ARM: EXYNOS: Move "mach/map.h" inclusion from regs-pmu.h to platsmp.c >>ARM: EXYNOS: Add device tree based initialization support for PMU. >> >> Young-Gun Jang (4): >>ARM: EXYNOS: Move SYSREG definition into sys-reg specific file. >>ARM: EXYNOS: Remove regs-pmu.h header dependency from pm_domain >>ARM: EXYNOS: Add support for mapping PMU base address via DT >>ARM: EXYNOS: Remove "linux/bug.h" from pmu.c >> >> arch/arm
Re: [PATCH RFC 0/2] percpu_ida: Take into account CPU topology when stealing tags
On 2014-04-25 18:01, Ming Lei wrote: Hi Jens, On Sat, Apr 26, 2014 at 5:23 AM, Jens Axboe wrote: On 04/25/2014 03:10 AM, Ming Lei wrote: Sorry, I did run it the other day. It has little to no effect here, but that's mostly because there's so much other crap going on in there. The most effective way to currently make it work better, is just to ensure the caching pool is of a sane size. Yes, that is just what the patch is doing, :-) But it's not enough. For instance, my test case, it's 255 tags and 64 CPUs. We end up in cross-cpu spinlock nightmare mode. From percpu_ida view, it is easy to observe it can improve allocation performance. I have several patches to export these information by sysfs for monitoring percpu_ida performance. Sounds good! I've got an alternative tagging scheme that I think would be useful for the cases where the tag space to cpu ratio isn't big enough. So I think we'll retain percpu_ida for the cases where it can cache enough, and punt to an alternative scheme when not. OK, care to comment on the patch or the idea of setting percpu cache size as (nr_tags / hctx->nr_ctx)? I think it's a good idea. The problem is that for percpu_ida to be effective, you need a bigger cache than the 3 I'd get above. If that isn't the case, it performs poorly. I'm just not convinced the design can ever work in the realm of realistic queue depths. That doesn't mean we should not improve percpu_ida. There's quite a bit of low hanging fruit in there. IMO percpu_max_size in percpu_ida is very important for the performance, and it might need to adjust dynamically according to the percpu allocation loading, but it is far more complicated to implement. And it might be the simplest way to fix the parameter before percpu_ida_init(). That's what I did, essentially. Ensuring that the percpu_max_size is at least 8 makes it a whole lot better here. But still slower than a regular simple bitmap, which makes me sad. A fairly straight forward cmpxchg based scheme I tested here is around 20% faster than the bitmap approach on a basic desktop machine, and around 35% faster on a 4-socket. Outside of NVMe, I can't think of cases where that approach would not be faster than percpu_ida. That means all of SCSI, basically, and the basic block drivers. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core
On 24.04.2014 15:11, Ulf Hansson wrote:
On 24 April 2014 12:13, Geert Uytterhoeven wrote:
When adding a device from DT, check if its clocks are suitable for Runtime
PM, and register them with the PM core.
If Runtime PM is disabled, just enable the clock.
This allows the PM core to automatically manage gate clocks of devices for
Runtime PM.
Normally I don't think it's a good idea to "automatically" manage
clocks from PM core or any other place but from the driver (and
possibly the subsystem).
The reason is simply that we hide things that normally is supposed to
be handled by the driver. Typically a cross SOC driver should work
fine both with and without a pm_domain. It should also not rely on
CONFIG_PM_RUNTIME.
Signed-off-by: Geert Uytterhoeven
---
drivers/of/Makefile|1 +
drivers/of/of_clk.c| 103
drivers/of/platform.c |3 ++
include/linux/of_clk.h | 18 +
4 files changed, 125 insertions(+)
create mode 100644 drivers/of/of_clk.c
create mode 100644 include/linux/of_clk.h
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index ed9660adad77..49bcd413906f 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_MTD) += of_mtd.o
obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
+obj-$(CONFIG_COMMON_CLK) += of_clk.o
diff --git a/drivers/of/of_clk.c b/drivers/of/of_clk.c
new file mode 100644
index ..35f5e9f3dd42
--- /dev/null
+++ b/drivers/of/of_clk.c
@@ -0,0 +1,103 @@
+/*
+ * Copyright (C) 2014 Glider bvba
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#ifdef CONFIG_PM_RUNTIME
+
+static int of_clk_pm_runtime_suspend(struct device *dev)
+{
+ int ret;
+
+ ret = pm_generic_runtime_suspend(dev);
+ if (ret)
+ return ret;
+
+ ret = pm_clk_suspend(dev);
+ if (ret) {
+ pm_generic_runtime_resume(dev);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int of_clk_pm_runtime_resume(struct device *dev)
+{
+ pm_clk_resume(dev);
+ return pm_generic_runtime_resume(dev);
+}
+
+static struct dev_pm_domain of_clk_pm_domain = {
+ .ops = {
+ .runtime_suspend = of_clk_pm_runtime_suspend,
+ .runtime_resume = of_clk_pm_runtime_resume,
+ USE_PLATFORM_PM_SLEEP_OPS
+ },
+};
+
+static int of_clk_register(struct device *dev, struct clk *clk)
+{
+ int error;
+
+ if (!dev->pm_domain) {
+ error = pm_clk_create(dev);
+ if (error)
+ return error;
+
+ dev->pm_domain = &of_clk_pm_domain;
I am concerned about how this will work in conjunction with the
generic power domain.
A device can't reside in more than one pm_domain; thus I think it
would be better to always use the generic power domain and not have a
specific one for clocks. Typically the genpd should invoke
pm_clk_resume|suspend from it's runtime PM callbacks.
I'm not sure about this. A typical use case would be to gate clocks ASAP
and then wait until device is idle long enough to consider turning off
the power domain worthwhile. Also sometimes we may want to gate the
clocks, but prevent power domain from being powered off to retain
hardware state (e.g. because there is no way to read it and restore later).
I believe, though, that for devices that are not inside a controllable
power domain, this might be a good solution.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 10/12] scsi/NCR5380: remove unused macro definitions
Acked-by: MIchael Schmitz
Remove the unused (and divergent) debugging macro definitions from
the sun3_NCR5380 and atari_NCR5380 drivers. These drivers have been
converted to use the common macros in NCR5380.h.
Signed-off-by: Finn Thain
---
drivers/scsi/atari_scsi.h | 93 ---
drivers/scsi/sun3_scsi.h | 181
--
2 files changed, 274 deletions(-)
Index: linux-m68k/drivers/scsi/atari_scsi.h
===
--- linux-m68k.orig/drivers/scsi/atari_scsi.h 2014-03-19 23:23:02.0
+1100
+++ linux-m68k/drivers/scsi/atari_scsi.h2014-03-19 23:34:45.0
+1100
@@ -80,99 +80,6 @@
#define SCSI_RESET_HOST_RESET 0x200
#define SCSI_RESET_ACTION 0xff
-/* Debugging printk definitions:
- *
- * ARB -> arbitration
- * ASEN -> auto-sense
- * DMA -> DMA
- * HSH -> PIO handshake
- * INF -> information transfer
- * INI -> initialization
- * INT -> interrupt
- * LNK -> linked commands
- * MAIN -> NCR5380_main() control flow
- * NDAT -> no data-out phase
- * NWR -> no write commands
- * PIO -> PIO transfers
- * PDMA -> pseudo DMA (unused on Atari)
- * QU -> queues
- * RSL -> reselections
- * SEL -> selections
- * USL -> usleep cpde (unused on Atari)
- * LBS -> last byte sent (unused on Atari)
- * RSS -> restarting of selections
- * EXT -> extended messages
- * ABRT -> aborting and resetting
- * TAG -> queue tag handling
- * MER -> merging of consec. buffers
- *
- */
-
-#define dprint(flg, format...) \
-({ \
- if (NDEBUG & (flg)) \
- printk(KERN_DEBUG format); \
-})
-
-#define ARB_PRINTK(format, args...) \
- dprint(NDEBUG_ARBITRATION, format , ## args)
-#define ASEN_PRINTK(format, args...) \
- dprint(NDEBUG_AUTOSENSE, format , ## args)
-#define DMA_PRINTK(format, args...) \
- dprint(NDEBUG_DMA, format , ## args)
-#define HSH_PRINTK(format, args...) \
- dprint(NDEBUG_HANDSHAKE, format , ## args)
-#define INF_PRINTK(format, args...) \
- dprint(NDEBUG_INFORMATION, format , ## args)
-#define INI_PRINTK(format, args...) \
- dprint(NDEBUG_INIT, format , ## args)
-#define INT_PRINTK(format, args...) \
- dprint(NDEBUG_INTR, format , ## args)
-#define LNK_PRINTK(format, args...) \
- dprint(NDEBUG_LINKED, format , ## args)
-#define MAIN_PRINTK(format, args...) \
- dprint(NDEBUG_MAIN, format , ## args)
-#define NDAT_PRINTK(format, args...) \
- dprint(NDEBUG_NO_DATAOUT, format , ## args)
-#define NWR_PRINTK(format, args...) \
- dprint(NDEBUG_NO_WRITE, format , ## args)
-#define PIO_PRINTK(format, args...) \
- dprint(NDEBUG_PIO, format , ## args)
-#define PDMA_PRINTK(format, args...) \
- dprint(NDEBUG_PSEUDO_DMA, format , ## args)
-#define QU_PRINTK(format, args...) \
- dprint(NDEBUG_QUEUES, format , ## args)
-#define RSL_PRINTK(format, args...) \
- dprint(NDEBUG_RESELECTION, format , ## args)
-#define SEL_PRINTK(format, args...) \
- dprint(NDEBUG_SELECTION, format , ## args)
-#define USL_PRINTK(format, args...) \
- dprint(NDEBUG_USLEEP, format , ## args)
-#define LBS_PRINTK(format, args...) \
- dprint(NDEBUG_LAST_BYTE_SENT, format , ## args)
-#define RSS_PRINTK(format, args...) \
- dprint(NDEBUG_RESTART_SELECT, format , ## args)
-#define EXT_PRINTK(format, args...) \
- dprint(NDEBUG_EXTENDED, format , ## args)
-#define ABRT_PRINTK(format, args...) \
- dprint(NDEBUG_ABORT, format , ## args)
-#define TAG_PRINTK(format, args...) \
- dprint(NDEBUG_TAGS, format , ## args)
-#define MER_PRINTK(format, args...) \
- dprint(NDEBUG_MERGING, format , ## args)
-
-/* conditional macros for NCR5380_print_{,phase,status} */
-
-#define NCR_PRINT(mask)\
- ((NDEBUG & (mask)) ? NCR5380_print(instance) : (void)0)
-
-#define NCR_PRINT_PHASE(mask) \
- ((NDEBUG & (mask)) ? NCR5380_print_phase(instance) : (void)0)
-
-#define NCR_PRINT_STATUS(mask) \
- ((NDEBUG & (mask)) ? NCR5380_print_status(instance) : (void)0)
-
-
#endif /* ndef ASM */
#endif /* ATARI_SCSI_H */
Index: linux-m68k/drivers/scsi/sun3_scsi.h
===
--- linux-m68k.orig/drivers/scsi/sun3_scsi.h2014-03-19 23:34:41.0
+1100
+++ linux-m68k/drivers/scsi/sun3_scsi.h 2014-03-19 23:34:45.0 +1100
@@ -182,188 +182,7 @@ struct sun3_udc_regs {
#define VME_DATA24 0x3d00
-// debugging printk's, taken from atari_scsi.h
-/* Debugging printk definitions:
- *
- * ARB -> arbitration
- * ASEN -> auto-sense
- * DMA -> DMA
- * HSH -> PIO handshake
- * INF -> information transfer
- * INI -> initialization
- * INT -> interrupt
- * LNK -> linked commands
- * MAIN -> NCR5380_main() control flow
- * NDAT -> no data-out phase
- * NWR -> no write commands
- *
Re: [PATCH v2] clk: qcom: Add support for IPQ8064's global clock controller (GCC)
On 04/04/14 13:19, Kumar Gala wrote:
> +
> +#define P_PXO0
> +#define P_PLL8 1
> +#define P_CXO2
> +#define P_PLL3 3
This #define needs to be 1. Unfortunately the way we do this mapping
requires that they match the parents string array. If you have a better
idea I'm all for it.
> +
> +static const u8 gcc_pxo_pll8_map[] = {
> + [P_PXO] = 0,
> + [P_PLL8]= 3,
> +};
> +
> +static const char *gcc_pxo_pll8[] = {
> + "pxo",
> + "pll8_vote",
> +};
> +
> +static const u8 gcc_pxo_pll8_cxo_map[] = {
> + [P_PXO] = 0,
> + [P_PLL8]= 3,
> + [P_CXO] = 5,
> +};
> +
> +static const char *gcc_pxo_pll8_cxo[] = {
> + "pxo",
> + "pll8_vote",
> + "cxo",
> +};
> +
> +static const u8 gcc_pxo_pll3_map[] = {
> + [P_PXO] = 0,
> + [P_PLL3]= 1,
> +};
> +
> +static const char *gcc_pxo_pll3[] = {
> + "pxo",
> + "pll3",
> +};
> +
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 08/12] scsi/NCR5380: adopt dprintk()
Acked-by: Michael Schmitz
All NCR5380 drivers already include the NCR5380.h header. Better to
adopt those macros rather than have three variations on them.
Moreover, the macros in NCR5380.h are preferable because the atari_NCR5380
and sun3_NCR5380 versions are inflexible. For example, they can't accomodate
dprintk(NDEBUG_MAIN | NDEBUG_QUEUES, ...)
Replace the *_PRINTK macros from atari_NCR5380.h and sun3_NCR5380.h with
the equivalent macros from NCR5380.h.
Signed-off-by: Finn Thain
---
drivers/scsi/atari_NCR5380.c | 130
+--
drivers/scsi/atari_scsi.c| 16 ++---
drivers/scsi/sun3_NCR5380.c | 122
3 files changed, 134 insertions(+), 134 deletions(-)
Index: linux-m68k/drivers/scsi/atari_NCR5380.c
===
--- linux-m68k.orig/drivers/scsi/atari_NCR5380.c2014-03-19
23:34:43.0 +1100
+++ linux-m68k/drivers/scsi/atari_NCR5380.c 2014-03-19 23:34:44.0
+1100
@@ -370,7 +370,7 @@ static int is_lun_busy(Scsi_Cmnd *cmd, i
return 0;
if (TagAlloc[cmd->device->id][cmd->device->lun].nr_allocated >=
TagAlloc[cmd->device->id][cmd->device->lun].queue_size) {
- TAG_PRINTK("scsi%d: target %d lun %d: no free tags\n",
+ dprintk(NDEBUG_TAGS, "scsi%d: target %d lun %d: no free tags\n",
H_NO(cmd), cmd->device->id, cmd->device->lun);
return 1;
}
@@ -394,7 +394,7 @@ static void cmd_get_tag(Scsi_Cmnd *cmd,
!setup_use_tagged_queuing || !cmd->device->tagged_supported) {
cmd->tag = TAG_NONE;
hostdata->busy[cmd->device->id] |= (1 << cmd->device->lun);
- TAG_PRINTK("scsi%d: target %d lun %d now allocated by untagged "
+ dprintk(NDEBUG_TAGS, "scsi%d: target %d lun %d now allocated by
untagged "
"command\n", H_NO(cmd), cmd->device->id,
cmd->device->lun);
} else {
TAG_ALLOC *ta = &TagAlloc[cmd->device->id][cmd->device->lun];
@@ -402,7 +402,7 @@ static void cmd_get_tag(Scsi_Cmnd *cmd,
cmd->tag = find_first_zero_bit(ta->allocated, MAX_TAGS);
set_bit(cmd->tag, ta->allocated);
ta->nr_allocated++;
- TAG_PRINTK("scsi%d: using tag %d for target %d lun %d "
+ dprintk(NDEBUG_TAGS, "scsi%d: using tag %d for target %d lun %d
"
"(now %d tags in use)\n",
H_NO(cmd), cmd->tag, cmd->device->id,
cmd->device->lun, ta->nr_allocated);
@@ -420,7 +420,7 @@ static void cmd_free_tag(Scsi_Cmnd *cmd)
if (cmd->tag == TAG_NONE) {
hostdata->busy[cmd->device->id] &= ~(1 << cmd->device->lun);
- TAG_PRINTK("scsi%d: target %d lun %d untagged cmd finished\n",
+ dprintk(NDEBUG_TAGS, "scsi%d: target %d lun %d untagged cmd
finished\n",
H_NO(cmd), cmd->device->id, cmd->device->lun);
} else if (cmd->tag >= MAX_TAGS) {
printk(KERN_NOTICE "scsi%d: trying to free bad tag %d!\n",
@@ -429,7 +429,7 @@ static void cmd_free_tag(Scsi_Cmnd *cmd)
TAG_ALLOC *ta = &TagAlloc[cmd->device->id][cmd->device->lun];
clear_bit(cmd->tag, ta->allocated);
ta->nr_allocated--;
- TAG_PRINTK("scsi%d: freed tag %d for target %d lun %d\n",
+ dprintk(NDEBUG_TAGS, "scsi%d: freed tag %d for target %d lun
%d\n",
H_NO(cmd), cmd->tag, cmd->device->id,
cmd->device->lun);
}
}
@@ -478,7 +478,7 @@ static void merge_contiguous_buffers(Scs
for (endaddr = virt_to_phys(cmd->SCp.ptr + cmd->SCp.this_residual - 1)
+ 1;
cmd->SCp.buffers_residual &&
virt_to_phys(sg_virt(&cmd->SCp.buffer[1])) == endaddr;) {
- MER_PRINTK("VTOP(%p) == %08lx -> merging\n",
+ dprintk(NDEBUG_MERGING, "VTOP(%p) == %08lx -> merging\n",
page_address(sg_page(&cmd->SCp.buffer[1])), endaddr);
#if (NDEBUG & NDEBUG_MERGING)
++cnt;
@@ -490,7 +490,7 @@ static void merge_contiguous_buffers(Scs
}
#if (NDEBUG & NDEBUG_MERGING)
if (oldlen != cmd->SCp.this_residual)
- MER_PRINTK("merged %d buffers from %p, new length %08x\n",
+ dprintk(NDEBUG_MERGING, "merged %d buffers from %p, new length
%08x\n",
cnt, cmd->SCp.ptr, cmd->SCp.this_residual);
#endif
}
@@ -676,7 +676,7 @@ static inline void NCR5380_all_init(void
{
static int done = 0;
if (!done) {
- INI_PRINTK("scsi : NCR5380_all_init()\n");
+ dprintk(NDEBUG_INIT, "scsi : NCR5380_all_init()\n");
done = 1;
}
}
@@ -984,7 +984,7 @@ static int NCR5380_queue_command_lck(Scs
Re: [PATCH v2 07/12] scsi/NCR5380: adopt NCR5380_dprint() and NCR5380_dprint_phase()
Acked-by: Michael Schmitz
All NCR5380 drivers already include the NCR5380.h header. Better to
adopt those macros rather than have three variations on them.
Moreover, the macros in NCR5380.h are preferable anyway: the atari_NCR5380
and sun3_NCR5380 versions are inflexible. For example, they can't accomodate
NCR5380_dprint(NDEBUG_MAIN | NDEBUG_QUEUES, ...)
Replace the NCR_PRINT* macros from atari_NCR5380.h and sun3_NCR5380.h with
the equivalent macros from NCR5380.h.
Signed-off-by: Finn Thain
---
drivers/scsi/atari_NCR5380.c | 22 +++---
drivers/scsi/sun3_NCR5380.c | 22 +++---
2 files changed, 22 insertions(+), 22 deletions(-)
Index: linux-m68k/drivers/scsi/atari_NCR5380.c
===
--- linux-m68k.orig/drivers/scsi/atari_NCR5380.c2014-03-19
23:23:02.0 +1100
+++ linux-m68k/drivers/scsi/atari_NCR5380.c 2014-03-19 23:34:43.0
+1100
@@ -739,8 +739,8 @@ static void NCR5380_print_status(struct
Scsi_Cmnd *ptr;
unsigned long flags;
- NCR_PRINT(NDEBUG_ANY);
- NCR_PRINT_PHASE(NDEBUG_ANY);
+ NCR5380_dprint(NDEBUG_ANY, instance);
+ NCR5380_dprint_phase(NDEBUG_ANY, instance);
hostdata = (struct NCR5380_hostdata *)instance->hostdata;
@@ -1268,7 +1268,7 @@ static irqreturn_t NCR5380_intr(int irq,
INT_PRINTK("scsi%d: BASR=%02x\n", HOSTNO, basr);
/* dispatch to appropriate routine if found and done=0 */
if (basr & BASR_IRQ) {
- NCR_PRINT(NDEBUG_INTR);
+ NCR5380_dprint(NDEBUG_INTR, instance);
if ((NCR5380_read(STATUS_REG) & (SR_SEL|SR_IO)) ==
(SR_SEL|SR_IO)) {
done = 0;
ENABLE_IRQ();
@@ -1396,7 +1396,7 @@ static int NCR5380_select(struct Scsi_Ho
unsigned long flags;
hostdata->restart_select = 0;
- NCR_PRINT(NDEBUG_ARBITRATION);
+ NCR5380_dprint(NDEBUG_ARBITRATION, instance);
ARB_PRINTK("scsi%d: starting arbitration, id = %d\n", HOSTNO,
instance->this_id);
@@ -1617,7 +1617,7 @@ static int NCR5380_select(struct Scsi_Ho
printk(KERN_ERR "scsi%d: weirdness\n", HOSTNO);
if (hostdata->restart_select)
printk(KERN_NOTICE "\trestart select\n");
- NCR_PRINT(NDEBUG_ANY);
+ NCR5380_dprint(NDEBUG_ANY, instance);
NCR5380_write(SELECT_ENABLE_REG, hostdata->id_mask);
return -1;
}
@@ -1742,7 +1742,7 @@ static int NCR5380_transfer_pio(struct S
/* Check for phase mismatch */
if ((tmp & PHASE_MASK) != p) {
PIO_PRINTK("scsi%d: phase mismatch\n", HOSTNO);
- NCR_PRINT_PHASE(NDEBUG_PIO);
+ NCR5380_dprint_phase(NDEBUG_PIO, instance);
break;
}
@@ -1764,18 +1764,18 @@ static int NCR5380_transfer_pio(struct S
if (!(p & SR_IO)) {
if (!((p & SR_MSG) && c > 1)) {
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE |
ICR_ASSERT_DATA);
- NCR_PRINT(NDEBUG_PIO);
+ NCR5380_dprint(NDEBUG_PIO, instance);
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE |
ICR_ASSERT_DATA | ICR_ASSERT_ACK);
} else {
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE |
ICR_ASSERT_DATA | ICR_ASSERT_ATN);
- NCR_PRINT(NDEBUG_PIO);
+ NCR5380_dprint(NDEBUG_PIO, instance);
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE |
ICR_ASSERT_DATA | ICR_ASSERT_ATN
| ICR_ASSERT_ACK);
}
} else {
- NCR_PRINT(NDEBUG_PIO);
+ NCR5380_dprint(NDEBUG_PIO, instance);
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE |
ICR_ASSERT_ACK);
}
@@ -1997,7 +1997,7 @@ static void NCR5380_information_transfer
phase = (tmp & PHASE_MASK);
if (phase != old_phase) {
old_phase = phase;
- NCR_PRINT_PHASE(NDEBUG_INFORMATION);
+ NCR5380_dprint_phase(NDEBUG_INFORMATION,
instance);
}
if (sink && (phase != PHASE_MSGOUT)) {
@@ -2451,7 +2451,7 @@ static void NCR5380_information_transfer
break;
default:
printk("scsi%d: unknown phase\n", HOSTNO);
Re: [PATCH v2 RESEND 0/5] clk: bcm21664: add common clock support
On 04/25/2014 07:09 PM, Mike Turquette wrote: > Quoting Alex Elder (2014-04-21 14:26:22) >> This is series has two parts. The first two patches are changes >> to the existing Broadcom Kona family clock code to prepare for the >> addition of support for another SoC, bcm21664. >> >> The remaining three define the binding and code for bcm21664, and >> replace the use of "fake" clocks in the device tree with the real >> ones. This ends up being a fairly straightforward definition of >> the clocks on this SoC; the rest of the clock code is shared with >> other SoCs that use the Kona style clock system. > > Hi Alex, > > I'm happy to take only the clk patches or I can take the DT stuff as > well if it gets some Acks. Let me know how you want it handled. If all you need is an ack from Matt or Christian I'm sure they'll provide it. I don't care much but if you'll take it all I can just consider it done, so that would be my slight preference. The DT stuff has been out there for way past the requisite few weeks... Thanks Mike. -Alex > Regards, > Mike > >> >> This series depends on the following patch, which has been taken >> into the clk-fixes tree: >> clk: bcm281xx: don't use unnamed structs or unions >> https://lkml.org/lkml/2014/4/7/322 >> >> In addition, it depends on the version 4 of the following series, >> just (re)posted for review: >> clk: bcm281xx: updates >> https://lkml.org/lkml/2014/4/8/485 >> >> The patches in this series--based on the current linus/master branch >> plus the patches mentioned above--are available here: >> http://git.linaro.org/git/landing-teams/working/broadcom/kernel.git >> Branch review/bcm21664-clock-v2 >> >> Alex Elder (5): >> clk: bcm281xx: move compatible string definitions >> ARM: dts: revise kona clock binding document >> ARM: dts: define clock binding for bcm21664 >> clk: bcm21664: use common clock framework >> ARM: dts: use real clocks for bcm21664 >> >> .../devicetree/bindings/clock/bcm-kona-clock.txt | 116 ++--- >> arch/arm/boot/dts/bcm21664.dtsi| 190 +- >> drivers/clk/bcm/Kconfig| 2 +- >> drivers/clk/bcm/Makefile | 1 + >> drivers/clk/bcm/clk-bcm21664.c | 290 >> + >> drivers/clk/bcm/clk-bcm281xx.c | 12 - >> include/dt-bindings/clock/bcm21664.h | 62 + >> include/dt-bindings/clock/bcm281xx.h | 12 + >> 8 files changed, 565 insertions(+), 120 deletions(-) >> create mode 100644 drivers/clk/bcm/clk-bcm21664.c >> create mode 100644 include/dt-bindings/clock/bcm21664.h >> >> -- >> 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mfd: pm8x41: add support for Qualcomm 8x41 PMICs
On 04/23/2014 04:36 PM, Courtney Cavin wrote:
> On Wed, Apr 23, 2014 at 11:46:26PM +0200, Josh Cartwright wrote:
>> On Tue, Apr 22, 2014 at 05:31:49PM -0700, Courtney Cavin wrote:
[..]
>>> +++ b/drivers/mfd/pm8x41.c
>>> @@ -0,0 +1,63 @@
>>> +/* Copyright (c) 2013, The Linux Foundation. All rights reserved.
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 and
>>> + * only version 2 as published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + */
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +static const struct regmap_config pm8x41_regmap_config = {
>>> + .reg_bits = 16,
>>> + .val_bits = 8,
>>> + .max_register = 0x,
>>> +};
>>
>> This reminds me. David Collins (CC'd) noticed that there are usecases
>> where peripheral drivers will need to be accessing registers from atomic
>> context, so we should probably be setting .fast_io in the SPMI
>> regmap_bus structures, but we can tackle that when we get there.
>
> Hrm. Please comment on this David. I would like to see a solid
> use-case before even considering that.
Several drivers in the downstream msm-3.10 tree [1] are currently making
SPMI read and write calls from atomic context. For the most part this
corresponds to non-threaded interrupt handlers. Some examples of that are
qpnp-charger [2] and qpnp-adc-tm [3].
Another case in which atomic SPMI read and write calls are needed is when
very tight timing constraints must be ensured between successive SPMI
transactions. An example of this can be found in the qpnp-bsi MIPI-BIF
smart battery driver [4]. It disables interrupts when performing BIF
burst reads because the data register must be read within 10's of
microseconds after the status register indicates that data is ready. If
the data read is too slow, then next word in the burst read overrides the
current one.
- David
[1]: git://codeaurora.org/quic/la/kernel/msm-3.10#msm-3.10
[2]:
https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/drivers/power/qpnp-charger.c?h=msm-3.10&id=77ea4f2d70056169a80519fc9c7dd7156469ef11#n4173
[3]:
https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/drivers/thermal/qpnp-adc-tm.c?h=msm-3.10&id=77ea4f2d70056169a80519fc9c7dd7156469ef11#n2076
[4]:
https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/drivers/bif/qpnp-bsi.c?h=msm-3.10&id=77ea4f2d70056169a80519fc9c7dd7156469ef11#n943
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] at91: fixes for 3.15 #1
On 18/04/2014 14:52, Nicolas Ferre :
> Arnd, Olof, Kevin,
>
> Two little fixes for AT91. The one that moves the dt-bindings include
> directory is pretty interesting as, with Exynos, AT91 was the only one
> to use this "clk" directory.
>
> Thanks, best regards,
>
> The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5:
>
> Linux 3.15-rc1 (2014-04-13 14:18:35 -0700)
>
> are available in the git repository at:
>
> git://github.com/at91linux/linux-at91.git tags/at91-fixes
Arnd,
It seems that this material has not been integrated in today's arm-soc
pull-request to Linus.
Was it too late for this batch?
Bye,
> for you to fetch changes up to 35d35aae817706800a4913711d563a99e1dc380a:
>
> dt-bindings: clock: Move at91.h to dt-bindigs/clock (2014-04-18 23:44:52
> +0200)
>
>
> 3.15 fixes for AT91
> - one little DT fix
> - the use of proper directory for clock in include/dt-bindings
> it allows to remove the now empty include/dt-bindings/clk
>
>
> Bo Shen (1):
> ARM: at91: fix spi cs on sama5d3 Xplained board
>
> Tushar Behera (1):
> dt-bindings: clock: Move at91.h to dt-bindigs/clock
>
> Documentation/devicetree/bindings/clock/at91-clock.txt | 2 +-
> arch/arm/boot/dts/at91-sama5d3_xplained.dts| 4 ++--
> arch/arm/boot/dts/at91sam9261.dtsi | 2 +-
> arch/arm/boot/dts/at91sam9rl.dtsi | 2 +-
> arch/arm/boot/dts/sama5d3.dtsi | 2 +-
> arch/arm/boot/dts/sama5d3_mci2.dtsi| 2 +-
> arch/arm/boot/dts/sama5d3_tcb1.dtsi| 2 +-
> arch/arm/boot/dts/sama5d3_uart.dtsi| 2 +-
> include/dt-bindings/{clk => clock}/at91.h | 0
> 9 files changed, 9 insertions(+), 9 deletions(-)
> rename include/dt-bindings/{clk => clock}/at91.h (100%)
>
--
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 1/1] hyperv: Properly handle checksum offload
On Fri, 2014-04-25 at 17:43 -0700, Stephen Hemminger wrote: > On Fri, 25 Apr 2014 11:45:14 -0700 > "K. Y. Srinivasan" wrote: > > > @@ -474,6 +477,9 @@ static int netvsc_start_xmit(struct sk_buff *skb, > > struct net_device *net) > > csum_info = (struct ndis_tcp_ip_checksum_info *)((void *)ppi + > > ppi->ppi_offset); > > > > + ip_hdr(skb)->check = 0; > > + csum_info->transmit.ip_header_checksum = 1; > > + > > if (net_trans_info & (INFO_IPV4 << 16)) > > csum_info->transmit.is_ipv4 = 1; > > else > > Linux doesn't need or want IP checksum offload. > It will not have any performance gain. BTW, was this patch even tested with IPv6 packets ??? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mfd: pm8x41: add support for Qualcomm 8x41 PMICs
On 4/25/2014 5:40 PM, Courtney Cavin wrote:
> On Sat, Apr 26, 2014 at 02:28:06AM +0200, Frank Rowand wrote:
>> On 4/23/2014 6:19 AM, Ivan T. Ivanov wrote:
> [...]
+static int pm8x41_probe(struct spmi_device *sdev)
+{
+ struct regmap *regmap;
+
+ regmap = devm_regmap_init_spmi_ext(sdev, &pm8x41_regmap_config);
+ if (IS_ERR(regmap)) {
+ dev_dbg(&sdev->dev, "regmap creation failed.\n");
+ return PTR_ERR(regmap);
+ }
+
+ return of_platform_populate(sdev->dev.of_node, NULL, NULL, &sdev->dev);
>>>
>>> I think that this will not going to work. For example in this particular
>>> case, both controllers have "qcom,qpnp-revid" peripheral which is
>>> located at offset 0x100.
>>>
>>> And the result is:
>>>
>>> [0.963944] sysfs: cannot create duplicate filename
>>> '/bus/platform/devices/100.revid'
>>
>> The duplicate filename error is because pm8x41_probe() is calling
>> of_platform_populate()
>> directly.
>>
>> If that call is removed then there is no attempt to create a revid file in
>> /sys/bus/platform/devices. If I add your pm8841@4 node to my dts file, then
>> the 100.revid file is properly created at
>>
>>
>> /sys/firmware/devicetree/base/soc/qcom,spmi@fc4cf000/pm8841@4/qcom,revid@100
>>
>> and no attempt is made to create /sys/bus/platform/devices/100.revid
>>
>> This appears to be correct to me, because I do not think revid should be
>> created as
>> a platform device.
>>
>
> Wait, what? That's the entire point of this driver.
>
> [...]
>>> Any suggestions?
>>
>> Remove of_platform_populate() from pm8x41_probe(). Do you know of any
>> other reason it can not be removed?
>
> I do! If you remove it, the entire driver becomes a useless pile of
> nothing!
>
> The PMICs targeted by this driver are mostly made up of independent
> blocks which should be able to be written as standalone device drivers.
> The design of this driver is to create a simple bus-like layer between
> SPMI and these independent blocks. of_platform_populate() is what makes
> it work.
>
> -Courtney
>
H, yet another device tree conceptual thing for me to grok. I'll go
off and see if a bus-like layer can exist without being a platform device.
-Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 7/7] ARM: dts: Add device tree sources for Exynos3250
Hi Chanwoo,
On 25.04.2014 03:16, Chanwoo Choi wrote:
From: Tomasz Figa
This patch add new exynos3250.dtsi to support Exynos3250 SoC based on Cortex-A7
dual core and includes following dt nodes:
- GIC interrupt controller
- Pinctrl to control GPIOs
- Clock controller
- CPU information (Cortex-A7 dual core)
- UART to support serial port
- MCT (Multi Core Timer)
- ADC (Analog Digital Converter)
- I2C/SPI bus
- Power domain
- PMU (Performance Monitoring Unit)
- MSHC (Mobile Storage Host Controller)
- PWM (Pluse Width Modulation)
- AMBA bus
Signed-off-by: Tomasz Figa
Signed-off-by: Chanwoo Choi
Signed-off-by: Kyungmin Park
Signed-off-by: Inki Dae
Signed-off-by: Hyunhee Kim
Signed-off-by: Jaehoon Chung
Signed-off-by: Bartlomiej Zolnierkiewicz
Cc: Ben Dooks
Cc: Kukjin Kim
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Russell King
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 477 +++
arch/arm/boot/dts/exynos3250.dtsi | 405 +
arch/arm/boot/dts/exynos4212-tizenw.dts | 926 ++
3 files changed, 1808 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos3250-pinctrl.dtsi
create mode 100644 arch/arm/boot/dts/exynos3250.dtsi
create mode 100644 arch/arm/boot/dts/exynos4212-tizenw.dts
diff --git a/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
new file mode 100644
index 000..976490b
--- /dev/null
+++ b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
@@ -0,0 +1,477 @@
+/*
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config optiosn are listed as
device
+ * tree nodes are listed in this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/ {
+ pinctrl@1140 {
Could you use references instead of re-specifying the whole tree
hierarchy in every file a node is used?
Instead of
/ {
pinctrl@1140 {
};
};
one may simply use
&pinctrl_0 {
};
You might just need to change the location of #include
"exynos3250-pinctrl.dtsi" from top of exynos3250.dtsi to bottom of it.
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpb: gpb {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpc0: gpc0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpc1: gpc1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpd0: gpd0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpd1: gpd1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ uart0_data: uart0-data {
+ samsung,pins = "gpa0-0", "gpa0-1";
+ samsung,pin-function = <0x2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart0_fctl: uart0-fctl {
+ samsung,pins = "gpa0-2", "gpa0-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart1_data: uart1-data {
+ samsung,pins = "gpa0-4", "gpa0-5";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart1_fctl: uart1-fctl {
+ samsung,pins = "gpa0-6", "gpa0-7";
+ samsung,pin-f
Re: [PATCH net-next 1/1] hyperv: Properly handle checksum offload
On Fri, 25 Apr 2014 11:45:14 -0700 "K. Y. Srinivasan" wrote: > @@ -474,6 +477,9 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct > net_device *net) > csum_info = (struct ndis_tcp_ip_checksum_info *)((void *)ppi + > ppi->ppi_offset); > > + ip_hdr(skb)->check = 0; > + csum_info->transmit.ip_header_checksum = 1; > + > if (net_trans_info & (INFO_IPV4 << 16)) > csum_info->transmit.is_ipv4 = 1; > else Linux doesn't need or want IP checksum offload. It will not have any performance gain. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 2/7] ARM: EXYNOS: Support secondary CPU boot of Exynos4212
Hi,
On 25.04.2014 03:16, Chanwoo Choi wrote:
From: Kyungmin Park
This patch fix the offset of CPU boot address and change parameter of smc call
of SMC_CMD_CPU1BOOT command for Exynos4212.
Signed-off-by: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
arch/arm/mach-exynos/firmware.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 932129e..aa01c42 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -18,6 +18,8 @@
#include
+#include
+
#include "smc.h"
static int exynos_do_idle(void)
@@ -28,13 +30,24 @@ static int exynos_do_idle(void)
static int exynos_cpu_boot(int cpu)
{
+ /*
+* The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
+* But, Exynos4212 has only one secondary CPU so second parameter
+* isn't used for informing secure firmware about CPU id.
+*/
+ if (soc_is_exynos4212())
+ cpu = 0;
+
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
return 0;
}
static int exynos_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
{
- void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
+ void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
+
+ if (!soc_is_exynos4212())
+ boot_reg += 4*cpu;
__raw_writel(boot_addr, boot_reg);
return 0;
This patch should be applied independently of Exynos3250 support.
Kukjin, what do you think?
Anyway,
Reviewed-by: Tomasz Figa
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 1/7] ARM: EXYNOS: Add Exynos3250 SoC ID
Hi Chanwoo, On 25.04.2014 03:16, Chanwoo Choi wrote: This patch add Exynos3250's SoC ID. Exynos 3250 is System-On-Chip(SoC) that is based on the 32-bit RISC processor for Smartphone. Exynos3250 uses Cortex-A7 dual cores and has a target speed of 1.0GHz. Signed-off-by: Chanwoo Choi Acked-by: Kyungmin Park --- arch/arm/mach-exynos/Kconfig | 22 ++ arch/arm/mach-exynos/exynos.c| 2 ++ arch/arm/plat-samsung/include/plat/cpu.h | 10 ++ 3 files changed, 34 insertions(+) You can add my Reviewed-by: Tomasz Figa Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mfd: pm8x41: add support for Qualcomm 8x41 PMICs
On Sat, Apr 26, 2014 at 02:28:06AM +0200, Frank Rowand wrote:
> On 4/23/2014 6:19 AM, Ivan T. Ivanov wrote:
[...]
> >> +static int pm8x41_probe(struct spmi_device *sdev)
> >> +{
> >> + struct regmap *regmap;
> >> +
> >> + regmap = devm_regmap_init_spmi_ext(sdev, &pm8x41_regmap_config);
> >> + if (IS_ERR(regmap)) {
> >> + dev_dbg(&sdev->dev, "regmap creation failed.\n");
> >> + return PTR_ERR(regmap);
> >> + }
> >> +
> >> + return of_platform_populate(sdev->dev.of_node, NULL, NULL, &sdev->dev);
> >
> > I think that this will not going to work. For example in this particular
> > case, both controllers have "qcom,qpnp-revid" peripheral which is
> > located at offset 0x100.
> >
> > And the result is:
> >
> > [0.963944] sysfs: cannot create duplicate filename
> > '/bus/platform/devices/100.revid'
>
> The duplicate filename error is because pm8x41_probe() is calling
> of_platform_populate()
> directly.
>
> If that call is removed then there is no attempt to create a revid file in
> /sys/bus/platform/devices. If I add your pm8841@4 node to my dts file, then
> the 100.revid file is properly created at
>
> /sys/firmware/devicetree/base/soc/qcom,spmi@fc4cf000/pm8841@4/qcom,revid@100
>
> and no attempt is made to create /sys/bus/platform/devices/100.revid
>
> This appears to be correct to me, because I do not think revid should be
> created as
> a platform device.
>
Wait, what? That's the entire point of this driver.
[...]
> > Any suggestions?
>
> Remove of_platform_populate() from pm8x41_probe(). Do you know of any
> other reason it can not be removed?
I do! If you remove it, the entire driver becomes a useless pile of
nothing!
The PMICs targeted by this driver are mostly made up of independent
blocks which should be able to be written as standalone device drivers.
The design of this driver is to create a simple bus-like layer between
SPMI and these independent blocks. of_platform_populate() is what makes
it work.
-Courtney
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 5/7] clk: samsung: exynos3250: Add clocks using common clock framework
Hi Chanwoo, On 25.04.2014 03:16, Chanwoo Choi wrote: From: Tomasz Figa This patch add new the clock drvier of Exynos3250 SoC based on Cortex-A7 using common clock framework. The CMU (Clock Management Unit) of Exynos3250 control PLLs(Phase Locked Loops) and generate system clocks for CPU, buses, and function clocks for individual IPs. The CMU of Exynos3250 includes following clock doamins: - CPU block for Cortex-A7 MPCore processor - LEFTBUS/RIGHTBUS block - TOP block for G3D/MFC/LCD0/ISP/CAM/FSYS/MFC/PERIL/PERIR In original driver present in our internal tree I have separated several CMUs to account for certain factors caused by hardware design, which require such separation. Is there any reason why they were merged together into a single CMU again? Cc: Mike Turquette Cc: Kukjin Kim Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Signed-off-by: Tomasz Figa Signed-off-by: Chanwoo Choi Signed-off-by: Hyunhee Kim Signed-off-by: Sylwester Nawrocki Signed-off-by: Inki Dae Signed-off-by: Seung-Woo Kim Signed-off-by: Jaehoon Chung Signed-off-by: Karol Wrona Signed-off-by: YoungJun Cho Signed-off-by: Kyungmin Park --- drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos3250.c | 785 + include/dt-bindings/clock/exynos3250.h | 256 +++ 3 files changed, 1042 insertions(+) create mode 100644 drivers/clk/samsung/clk-exynos3250.c create mode 100644 include/dt-bindings/clock/exynos3250.h diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile index 8eb4799..d120797 100644 --- a/drivers/clk/samsung/Makefile +++ b/drivers/clk/samsung/Makefile @@ -3,6 +3,7 @@ # obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o +obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o obj-$(CONFIG_ARCH_EXYNOS4)+= clk-exynos4.o obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o diff --git a/drivers/clk/samsung/clk-exynos3250.c b/drivers/clk/samsung/clk-exynos3250.c new file mode 100644 index 000..0574a76 --- /dev/null +++ b/drivers/clk/samsung/clk-exynos3250.c @@ -0,0 +1,785 @@ +/* + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * Common Clock Framework support for Exynos3250 SoC. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "clk.h" +#include "clk-pll.h" + +#define SRC_LEFTBUS0x4200 +#define DIV_LEFTBUS0x4500 +#define GATE_IP_LEFTBUS0x4800 +#define SRC_RIGHTBUS 0x8200 +#define DIV_RIGHTBUS 0x8500 +#define GATE_IP_RIGHTBUS 0x8800 +#define GATE_IP_PERIR 0x8960 +#define MPLL_LOCK 0xc010 +#define MPLL_CON0 0xc110 +#define VPLL_LOCK 0xc020 +#define VPLL_CON0 0xc120 +#define UPLL_LOCK 0xc030 +#define UPLL_CON0 0xc130 +#define SRC_TOP0 0xc210 +#define SRC_TOP1 0xc214 +#define SRC_CAM0xc220 +#define SRC_MFC0xc228 +#define SRC_G3D0xc22c +#define SRC_LCD0xc234 +#define SRC_ISP0xc238 +#define SRC_FSYS 0xc240 +#define SRC_PERIL0 0xc250 +#define SRC_PERIL1 0xc254 +#define SRC_MASK_TOP 0xc310 +#define SRC_MASK_CAM 0xc320 +#define SRC_MASK_LCD 0xc334 +#define SRC_MASK_ISP 0xc338 +#define SRC_MASK_FSYS 0xc340 +#define SRC_MASK_PERIL00xc350 +#define SRC_MASK_PERIL10xc354 +#define DIV_TOP0xc510 +#define DIV_CAM0xc520 +#define DIV_MFC0xc528 +#define DIV_G3D0xc52c +#define DIV_LCD0xc534 +#define DIV_ISP0xc538 +#define DIV_FSYS0 0xc540 +#define DIV_FSYS1 0xc544 +#define DIV_FSYS2 0xc548 +#define DIV_PERIL0 0xc550 +#define DIV_PERIL1 0xc554 +#define DIV_PERIL3 0xc55c +#define DIV_PERIL4 0xc560 +#define DIV_PERIL5 0xc564 +#define DIV_CAM1 0xc568 +#define CLKDIV2_RATIO 0xc580 +#define GATE_SCLK_CAM 0xc820 +#define GATE_SCLK_MFC 0xc828 +#define GATE_SCLK_G3D 0xc82c +#define GATE_SCLK_LCD 0xc834 +#define GATE_SCLK_ISP_TOP 0xc838 +#define GATE_SCLK_FSYS 0xc840 +#define GATE_SCLK_PERIL0xc850 +#define GATE_IP_CAM0xc920 +#define GATE_IP_MFC0xc928 +#define GATE_IP_G3D0xc92c +#define GATE_IP_LCD0xc934 +#define
Re: [PATCHv4 4/7] ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7
On Sat, Apr 26, 2014 at 02:25:03AM +0200, Tomasz Figa wrote:
> On 25.04.2014 03:16, Chanwoo Choi wrote:
>> This patch decide proper lowpower mode of either a15 or a9 according to own
>> ID
>> from Main ID register.
>>
>> Cc: Arnd Bergmann
>> Cc: Marc Zynigier
>> Signed-off-by: Chanwoo Choi
>> Acked-by: Kyungmin Park
>> ---
>> arch/arm/mach-exynos/hotplug.c | 19 ---
>> 1 file changed, 12 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
>> index 5eead53..acf3119 100644
>> --- a/arch/arm/mach-exynos/hotplug.c
>> +++ b/arch/arm/mach-exynos/hotplug.c
>> @@ -135,16 +135,21 @@ void __ref exynos_cpu_die(unsigned int cpu)
>> int primary_part = 0;
>>
>> /*
>> - * we're ready for shutdown now, so do it.
>> - * Exynos4 is A9 based while Exynos5 is A15; check the CPU part
>> - * number by reading the Main ID register and then perform the
>> - * appropriate sequence for entering low power.
>> + * Prepare the CPU for shutting down. The required sequence of
>> + * operations depends on core type. CPUID part number can be used to
>> + * determine the right way.
>> */
>> -asm("mrc p15, 0, %0, c0, c0, 0" : "=r"(primary_part) : : "cc");
>> -if ((primary_part & 0xfff0) == 0xc0f0)
>> +primary_part = read_cpuid_part_number();
>> +
>> +switch (primary_part) {
>> +case ARM_CPU_PART_CORTEX_A7:
>> +case ARM_CPU_PART_CORTEX_A15:
Although I believe we're approaching the point where everyone just uses
ARM Ltd designed CPUs, it should be remembered that the part number
field is designer specific, so if we were being strict, we'd check both
the part number and the designer fields together.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mfd: pm8x41: add support for Qualcomm 8x41 PMICs
On 4/23/2014 6:19 AM, Ivan T. Ivanov wrote:
>
> Hi,
>
> On Tue, 2014-04-22 at 17:31 -0700, Courtney Cavin wrote:
>> From: Josh Cartwright
>>
>> The Qualcomm 8941 and 8841 PMICs are components used with the Snapdragon
>> 800 series SoC family. This driver exists largely as a glue mfd component,
>> it exists to be an owner of an SPMI regmap for children devices
>> described in device tree.
>>
>
> Thanks. This is exactly what I have planed to do :-)
>
>> Signed-off-by: Josh Cartwright
>> Signed-off-by: Courtney Cavin
>> ---
>> drivers/mfd/Kconfig | 13 +++
>> drivers/mfd/Makefile | 1 +
>> drivers/mfd/pm8x41.c | 63
>>
>> 3 files changed, 77 insertions(+)
>> create mode 100644 drivers/mfd/pm8x41.c
>>
>
>
>
>> +
>> +static int pm8x41_probe(struct spmi_device *sdev)
>> +{
>> +struct regmap *regmap;
>> +
>> +regmap = devm_regmap_init_spmi_ext(sdev, &pm8x41_regmap_config);
>> +if (IS_ERR(regmap)) {
>> +dev_dbg(&sdev->dev, "regmap creation failed.\n");
>> +return PTR_ERR(regmap);
>> +}
>> +
>> +return of_platform_populate(sdev->dev.of_node, NULL, NULL, &sdev->dev);
>
> I think that this will not going to work. For example in this particular
> case, both controllers have "qcom,qpnp-revid" peripheral which is
> located at offset 0x100.
>
> And the result is:
>
> [0.963944] sysfs: cannot create duplicate filename
> '/bus/platform/devices/100.revid'
The duplicate filename error is because pm8x41_probe() is calling
of_platform_populate()
directly.
If that call is removed then there is no attempt to create a revid file in
/sys/bus/platform/devices. If I add your pm8841@4 node to my dts file, then
the 100.revid file is properly created at
/sys/firmware/devicetree/base/soc/qcom,spmi@fc4cf000/pm8841@4/qcom,revid@100
and no attempt is made to create /sys/bus/platform/devices/100.revid
This appears to be correct to me, because I do not think revid should be
created as
a platform device.
>
> DT looks like this:
>
> spmi {
> compatible = "qcom,spmi-pmic-arb";
> reg-names = "core", "intr", "cnfg";
> reg = <0xfc4cf000 0x1000>,
> <0xfc4cb000 0x1000>,
> <0xfc4ca000 0x1000>;
>
> interrupt-names = "periph_irq";
> interrupts = <0 190 0>;
>
> qcom,ee = <0>;
> qcom,channel = <0>;
>
> #address-cells = <2>;
> #size-cells = <0>;
>
> interrupt-controller;
> #interrupt-cells = <4>;
>
> pm8941@0 {
> compatible = "qcom,pm8941";
> reg = <0x0 SPMI_USID>;
>
> #address-cells = <1>;
> #size-cells = <0>;
>
> revid@100 {
> compatible = "qcom,qpnp-revid";
> reg = <0x100 0x100>;
> };
> };
>
> pm8841@4 {
typo nit - that should be pm8941@4.
The nit does not change what you reported though.
> compatible = "qcom,pm8941";
> reg = <0x4 SPMI_USID>;
>
> #address-cells = <1>;
> #size-cells = <0>;
>
> revid@100 {
> compatible = "qcom,qpnp-revid";
> reg = <0x100 0x100>;
> };
> };
> };
>
> Any suggestions?
Remove of_platform_populate() from pm8x41_probe(). Do you know of any
other reason it can not be removed?
-Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tty: serial: 8250_core.c Bug fix for Exar chips.
The sleep function was updated to put the serial port to sleep only when
necessary.
This appears to resolve the errant behavior of the driver as described in
Kernel Bug 61961 – "My Exar Corp. XR17C/D152 Dual PCI UART modem does not
work with 3.8.0".
Signed-off-by: Michael Welling
---
drivers/tty/serial/8250/8250_core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 81f909c..1d32355 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -555,7 +555,7 @@ static void serial8250_set_sleep(struct uart_8250_port *p,
int sleep)
*/
if ((p->port.type == PORT_XR17V35X) ||
(p->port.type == PORT_XR17D15X)) {
- serial_out(p, UART_EXAR_SLEEP, 0xff);
+ serial_out(p, UART_EXAR_SLEEP, sleep ? 0xff : 0);
return;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: silicom: Add appropriate ifdef conditions in bpctl_mod.c
2014-04-26 7:33 GMT+09:00, Greg KH : > On Mon, Apr 07, 2014 at 12:03:41PM +0900, Daeseok Youn wrote: >> >> The bp_proc_create() can be called if BP_PROC_SUPPORT is defined. >> >> Signed-off-by: Daeseok Youn >> --- >> drivers/staging/silicom/bpctl_mod.c |5 + >> 1 files changed, 5 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/staging/silicom/bpctl_mod.c >> b/drivers/staging/silicom/bpctl_mod.c >> index 6b9365b..5a3d758 100644 >> --- a/drivers/staging/silicom/bpctl_mod.c >> +++ b/drivers/staging/silicom/bpctl_mod.c >> @@ -119,7 +119,10 @@ static void if_scan_init(void); >> >> static int bypass_proc_create_dev_sd(struct bpctl_dev >> *pbp_device_block); >> static int bypass_proc_remove_dev_sd(struct bpctl_dev >> *pbp_device_block); >> + >> +#ifdef BP_PROC_SUPPORT >> static int bp_proc_create(void); >> +#endif > > No, this code should just be removed, right? Yes, someone sent a patch for this. Regards, Daeseok Youn > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 4/7] ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7
Hi Chanwoo,
On 25.04.2014 03:16, Chanwoo Choi wrote:
This patch decide proper lowpower mode of either a15 or a9 according to own ID
from Main ID register.
Cc: Arnd Bergmann
Cc: Marc Zynigier
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/mach-exynos/hotplug.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..acf3119 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -135,16 +135,21 @@ void __ref exynos_cpu_die(unsigned int cpu)
int primary_part = 0;
/*
-* we're ready for shutdown now, so do it.
-* Exynos4 is A9 based while Exynos5 is A15; check the CPU part
-* number by reading the Main ID register and then perform the
-* appropriate sequence for entering low power.
+* Prepare the CPU for shutting down. The required sequence of
+* operations depends on core type. CPUID part number can be used to
+* determine the right way.
*/
- asm("mrc p15, 0, %0, c0, c0, 0" : "=r"(primary_part) : : "cc");
- if ((primary_part & 0xfff0) == 0xc0f0)
+ primary_part = read_cpuid_part_number();
+
+ switch (primary_part) {
+ case ARM_CPU_PART_CORTEX_A7:
+ case ARM_CPU_PART_CORTEX_A15:
cpu_enter_lowpower_a15();
- else
+ break;
+ default:
cpu_enter_lowpower_a9();
+ break;
+ }
platform_do_lowpower(cpu, &spurious);
I have noticed Leela Krishna Amudala's patch [1] that removes this
distinction completely and simply uses generic code. Could you check if
this works on Exynos3250 as well? If yes, then this patch could be
dropped and Leela's one would be enough.
[1]
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg29064.html
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 00/11] CPU idle for Armada XP
On Mon, Apr 14, 2014 at 05:10:03PM +0200, Gregory CLEMENT wrote: > This patch set adds the CPU idle support for Armada XP and prepares > the support for Armada 370. This was based on the work of Nadav > Haklai. > > The main change in this new version is a rebasing onto the v3.15-rc1 > and the last PMSU reworked series sent by Thomas Petazzoni: > http://www.spinics.net/lists/arm-kernel/msg322113.html > > The first patch should go through ARM subsystem and should be taken by > Russell King. It was alreadu submitted to Russell's patch system. > > All the other patches can go to mvebu subsystem (and then arm-soc), as > the PM related patches have received the acked-by from Daniel > Lezcano. From my point of view this series is ready to be pulled. > > The whole series (and the pmsu patches needed) is also available in > the branch CPU-idle-ArmadaXP-v7 at > https://github.com/MISL-EBU-System-SW/mainline-public.git Whole series, except patch #1, applied to mvebu/soc-cpuidle. I made one change as I noted in my other reply to the individual patch. Thomas, please check that it still works for you. It compiles cleanly, so absolutely nothing can go wrong with it. :) thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 04/11] ARM: mvebu: Remove the unused argument of set_cpu_coherent()
On Mon, Apr 14, 2014 at 05:10:07PM +0200, Gregory CLEMENT wrote:
> set_cpu_coherent() took the SMP group ID as parameter. But this
> parameter was never used, and the CPU always uses the SMP group 0. So
> we can remove this parameter.
>
> Signed-off-by: Gregory CLEMENT
> ---
> arch/arm/mach-mvebu/coherency.c | 4 ++--
> arch/arm/mach-mvebu/coherency.h | 2 +-
> arch/arm/mach-mvebu/platsmp.c | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
Thomas' work
https://lkml.kernel.org/r/1397483228-25625-2-git-send-email-thomas.petazz...@free-electrons.com
introduced an extra call to set_cpu_coherent() that wasn't caught by
this patch.
I've amended it as attached below.
thx,
Jason.
> diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
> index 51010dbbf7e4..ad61251f7faf 100644
> --- a/arch/arm/mach-mvebu/coherency.c
> +++ b/arch/arm/mach-mvebu/coherency.c
> @@ -46,7 +46,7 @@ static struct of_device_id of_coherency_table[] = {
> /* Function defined in coherency_ll.S */
> int ll_set_cpu_coherent(void);
>
> -int set_cpu_coherent(int smp_group_id)
> +int set_cpu_coherent(void)
> {
> if (!coherency_base) {
> pr_warn("Can't make current CPU cache coherent.\n");
> @@ -140,7 +140,7 @@ int __init coherency_init(void)
> sync_cache_w(&coherency_phys_base);
> coherency_base = of_iomap(np, 0);
> coherency_cpu_base = of_iomap(np, 1);
> - set_cpu_coherent(0);
> + set_cpu_coherent();
> of_node_put(np);
> }
>
> diff --git a/arch/arm/mach-mvebu/coherency.h b/arch/arm/mach-mvebu/coherency.h
> index c7e5df368d98..dff16612dd93 100644
> --- a/arch/arm/mach-mvebu/coherency.h
> +++ b/arch/arm/mach-mvebu/coherency.h
> @@ -15,8 +15,8 @@
> #define __MACH_370_XP_COHERENCY_H
>
> extern unsigned long coherency_phys_base;
> +int set_cpu_coherent(void);
>
> -int set_cpu_coherent(int smp_group_id);
> int coherency_init(void);
>
> #endif /* __MACH_370_XP_COHERENCY_H */
> diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
> index a99d71a747f0..f2f1830063c8 100644
> --- a/arch/arm/mach-mvebu/platsmp.c
> +++ b/arch/arm/mach-mvebu/platsmp.c
> @@ -102,7 +102,7 @@ static void __init armada_xp_smp_prepare_cpus(unsigned
> int max_cpus)
>
> set_secondary_cpus_clock();
> flush_cache_all();
> - set_cpu_coherent(0);
> + set_cpu_coherent();
>
> /*
>* In order to boot the secondary CPUs we need to ensure
> --
> 1.8.1.2
->8-
commit cfa292006fb7016fad58659d01e84a3aba488db2
Author: Gregory CLEMENT
Date: Mon Apr 14 17:10:07 2014 +0200
ARM: mvebu: Remove the unused argument of set_cpu_coherent()
set_cpu_coherent() took the SMP group ID as parameter. But this
parameter was never used, and the CPU always uses the SMP group 0. So
we can remove this parameter.
Signed-off-by: Gregory CLEMENT
Link:
https://lkml.kernel.org/r/1397488214-20685-5-git-send-email-gregory.clem...@free-electrons.com
Signed-off-by: Jason Cooper
diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
index 2f7eb0e10164..0297cca32635 100644
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -63,7 +63,7 @@ static struct of_device_id of_coherency_table[] = {
/* Function defined in coherency_ll.S */
int ll_set_cpu_coherent(void);
-int set_cpu_coherent(int smp_group_id)
+int set_cpu_coherent(void)
{
if (!coherency_base) {
pr_warn("Can't make current CPU cache coherent.\n");
@@ -302,7 +302,7 @@ static void __init armada_370_coherency_init(struct
device_node *np)
sync_cache_w(&coherency_phys_base);
coherency_base = of_iomap(np, 0);
coherency_cpu_base = of_iomap(np, 1);
- set_cpu_coherent(0);
+ set_cpu_coherent();
}
static void __init armada_375_380_coherency_init(struct device_node *np)
@@ -330,7 +330,7 @@ static int coherency_type(void)
sync_cache_w(&coherency_phys_base);
coherency_base = of_iomap(np, 0);
coherency_cpu_base = of_iomap(np, 1);
- set_cpu_coherent(0);
+ set_cpu_coherent();
of_node_put(np);
}
diff --git a/arch/arm/mach-mvebu/coherency.h b/arch/arm/mach-mvebu/coherency.h
index ab594a75fef3..54cb7607b526 100644
--- a/arch/arm/mach-mvebu/coherency.h
+++ b/arch/arm/mach-mvebu/coherency.h
@@ -15,8 +15,8 @@
#define __MACH_370_XP_COHERENCY_H
extern unsigned long coherency_phys_base;
+int set_cpu_coherent(void);
-int set_cpu_coherent(int smp_group_id);
int coherency_init(void);
int coherency_available(void);
diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index 75436c0023a8..88b976b31719 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -103,7 +103,7 @@ static void __init armada_xp_smp_prepare
[GIT PULL] ACPI and power management fixes for v3.15-rc3
Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm+acpi-3.15-rc3 to receive ACPI, power management and PNP fixes for v3.15-rc3 with top-most commit d4c9c8a09cff85f69b2c224ca7dbeb42431da2b3 Merge branches 'pnp' and 'acpi-hotplug' on top of commit a798c10faf62a505d24e5f6213fbaf904a39623f Linux 3.15-rc2 These include a fix for a recent ACPI regression related to device notifications, intel_idle fix related to IvyTown support, fix for a buffer size issue in ACPICA, PM core fix related to the "freeze" sleep state, four fixes for various types of breakage in cpufreq drivers, a PNP workaround for a wrong memory region size in ACPI tables, and a fix and cleanup for the ACPI tools Makefile. Specifics: - Fix for broken ACPI notifications on some systems caused by a recent ACPI hotplug commit that blocked the propagation of unknown type notifications to device drivers inadvertently. - intel_idle fix to make the IvyTown C-states handling (added recently) work as intended which now is broken due to missing braces. From Christoph Jaeger. - ACPICA fix to make it allocate buffers of the right sizes for the Generic Serial Bus operation region access. From Lv Zheng. - PM core fix unblocking cpuidle before entering the "freeze" sleep state which causes that state to be able to actually save more energy than runtime idle. - Configuration and build fixes for the highbank and powernv cpufreq drivers from Kefeng Wang and Srivatsa S Bhat. - Coccinelle warning fix related to error pointers for the unicore32 cpufreq driver from Duan Jiong. - Integer overflow fix for the ppc-corenet cpufreq driver from Geert Uytterhoeven. - Workaround for BIOSes that don't report the entire Intel MCH area in their ACPI tables from Bjorn Helgaas. - ACPI tools Makefile fix and cleanup from Thomas Renninger. Thanks! --- Bjorn Helgaas (1): PNP: Work around BIOS defects in Intel MCH area reporting Christoph Jaeger (1): intel_idle: fix IVT idle state table setting Duan Jiong (1): cpufreq: unicore32: replace IS_ERR and PTR_ERR with PTR_ERR_OR_ZERO Geert Uytterhoeven (1): cpufreq: ppc: Fix integer overflow in expression Kefeng Wang (1): cpufreq: highbank: fix ARM_HIGHBANK_CPUFREQ dependency warning Lv Zheng (1): ACPICA: Fix buffer allocation issue for generic_serial_bus region accesses. Rafael J. Wysocki (2): PM / suspend: Make cpuidle work in the "freeze" state ACPI / notify: Do not block unknown type notifications in root handler Srivatsa S. Bhat (1): cpufreq, powernv: Fix build failure on UP Thomas Renninger (1): tools/power/acpi: Minor bugfixes --- drivers/acpi/acpica/exfield.c | 104 +++--- drivers/acpi/bus.c| 5 +- drivers/cpufreq/Kconfig.arm | 6 +- drivers/cpufreq/powernv-cpufreq.c | 1 + drivers/cpufreq/ppc-corenet-cpufreq.c | 2 +- drivers/cpufreq/unicore2-cpufreq.c| 4 +- drivers/idle/intel_idle.c | 3 +- drivers/pnp/quirks.c | 79 ++ kernel/power/suspend.c| 3 + tools/power/acpi/Makefile | 11 +--- 10 files changed, 188 insertions(+), 30 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] serial: sc16is7xx: dynamically allocate tx/rx buffer
From: Jon Ringle
This fixes the warnings:
drivers/tty/serial/sc16is7xx.c: In function 'sc16is7xx_handle_rx':
>> drivers/tty/serial/sc16is7xx.c:548:1: warning: 'sc16is7xx_handle_rx' uses
>> dynamic stack allocation [enabled by default]
drivers/tty/serial/sc16is7xx.c: In function 'sc16is7xx_handle_tx':
>> drivers/tty/serial/sc16is7xx.c:589:1: warning: 'sc16is7xx_handle_tx' uses
>> dynamic stack allocation [enabled by default]
Signed-off-by: Jon Ringle
---
drivers/tty/serial/sc16is7xx.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
index 7206a64..880cedd 100644
--- a/drivers/tty/serial/sc16is7xx.c
+++ b/drivers/tty/serial/sc16is7xx.c
@@ -317,6 +317,7 @@ struct sc16is7xx_port {
#ifdef CONFIG_GPIOLIB
struct gpio_chipgpio;
#endif
+ unsigned char buf[SC16IS7XX_FIFO_SIZE];
struct sc16is7xx_onep[0];
};
@@ -471,16 +472,15 @@ static void sc16is7xx_handle_rx(struct uart_port *port,
unsigned int rxlen,
{
struct sc16is7xx_port *s = dev_get_drvdata(port->dev);
unsigned int lsr = 0, ch, flag, bytes_read, i;
- u8 buf[port->fifosize];
bool read_lsr = (iir == SC16IS7XX_IIR_RLSE_SRC) ? true : false;
- if (unlikely(rxlen >= port->fifosize)) {
+ if (unlikely(rxlen >= sizeof(s->buf))) {
dev_warn_ratelimited(port->dev,
"Port %i: Possible RX FIFO overrun: %d\n",
port->line, rxlen);
port->icount.buf_overrun++;
/* Ensure sanity of RX level */
- rxlen = port->fifosize;
+ rxlen = sizeof(s->buf);
}
while (rxlen) {
@@ -493,12 +493,12 @@ static void sc16is7xx_handle_rx(struct uart_port *port,
unsigned int rxlen,
lsr = 0;
if (read_lsr) {
- buf[0] = sc16is7xx_port_read(port, SC16IS7XX_RHR_REG);
+ s->buf[0] = sc16is7xx_port_read(port,
SC16IS7XX_RHR_REG);
bytes_read = 1;
} else {
regcache_cache_bypass(s->regmap, true);
regmap_raw_read(s->regmap, SC16IS7XX_RHR_REG,
- buf, rxlen);
+ s->buf, rxlen);
regcache_cache_bypass(s->regmap, false);
bytes_read = rxlen;
}
@@ -532,7 +532,7 @@ static void sc16is7xx_handle_rx(struct uart_port *port,
unsigned int rxlen,
}
for (i = 0; i < bytes_read; ++i) {
- ch = buf[i];
+ ch = s->buf[i];
if (uart_handle_sysrq_char(port, ch))
continue;
@@ -553,7 +553,6 @@ static void sc16is7xx_handle_tx(struct uart_port *port)
struct sc16is7xx_port *s = dev_get_drvdata(port->dev);
struct circ_buf *xmit = &port->state->xmit;
unsigned int txlen, to_send, i;
- u8 buf[port->fifosize];
if (unlikely(port->x_char)) {
sc16is7xx_port_write(port, SC16IS7XX_THR_REG, port->x_char);
@@ -577,11 +576,11 @@ static void sc16is7xx_handle_tx(struct uart_port *port)
/* Convert to linear buffer */
for (i = 0; i < to_send; ++i) {
- buf[i] = xmit->buf[xmit->tail];
+ s->buf[i] = xmit->buf[xmit->tail];
xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
}
regcache_cache_bypass(s->regmap, true);
- regmap_raw_write(s->regmap, SC16IS7XX_THR_REG, buf, to_send);
+ regmap_raw_write(s->regmap, SC16IS7XX_THR_REG, s->buf, to_send);
regcache_cache_bypass(s->regmap, false);
}
--
1.8.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 RESEND 0/5] clk: bcm21664: add common clock support
Quoting Alex Elder (2014-04-21 14:26:22) > This is series has two parts. The first two patches are changes > to the existing Broadcom Kona family clock code to prepare for the > addition of support for another SoC, bcm21664. > > The remaining three define the binding and code for bcm21664, and > replace the use of "fake" clocks in the device tree with the real > ones. This ends up being a fairly straightforward definition of > the clocks on this SoC; the rest of the clock code is shared with > other SoCs that use the Kona style clock system. Hi Alex, I'm happy to take only the clk patches or I can take the DT stuff as well if it gets some Acks. Let me know how you want it handled. Regards, Mike > > This series depends on the following patch, which has been taken > into the clk-fixes tree: > clk: bcm281xx: don't use unnamed structs or unions > https://lkml.org/lkml/2014/4/7/322 > > In addition, it depends on the version 4 of the following series, > just (re)posted for review: > clk: bcm281xx: updates > https://lkml.org/lkml/2014/4/8/485 > > The patches in this series--based on the current linus/master branch > plus the patches mentioned above--are available here: > http://git.linaro.org/git/landing-teams/working/broadcom/kernel.git > Branch review/bcm21664-clock-v2 > > Alex Elder (5): > clk: bcm281xx: move compatible string definitions > ARM: dts: revise kona clock binding document > ARM: dts: define clock binding for bcm21664 > clk: bcm21664: use common clock framework > ARM: dts: use real clocks for bcm21664 > > .../devicetree/bindings/clock/bcm-kona-clock.txt | 116 ++--- > arch/arm/boot/dts/bcm21664.dtsi| 190 +- > drivers/clk/bcm/Kconfig| 2 +- > drivers/clk/bcm/Makefile | 1 + > drivers/clk/bcm/clk-bcm21664.c | 290 > + > drivers/clk/bcm/clk-bcm281xx.c | 12 - > include/dt-bindings/clock/bcm21664.h | 62 + > include/dt-bindings/clock/bcm281xx.h | 12 + > 8 files changed, 565 insertions(+), 120 deletions(-) > create mode 100644 drivers/clk/bcm/clk-bcm21664.c > create mode 100644 include/dt-bindings/clock/bcm21664.h > > -- > 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] sched: idle: Add sched balance option
On Friday, April 25, 2014 03:20:55 PM Peter Zijlstra wrote: > On Fri, Apr 25, 2014 at 01:46:53PM +0200, Rafael J. Wysocki wrote: > > _trim_ emails!!! one of these days I'm going to write a bot to flame > your head of if there's excessive quoting. Words ... > > > > Well, so now the question is whether or not we relly want to always > > go to the "power" (or "energy efficiency" if you will) mode if the system > > is on battery. That arguably may not be a good thing even for energy > > efficiency depending on how exactly the modes are defined. > > Nobody is talking about always. But in general it seems a good enough > approach. Hell, many of the AC/BAT switches in todays power management > crap things are not always right. > > Do I want it to dim the LCD further when I unplug the laptop -- mostly > no, but still it does. And the most annoying one is that it reduces the > screen blank time to something near 5 seconds or so. > > Why would this be any different? And why do we have to do things that we hate it when they are done by others? > If you know what you want you can turn the knob. > > > So in my opinion it's too early to add things like that at this point. > > Meh.. Seriously, I'm not even sure if we really need that stuff to be honest. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/2] percpu_ida: Take into account CPU topology when stealing tags
Hi Jens, On Sat, Apr 26, 2014 at 5:23 AM, Jens Axboe wrote: > On 04/25/2014 03:10 AM, Ming Lei wrote: > > Sorry, I did run it the other day. It has little to no effect here, but > that's mostly because there's so much other crap going on in there. The > most effective way to currently make it work better, is just to ensure > the caching pool is of a sane size. Yes, that is just what the patch is doing, :-) >From percpu_ida view, it is easy to observe it can improve allocation performance. I have several patches to export these information by sysfs for monitoring percpu_ida performance. > > I've got an alternative tagging scheme that I think would be useful for > the cases where the tag space to cpu ratio isn't big enough. So I think > we'll retain percpu_ida for the cases where it can cache enough, and > punt to an alternative scheme when not. OK, care to comment on the patch or the idea of setting percpu cache size as (nr_tags / hctx->nr_ctx)? > > That doesn't mean we should not improve percpu_ida. There's quite a bit > of low hanging fruit in there. IMO percpu_max_size in percpu_ida is very important for the performance, and it might need to adjust dynamically according to the percpu allocation loading, but it is far more complicated to implement. And it might be the simplest way to fix the parameter before percpu_ida_init(). Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 1/5] Input: add common DT binding for touchscreens
Add common DT binding documentation for touchscreen devices and
implement input_parse_touchscreen_of_params, which parses the common
properties and configures the input device accordingly.
The method currently does not interpret the axis inversion properties,
since there is no matching flag in the generic linux input device.
Signed-off-by: Sebastian Reichel
---
.../bindings/input/touchscreen/touchscreen.txt | 27 +
drivers/input/input.c | 34 ++
include/linux/input.h | 8 +
3 files changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
diff --git
a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
new file mode 100644
index 000..d8e0616
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
@@ -0,0 +1,27 @@
+General Touchscreen Properties:
+
+Optional properties for Touchscreens:
+ - touchscreen-size-x : horizontal resolution of touchscreen
+ (in pixels)
+ - touchscreen-size-y : vertical resolution of touchscreen
+ (in pixels)
+ - touchscreen-max-pressure: maximum reported pressure (arbitrary range
+ dependent on the controller)
+ - touchscreen-fuzz-x : horizontal noise value of the absolute input
+ device (in pixels)
+ - touchscreen-fuzz-y : vertical noise value of the absolute input
+ device (in pixels)
+ - touchscreen-fuzz-pressure : pressure noise value of the absolute input
+ device (arbitrary range dependent on the
+ controller)
+ - touchscreen-inverted-x : X axis is inverted (boolean)
+ - touchscreen-inverted-y : Y axis is inverted (boolean)
+
+Deprecated properties for Touchscreens:
+ - x-size : deprecated name for touchscreen-size-x
+ - y-size : deprecated name for touchscreen-size-y
+ - moving-threshold: deprecated name for a combination of
+ touchscreen-fuzz-x and touchscreen-fuzz-y
+ - contact-threshold : deprecated name for touchscreen-fuzz-pressure
+ - x-invert: deprecated name for touchscreen-inverted-x
+ - y-invert: deprecated name for touchscreen-inverted-y
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 1c4c0db..97966d93 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include "input-compat.h"
MODULE_AUTHOR("Vojtech Pavlik ");
@@ -2398,6 +2399,39 @@ void input_free_minor(unsigned int minor)
}
EXPORT_SYMBOL(input_free_minor);
+#if defined(CONFIG_OF)
+/**
+ * input_parse_touchscreen_of_params - parse common touchscreen DT properties
+ * @dev: device that should be parsed
+ *
+ * This function parses common DT properties for touchscreens and setups the
+ * input device accordingly. The function keeps previously setuped default
+ * values if no value is specified via DT.
+ */
+void input_parse_touchscreen_of_params(struct input_dev *dev)
+{
+ struct device_node *np = dev->dev.parent->of_node;
+ struct input_absinfo *absinfo;
+
+ input_alloc_absinfo(dev);
+ if (!dev->absinfo)
+ return;
+
+ absinfo = &dev->absinfo[ABS_X];
+ of_property_read_u32(np, "touchscreen-size-x", &absinfo->maximum);
+ of_property_read_u32(np, "touchscreen-fuzz-x", &absinfo->fuzz);
+
+ absinfo = &dev->absinfo[ABS_Y];
+ of_property_read_u32(np, "touchscreen-size-y", &absinfo->maximum);
+ of_property_read_u32(np, "touchscreen-fuzz-y", &absinfo->fuzz);
+
+ absinfo = &dev->absinfo[ABS_PRESSURE];
+ of_property_read_u32(np, "touchscreen-max-pressure", &absinfo->maximum);
+ of_property_read_u32(np, "touchscreen-fuzz-pressure", &absinfo->fuzz);
+}
+EXPORT_SYMBOL(input_parse_touchscreen_of_params);
+#endif
+
static int __init input_init(void)
{
int err;
diff --git a/include/linux/input.h b/include/linux/input.h
index 82ce323..3dc3b1e 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -531,4 +531,12 @@ int input_ff_erase(struct input_dev *dev, int effect_id,
struct file *file);
int input_ff_create_memless(struct input_dev *dev, void *data,
int (*play_effect)(struct input_dev *, void *, struct ff_effect
*));
+#if defined(CONFIG_OF)
+void input_parse_touchscreen_of_params(struct input_dev *dev);
+#else
+static inline void input_parse_touchscreen_of_params(struct input_dev *dev) {
+ return;
+}
+#endif
+
#endif
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
[PATCHv3 3/5] Input: tsc2005: convert driver to use devm_*
Simplify the driver by using managed resources for memory allocation of
internal struct, input device allocation and irq request.
Signed-off-by: Sebastian Reichel
---
drivers/input/touchscreen/tsc2005.c | 30 ++
1 file changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2005.c
b/drivers/input/touchscreen/tsc2005.c
index 520e673..9daaddd 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -604,12 +604,10 @@ static int tsc2005_probe(struct spi_device *spi)
if (error)
return error;
- ts = kzalloc(sizeof(*ts), GFP_KERNEL);
- input_dev = input_allocate_device();
- if (!ts || !input_dev) {
- error = -ENOMEM;
- goto err_free_mem;
- }
+ ts = devm_kzalloc(&spi->dev, sizeof(*ts), GFP_KERNEL);
+ input_dev = devm_input_allocate_device(&spi->dev);
+ if (!ts || !input_dev)
+ return -ENOMEM;
ts->spi = spi;
ts->idev = input_dev;
@@ -649,12 +647,13 @@ static int tsc2005_probe(struct spi_device *spi)
/* Ensure the touchscreen is off */
tsc2005_stop_scan(ts);
- error = request_threaded_irq(spi->irq, NULL, tsc2005_irq_thread,
-IRQF_TRIGGER_RISING | IRQF_ONESHOT,
-"tsc2005", ts);
+ error = devm_request_threaded_irq(&spi->dev, spi->irq, NULL,
+ tsc2005_irq_thread,
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ "tsc2005", ts);
if (error) {
dev_err(&spi->dev, "Failed to request irq, err: %d\n", error);
- goto err_free_mem;
+ return error;
}
spi_set_drvdata(spi, ts);
@@ -662,7 +661,7 @@ static int tsc2005_probe(struct spi_device *spi)
if (error) {
dev_err(&spi->dev,
"Failed to create sysfs attributes, err: %d\n", error);
- goto err_clear_drvdata;
+ return error;
}
error = input_register_device(ts->idev);
@@ -677,11 +676,6 @@ static int tsc2005_probe(struct spi_device *spi)
err_remove_sysfs:
sysfs_remove_group(&spi->dev.kobj, &tsc2005_attr_group);
-err_clear_drvdata:
- free_irq(spi->irq, ts);
-err_free_mem:
- input_free_device(input_dev);
- kfree(ts);
return error;
}
@@ -691,10 +685,6 @@ static int tsc2005_remove(struct spi_device *spi)
sysfs_remove_group(&ts->spi->dev.kobj, &tsc2005_attr_group);
- free_irq(ts->spi->irq, ts);
- input_unregister_device(ts->idev);
- kfree(ts);
-
return 0;
}
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 4/5] Input: tsc2005: add DT support
This adds DT support to the tsc2005 touchscreen
driver.
Signed-off-by: Sebastian Reichel
---
drivers/input/touchscreen/tsc2005.c | 96 +
1 file changed, 77 insertions(+), 19 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2005.c
b/drivers/input/touchscreen/tsc2005.c
index 9daaddd..a83d1be 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -28,6 +28,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -100,6 +102,11 @@
TSC2005_CFR2_AVG_7)
#define MAX_12BIT 0xfff
+#define TSC2005_DEF_X_FUZZ 4
+#define TSC2005_DEF_Y_FUZZ 8
+#define TSC2005_DEF_P_FUZZ 2
+#define TSC2005_DEF_RESISTOR 280
+
#define TSC2005_SPI_MAX_SPEED_HZ 1000
#define TSC2005_PENUP_TIME_MS 40
@@ -143,6 +150,7 @@ struct tsc2005 {
boolpen_down;
+ int reset_gpio;
void(*set_reset)(bool enable);
};
@@ -337,6 +345,14 @@ static void tsc2005_stop_scan(struct tsc2005 *ts)
tsc2005_cmd(ts, TSC2005_CMD_STOP);
}
+static void tsc2005_set_reset(struct tsc2005 *ts, bool enable)
+{
+ if (ts->reset_gpio >= 0)
+ gpio_set_value(ts->reset_gpio, enable);
+ else if (ts->set_reset)
+ ts->set_reset(enable);
+}
+
/* must be called with ts->mutex held */
static void __tsc2005_disable(struct tsc2005 *ts)
{
@@ -355,7 +371,7 @@ static void __tsc2005_enable(struct tsc2005 *ts)
{
tsc2005_start_scan(ts);
- if (ts->esd_timeout && ts->set_reset) {
+ if (ts->esd_timeout && (ts->set_reset || ts->reset_gpio)) {
ts->last_valid_interrupt = jiffies;
schedule_delayed_work(&ts->esd_work,
round_jiffies_relative(
@@ -414,9 +430,9 @@ static ssize_t tsc2005_selftest_show(struct device *dev,
}
/* hardware reset */
- ts->set_reset(false);
+ tsc2005_set_reset(ts, false);
usleep_range(100, 500); /* only 10us required */
- ts->set_reset(true);
+ tsc2005_set_reset(ts, true);
if (!success)
goto out;
@@ -459,7 +475,7 @@ static umode_t tsc2005_attr_is_visible(struct kobject *kobj,
umode_t mode = attr->mode;
if (attr == &dev_attr_selftest.attr) {
- if (!ts->set_reset)
+ if (!ts->set_reset && !ts->reset_gpio)
mode = 0;
}
@@ -509,9 +525,9 @@ static void tsc2005_esd_work(struct work_struct *work)
tsc2005_update_pen_state(ts, 0, 0, 0);
- ts->set_reset(false);
+ tsc2005_set_reset(ts, false);
usleep_range(100, 500); /* only 10us required */
- ts->set_reset(true);
+ tsc2005_set_reset(ts, true);
enable_irq(ts->spi->irq);
tsc2005_start_scan(ts);
@@ -572,29 +588,47 @@ static void tsc2005_setup_spi_xfer(struct tsc2005 *ts)
static int tsc2005_probe(struct spi_device *spi)
{
const struct tsc2005_platform_data *pdata = dev_get_platdata(&spi->dev);
+ struct device_node *np = spi->dev.of_node;
+
struct tsc2005 *ts;
struct input_dev *input_dev;
- unsigned int max_x, max_y, max_p;
- unsigned int fudge_x, fudge_y, fudge_p;
+ unsigned int max_x = MAX_12BIT;
+ unsigned int max_y = MAX_12BIT;
+ unsigned int max_p = MAX_12BIT;
+ unsigned int fudge_x = TSC2005_DEF_X_FUZZ;
+ unsigned int fudge_y = TSC2005_DEF_Y_FUZZ;
+ unsigned int fudge_p = TSC2005_DEF_P_FUZZ;
+ unsigned int x_plate_ohm = TSC2005_DEF_RESISTOR;
+ unsigned int esd_timeout;
int error;
- if (!pdata) {
+ if (!np && !pdata) {
dev_err(&spi->dev, "no platform data\n");
return -ENODEV;
}
- fudge_x = pdata->ts_x_fudge? : 4;
- fudge_y = pdata->ts_y_fudge? : 8;
- fudge_p = pdata->ts_pressure_fudge ? : 2;
- max_x = pdata->ts_x_max ? : MAX_12BIT;
- max_y = pdata->ts_y_max ? : MAX_12BIT;
- max_p = pdata->ts_pressure_max ? : MAX_12BIT;
-
if (spi->irq <= 0) {
dev_err(&spi->dev, "no irq\n");
return -ENODEV;
}
+ if (pdata) {
+ fudge_x = pdata->ts_x_fudge;
+ fudge_y = pdata->ts_y_fudge;
+ fudge_p = pdata->ts_pressure_fudge;
+ max_x = pdata->ts_x_max;
+ max_y = pdata->ts_y_max;
+ max_p = pdata->ts_pressure_max;
+ x_plate_ohm = pdata->ts_x_plate_ohm;
+ esd_timeout = pdata->esd_timeout_ms;
+ } else {
+ x_plate_ohm = TSC2005_DEF_RESISTOR;
+ of_property_read_u32(np, "ti,x-plate-ohms", &x_plate_ohm);
+ esd_timeout = 0;
+ of_prop
[PATCHv3 5/5] Documentation: dt: Document TSC2005 DT binding
Add devicetree binding documentation for TSC2005 touchscreen.
Signed-off-by: Sebastian Reichel
---
.../bindings/input/touchscreen/tsc2005.txt | 39 ++
1 file changed, 39 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
new file mode 100644
index 000..663f8ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
@@ -0,0 +1,39 @@
+* Texas Instruments tsc2005 touchscreen controller
+
+Required properties:
+ - compatible: "ti,tsc2005"
+ - reg : SPI device address
+ - spi-max-frequency : Maximal SPI speed
+ - interrupts: IRQ specifier
+ - reset-gpios : GPIO specifier
+
+Optional properties:
+ - ti,x-plate-ohms : integer, resistance of the touchscreen's X
plates
+ in ohm (defaults to 280)
+ - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond
after
+ the configured time (in milli seconds), the
driver
+ will reset it. This is disabled by default.
+ - properties defined in touchscreen.txt
+
+Example:
+
+&mcspi1 {
+ tsc2005@0 {
+ compatible = "ti,tsc2005";
+ spi-max-frequency = <600>;
+ reg = <0>;
+
+ reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>; /* 104 */
+ interrupts-extended = <&gpio4 4 IRQ_TYPE_NONE>; /* 100 */
+
+ touchscreen-fuzz-x = <4>;
+ touchscreen-fuzz-y = <7>;
+ touchscreen-fuzz-pressure = <2>;
+ touchscreen-max-x = <4096>;
+ touchscreen-max-y = <4096>;
+ touchscreen-max-pressure = <2048>;
+
+ ti,x-plate-ohms = <280>;
+ ti,esd-recovery-timeout-ms = <8000>;
+ };
+}
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 2/5] Input: tsc2005: use dev_err for error messages
Change some dev_dbg() invocations to dev_err() ones, because they
are supposed to output error messages.
Signed-off-by: Sebastian Reichel
---
drivers/input/touchscreen/tsc2005.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2005.c
b/drivers/input/touchscreen/tsc2005.c
index 550adcb..520e673 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -579,7 +579,7 @@ static int tsc2005_probe(struct spi_device *spi)
int error;
if (!pdata) {
- dev_dbg(&spi->dev, "no platform data\n");
+ dev_err(&spi->dev, "no platform data\n");
return -ENODEV;
}
@@ -591,7 +591,7 @@ static int tsc2005_probe(struct spi_device *spi)
max_p = pdata->ts_pressure_max ? : MAX_12BIT;
if (spi->irq <= 0) {
- dev_dbg(&spi->dev, "no irq\n");
+ dev_err(&spi->dev, "no irq\n");
return -ENODEV;
}
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 0/5] tsc2005 DT binding
Hi, This adds device tree support for the tsc2005 touchscreen controller, which is currently only used by the Nokia N900 board. The patch does not update the reset pin handling for platform data based probe to avoid merge conflicts. The n900 platform code will be removed in the near future (3.16?) and the driver can be simplified once that has happened. Changes since v2 [0]: * rename "ti,x-plate-resistance" to "ti,x-plate-ohms", so that the same property name is used for tsc2005 and tsc2007 * document "x-size" and "y-size" as deprecated form of touchscreen-size-x and touchscreen-size-y * add documentation for "touchscreen-inverted-x" and "touchscreen-inverted-y" to the common touchscreen binding and mark "x-invert" and "y-invert" as deprecated. * add units to the property descriptions in the common touchscreen binding Documentation * document "moving-threshold" as deprecated form of "touchscreen-fuzz-x" and "touchscreen-fuzz-y" combination * document "contact-threshold" as deprecated form of "touchscreen-fuzz-pressure" [0] https://lkml.org/lkml/2014/4/5/103 -- Sebastian Sebastian Reichel (5): Input: add common DT binding for touchscreens Input: tsc2005: use dev_err for error messages Input: tsc2005: convert driver to use devm_* Input: tsc2005: add DT support Documentation: dt: Document TSC2005 DT binding .../bindings/input/touchscreen/touchscreen.txt | 27 + .../bindings/input/touchscreen/tsc2005.txt | 39 +++ drivers/input/input.c | 34 ++ drivers/input/touchscreen/tsc2005.c| 130 ++--- include/linux/input.h | 8 ++ 5 files changed, 197 insertions(+), 41 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt create mode 100644 Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 25/28] nios2: ptrace support
Does this support PTRACE_GETREGSET / PTRACE_SETREGSET ? IMO, the kernel shouldn't accept ports without those anymore. And IMHO, we shouldn't even allow new ports having PTRACE_GETREGS. http://sourceware.org/ml/archer/2010-q3/msg00193.html -- Pedro Alves -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core
Geert Uytterhoeven writes:
> When adding a device from DT, check if its clocks are suitable for Runtime
> PM, and register them with the PM core.
> If Runtime PM is disabled, just enable the clock.
>
> This allows the PM core to automatically manage gate clocks of devices for
> Runtime PM.
...unless the device is already in an existing pm_domain, right?
I like this approach, and it extends nicely what we already do on
platforms using drivers/base/power/clock_ops.c into DT land.
My only concern is how this will interact if it's used along with
devices that have existing pm_domains. I don't have any specific
concerns (yet, because it's Friday, and my brain is turing off), but it
just made me wonder if this will be potentially confusing.
Also...
[...]
> +static int of_clk_register(struct device *dev, struct clk *clk)
> +{
> + int error;
> +
> + if (!dev->pm_domain) {
> + error = pm_clk_create(dev);
> + if (error)
> + return error;
> +
> + dev->pm_domain = &of_clk_pm_domain;
> + }
> +
> + dev_dbg(dev, "Setting up clock for runtime PM management\n");
> + return pm_clk_add_clk(dev, clk);
I would've expected these 2 lines to be inside the pm_domain check.
What's the reason for doing the pm_clk_add() when the pm_domain isn't
going to be used? I suppose it's harmless, but it's a bit confusing.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] powerpc, ptrace: Add new ptrace request macros for transactional memory
On 04/02/2014 08:02 AM, Anshuman Khandual wrote: > This patch adds following new sets of ptrace request macros for transactional > memory expanding the existing ptrace ABI on PowerPC. > > /* TM special purpose registers */ > PTRACE_GETTM_SPRREGS > PTRACE_SETTM_SPRREGS > > /* TM checkpointed GPR registers */ > PTRACE_GETTM_CGPRREGS > PTRACE_SETTM_CGPRREGS > > /* TM checkpointed FPR registers */ > PTRACE_GETTM_CFPRREGS > PTRACE_SETTM_CFPRREGS > > /* TM checkpointed VMX registers */ > PTRACE_GETTM_CVMXREGS > PTRACE_SETTM_CVMXREGS Urgh, we're _still_ adding specialized register specific calls? Why aren't these exported as new register sets, accessible through PTRACE_GETREGSET / PTRACE_SETREGSET? That's supposed to be the Modern Way to do things. -- Pedro Alves -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: xgifb: Coding style cleanup, newline added after declarations
On Wed, Apr 02, 2014 at 11:25:19AM +0200, Martin Berglund wrote: > Added newlines after declarations. > > Signed-off-by: Martin Berglund > --- > drivers/staging/xgifb/XGI_main_26.c | 2 ++ > drivers/staging/xgifb/vb_init.c | 2 ++ > drivers/staging/xgifb/vb_setmode.c | 2 ++ > 3 files changed, 6 insertions(+) Someone else sent this right before you did, sorry :( greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC v3 1/5] leds: Add sysfs and kernel internal API for flash LEDs
On Fri, Apr 11, 2014 at 7:56 AM, Jacek Anaszewski
wrote:
> Some LED devices support two operation modes - torch and
> flash.
Do we have a method to look up the capabilities from LED devices driver?
For example, the LED device supports Torch/Flash then LED device
driver should set a flag like LED_DEV_CAP_TORCH or LED_DEV_CAP_FLASH.
If it doesn't support those functions, it won't set those flags.
LED Flash class core can check those flags for further usage.
> This patch provides support for flash LED devices
> in the LED subsystem by introducing new sysfs attributes
> and kernel internal interface. The attributes being
> introduced are: flash_brightness, flash_strobe, flash_timeout,
> max_flash_timeout, max_flash_brightness, flash_fault and
> optional external_strobe, indicator_brightness and
> max_indicator_btightness. All the flash related features
typo here, it should max_indicator_btightness -> max_indicator_brightness
> are placed in a separate module.
Please add one empty line here.
> The modifications aim to be compatible with V4L2 framework
> requirements related to the flash devices management. The
> design assumes that V4L2 sub-device can take of the LED class
> device control and communicate with it through the kernel
> internal interface. When V4L2 Flash sub-device file is
> opened, the LED class device sysfs interface is made
> unavailable.
>
I don't quite understand the last sentence here. Looks like the LED
flash class interface binds to V4L2 Flash sub-device, then why we need
to export sysfs for user space if the only user is V4L2 which can talk
through kernel internal API here.
> Signed-off-by: Jacek Anaszewski
> Acked-by: Kyungmin Park
> Cc: Bryan Wu
> Cc: Richard Purdie
> ---
> drivers/leds/Kconfig|8 +
> drivers/leds/Makefile |1 +
> drivers/leds/led-class.c| 36 ++-
> drivers/leds/led-flash.c| 627
+++
If we go for the LED Flash class, I prefer to use led-class-flash.c
rather than led-flash.c
> drivers/leds/led-triggers.c | 16 +-
> drivers/leds/leds.h |6 +
> include/linux/leds.h| 50 +++-
> include/linux/leds_flash.h | 252 +
leds_flash.h -> led-class-flash.h
> 8 files changed, 982 insertions(+), 14 deletions(-)
> create mode 100644 drivers/leds/led-flash.c
> create mode 100644 include/linux/leds_flash.h
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 2062682..1e1c81f 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -19,6 +19,14 @@ config LEDS_CLASS
> This option enables the led sysfs class in /sys/class/leds. You'll
> need this to do anything useful with LEDs. If unsure, say N.
>
> +config LEDS_CLASS_FLASH
> + tristate "Flash LEDs Support"
"LED Flash Class Support"
> + depends on LEDS_CLASS
> + help
> + This option enables support for flash LED devices. Say Y if you
> + want to use flash specific features of a LED device, if they
> + are supported.
> +
This help message is not very accurate, please take a look at
LEDS_CLASS. And I prefer this driver can be a module, so it should be
mentioned here.
> comment "LED drivers"
>
> config LEDS_88PM860X
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 3cd76db..8861b86 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -2,6 +2,7 @@
> # LED Core
> obj-$(CONFIG_NEW_LEDS) += led-core.o
> obj-$(CONFIG_LEDS_CLASS) += led-class.o
> +obj-$(CONFIG_LEDS_CLASS_FLASH) += led-flash.o
> obj-$(CONFIG_LEDS_TRIGGERS)+= led-triggers.o
>
> # LED Platform Drivers
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index f37d63c..58f16c3 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -9,15 +9,16 @@
> * published by the Free Software Foundation.
> */
>
> -#include
> -#include
> +#include
> +#include
> +#include
> #include
> +#include
> #include
> +#include
> +#include
> #include
> -#include
> #include
> -#include
> -#include
> #include
> #include "leds.h"
>
I believe this change is kind of cleanup, could you please split them
out? For this patch we just need add those LED Flash class related
code.
> @@ -45,28 +46,38 @@ static ssize_t brightness_store(struct device *dev,
> {
> struct led_classdev *led_cdev = dev_get_drvdata(dev);
> unsigned long state;
> - ssize_t ret = -EINVAL;
> + ssize_t ret;
> +
> + mutex_lock(&led_cdev->led_lock);
> +
> + if (led_sysfs_is_locked(led_cdev)) {
> + ret = -EBUSY;
> + goto unlock;
> + }
>
> ret = kstrtoul(buf, 10, &state);
> if (ret)
> - return ret;
> + goto unlock;
>
> if (state == LED_OFF)
> led_trigger_remove(led_cdev);
> __led_set_brightness(led_cdev, state);
> +
Re: Tux3 Report: Untar Unleashed
Yesterday I wrote: > When we checked read performance on the untarred tree, we immediately saw > mixed results. Re-tarring the kernel tree is faster than Ext4, but directory listing is > slower by a multiple. So we need to analyze and fix ls without breaking the good tar > and untar behavior. The question is, is it worth another delay before putting Tux3 > patches up for review? Hirofumi would not let me slink cowardly away from that open question. We noticed that Tux3 does slightly more than one seek per directory, which is entirely reasonable. But Ext4 goes way beyond that and does some special magic to read multiple directories per seek. The only possible way to do that is, pack directories together so there are many per track. A bit of sleuthing confirmed that this is indeed the case, and apparently comes from a patch posted by Ted T'so a few years back: lwn.net/Articles/319829/ [PATCH, RFC] ext4: New inode/block allocation algorithms for flex_bg filesystems That patch was aimed at speeding up fsck and the huge ls speedup appears to have gone unnoticed. Thus inspired, Hirofumi whipped up a prototype patch to allocate new directories first, per delta. Result: Tux3 went from 400% slower to 25% faster than Ext4, for "ls -R" of the kernel source. Even better, tar and untar performance stayed about the same with Tux3 topping the untar test at 20% faster and tar at 350%. (The lopsided tar result looks like a performance bug for Ext4.) This optimization only applies to spinning disk. It is pretty hard to think of a reason why packing directories together would benefit flash. Maybe, directories that are written together are more likely to be updated together? But it doesn't hurt flash either, and is another data point to support our theory that optimizing for spinning disk also optimizes for flash. We are still waiting for the first counterexample to show up. There are a few reasons why Tux3 has an edge for the case exercised by the kernel source loads: * Defer everything Tux3 takes the idea of delayed allocation much further and delays nearly everything. Directory updates and inode number selection are the only exceptions. (In future we will attempt to defer the namespace updates as well.) * Front back separation Besides enabling defer-everything, this simplifies locking and reduces contention a lot, for both read and update. For now, a naive locking strategy serves us well. Eventually we will multithread the backend, which will help with high processor core counts, once we get there. * Big deltas Under heavy update load, Tux3 deltas grow as big as cache will allow, so per-delta layout algorithms have a big data window available to optimize over. With our current strategy, we observe an effect similar to Ext4 flex_bg, where directories and other metadata tend to self-organize along delta boundaries, with beneficial performance effects. We might control this behavior more explicitly in future. * More inodes per inode table block. Tux3 stores about 57 inodes per block while Ext4 typically has 16 or less. Multiple inodes per block already resembles a kind of inode table readahead. Without this, there would be two seeks per directory even with directories packed together. Anyway, I don't think we need to hang our heads in shame for performance reasons at this point, even though plenty of major optimization issues still remain on the list. For example, you can embarras Tux3 just by running a benchmark with 10,000 files per directory. The answer to that one is Shardmap, which needs a couple of months to bring up and solves a problem that does not come up on your home server or phone. Not a reason to get sidetracked again.. Regards, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging/imx-drm: fix code line width
On Sat, Apr 12, 2014 at 02:04:21PM +0400, Brilliantov Kirill Vladimirovich
wrote:
> Signed-off-by: Brilliantov Kirill Vladimirovich
> ---
> drivers/staging/imx-drm/imx-tve.c | 3 ++-
> drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 3 ++-
> drivers/staging/imx-drm/ipu-v3/ipu-common.c | 23 +++
> drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 27 ++-
> drivers/staging/imx-drm/ipu-v3/ipu-di.c | 12
> drivers/staging/imx-drm/ipuv3-crtc.c| 6 --
> 6 files changed, 49 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/staging/imx-drm/imx-tve.c
> b/drivers/staging/imx-drm/imx-tve.c
> index 575533f..7023035 100644
> --- a/drivers/staging/imx-drm/imx-tve.c
> +++ b/drivers/staging/imx-drm/imx-tve.c
> @@ -669,7 +669,8 @@ static int imx_tve_bind(struct device *dev, struct device
> *master, void *data)
>
> ret = regmap_read(tve->regmap, TVE_COM_CONF_REG, &val);
> if (ret < 0) {
> - dev_err(dev, "failed to read configuration register: %d\n",
> ret);
> + dev_err(dev,
> + "failed to read configuration register: %d\n", ret);
Why not just move the ret variable to the next line?
> return ret;
> }
> if (val != 0x0010) {
> diff --git a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
> b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
> index c4d14ea..4fd7be7 100644
> --- a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
> +++ b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
> @@ -230,7 +230,8 @@ struct ipu_ch_param {
> struct ipu_cpmem_word word[2];
> };
>
> -void ipu_ch_param_write_field(struct ipu_ch_param __iomem *base, u32 wbs,
> u32 v);
> +void ipu_ch_param_write_field(struct ipu_ch_param __iomem *base, u32 wbs,
> + u32 v);
> u32 ipu_ch_param_read_field(struct ipu_ch_param __iomem *base, u32 wbs);
> struct ipu_ch_param __iomem *ipu_get_cpmem(struct ipuv3_channel *channel);
> void ipu_ch_param_dump(struct ipu_ch_param __iomem *p);
> diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
> b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
> index ca85d3d..b2c672f 100644
> --- a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
> +++ b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
> @@ -233,14 +233,20 @@ void ipu_cpmem_set_yuv_interleaved(struct ipu_ch_param
> __iomem *p,
> {
> switch (pixel_format) {
> case V4L2_PIX_FMT_UYVY:
> - ipu_ch_param_write_field(p, IPU_FIELD_BPP, 3);/* bits/pixel
> */
> - ipu_ch_param_write_field(p, IPU_FIELD_PFS, 0xA); /* pix format
> */
> - ipu_ch_param_write_field(p, IPU_FIELD_NPB, 31); /* burst size
> */
> + /* bits/pixel */
> + ipu_ch_param_write_field(p, IPU_FIELD_BPP, 3);
> + /* pix format */
> + ipu_ch_param_write_field(p, IPU_FIELD_PFS, 0xA);
> + /* burst size */
> + ipu_ch_param_write_field(p, IPU_FIELD_NPB, 31);
> break;
> case V4L2_PIX_FMT_YUYV:
> - ipu_ch_param_write_field(p, IPU_FIELD_BPP, 3);/* bits/pixel
> */
> - ipu_ch_param_write_field(p, IPU_FIELD_PFS, 0x8); /* pix format
> */
> - ipu_ch_param_write_field(p, IPU_FIELD_NPB, 31); /* burst size
> */
> + /* bits/pixel */
> + ipu_ch_param_write_field(p, IPU_FIELD_BPP, 3);
> + /* pix format */
> + ipu_ch_param_write_field(p, IPU_FIELD_PFS, 0x8);
> + /* burst size */
> + ipu_ch_param_write_field(p, IPU_FIELD_NPB, 31);
> break;
> }
> }
> @@ -900,7 +906,8 @@ static void ipu_irq_handle(struct ipu_soc *ipu, const int
> *regs, int num_regs)
> status &= ipu_cm_read(ipu, IPU_INT_CTRL(regs[i]));
>
> for_each_set_bit(bit, &status, 32) {
> - irq = irq_linear_revmap(ipu->domain, regs[i] * 32 +
> bit);
> + irq =
> + irq_linear_revmap(ipu->domain, regs[i] * 32 + bit);
Does that really look better?
> if (irq)
> generic_handle_irq(irq);
> }
> @@ -1053,7 +1060,7 @@ static int ipu_irq_init(struct ipu_soc *ipu)
> }
>
> ret = irq_alloc_domain_generic_chips(ipu->domain, 32, 1, "IPU",
> - handle_level_irq, 0, IRQF_VALID,
> 0);
> + handle_level_irq, 0, IRQF_VALID, 0);
> if (ret < 0) {
> dev_err(ipu->dev, "failed to alloc generic irq chips\n");
> irq_domain_remove(ipu->domain);
> diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
> b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
> index d5de8bb..b05111a 100644
> --- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
> +++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
> @@ -132,10 +132,12 @@ static void dc_write_tmpl(struct ipu_dc *dc, int word,
> u32 opcod
[PATCH 09/10] ARM: dts: OMAP4: clk: Add clk node for DES IP
From: Lokesh Vutla
DES IP already has main and interface clk as des_fck.
Node for des_fck is missing in clk tree. Adding the same.
Signed-off-by: Lokesh Vutla
Signed-off-by: Joel Fernandes
---
arch/arm/boot/dts/omap44xx-clocks.dtsi |8
drivers/clk/ti/clk-44xx.c |1 +
2 files changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap44xx-clocks.dtsi
b/arch/arm/boot/dts/omap44xx-clocks.dtsi
index c821ff5..83cf189 100644
--- a/arch/arm/boot/dts/omap44xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap44xx-clocks.dtsi
@@ -985,6 +985,14 @@
reg = <0x15a8>;
};
+ des_fck: des_fck@4a0095b0 {
+ #clock-cells = <0>;
+ compatible = "gate-clock";
+ clocks = <&l3_div_ck>;
+ bit-shift = <1>;
+ reg = <0x4a0095b0 0x4>;
+ };
+
dss_sys_clk: dss_sys_clk {
#clock-cells = <0>;
compatible = "ti,gate-clock";
diff --git a/drivers/clk/ti/clk-44xx.c b/drivers/clk/ti/clk-44xx.c
index 02517a8..85d97c3 100644
--- a/drivers/clk/ti/clk-44xx.c
+++ b/drivers/clk/ti/clk-44xx.c
@@ -120,6 +120,7 @@ static struct ti_dt_clk omap44xx_clks[] = {
DT_CLK(NULL, "syc_clk_div_ck", "syc_clk_div_ck"),
DT_CLK(NULL, "aes1_fck", "aes1_fck"),
DT_CLK(NULL, "aes2_fck", "aes2_fck"),
+ DT_CLK(NULL, "des_fck", "des_fck"),
DT_CLK(NULL, "dmic_sync_mux_ck", "dmic_sync_mux_ck"),
DT_CLK(NULL, "func_dmic_abe_gfclk", "func_dmic_abe_gfclk"),
DT_CLK(NULL, "dss_sys_clk", "dss_sys_clk"),
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/10] ARM: OMAP4: hwmod: Add hwmod data for AES IP
Crypto modules AES0/1 belong to:
PD_L4_PER power domain
CD_L4_SEC clock domain
On the L3, the AES modules are mapped to
L3_CLK2: Peripherals and multimedia sub clock domain
We add hwmod data for the same.
Signed-off-by: Joel Fernandes
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 43
1 file changed, 43 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 1219280..3b12244 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4782,6 +4782,48 @@ static struct omap_hwmod_ocp_if omap44xx_mpu__emif2 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/*
+Crypto modules AES0/1 belong to:
+ PD_L4_PER power domain
+ CD_L4_SEC clock domain
+ On the L3, the AES modules are mapped to
+ L3_CLK2: Peripherals and multimedia sub clock domain
+*/
+
+static struct omap_hwmod_class_sysconfig omap4_aes1_sysc = {
+ .rev_offs = 0x80,
+ .sysc_offs = 0x84,
+ .syss_offs = 0x88,
+ .sysc_flags = SYSS_HAS_RESET_STATUS,
+ .sysc_fields= &omap_hwmod_sysc_type4,
+};
+
+static struct omap_hwmod_class omap4_aes1_hwmod_class = {
+ .name = "aes1",
+ .sysc = &omap4_aes1_sysc,
+};
+
+static struct omap_hwmod omap4_aes1_hwmod = {
+ .name = "aes",
+ .class = &omap4_aes1_hwmod_class,
+ .clkdm_name = "l4_secure_clkdm",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_L4SEC_AES1_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_L4SEC_AES1_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* l3_main_2 -> aes1 */
+static struct omap_hwmod_ocp_if omap4_l3_main_2__aes1 = {
+ .master = &omap44xx_l3_main_2_hwmod,
+ .slave = &omap4_aes1_hwmod,
+ .clk= "aes1_fck",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] __initdata = {
&omap44xx_l3_main_1__dmm,
&omap44xx_mpu__dmm,
@@ -4936,6 +4978,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
&omap44xx_l4_abe__wd_timer3_dma,
&omap44xx_mpu__emif1,
&omap44xx_mpu__emif2,
+ &omap4_l3_main_2__aes1,
NULL,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC
Hi Kevin,
On 26.04.2014 00:52, Kevin Hilman wrote:
Tarek Dakhran writes:
EXYNOS5410 is SoC in Samsung's Exynos5 SoC series.
Add initial support for this SoC.
Signed-off-by: Tarek Dakhran
Signed-off-by: Vyacheslav Tyrtov
Reviewed-by: Tomasz Figa
[...]
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..83ae5fb 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -95,8 +95,8 @@ static inline void platform_do_lowpower(unsigned int cpu, int
*spurious)
for (;;) {
/* make cpu1 to be turned off at next WFI command */
- if (cpu == 1)
- __raw_writel(0, S5P_ARM_CORE1_CONFIGURATION);
+ if (cpu > 0)
+ __raw_writel(0, S5P_ARM_CORE_CONFIGURATION(cpu));
This looks like a fix that's probably not specific to the 5410 and maybe
deserves it's own patch?
[...]
@@ -107,14 +111,14 @@ static int exynos_boot_secondary(unsigned int cpu, struct
task_struct *idle)
*/
write_pen_release(phys_cpu);
- if (!(__raw_readl(S5P_ARM_CORE1_STATUS) & S5P_CORE_LOCAL_PWR_EN)) {
+ if (!(__raw_readl(S5P_ARM_CORE_STATUS(cpu)) & S5P_CORE_LOCAL_PWR_EN)) {
__raw_writel(S5P_CORE_LOCAL_PWR_EN,
-S5P_ARM_CORE1_CONFIGURATION);
+S5P_ARM_CORE_CONFIGURATION(cpu));
timeout = 10;
/* wait max 10 ms until cpu1 is on */
- while ((__raw_readl(S5P_ARM_CORE1_STATUS)
+ while ((__raw_readl(S5P_ARM_CORE_STATUS(cpu))
& S5P_CORE_LOCAL_PWR_EN) != S5P_CORE_LOCAL_PWR_EN) {
if (timeout-- == 0)
break;
...and this hunk too?
Yes, they do, but we are currently refactoring this code anyway.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/10] ARM: dts: DRA7: Add DT node for AES IP
DRA7 SoC has same AES IP as on OMAP4. Add DT entries for the same.
Signed-off-by: Joel Fernandes
---
arch/arm/boot/dts/dra7.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 0533b89..c45f7e9 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -790,6 +790,17 @@
status = "disabled";
};
+ aes: aes@4b50 {
+ compatible = "ti,omap4-aes";
+ ti,hwmods = "aes";
+ reg = <0x4b50 0xa0>;
+ interrupts = ;
+ dmas = <&sdma 111>, <&sdma 110>;
+ dma-names = "tx", "rx";
+ clocks = <&l3_iclk_div>;
+ clock-names = "fck";
+ };
+
des: des@480a5000 {
compatible = "ti,omap4-des";
ti,hwmods = "des";
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/2] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Vivek,
I have reviewed v5 without noticing this one, but I think most of the
comments still apply.
Best regards,
Tomasz
On 22.04.2014 13:24, Vivek Gautam wrote:
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam
---
Mistakenly sent a WIP patchset in v5 version of this patch, that gives
build errors. So fixed those.
Changes from v5:
- Removed any mention about sclk_usbphy30* in the driver.
.../devicetree/bindings/phy/samsung-phy.txt| 40 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 626
4 files changed, 678 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index b422e38..51efe4c 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -114,3 +114,43 @@ Example:
compatible = "samsung,exynos-sataphy-i2c";
reg = <0x38>;
};
+
+Samsung Exynos5 SoC series USB DRD PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+ - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
+ - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
+- reg : Register offset and length of USB DRD PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+ Required clocks:
+ - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
+ used for register access.
+ - ref: PHY's reference clock (usually crystal clock), used for
+ PHY operations, associated by phy name. It is used to
+ determine bit values for clock settings register.
+ For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
+- samsung,pmu-syscon: phandle for PMU system controller interface, used to
+ control pmu registers for power isolation.
+- samsung,pmu-offset: phy power control register offset to
pmu-system-controller
+ base.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+ 0 - UTMI+ type phy,
+ 1 - PIPE3 type phy,
+
+Example:
+ usb3_phy: usbphy@1210 {
+ compatible = "samsung,exynos5250-usbdrd-phy";
+ reg = <0x1210 0x100>;
+ clocks = <&clock 286>, <&clock 1>;
+ clock-names = "phy", "ref";
+ samsung,pmu-syscon = <&pmu_system_controller>;
+ samsung,pmu-offset = <0x704>;
+ #phy-cells = <1>;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 3bb05f1..8a5d2b4 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -166,4 +166,15 @@ config PHY_XGENE
help
This option enables support for APM X-Gene SoC multi-purpose PHY.
+config PHY_EXYNOS5_USBDRD
+ tristate "Exynos5 SoC series USB DRD PHY driver"
+ depends on ARCH_EXYNOS5 && OF
+ depends on HAS_IOMEM
+ select GENERIC_PHY
+ select MFD_SYSCON
+ help
+ Enable USB DRD PHY support for Exynos 5 SoC series.
+ This driver provides PHY interface for USB 3.0 DRD controller
+ present on Exynos5 SoC series.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 2faf78e..31baa0c 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-usb2.o
obj-$(CONFIG_PHY_EXYNOS4X12_USB2) += phy-exynos4x12-usb2.o
obj-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o
obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
+obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
new file mode 100644
index 000..ca1f6ab
--- /dev/null
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -0,0 +1,626 @@
+/*
+ * Samsung EXYNOS5 SoC series USB DRD PHY driver
+ *
+ * Phy provider for USB 3.0 DRD controller on Exynos5 SoC series
+ *
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd.
+ * Author: Vivek Gautam
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the ter
[PATCH 01/10] ARM: OMAP: hwmod: Add SYSC offsets for AES IP
The AES IP has the SIDLE offset by 2 and not 3, to allow SIDLE modes
to work for AES, we add a new SYSC type to HWMOD code.
Signed-off-by: Joel Fernandes
---
arch/arm/mach-omap2/omap_hwmod.h | 11 +++
arch/arm/mach-omap2/omap_hwmod_common_data.c | 10 ++
2 files changed, 21 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 0f97d63..b2efcc8 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -41,6 +41,7 @@ struct omap_device;
extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type1;
extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type2;
extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3;
+extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type4;
/*
* OCP SYSCONFIG bit shifts/masks TYPE1. These are for IPs compliant
@@ -81,6 +82,16 @@ extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3;
#define SYSC_TYPE3_MIDLEMODE_SHIFT 2
#define SYSC_TYPE3_MIDLEMODE_MASK (0x3 << SYSC_TYPE3_MIDLEMODE_SHIFT)
+/*
+ * OCP SYSCONFIG bit shifts/masks TYPE4.
+ */
+#define SYSC_TYPE4_SIDLEMODE_SHIFT 2
+#define SYSC_TYPE4_SIDLEMODE_MASK (0x3 << SYSC_TYPE4_SIDLEMODE_SHIFT)
+#define SYSC_TYPE4_SOFTRESET_SHIFT 1
+#define SYSC_TYPE4_SOFTRESET_MASK (1 << SYSC_TYPE4_SOFTRESET_SHIFT)
+#define SYSC_TYPE4_AUTOIDLE_SHIFT 0
+#define SYSC_TYPE4_AUTOIDLE_MASK (1 << SYSC_TYPE4_AUTOIDLE_SHIFT)
+
/* OCP SYSSTATUS bit shifts/masks */
#define SYSS_RESETDONE_SHIFT 0
#define SYSS_RESETDONE_MASK(1 << SYSS_RESETDONE_SHIFT)
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.c
b/arch/arm/mach-omap2/omap_hwmod_common_data.c
index 79d623b..7443dc0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.c
@@ -59,6 +59,16 @@ struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3 = {
.sidle_shift= SYSC_TYPE3_SIDLEMODE_SHIFT,
};
+/**
+ * struct omap_hwmod_sysc_type4 - TYPE4 sysconfig scheme.
+ * Used by some IPs on AM33xx
+ */
+struct omap_hwmod_sysc_fields omap_hwmod_sysc_type4 = {
+ .sidle_shift= SYSC_TYPE4_SIDLEMODE_SHIFT,
+ .srst_shift = SYSC_TYPE4_SOFTRESET_SHIFT,
+ .autoidle_shift = SYSC_TYPE4_AUTOIDLE_SHIFT,
+};
+
struct omap_dss_dispc_dev_attr omap2_3_dss_dispc_dev_attr = {
.manager_count = 2,
.has_framedonetv_irq= 0
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/10] ARM: DRA7xx: hwmod: Add hwmod data for DES IP
dra7xx SoC has a DES module. Add the required data to hwmod.
Signed-off-by: Joel Fernandes
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 39 +
1 file changed, 39 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 810c205..24ab160 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -561,6 +561,23 @@ static struct omap_hwmod_class dra7xx_gpio_hwmod_class = {
.rev= 2,
};
+static struct omap_hwmod_class_sysconfig dra7xx_des_sysc = {
+ .rev_offs = 0x0030,
+ .sysc_offs = 0x0034,
+ .syss_offs = 0x0038,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO),
+ .sysc_fields= &omap_hwmod_sysc_type4,
+};
+
+static struct omap_hwmod_class dra7xx_des_hwmod_class = {
+ .name = "des",
+ .sysc = &dra7xx_des_sysc,
+ .rev= 2,
+};
+
/* gpio dev_attr */
static struct omap_gpio_dev_attr gpio_dev_attr = {
.bank_width = 32,
@@ -750,6 +767,19 @@ static struct omap_hwmod dra7xx_gpio8_hwmod = {
.dev_attr = &gpio_dev_attr,
};
+static struct omap_hwmod dra7xx_des_hwmod = {
+ .name = "des",
+ .class = &dra7xx_des_hwmod_class,
+ .clkdm_name = "l4sec_clkdm",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4SEC_DES3DES_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4SEC_DES3DES_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
/*
* 'gpmc' class
*
@@ -2170,6 +2200,14 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per1__gpio8 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_per1 -> des */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__des = {
+ .master = &dra7xx_l4_per1_hwmod,
+ .slave = &dra7xx_des_hwmod,
+ .clk= "l3_iclk_div",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space dra7xx_gpmc_addrs[] = {
{
.pa_start = 0x5000,
@@ -2704,6 +2742,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
&dra7xx_l4_per1__uart4,
&dra7xx_l4_per1__uart5,
&dra7xx_l4_per1__uart6,
+ &dra7xx_l4_per1__des,
&dra7xx_l4_per3__usb_otg_ss1,
&dra7xx_l4_per3__usb_otg_ss2,
&dra7xx_l4_per3__usb_otg_ss3,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/10] ARM: OMAP4: hwmod: add hwmod data for DES IP
OMAP4 has a DES IP for DES and 3DES encryption, Add hwmod data for the same.
Signed-off-by: Joel Fernandes
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 35
1 file changed, 35 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 3b12244..8bf6083 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4824,6 +4824,40 @@ static struct omap_hwmod_ocp_if omap4_l3_main_2__aes1 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* DES3DES */
+static struct omap_hwmod_class_sysconfig omap4_des_sysc = {
+ .rev_offs = 0x30,
+ .sysc_offs = 0x34,
+ .syss_offs = 0x38,
+ .sysc_flags = SYSS_HAS_RESET_STATUS,
+ .sysc_fields= &omap_hwmod_sysc_type4,
+};
+
+static struct omap_hwmod_class omap4_des_hwmod_class = {
+ .name = "des",
+ .sysc = &omap4_des_sysc,
+};
+
+static struct omap_hwmod omap4_des_hwmod = {
+ .name = "des",
+ .class = &omap4_des_hwmod_class,
+ .clkdm_name = "l4_secure_clkdm",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_L4SEC_DES3DES_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_L4SEC_DES3DES_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+static struct omap_hwmod_ocp_if omap4_l4_per__des = {
+ .master = &omap44xx_l4_per_hwmod,
+ .slave = &omap4_des_hwmod,
+ .clk= "des_fck",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] __initdata = {
&omap44xx_l3_main_1__dmm,
&omap44xx_mpu__dmm,
@@ -4979,6 +5013,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
&omap44xx_mpu__emif1,
&omap44xx_mpu__emif2,
&omap4_l3_main_2__aes1,
+ &omap4_l4_per__des,
NULL,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/10] ARM: DRA7xx: Add hwmod entries for RNG module
Add the CLKCTRL offsets, SYSC offsets to the RNG module.
Signed-off-by: Joel Fernandes
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 35 +
1 file changed, 35 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index e76e712..7c75e5f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -583,6 +583,15 @@ static struct omap_hwmod_class_sysconfig dra7xx_des_sysc =
{
.sysc_fields= &omap_hwmod_sysc_type4,
};
+/* rng */
+static struct omap_hwmod_class_sysconfig dra7xx_rng_sysc = {
+.rev_offs = 0x1fe0,
+.sysc_offs = 0x1fe4,
+.sysc_flags = SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE,
+.idlemodes = SIDLE_FORCE | SIDLE_NO,
+.sysc_fields= &omap_hwmod_sysc_type1,
+};
+
static struct omap_hwmod_class dra7xx_aes_hwmod_class = {
.name = "aes",
.sysc = &dra7xx_aes_sysc,
@@ -595,6 +604,11 @@ static struct omap_hwmod_class dra7xx_des_hwmod_class = {
.rev= 2,
};
+static struct omap_hwmod_class dra7xx_rng_hwmod_class = {
+.name = "rng",
+.sysc = &dra7xx_rng_sysc,
+};
+
/* gpio dev_attr */
static struct omap_gpio_dev_attr gpio_dev_attr = {
.bank_width = 32,
@@ -810,6 +824,19 @@ static struct omap_hwmod dra7xx_des_hwmod = {
},
};
+static struct omap_hwmod dra7xx_rng_hwmod = {
+.name = "rng",
+.class = &dra7xx_rng_hwmod_class,
+.clkdm_name = "l4sec_clkdm",
+.prcm = {
+.omap4 = {
+.clkctrl_offs = DRA7XX_CM_L4SEC_RNG_CLKCTRL_OFFSET,
+.context_offs = DRA7XX_RM_L4SEC_RNG_CONTEXT_OFFSET,
+.modulemode = MODULEMODE_HWCTRL,
+},
+},
+};
+
/*
* 'gpmc' class
*
@@ -2246,6 +2273,13 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per1__des = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_per1 -> rng */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__rng = {
+.master = &dra7xx_l4_per1_hwmod,
+.slave = &dra7xx_rng_hwmod,
+.user = OCP_USER_MPU,
+};
+
static struct omap_hwmod_addr_space dra7xx_gpmc_addrs[] = {
{
.pa_start = 0x5000,
@@ -2782,6 +2816,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
&dra7xx_l4_per1__uart5,
&dra7xx_l4_per1__uart6,
&dra7xx_l4_per1__des,
+ &dra7xx_l4_per1__rng,
&dra7xx_l4_per3__usb_otg_ss1,
&dra7xx_l4_per3__usb_otg_ss2,
&dra7xx_l4_per3__usb_otg_ss3,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/10] ARM: dts: OMAP4: Add clock nodes for AES/DES nodes
AES/DES nodes have clock nodes in the clock tree, use them. Internal trees were
using hwmod, but now that clock nodes are there, we can use them instead and
upstream it.
Signed-off-by: Joel Fernandes
---
arch/arm/boot/dts/omap4.dtsi |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 27fcac8..f19ffa8 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -806,6 +806,8 @@
interrupts = ;
dmas = <&sdma 111>, <&sdma 110>;
dma-names = "tx", "rx";
+ clocks = <&aes1_fck>;
+ clock-names = "fck";
};
des: des@480a5000 {
@@ -815,6 +817,8 @@
interrupts = ;
dmas = <&sdma 117>, <&sdma 116>;
dma-names = "tx", "rx";
+ clocks = <&des_fck>;
+ clock-names = "fck";
};
abb_mpu: regulator-abb-mpu {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/10] ARM: DRA7xx: hwmod: Add hwmod data for AES IP
DRA7xx SoC has same AES IP as OMAP4. Add hwmod data for the same.
Signed-off-by: Joel Fernandes
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 39 +
1 file changed, 39 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 24ab160..e76e712 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -561,6 +561,17 @@ static struct omap_hwmod_class dra7xx_gpio_hwmod_class = {
.rev= 2,
};
+static struct omap_hwmod_class_sysconfig dra7xx_aes_sysc = {
+ .rev_offs = 0x0080,
+ .sysc_offs = 0x0084,
+ .syss_offs = 0x0088,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type4,
+};
+
static struct omap_hwmod_class_sysconfig dra7xx_des_sysc = {
.rev_offs = 0x0030,
.sysc_offs = 0x0034,
@@ -572,6 +583,12 @@ static struct omap_hwmod_class_sysconfig dra7xx_des_sysc =
{
.sysc_fields= &omap_hwmod_sysc_type4,
};
+static struct omap_hwmod_class dra7xx_aes_hwmod_class = {
+ .name = "aes",
+ .sysc = &dra7xx_aes_sysc,
+ .rev= 2,
+};
+
static struct omap_hwmod_class dra7xx_des_hwmod_class = {
.name = "des",
.sysc = &dra7xx_des_sysc,
@@ -767,6 +784,19 @@ static struct omap_hwmod dra7xx_gpio8_hwmod = {
.dev_attr = &gpio_dev_attr,
};
+static struct omap_hwmod dra7xx_aes_hwmod = {
+ .name = "aes",
+ .class = &dra7xx_aes_hwmod_class,
+ .clkdm_name = "l4sec_clkdm",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4SEC_AES1_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4SEC_AES1_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
static struct omap_hwmod dra7xx_des_hwmod = {
.name = "des",
.class = &dra7xx_des_hwmod_class,
@@ -2118,6 +2148,14 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__hdmi =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l3_main_1 -> aes */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__aes = {
+ .master = &dra7xx_l3_main_1_hwmod,
+ .slave = &dra7xx_aes_hwmod,
+ .clk= "l3_iclk_div",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space dra7xx_elm_addrs[] = {
{
.pa_start = 0x48078000,
@@ -2694,6 +2732,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
&dra7xx_l3_main_1__dss,
&dra7xx_l3_main_1__dispc,
&dra7xx_l3_main_1__hdmi,
+ &dra7xx_l3_main_1__aes,
&dra7xx_l4_per1__elm,
&dra7xx_l4_wkup__gpio1,
&dra7xx_l4_per1__gpio2,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: radeon: screen garbled after page allocator change, was: Re: [patch v2 3/3] mm: page_alloc: fair zone allocator policy
On Fri, Apr 25, 2014 at 05:50:57PM -0400, Jerome Glisse wrote: > On Fri, Apr 25, 2014 at 05:47:48PM -0400, Jerome Glisse wrote: > > On Thu, Apr 24, 2014 at 09:37:22AM -0400, Johannes Weiner wrote: > > > Hi Thomas, > > > > > > On Wed, Apr 02, 2014 at 04:26:08PM +0200, Thomas Schwinge wrote: > > > > Hi! > > > > > > > > On Fri, 2 Aug 2013 11:37:26 -0400, Johannes Weiner > > > > wrote: > > > > > Each zone that holds userspace pages of one workload must be aged at a > > > > > speed proportional to the zone size. [...] > > > > > > > > > Fix this with a very simple round robin allocator. [...] > > > > > > > > This patch, adding NR_ALLOC_BATCH, eventually landed in mainline as > > > > commit 81c0a2bb515fd4daae8cab64352877480792b515 (2013-09-11). > > > > > > > > I recently upgraded a Debian testing system from a 3.11 kernel to 3.12, > > > > and it started to exhibit "strange" issues, which I then bisected to > > > > this > > > > patch. I'm not saying that the patch is faulty, as it seems to be > > > > working fine for everyone else, so I rather assume that something in a > > > > (vastly?) different corner of the kernel (or my hardware?) is broken. > > > > ;-) > > > > > > > > The issue is that when X.org/lightdm starts up, there are "garbled" > > > > section on the screen, for example, rectangular boxes that are just > > > > black > > > > or otherwise "distorted", and/or sets of glyphs (corresponding to a set > > > > of characters; but not all characters) are displayed as rectangular gray > > > > or black boxes, and/or icons in a GNOME session are not displayed > > > > properly, and so on. (Can take a snapshot if that helps?) Switching to > > > > a Linux console, I can use that one fine. Switching back to X, in the > > > > majority of all cases, the screen will be completely black, but with the > > > > mouse cursor still rendered properly (done in hardware, I assume). > > > > > > > > Reverting commit 81c0a2bb515fd4daae8cab64352877480792b515, for example > > > > on > > > > top of v3.12, and everything is back to normal. The problem also > > > > persists with a v3.14 kernel that I just built. > > > > > > > > I will try to figure out what's going on, but will gladly take any > > > > pointers, or suggestions about how to tackle such a problem. > > > > > > > > The hardware is a Fujitsu Siemens Esprimo E5600, mainboard D2264-A1, CPU > > > > AMD Sempron 3000+. There is a on-board graphics thingy, but I'm not > > > > using that; instead I put in a Sapphire Radeon HD 4350 card. > > > > > > I went over this code change repeatedly but I could not see anything > > > directly that would explain it. However, this patch DOES change the > > > way allocations are placed (while still respecting zone specifiers > > > like __GFP_DMA etc.) and so it's possible that they unearthed a > > > corruption, or a wrongly set dma mask in the drivers. > > > > > > Ccing the radeon driver guys. Full quote follows. > > > > Can we get a full dmesg, to know if thing like IOMMU are enabled or not. > > This is even more puzzling as rv710 has 40bit dma mask iirc and thus you > > should be fine even without IOMMU. But given the patch you point to, it > > really can only be something that allocate page in place the GPU fails > > to access. > > > > Thomas how much memory do you have (again dmes will also provide mapping > > informations) ? > > > > My guess is that the pcie bridge can only remap dma page with 32bit dma > > mask while the gpu is fine with 40bit dma mask. I always thought that the > > pcie/pci code did take care of such thing for us. > > > > Cheers, > > Jérôme Glisse > > Forgot to attach patch to test my theory. Does the attached patch fix > the issue ? So this is likely it, the SIS chipset of this motherboard is a freak show. It support both PCIE and AGP at same time http://www.newegg.com/Product/Product.aspx?Item=N82E16813185068 Why in hell ? So my guess is that the root pcie bridge is behind the AGP bridge which swallow any address > 32bit and thus the dma mask of the pcie radeon card is just believing that we are living in a sane world. Cheers, Jérôme Glisse > > > > > > > > > > $ cat < /proc/cpuinfo > > > > processor : 0 > > > > vendor_id : AuthenticAMD > > > > cpu family : 15 > > > > model : 47 > > > > model name : AMD Sempron(tm) Processor 3000+ > > > > stepping: 2 > > > > cpu MHz : 1000.000 > > > > cache size : 128 KB > > > > physical id : 0 > > > > siblings: 1 > > > > core id : 0 > > > > cpu cores : 1 > > > > apicid : 0 > > > > initial apicid : 0 > > > > fpu : yes > > > > fpu_exception : yes > > > > cpuid level : 1 > > > > wp : yes > > > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr > > > > pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext > > > > fxsr_opt lm
[PATCH 07/10] ARM: dts: DRA7: Add DT node for DES IP
DRA7xx SoCs have a DES3DES IP. Add DT data for the same.
Signed-off-by: Joel Fernandes
---
arch/arm/boot/dts/dra7.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1c0f8e1..0533b89 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -789,6 +789,17 @@
dma-names = "tx0", "rx0";
status = "disabled";
};
+
+ des: des@480a5000 {
+ compatible = "ti,omap4-des";
+ ti,hwmods = "des";
+ reg = <0x480a5000 0xa0>;
+ interrupts = ;
+ dmas = <&sdma 117>, <&sdma 116>;
+ dma-names = "tx", "rx";
+ clocks = <&l3_iclk_div>;
+ clock-names = "fck";
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/2] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Vivek,
On 22.04.2014 10:03, Vivek Gautam wrote:
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam
---
.../devicetree/bindings/phy/samsung-phy.txt| 40 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 629
4 files changed, 681 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index b422e38..51efe4c 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -114,3 +114,43 @@ Example:
compatible = "samsung,exynos-sataphy-i2c";
reg = <0x38>;
};
+
+Samsung Exynos5 SoC series USB DRD PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+ - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
+ - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
+- reg : Register offset and length of USB DRD PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+ Required clocks:
+ - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
+ used for register access.
+ - ref: PHY's reference clock (usually crystal clock), used for
+ PHY operations, associated by phy name. It is used to
+ determine bit values for clock settings register.
+ For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
+- samsung,pmu-syscon: phandle for PMU system controller interface, used to
+ control pmu registers for power isolation.
+- samsung,pmu-offset: phy power control register offset to
pmu-system-controller
+ base.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+ 0 - UTMI+ type phy,
+ 1 - PIPE3 type phy,
+
+Example:
+ usb3_phy: usbphy@1210 {
+ compatible = "samsung,exynos5250-usbdrd-phy";
+ reg = <0x1210 0x100>;
+ clocks = <&clock 286>, <&clock 1>;
+ clock-names = "phy", "ref";
+ samsung,pmu-syscon = <&pmu_system_controller>;
+ samsung,pmu-offset = <0x704>;
+ #phy-cells = <1>;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 3bb05f1..8a5d2b4 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -166,4 +166,15 @@ config PHY_XGENE
help
This option enables support for APM X-Gene SoC multi-purpose PHY.
+config PHY_EXYNOS5_USBDRD
+ tristate "Exynos5 SoC series USB DRD PHY driver"
+ depends on ARCH_EXYNOS5 && OF
+ depends on HAS_IOMEM
+ select GENERIC_PHY
+ select MFD_SYSCON
+ help
+ Enable USB DRD PHY support for Exynos 5 SoC series.
+ This driver provides PHY interface for USB 3.0 DRD controller
+ present on Exynos5 SoC series.
+
I think you should probably keep the entries sorted, so this one should
be somewhere around other EXYNOS PHYs.
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 2faf78e..31baa0c 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-usb2.o
obj-$(CONFIG_PHY_EXYNOS4X12_USB2) += phy-exynos4x12-usb2.o
obj-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o
obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
+obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
Ditto.
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
new file mode 100644
index 000..89d7ae8
--- /dev/null
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -0,0 +1,629 @@
+/*
+ * Samsung EXYNOS5 SoC series USB DRD PHY driver
+ *
+ * Phy provider for USB 3.0 DRD controller on Exynos5 SoC series
+ *
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd.
+ * Author: Vivek Gautam
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
[PATCH 00/10] ARM: OMAP: dts and HWMOD entries for crypto modules
Hi Tony, Benoit, Here are some dts/hwmod patches for crypto on OMAP4 and DRA7, couple of them are resends and some are sent for first time now that clock nodes are available in dts. If there's no other feedback, I would like these queued for v3.16. Thanks. Patches 1,2 and 3 are dts, the rest are hwmod entries. The patches are rebased on v3.15-rc2. and can pulled from the Git repo below: https://github.com/joelagnel/linux-kernel.git (branch v3.16/prep-dts) Joel Fernandes (9): ARM: OMAP: hwmod: Add SYSC offsets for AES IP ARM: DRA7xx: hwmod: Add hwmod data for DES IP ARM: DRA7xx: hwmod: Add hwmod data for AES IP ARM: DRA7xx: Add hwmod entries for RNG module ARM: OMAP4: hwmod: Add hwmod data for AES IP ARM: OMAP4: hwmod: add hwmod data for DES IP ARM: dts: DRA7: Add DT node for DES IP ARM: dts: DRA7: Add DT node for AES IP ARM: dts: OMAP4: Add clock nodes for AES/DES nodes Lokesh Vutla (1): ARM: dts: OMAP4: clk: Add clk node for DES IP arch/arm/boot/dts/dra7.dtsi | 22 + arch/arm/boot/dts/omap4.dtsi |4 + arch/arm/boot/dts/omap44xx-clocks.dtsi |8 ++ arch/arm/mach-omap2/omap_hwmod.h | 11 +++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 78 ++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c| 113 ++ arch/arm/mach-omap2/omap_hwmod_common_data.c | 10 +++ drivers/clk/ti/clk-44xx.c|1 + 8 files changed, 247 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 RESEND 0/7] clk: bcm281xx: updates
Quoting Alex Elder (2014-04-21 14:11:36) > This series includes updates for the bcm281xx clock code. It is > dependent on the following patch, which has been taken into the > clk-fixes tree: > clk: bcm281xx: don't use unnamed structs or unions > https://lkml.org/lkml/2014/4/7/322 Thanks for the resend. I've taken these into clk-next. Regards, Mike > > There are three groups of patches: > - Some straightforward code cleanups > - Changing CCU and clock definitions so they're almost > completely initialized statically (i.e., not at run-time) > - Add two small features > > Initially this series included support for "prerequisite clocks" > but that has been removed so it can be discussed independently. > > The patches in this series--based on the current linus/master branch > plus the patch mentioned above--are available here: > http://git.linaro.org/landing-teams/working/broadcom/kernel.git > Branch review/bcm-clk-next-v4 > > -Alex > > History: > - v4: Rebased on current linus/master and reworked to account > for the no-longer-unnamed union and struct members. > - v3: Dropped prerequisite clock support so resolving how > best to handle that can be resolved separately. As > a result, bus clock support is no longer included. > - v2: Removed one unrelated patch from the series. > > Alex Elder (7): > clk: bcm281xx: warn if ccu_wait_bit() fails > clk: bcm281xx: use init_data.name for clock name > clk: bcm281xx: change some symbol names > clk: bcm281xx: initialize CCU structures statically > clk: bcm281xx: define CCU clock data statically > clk: bcm281xx: add clock policy support > clk: bcm281xx: add clock hysteresis support > > drivers/clk/bcm/clk-bcm281xx.c | 243 > +-- > drivers/clk/bcm/clk-kona-setup.c | 229 ++-- > drivers/clk/bcm/clk-kona.c | 212 -- > drivers/clk/bcm/clk-kona.h | 160 +- > 4 files changed, 611 insertions(+), 233 deletions(-) > > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/3] Exynos 5410 support
Tarek Dakhran writes: > The series of patches represent support of Exynos 5410 SoC > > The Exynos 5410 is the first Samsung SoC based on bigLITTLE architecture > > Patches add new platform description, support of clock controller and device > tree for Exynos 5410. > > Has been build on Linux Kernel v3.15-rc1 > Has been tested on: 1) Exynos 5410 reference board (exynos_defconfig) > 2) Odroid-XU board (exynos_defconfig) Tested-by: Kevin Hilman I also boot tested (to initramfs) on my odroid-XU and see the 4 "big" cores booted. Presumably I'm still missing the u-boot/firmware magic for the little cores. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 2/2] fs/ext4/fsync.c: generic_file_fsync call based on barrier flag
generic_file_fsync has been updated to issue a flush for
older filesystems.
This patch checks barrier flag in ext4 mount flags
and calls the right function.
Suggested-by: Jan Kara
Suggested-by: Christoph Hellwig
Cc: Jan Kara
Cc: Christoph Hellwig
Cc: Alexander Viro
Cc: "Theodore Ts'o"
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
fs/ext4/fsync.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/fsync.c b/fs/ext4/fsync.c
index a8bc47f..95bbca0 100644
--- a/fs/ext4/fsync.c
+++ b/fs/ext4/fsync.c
@@ -107,7 +107,11 @@ int ext4_sync_file(struct file *file, loff_t start, loff_t
end, int datasync)
}
if (!journal) {
- ret = generic_file_fsync(file, start, end, datasync);
+ if (test_opt(inode->i_sb, BARRIER))
+ ret = generic_file_fsync(file, start, end, datasync);
+ else
+ ret = __generic_file_fsync(file, start, end, datasync,
+ false);
if (!ret && !hlist_empty(&inode->i_dentry))
ret = ext4_sync_parent(inode);
goto out;
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] SCSI fixes for 3.15-rc3
On Fri, Apr 25, 2014 at 3:49 PM, David Rientjes wrote: > > Hmm, I see why this is needed because of the scsi_put_command(cmd), but I > think you need to do struct scsi_device *sdev = ACCESS_ONCE(cmd->device) > instead to prevent gcc from messing with the code generation. No, if gcc were to move the access to 'cmd' to after the 'scsi_put_command(cmd)', that would be a major compiler bug. Compilers can't just randomly move code around, guys. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC
Tarek Dakhran writes:
> EXYNOS5410 is SoC in Samsung's Exynos5 SoC series.
> Add initial support for this SoC.
>
> Signed-off-by: Tarek Dakhran
> Signed-off-by: Vyacheslav Tyrtov
> Reviewed-by: Tomasz Figa
[...]
> diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
> index 5eead53..83ae5fb 100644
> --- a/arch/arm/mach-exynos/hotplug.c
> +++ b/arch/arm/mach-exynos/hotplug.c
> @@ -95,8 +95,8 @@ static inline void platform_do_lowpower(unsigned int cpu,
> int *spurious)
> for (;;) {
>
> /* make cpu1 to be turned off at next WFI command */
> - if (cpu == 1)
> - __raw_writel(0, S5P_ARM_CORE1_CONFIGURATION);
> + if (cpu > 0)
> + __raw_writel(0, S5P_ARM_CORE_CONFIGURATION(cpu));
This looks like a fix that's probably not specific to the 5410 and maybe
deserves it's own patch?
[...]
> @@ -107,14 +111,14 @@ static int exynos_boot_secondary(unsigned int cpu,
> struct task_struct *idle)
>*/
> write_pen_release(phys_cpu);
>
> - if (!(__raw_readl(S5P_ARM_CORE1_STATUS) & S5P_CORE_LOCAL_PWR_EN)) {
> + if (!(__raw_readl(S5P_ARM_CORE_STATUS(cpu)) & S5P_CORE_LOCAL_PWR_EN)) {
> __raw_writel(S5P_CORE_LOCAL_PWR_EN,
> - S5P_ARM_CORE1_CONFIGURATION);
> + S5P_ARM_CORE_CONFIGURATION(cpu));
>
> timeout = 10;
>
> /* wait max 10 ms until cpu1 is on */
> - while ((__raw_readl(S5P_ARM_CORE1_STATUS)
> + while ((__raw_readl(S5P_ARM_CORE_STATUS(cpu))
> & S5P_CORE_LOCAL_PWR_EN) != S5P_CORE_LOCAL_PWR_EN) {
> if (timeout-- == 0)
> break;
...and this hunk too?
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/2] FS: Add generic data flush to fsync
This patch issues a flush in generic_file_fsync.
(Modern filesystems already do it)
-Behaviour can be reversed using /sys/devices/.../cache_type
-Filesystems can also call __generic_file_fsync with bool flush false
Suggested-by: Jan Kara
Suggested-by: Christoph Hellwig
Cc: Jan Kara
Cc: Christoph Hellwig
Cc: Alexander Viro
Cc: "Theodore Ts'o"
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
fs/libfs.c | 36 +---
include/linux/fs.h | 1 +
2 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/fs/libfs.c b/fs/libfs.c
index a184424..7d4711d 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -3,6 +3,7 @@
* Library for filesystems writers.
*/
+#include
#include
#include
#include
@@ -923,16 +924,20 @@ struct dentry *generic_fh_to_parent(struct super_block
*sb, struct fid *fid,
EXPORT_SYMBOL_GPL(generic_fh_to_parent);
/**
- * generic_file_fsync - generic fsync implementation for simple filesystems
+ * __generic_file_fsync - generic fsync implementation for simple filesystems
+ *
* @file: file to synchronize
+ * @start: start offset in bytes
+ * @end: end offset in bytes (inclusive)
* @datasync: only synchronize essential metadata if true
+ * @flush: bool to issue the flush
*
* This is a generic implementation of the fsync method for simple
* filesystems which track all non-inode metadata in the buffers list
* hanging off the address_space structure.
*/
-int generic_file_fsync(struct file *file, loff_t start, loff_t end,
- int datasync)
+int __generic_file_fsync(struct file *file, loff_t start, loff_t end,
+int datasync, bool flush)
{
struct inode *inode = file->f_mapping->host;
int err;
@@ -952,10 +957,35 @@ int generic_file_fsync(struct file *file, loff_t start,
loff_t end,
err = sync_inode_metadata(inode, 1);
if (ret == 0)
ret = err;
+ if (flush == true) {
+ err = blkdev_issue_flush(inode->i_sb->s_bdev, GFP_KERNEL,
+NULL);
+ if (ret == 0)
+ ret = err;
+ }
+
out:
mutex_unlock(&inode->i_mutex);
return ret;
}
+EXPORT_SYMBOL(__generic_file_fsync);
+
+/**
+ * generic_file_fsync - generic fsync implementation for simple filesystems
+ * @file: file to synchronize
+ * @start: start offset in bytes
+ * @end: end offset in bytes (inclusive)
+ * @datasync: only synchronize essential metadata if true
+ *
+ * Calls __generic_file_fsync with flush = true
+ */
+
+int generic_file_fsync(struct file *file, loff_t start, loff_t end,
+ int datasync)
+{
+ return __generic_file_fsync(file, start, end, datasync, true);
+
+}
EXPORT_SYMBOL(generic_file_fsync);
/**
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 7a9c5bc..ecd6adea 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2590,6 +2590,7 @@ extern ssize_t simple_read_from_buffer(void __user *to,
size_t count,
extern ssize_t simple_write_to_buffer(void *to, size_t available, loff_t *ppos,
const void __user *from, size_t count);
+extern int __generic_file_fsync(struct file *, loff_t, loff_t, int, bool);
extern int generic_file_fsync(struct file *, loff_t, loff_t, int);
extern int generic_check_addressable(unsigned, u64);
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Git v2.0.0-rc1
A release candidate Git v2.0.0-rc1 is now available for testing
at the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the 'v2.0.0-rc1'
tag and the 'master' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v2.0 Release Notes (draft)
==
Backward compatibility notes
When "git push [$there]" does not say what to push, we have used the
traditional "matching" semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there). In Git 2.0, the default is now the "simple" semantics,
which pushes:
- only the current branch to the branch with the same name, and only
when the current branch is set to integrate with that remote
branch, if you are pushing to the same remote as you fetch from; or
- only the current branch to the branch with the same name, if you
are pushing to a remote that is not where you usually fetch from.
You can use the configuration variable "push.default" to change
this. If you are an old-timer who wants to keep using the
"matching" semantics, you can set the variable to "matching", for
example. Read the documentation for other possibilities.
When "git add -u" and "git add -A" are run inside a subdirectory
without specifying which paths to add on the command line, they
operate on the entire tree for consistency with "git commit -a" and
other commands (these commands used to operate only on the current
subdirectory). Say "git add -u ." or "git add -A ." if you want to
limit the operation to the current directory.
"git add " is the same as "git add -A " now, so that
"git add dir/" will notice paths you removed from the directory and
record the removal. In older versions of Git, "git add " used
to ignore removals. You can say "git add --ignore-removal " to
add only added or modified paths in , if you really want to.
The "-q" option to "git diff-files", which does *NOT* mean "quiet",
has been removed (it told Git to ignore deletion, which you can do
with "git diff-files --diff-filter=d").
"git request-pull" lost a few "heuristics" that often led to mistakes.
The default prefix for "git svn" has changed in Git 2.0. For a long
time, "git svn" created its remote-tracking branches directly under
refs/remotes, but it now places them under refs/remotes/origin/ unless
it is told otherwise with its --prefix option.
Updates since v1.9 series
-
UI, Workflows & Features
* The "multi-mail" post-receive hook (in contrib/) has been updated
to a more recent version from the upstream.
* "git gc --aggressive" learned "--depth" option and
"gc.aggressiveDepth" configuration variable to allow use of a less
insane depth than the built-in default value of 250.
* "git log" learned the "--show-linear-break" option to show where a
single strand-of-pearls is broken in its output.
* The "rev-parse --parseopt" mechanism used by scripted Porcelains to
parse command line options and to give help text learned to take
the argv-help (the placeholder string for an option parameter,
e.g. "key-id" in "--gpg-sign=").
* The pattern to find where the function begins in C/C++ used in
"diff" and "grep -p" have been updated to help C++ source better.
* "git rebase" learned to interpret a lone "-" as "@{-1}", the
branch that we were previously on.
* "git commit --cleanup=" learned a new mode, scissors.
* "git tag --list" output can be sorted using "version sort" with
"--sort=version:refname".
* Discard the accumulated "heuristics" to guess from which branch the
result wants to be pulled from and make sure what the end user
specified is not second-guessed by "git request-pull", to avoid
mistakes. When you pushed out your 'master' branch to your public
repository as 'for-linus', use the new "master:for-linus" syntax to
denote the branch to be pulled.
* "git grep" learned to behave in a way similar to native grep when
"-h" (no header) and "-c" (count) options are given.
* "git push" via transport-helper interface (e.g. remote-hg) has
been updated to allow ref deletion in a way similar to the natively
supported transports.
* The "simple" mode is the default for "git push".
* "git add -u" and "git add -A", when run without any pathspec, is a
tree-wide operation even when run inside a subdirectory of a
working tree.
* "git add is the same as "git add -A " now.
* "core.statinfo" configuration variable, which is a
never-advertised synonym to "core.checkstat", has been removed.
* The "-q" option t
Re: [GIT PULL] SCSI fixes for 3.15-rc3
On Fri, 25 Apr 2014, James Bottomley wrote:
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 65a123d..9db097a 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -137,6 +137,7 @@ static void __scsi_queue_insert(struct scsi_cmnd *cmd,
> int reason, int unbusy)
>* lock such that the kblockd_schedule_work() call happens
>* before blk_cleanup_queue() finishes.
>*/
> + cmd->result = 0;
> spin_lock_irqsave(q->queue_lock, flags);
> blk_requeue_request(q, cmd->request);
> kblockd_schedule_work(q, &device->requeue_work);
> @@ -1044,6 +1045,7 @@ static int scsi_init_sgtable(struct request *req,
> struct scsi_data_buffer *sdb,
> */
> int scsi_init_io(struct scsi_cmnd *cmd, gfp_t gfp_mask)
> {
> + struct scsi_device *sdev = cmd->device;
> struct request *rq = cmd->request;
>
> int error = scsi_init_sgtable(rq, &cmd->sdb, gfp_mask);
> @@ -1091,7 +1093,7 @@ err_exit:
> scsi_release_buffers(cmd);
> cmd->request->special = NULL;
> scsi_put_command(cmd);
> - put_device(&cmd->device->sdev_gendev);
> + put_device(&sdev->sdev_gendev);
> return error;
> }
> EXPORT_SYMBOL(scsi_init_io);
Hmm, I see why this is needed because of the scsi_put_command(cmd), but I
think you need to do struct scsi_device *sdev = ACCESS_ONCE(cmd->device)
instead to prevent gcc from messing with the code generation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH 3/4] clk: Use lockless functions for debug printing
In the near future we're going to move the prepare lock to a
per-clock ww_mutex. Use the lockless functions here for printing
the rate and accuracy so that we don't run into AA deadlocks in
the future.
Signed-off-by: Stephen Boyd
---
drivers/clk/clk.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index fd22a4583013..48b3a5594839 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -111,8 +111,8 @@ static void clk_summary_show_one(struct seq_file *s, struct
clk *c, int level)
seq_printf(s, "%*s%-*s %-11d %-12d %-10lu %-11lu",
level * 3 + 1, "",
30 - level * 3, c->name,
- c->enable_count, c->prepare_count, clk_get_rate(c),
- clk_get_accuracy(c));
+ c->enable_count, c->prepare_count, __clk_get_rate(c),
+ __clk_get_accuracy(c));
seq_printf(s, "\n");
}
@@ -171,8 +171,8 @@ static void clk_dump_one(struct seq_file *s, struct clk *c,
int level)
seq_printf(s, "\"%s\": { ", c->name);
seq_printf(s, "\"enable_count\": %d,", c->enable_count);
seq_printf(s, "\"prepare_count\": %d,", c->prepare_count);
- seq_printf(s, "\"rate\": %lu", clk_get_rate(c));
- seq_printf(s, "\"accuracy\": %lu", clk_get_accuracy(c));
+ seq_printf(s, "\"rate\": %lu", __clk_get_rate(c));
+ seq_printf(s, "\"accuracy\": %lu", __clk_get_accuracy(c));
}
static void clk_dump_subtree(struct seq_file *s, struct clk *c, int level)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH 1/4] clk: Recalc rate and accuracy in underscore functions if not caching
When we move this code to use ww_mutex we'll need to call
__clk_get_rate() and __clk_get_accuracy(), instead of their
non-underscore counterparts, while holding the clock's prepare
mutex. Move the recalculation of these values into the underscore
functions so that we can call __clk_get_rate() and
__clk_get_accuracy() while holding locks.
Signed-off-by: Stephen Boyd
---
drivers/clk/clk.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 1bdd561985fc..bebeaeec4aa1 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -617,6 +617,8 @@ unsigned int __clk_get_prepare_count(struct clk *clk)
return !clk ? 0 : clk->prepare_count;
}
+static void __clk_recalc_rates(struct clk *clk, unsigned long msg);
+
unsigned long __clk_get_rate(struct clk *clk)
{
unsigned long ret;
@@ -626,6 +628,9 @@ unsigned long __clk_get_rate(struct clk *clk)
goto out;
}
+ if (clk->flags & CLK_GET_RATE_NOCACHE)
+ __clk_recalc_rates(clk, 0);
+
ret = clk->rate;
if (clk->flags & CLK_IS_ROOT)
@@ -639,11 +644,16 @@ out:
}
EXPORT_SYMBOL_GPL(__clk_get_rate);
+static void __clk_recalc_accuracies(struct clk *clk);
+
unsigned long __clk_get_accuracy(struct clk *clk)
{
if (!clk)
return 0;
+ if (clk->flags & CLK_GET_ACCURACY_NOCACHE)
+ __clk_recalc_accuracies(clk);
+
return clk->accuracy;
}
@@ -1108,9 +1118,6 @@ long clk_get_accuracy(struct clk *clk)
unsigned long accuracy;
clk_prepare_lock();
- if (clk && (clk->flags & CLK_GET_ACCURACY_NOCACHE))
- __clk_recalc_accuracies(clk);
-
accuracy = __clk_get_accuracy(clk);
clk_prepare_unlock();
@@ -1176,10 +1183,6 @@ unsigned long clk_get_rate(struct clk *clk)
unsigned long rate;
clk_prepare_lock();
-
- if (clk && (clk->flags & CLK_GET_RATE_NOCACHE))
- __clk_recalc_rates(clk, 0);
-
rate = __clk_get_rate(clk);
clk_prepare_unlock();
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH 0/4] Use wound/wait mutexes in the common clock framework
The prepare mutex in the common clock framework can lead to tasks waiting a
long time for other tasks to finish a frequency switch or prepare/unprepare
step. In my particular case I have a clock controlled by a co-processor that
can take 10s of millliseconds to change rate. I've seen scenarios where it can
take more than 20ms for another thread to acquire the prepare mutex because
it's waiting on the co-processor to finish changing the rate. Pair this with a
display driver that wants to scale it's clock up before drawing a frame and you
may start dropping frames at 60FPS (one frame is budgeted 16ms). Similar
scenarios exist like CPUfreq scaling getting blocked for large amounts of time.
This patchset attempts to remedy this problem by introducing a per-clock
wwmutex. This allows multiple threads to be traversing and updating the tree at
the same time granted they don't touch the same subtree. In my testcase
this removes the contention on the co-processor clocks and allows the display
driver to scale the clock up and down in parallel.
There is a drawback though, we lose the recursive mutex property. I don't have
a good solution for this besides "don't do that" and I believe we actually have
usecases for such a thing? Technically a thread recursing into the clock
framework probably wouldn't be acquiring the same locks (and even if it was we
could recognize that this is the same thread acquiring it again) but due to the
way wound/wait mutexes work we may need to release all locks and try again the
second time we're in the clock framework and that sounds really annoying to
handle. We'd need to have some list of threads and acquire contexts and then we
would need to rely on drivers returning -EDEADLK through the ops, etc. At least
lockdep will complain loudly when you try this so it isn't a silent failure.
Due to the loss of recursion we can't allow clock drivers to call the
non-underscore versions of the clock APIs either. I don't see too many users
right now under drivers/clk but those would need to be updated before these
patches could be applied.
Please note these patches are based on some cleanup patches I sent already[1]
Stephen Boyd (4):
clk: Recalc rate and accuracy in underscore functions if not caching
clk: Make __clk_lookup() use a list instead of tree search
clk: Use lockless functions for debug printing
clk: Use ww_mutexes for clk_prepare_{lock/unlock}
drivers/clk/clk.c | 598 +++-
include/linux/clk-private.h | 4 +
2 files changed, 478 insertions(+), 124 deletions(-)
[1] https://lkml.org/lkml/2014/3/26/423
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH 4/4] clk: Use ww_mutexes for clk_prepare_{lock/unlock}
Changing the rate of a "slow" clock can take 10s of milliseconds
while changing the rate of a "fast" clock can be done in a few
microseconds. With one prepare mutex a task that's trying to
change the rate of a fast clock may have to wait for a slow
clock's rate to change before it can proceed. Consider the case
of a GPU driver which wants to scale up the GPU speed before
drawing a frame that gets stuck behind a PLL being reprogrammed.
In this case the thread performing the drawing may have to wait
for 10s of milliseconds while the PLL stabilizes. At 60 FPS
waiting for more than 16ms to grab the prepare mutex can lead to
missed frame updates and visible artifacts.
Furthermore, the recursive prepare mutex suffers from a deadlock
when a clock, say clock S, is controlled by a chip sitting on the
SPI bus and we need to enable the SPI master controller's clock
to send a message to enable clock S. The SPI core will use a
different thread to enable the SPI controller's clock causing the
recursion detection mechanism to fail.
Remedy these problems by introducing a per-clock wound/wait mutex
to replace the global prepare mutex. This should allow discreet
parts of the clock tree to change rates and prepare/unprepare in
parallel with each-other. Unfortunately we lose the recursive
feature of the prepare mutex with this change and lockdep
complains if the same thread tries to call any clk_* operations
from within a clock op even if that thread is only acquiring new
locks that aren't already held.
Signed-off-by: Stephen Boyd
---
drivers/clk/clk.c | 525 +---
include/linux/clk-private.h | 3 +
2 files changed, 445 insertions(+), 83 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 48b3a5594839..6596f47927df 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -20,18 +20,18 @@
#include
#include
#include
+#include
#include "clk.h"
static DEFINE_SPINLOCK(enable_lock);
-static DEFINE_MUTEX(prepare_lock);
+static DEFINE_WW_CLASS(prepare_ww_class);
-static struct task_struct *prepare_owner;
static struct task_struct *enable_owner;
-
-static int prepare_refcnt;
static int enable_refcnt;
+static DEFINE_MUTEX(clk_list_lock);
+static DEFINE_MUTEX(clk_notifier_lock);
static DEFINE_MUTEX(clk_lookup_lock);
static HLIST_HEAD(clk_root_list);
static HLIST_HEAD(clk_orphan_list);
@@ -39,30 +39,236 @@ static HLIST_HEAD(clk_lookup_list);
static LIST_HEAD(clk_notifier_list);
/*** locking ***/
-static void clk_prepare_lock(void)
+static void __clk_unlock(struct list_head *list)
+{
+ struct clk *entry, *temp;
+
+ list_for_each_entry_safe (entry, temp, list, ww_list) {
+ list_del_init(&entry->ww_list);
+ ww_mutex_unlock(&entry->lock);
+ }
+}
+
+static void clk_unlock(struct list_head *list, struct ww_acquire_ctx *ctx)
+{
+ __clk_unlock(list);
+ ww_acquire_fini(ctx);
+}
+
+static int clk_lock_one(struct clk *clk, struct list_head *list,
+ struct ww_acquire_ctx *ctx)
+{
+ int ret;
+
+ if (!clk)
+ return 0;
+
+ ret = ww_mutex_lock(&clk->lock, ctx);
+ if (ret == -EDEADLK) {
+ __clk_unlock(list);
+ ww_mutex_lock_slow(&clk->lock, ctx);
+ list_add(&clk->ww_list, list);
+ } else if (ret != -EALREADY) {
+ list_add_tail(&clk->ww_list, list);
+ }
+
+ return ret;
+}
+
+
+static int __clk_lock_subtree(struct clk *clk, struct list_head *list,
+struct ww_acquire_ctx *ctx)
+{
+ int ret;
+ struct clk *child;
+
+ lockdep_assert_held(&clk->lock.base);
+
+ hlist_for_each_entry(child, &clk->children, child_node) {
+ ret = clk_lock_one(child, list, ctx);
+ if (ret == -EDEADLK)
+ return ret;
+ ret = __clk_lock_subtree(child, list, ctx);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static void clk_lock_subtree(struct clk *clk, struct list_head *list,
+struct ww_acquire_ctx *ctx)
{
- if (!mutex_trylock(&prepare_lock)) {
- if (prepare_owner == current) {
- prepare_refcnt++;
- return;
+ int ret;
+
+ do {
+ ret = clk_lock_one(clk, list, ctx);
+ if (ret == -EDEADLK)
+ continue;
+ ret = __clk_lock_subtree(clk, list, ctx);
+ } while (ret == -EDEADLK);
+}
+
+/* Lock a clock, it's parent (and optionally a new parent),
+ * and all it's descendents
+ */
+static void clk_parent_lock(struct clk *clk, struct clk *new_parent,
+ struct list_head *list, struct ww_acquire_ctx *ctx)
+{
+ int ret;
+
+ ww_acquire_init(ctx, &prepare_ww_class);
+
+ do {
+ ret = clk_lock_one(clk,
[RFC/PATCH 2/4] clk: Make __clk_lookup() use a list instead of tree search
In the near future we're going to move the prepare lock to be a
per-clock ww_mutex. __clk_lookup() is called very deep in the
set-rate path and we would like to avoid having to take all the
locks in the clock tree to search for a clock (basically
defeating the purpose of introducing per-clock locks). Introduce
a new list that contains all clocks registered in the system and
walk this list until the clock is found.
Signed-off-by: Stephen Boyd
---
drivers/clk/clk.c | 52 +
include/linux/clk-private.h | 1 +
2 files changed, 21 insertions(+), 32 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index bebeaeec4aa1..fd22a4583013 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -32,8 +32,10 @@ static struct task_struct *enable_owner;
static int prepare_refcnt;
static int enable_refcnt;
+static DEFINE_MUTEX(clk_lookup_lock);
static HLIST_HEAD(clk_root_list);
static HLIST_HEAD(clk_orphan_list);
+static HLIST_HEAD(clk_lookup_list);
static LIST_HEAD(clk_notifier_list);
/*** locking ***/
@@ -706,46 +708,23 @@ out:
}
EXPORT_SYMBOL_GPL(__clk_is_enabled);
-static struct clk *__clk_lookup_subtree(const char *name, struct clk *clk)
-{
- struct clk *child;
- struct clk *ret;
-
- if (!strcmp(clk->name, name))
- return clk;
-
- hlist_for_each_entry(child, &clk->children, child_node) {
- ret = __clk_lookup_subtree(name, child);
- if (ret)
- return ret;
- }
-
- return NULL;
-}
-
struct clk *__clk_lookup(const char *name)
{
- struct clk *root_clk;
- struct clk *ret;
+ struct clk *clk;
if (!name)
return NULL;
- /* search the 'proper' clk tree first */
- hlist_for_each_entry(root_clk, &clk_root_list, child_node) {
- ret = __clk_lookup_subtree(name, root_clk);
- if (ret)
- return ret;
+ mutex_lock(&clk_lookup_lock);
+ hlist_for_each_entry(clk, &clk_lookup_list, lookup_node) {
+ if (!strcmp(clk->name, name))
+ goto found;
}
+ clk = NULL;
+found:
+ mutex_unlock(&clk_lookup_lock);
- /* if not found, then search the orphan tree */
- hlist_for_each_entry(root_clk, &clk_orphan_list, child_node) {
- ret = __clk_lookup_subtree(name, root_clk);
- if (ret)
- return ret;
- }
-
- return NULL;
+ return clk;
}
/*
@@ -1855,6 +1834,11 @@ int __clk_init(struct device *dev, struct clk *clk)
clk->parent = __clk_init_parent(clk);
+ /* Insert into clock lookup list */
+ mutex_lock(&clk_lookup_lock);
+ hlist_add_head(&clk->lookup_node, &clk_lookup_list);
+ mutex_unlock(&clk_lookup_lock);
+
/*
* Populate clk->parent if parent has already been __clk_init'd. If
* parent has not yet been __clk_init'd then place clk in the orphan
@@ -2159,6 +2143,10 @@ void clk_unregister(struct clk *clk)
hlist_del_init(&clk->child_node);
+ mutex_lock(&clk_lookup_lock);
+ hlist_del_init(&clk->lookup_node);
+ mutex_unlock(&clk_lookup_lock);
+
if (clk->prepare_count)
pr_warn("%s: unregistering prepared clock: %s\n",
__func__, clk->name);
diff --git a/include/linux/clk-private.h b/include/linux/clk-private.h
index efbf70b9fd84..3cd98a930006 100644
--- a/include/linux/clk-private.h
+++ b/include/linux/clk-private.h
@@ -48,6 +48,7 @@ struct clk {
unsigned long accuracy;
struct hlist_head children;
struct hlist_node child_node;
+ struct hlist_node lookup_node;
unsigned intnotifier_count;
#ifdef CONFIG_DEBUG_FS
struct dentry *dentry;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] ARM: Exynos: PMU cleanup and refactoring for using DT
Hi Pankaj, Just a small note - please refrain from sending next versions of series in reply to previous version. With threading applied, it gets hard to notice that a new version was posted, because the first message of the thread is always v1. Also it makes threads unnecessarily long. Best regards, Tomasz On 25.04.2014 14:32, Pankaj Dubey wrote: This patch series, does some minor cleanup and modifies Exynos PMU related code for mapping and initialization of Exynos Power Management Unit (PMU) base address from device tree. This is also preparation for moving PMU related code out of machine folder and moving into a "drivers/mfd", so that ARM64 based SoC can utilize common piece of code. These patches require change in Exynos4210, Exynos4212 and Exynos4412 dtsi files, which has been posted as separate patch series [2] These patches are created on top of Kukjin Kim's for-next (v3.15-rc1 tag) branch. These patches depends on following two patch series: 1) mfd: syscon: Support early initialization https://lkml.org/lkml/2014/4/8/239 2) Add PMU node for Exynos SoCs http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg29329.html We have tested these patches on SMDK5250 and Arndale (Exynos5250) boards for System boot and PMU initialization and S2R. For testing on Arndale (Exynos5250) board: Tested-by: Pankaj Dubey Changes Since v1: - Rebased on latest for-next of Kukjin Kim's tree. - Added patch: "Make exynos machine_ops as static". For making more cleanup in "mach-exynos/common.h" as suggested by Tomasz Figa. - Addressed comments of Tomasz Figa for cleaning "mach-exynos/common.h". - Updated patch: Remove file path from comment section As suggested by Michel Simek, instead of updating file path lets remove them from each file under "mach-exynos". Even though Kukjin pointed out that there is similar patch pending from Sachin/Tushar but since I could not find I have included this here. If I have missed something please point to any existing such patch. - Updated patch: Add support for mapping PMU base address via DT - Removed __initdata from declaration of "exynos_pmu_base", as it caused kernel crash as pointed out by Vikas Sajjan. - Added support for Syscon initialization and getting PMU regmap handle as suggested by Sylwester. Since current implementation of early intialization [1] has limitation that "early_syscon_init" requires DT to be unflattened and system should be able to allocate memory, we can't use regmap handles for platsmp.c file as "smp_secondary_init" will be called before DT unflattening. So I have kept both method for accessing PMU base address. platsmp.c will use ioremmaped address where as rest other files can use regmap handle. - Added patch: Remove "linux/bug.h" from pmu.c. - Updated patch: Refactored code for PMU register mapping via DT - Modified to use regmap_read/write when using regmap handle. - Added patch: Move "mach/map.h" inclusion from regs-pmu.h to platsmp.c - Added patch: Add device tree based initialization support for PMU. - Convert existing PMU implementation to be a device tree based before moving it to "drivers/mfd" folder. As suggested by Bartlomiej. - Dropped making a platform_driver for PMU, as currently PMU binding has two compatibility strings as "samsung, exynosxxx-pmu", "syscon", once we enable MFD_SYSCON config option, current "syscon" driver probe gets called and PMU probe never gets called. So modified PMU initialization code to scan DT and match against supported compatiblity string in driver code, and once we get matching node use that for accessing PMU regmap handle using "syscon_early_regmap_lookup_by_phandle". If there is any better solution please suggest. Pankaj Dubey (6): ARM: EXYNOS: Make exynos machine_ops as static ARM: EXYNOS: Cleanup "mach-exynos/common.h" file ARM: EXYNOS: Remove file path from comment section ARM: EXYNOS: Refactored code for using PMU address via DT ARM: EXYNOS: Move "mach/map.h" inclusion from regs-pmu.h to platsmp.c ARM: EXYNOS: Add device tree based initialization support for PMU. Young-Gun Jang (4): ARM: EXYNOS: Move SYSREG definition into sys-reg specific file. ARM: EXYNOS: Remove regs-pmu.h header dependency from pm_domain ARM: EXYNOS: Add support for mapping PMU base address via DT ARM: EXYNOS: Remove "linux/bug.h" from pmu.c arch/arm/mach-exynos/Kconfig |2 + arch/arm/mach-exynos/common.h | 13 +- arch/arm/mach-exynos/cpuidle.c | 37 +- arch/arm/mach-exynos/exynos.c | 104 +- arch/arm/mach-exynos/headsmp.S |2 - arch/arm/mach-exynos/hotplug.c |7 +- arch/arm/mach-exynos/include/mach/map.h|3 - arch/arm/mach-exyn
[PATCH 0/8] [v4] x86: rework tlb range flushing code
Changes from v3: * Include the patch I was using to gather detailed statistics about the length of the ranged TLB flushes * Fix some documentation typos * Add a patch to rework the remote tlb flush code to plumb the tracepoints in easier, and add missing tracepoints * use __print_symbolic() for the human-readable tracepoint descriptions * change an int to bool in patch 1 * Specifically call out that we removed itlb vs. dtlb logic Changes from v2: * Added a brief comment above the ceiling tunable * Updated the documentation to mention large pages and say "individual flush" instead of invlpg in most cases. I guess the x86 tree is probably the right place to queue this up. I've run this through a variety of systems in the LKP harness, as well as running it on my desktop for a few days. I'm yet to see an to see if any perfmance regressions (or gains) show up. Without the last (instrumentation/debugging) patch: arch/x86/include/asm/mmu_context.h |6 ++ arch/x86/include/asm/processor.h |1 arch/x86/kernel/cpu/amd.c |7 -- arch/x86/kernel/cpu/common.c | 13 arch/x86/kernel/cpu/intel.c| 26 - arch/x86/mm/tlb.c | 106 ++--- include/linux/mm_types.h |8 ++ 7 files changed, 68 insertions(+), 99 deletions(-) [davehans@viggo linux.git]$ -- I originally went to look at this becuase I realized that newer CPUs were not present in the intel_tlb_flushall_shift_set() code. I went to try to figure out where to stick newer CPUs (do we consider them more like SandyBridge or IvyBridge), and was not able to repeat the original experiments. Instead, this set does: 1. Rework the code a bit to ready it for tracepoints 2. Add tracepoints 3. Add a new tunable and set it to a sane value -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] x86: mm: rip out complicated, out-of-date, buggy TLB flushing
From: Dave Hansen
I think the flush_tlb_mm_range() code that tries to tune the
flush sizes based on the CPU needs to get ripped out for
several reasons:
1. It is obviously buggy. It uses mm->total_vm to judge the
task's footprint in the TLB. It should certainly be using
some measure of RSS, *NOT* ->total_vm since only resident
memory can populate the TLB.
2. Haswell, and several other CPUs are missing from the
intel_tlb_flushall_shift_set() function. Thus, it has been
demonstrated to bitrot quickly in practice.
3. It is plain wrong in my vm:
[0.037444] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
[0.037444] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0
[0.037444] tlb_flushall_shift: 6
Which leads to it to never use invlpg.
4. The assumptions about TLB refill costs are wrong:
http://lkml.kernel.org/r/1337782555-8088-3-git-send-email-alex@intel.com
(more on this in later patches)
5. I can not reproduce the original data: https://lkml.org/lkml/2012/5/17/59
I believe the sample times were too short. Running the
benchmark in a loop yields times that vary quite a bit.
Note that this leaves us with a static ceiling of 1 page. This
is a conservative, dumb setting, and will be revised in a later
patch.
This also removes the code which attempts to predict whether we
are flushing data or instructions. We expect instruction flushes
to be relatively rare and not worth tuning for explicitly.
Signed-off-by: Dave Hansen
Acked-by: Rik van Riel
Acked-by: Mel Gorman
---
b/arch/x86/include/asm/processor.h |1
b/arch/x86/kernel/cpu/amd.c|7 --
b/arch/x86/kernel/cpu/common.c | 13 -
b/arch/x86/kernel/cpu/intel.c | 26 ---
b/arch/x86/mm/tlb.c| 87 -
5 files changed, 13 insertions(+), 121 deletions(-)
diff -puN
arch/x86/include/asm/processor.h~x8x-mm-rip-out-complicated-tlb-flushing
arch/x86/include/asm/processor.h
--- a/arch/x86/include/asm/processor.h~x8x-mm-rip-out-complicated-tlb-flushing
2014-04-25 15:33:12.526032931 -0700
+++ b/arch/x86/include/asm/processor.h 2014-04-25 15:33:12.536033383 -0700
@@ -72,7 +72,6 @@ extern u16 __read_mostly tlb_lld_4k[NR_I
extern u16 __read_mostly tlb_lld_2m[NR_INFO];
extern u16 __read_mostly tlb_lld_4m[NR_INFO];
extern u16 __read_mostly tlb_lld_1g[NR_INFO];
-extern s8 __read_mostly tlb_flushall_shift;
/*
* CPU type and hardware bug flags. Kept separately for each CPU.
diff -puN arch/x86/kernel/cpu/amd.c~x8x-mm-rip-out-complicated-tlb-flushing
arch/x86/kernel/cpu/amd.c
--- a/arch/x86/kernel/cpu/amd.c~x8x-mm-rip-out-complicated-tlb-flushing
2014-04-25 15:33:12.527032976 -0700
+++ b/arch/x86/kernel/cpu/amd.c 2014-04-25 15:33:12.536033383 -0700
@@ -741,11 +741,6 @@ static unsigned int amd_size_cache(struc
}
#endif
-static void cpu_set_tlb_flushall_shift(struct cpuinfo_x86 *c)
-{
- tlb_flushall_shift = 6;
-}
-
static void cpu_detect_tlb_amd(struct cpuinfo_x86 *c)
{
u32 ebx, eax, ecx, edx;
@@ -793,8 +788,6 @@ static void cpu_detect_tlb_amd(struct cp
tlb_lli_2m[ENTRIES] = eax & mask;
tlb_lli_4m[ENTRIES] = tlb_lli_2m[ENTRIES] >> 1;
-
- cpu_set_tlb_flushall_shift(c);
}
static const struct cpu_dev amd_cpu_dev = {
diff -puN arch/x86/kernel/cpu/common.c~x8x-mm-rip-out-complicated-tlb-flushing
arch/x86/kernel/cpu/common.c
--- a/arch/x86/kernel/cpu/common.c~x8x-mm-rip-out-complicated-tlb-flushing
2014-04-25 15:33:12.529033068 -0700
+++ b/arch/x86/kernel/cpu/common.c 2014-04-25 15:33:12.537033428 -0700
@@ -479,26 +479,17 @@ u16 __read_mostly tlb_lld_2m[NR_INFO];
u16 __read_mostly tlb_lld_4m[NR_INFO];
u16 __read_mostly tlb_lld_1g[NR_INFO];
-/*
- * tlb_flushall_shift shows the balance point in replacing cr3 write
- * with multiple 'invlpg'. It will do this replacement when
- * flush_tlb_lines <= active_lines/2^tlb_flushall_shift.
- * If tlb_flushall_shift is -1, means the replacement will be disabled.
- */
-s8 __read_mostly tlb_flushall_shift = -1;
-
void cpu_detect_tlb(struct cpuinfo_x86 *c)
{
if (this_cpu->c_detect_tlb)
this_cpu->c_detect_tlb(c);
printk(KERN_INFO "Last level iTLB entries: 4KB %d, 2MB %d, 4MB %d\n"
- "Last level dTLB entries: 4KB %d, 2MB %d, 4MB %d, 1GB %d\n"
- "tlb_flushall_shift: %d\n",
+ "Last level dTLB entries: 4KB %d, 2MB %d, 4MB %d, 1GB %d\n",
tlb_lli_4k[ENTRIES], tlb_lli_2m[ENTRIES],
tlb_lli_4m[ENTRIES], tlb_lld_4k[ENTRIES],
tlb_lld_2m[ENTRIES], tlb_lld_4m[ENTRIES],
- tlb_lld_1g[ENTRIES], tlb_flushall_shift);
+ tlb_lld_1g[ENTRIES]);
}
void detect_ht(struct cpuinfo_x86 *c)
diff -puN arch/x86/kernel/cpu/intel.c~x8x-mm-rip-out-complicated-tlb-flushing
arch/x86/kernel/cpu/intel.c
--- a/arch/x86/kernel/cpu/intel.c~x8x-mm-rip-out-complicated-tlb-flushing
Re: [PATCH v2 10/10] ARM: EXYNOS: Add device tree based initialization support for PMU.
Hi,
On 25.04.2014 14:32, Pankaj Dubey wrote:
This patch adds device tree based initialization for PMU and modifies
PMU initialization implementation in following way:
1: Let's initialize PMU based on device tree compatibility string.
2: Obtain PMU regmap handle using "syscon_early_regmap_lookup_by_phandle"
so that we can reduce dependency over machine header files.
3: Separate each SoC's PMU initialization function and bind this initialization
function with PMU compatibility string.
4 : It also removes uses of soc_is_exynos() thus making PMU implementation
independent of "plat/cpu.h".
Signed-off-by: Pankaj Dubey
Signed-off-by: Young-Gun Jang
---
arch/arm/mach-exynos/pmu.c | 182 +---
1 file changed, 138 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 67116a5..abcf753 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -9,17 +9,31 @@
* published by the Free Software Foundation.
*/
-#include
#include
#include
-
-#include
+#include
+#include
+#include
+#include
#include "common.h"
#include "regs-pmu.h"
+enum exynos_pmu_id {
+ PMU_EXYNOS4210,
+ PMU_EXYNOS4X12,
+ PMU_EXYNOS4412,
+ PMU_EXYNOS5250,
+};
+
+struct exynos_pmu_data {
+ enum exynos_pmu_id pmu_id;
+ struct regmap *pmu_regmap;
Again, since this uses the PMU node directly and doesn't seem to access
any registers shared with other drivers (or at least not at the time
most the functions from this file are called) I don't think there is any
reason why not to use of_iomap() and access the registers directly.
What about adding more fields to this struct? For example .pmu_config,
.pmu_config_extra (for model-specific settings, like for Exynos4412, see
my comment below) and (*pmu_init)? Of course the regmap (or base
address) would have to be moved outside, as it isn't const data.
Then for each PMU variant there would be a static const struct will all
those fields already filled in and entries in OF match table would
already point to appropriate structure.
+};
+
+struct exynos_pmu_data *pmu_data;
static const struct exynos_pmu_conf *exynos_pmu_config;
-static struct regmap *pmu_regmap;
+typedef void (*exynos_pmu_init_t)(void);
static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
/* { .reg = address, .val = { AFTR, LPA, SLEEP } */
@@ -348,28 +362,31 @@ static void exynos5_init_pmu(void)
* Enable both SC_FEEDBACK and SC_COUNTER
*/
for (i = 0 ; i < ARRAY_SIZE(exynos5_list_both_cnt_feed) ; i++) {
- regmap_read(pmu_regmap, exynos5_list_both_cnt_feed[i], &tmp);
+ regmap_read(pmu_data->pmu_regmap,
+ exynos5_list_both_cnt_feed[i], &tmp);
tmp |= (EXYNOS5_USE_SC_FEEDBACK |
EXYNOS5_USE_SC_COUNTER);
- regmap_write(pmu_regmap, exynos5_list_both_cnt_feed[i], tmp);
+ regmap_write(pmu_data->pmu_regmap,
+ exynos5_list_both_cnt_feed[i], tmp);
}
/*
* SKIP_DEACTIVATE_ACEACP_IN_PWDN_BITFIELD Enable
*/
- regmap_read(pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, &tmp);
+ regmap_read(pmu_data->pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, &tmp);
tmp |= EXYNOS5_SKIP_DEACTIVATE_ACEACP_IN_PWDN;
- regmap_write(pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
+ regmap_write(pmu_data->pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
/*
* Disable WFI/WFE on XXX_OPTION
*/
for (i = 0 ; i < ARRAY_SIZE(exynos5_list_diable_wfi_wfe) ; i++) {
- tmp = regmap_read(pmu_regmap, exynos5_list_diable_wfi_wfe[i],
- &tmp);
+ tmp = regmap_read(pmu_data->pmu_regmap,
+ exynos5_list_diable_wfi_wfe[i], &tmp);
tmp &= ~(EXYNOS5_OPTION_USE_STANDBYWFE |
EXYNOS5_OPTION_USE_STANDBYWFI);
- regmap_write(pmu_regmap, exynos5_list_diable_wfi_wfe[i], tmp);
+ regmap_write(pmu_data->pmu_regmap,
+ exynos5_list_diable_wfi_wfe[i], tmp);
}
}
@@ -377,52 +394,129 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
{
unsigned int i;
- if (soc_is_exynos5250())
+ if (pmu_data->pmu_id == PMU_EXYNOS5250)
exynos5_init_pmu();
Next field could be added to exynos_pmu_data struct, called
(*powerdown_conf) and then the code above replaced with:
if (pmu_data->powerdown_conf)
pmu_data->powerdown_conf(mode);
for (i = 0; (exynos_pmu_config[i].offset != PMU_TABLE_END) ; i++)
- regmap_write(pmu_regmap, exynos_pmu_config[i].offset,
+ regmap_write(pmu_data->pmu_regmap, exynos_pmu_config[i].offset,
e
[PATCH 5/8] x86: mm: add tracepoints for TLB flushes
Changes from v3:
* remove trace_tlb.c and __print_symbolic() instead
* make sure to cover all cases in flush_tlb_func()
* remove _DONE "reason" since it was not precise enough
--
From: Dave Hansen
We don't have any good way to figure out what kinds of flushes
are being attempted. Right now, we can try to use the vm
counters, but those only tell us what we actually did with the
hardware (one-by-one vs full) and don't tell us what was actually
_requested_.
This allows us to select out "interesting" TLB flushes that we
might want to optimize (like the ranged ones) and ignore the ones
that we have very little control over (the ones at context
switch).
Signed-off-by: Dave Hansen
Acked-by: Rik van Riel
Cc: Mel Gorman
---
b/arch/x86/include/asm/mmu_context.h |6 +
b/arch/x86/mm/tlb.c | 14 ++-
b/include/linux/mm_types.h |8 ++
b/include/trace/events/tlb.h | 41 +++
4 files changed, 67 insertions(+), 2 deletions(-)
diff -puN arch/x86/include/asm/mmu_context.h~tlb-trace-flushes
arch/x86/include/asm/mmu_context.h
--- a/arch/x86/include/asm/mmu_context.h~tlb-trace-flushes 2014-04-25
15:33:13.352070158 -0700
+++ b/arch/x86/include/asm/mmu_context.h2014-04-25 15:33:13.358070428
-0700
@@ -3,6 +3,10 @@
#include
#include
+#include
+
+#include
+
#include
#include
#include
@@ -44,6 +48,7 @@ static inline void switch_mm(struct mm_s
/* Re-load page tables */
load_cr3(next->pgd);
+ trace_tlb_flush(TLB_FLUSH_ON_TASK_SWITCH, TLB_FLUSH_ALL);
/* Stop flush ipis for the previous mm */
cpumask_clear_cpu(cpu, mm_cpumask(prev));
@@ -71,6 +76,7 @@ static inline void switch_mm(struct mm_s
* to make sure to use no freed page tables.
*/
load_cr3(next->pgd);
+ trace_tlb_flush(TLB_FLUSH_ON_TASK_SWITCH,
TLB_FLUSH_ALL);
load_LDT_nolock(&next->context);
}
}
diff -puN arch/x86/mm/tlb.c~tlb-trace-flushes arch/x86/mm/tlb.c
--- a/arch/x86/mm/tlb.c~tlb-trace-flushes 2014-04-25 15:33:13.353070203
-0700
+++ b/arch/x86/mm/tlb.c 2014-04-25 15:33:13.359070473 -0700
@@ -14,6 +14,9 @@
#include
#include
+#define CREATE_TRACE_POINTS
+#include
+
DEFINE_PER_CPU_SHARED_ALIGNED(struct tlb_state, cpu_tlbstate)
= { &init_mm, 0, };
@@ -49,6 +52,7 @@ void leave_mm(int cpu)
if (cpumask_test_cpu(cpu, mm_cpumask(active_mm))) {
cpumask_clear_cpu(cpu, mm_cpumask(active_mm));
load_cr3(swapper_pg_dir);
+ trace_tlb_flush(TLB_FLUSH_ON_TASK_SWITCH, TLB_FLUSH_ALL);
}
}
EXPORT_SYMBOL_GPL(leave_mm);
@@ -107,15 +111,19 @@ static void flush_tlb_func(void *info)
count_vm_tlb_event(NR_TLB_REMOTE_FLUSH_RECEIVED);
if (this_cpu_read(cpu_tlbstate.state) == TLBSTATE_OK) {
- if (f->flush_end == TLB_FLUSH_ALL)
+ if (f->flush_end == TLB_FLUSH_ALL) {
local_flush_tlb();
- else {
+ trace_tlb_flush(TLB_REMOTE_SHOOTDOWN, TLB_FLUSH_ALL);
+ } else {
unsigned long addr;
+ unsigned long nr_pages =
+ f->flush_end - f->flush_start / PAGE_SIZE;
addr = f->flush_start;
while (addr < f->flush_end) {
__flush_tlb_single(addr);
addr += PAGE_SIZE;
}
+ trace_tlb_flush(TLB_REMOTE_SHOOTDOWN, nr_pages);
}
} else
leave_mm(smp_processor_id());
@@ -153,6 +161,7 @@ void flush_tlb_current_task(void)
count_vm_tlb_event(NR_TLB_LOCAL_FLUSH_ALL);
local_flush_tlb();
+ trace_tlb_flush(TLB_LOCAL_SHOOTDOWN, TLB_FLUSH_ALL);
if (cpumask_any_but(mm_cpumask(mm), smp_processor_id()) < nr_cpu_ids)
flush_tlb_others(mm_cpumask(mm), mm, 0UL, TLB_FLUSH_ALL);
preempt_enable();
@@ -191,6 +200,7 @@ void flush_tlb_mm_range(struct mm_struct
__flush_tlb_single(addr);
}
}
+ trace_tlb_flush(TLB_LOCAL_MM_SHOOTDOWN, base_pages_to_flush);
out:
if (base_pages_to_flush == TLB_FLUSH_ALL) {
start = 0UL;
diff -puN include/linux/mm_types.h~tlb-trace-flushes include/linux/mm_types.h
--- a/include/linux/mm_types.h~tlb-trace-flushes2014-04-25
15:33:13.355070293 -0700
+++ b/include/linux/mm_types.h 2014-04-25 15:33:13.359070473 -0700
@@ -510,4 +510,12 @@ static inline void clear_tlb_flush_pendi
}
#endif
+enum tlb_flush_reason {
+ TLB_FLUSH_ON_TASK_SWITCH,
+ TLB_REMOTE_SHOOTDOWN,
+ TLB_LOCAL_SHOOTDOWN,
+ TLB_LOCAL_MM_SHOOTDOWN,
+
