* Re: simple framebuffer slower by factor of 20, on socfpga (arm) platform
From: Nicolas Pitre @ 2015-05-06 20:32 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Geert Uytterhoeven, Tomi Valkeinen, Pavel Machek, Archit Taneja,
Marek Vasut, kernel list, Dinh Nguyen,
Jean-Christophe PLAGNIOL-VILLARD, Grant Likely, Rob Herring,
Jingoo Han, Rob Clark, Linux Fbdev development list,
devicetree@vger.kernel.org, Alexander Shiyan, H Hartley Sweeten
In-Reply-To: <20150506104504.GM2067@n2100.arm.linux.org.uk>
On Wed, 6 May 2015, Russell King - ARM Linux wrote:
> On Tue, Apr 28, 2015 at 11:28:53AM -0400, Nicolas Pitre wrote:
> > On Tue, 28 Apr 2015, Russell King - ARM Linux wrote:
> >
> > > On Fri, Apr 24, 2015 at 03:46:56PM +0200, Geert Uytterhoeven wrote:
> > > > So please optimize ARM's _memcpy_fromio(), _memcpy_toio(), and _memset_io().
> > > > That will benefit other drivers on ARM, too.
> > >
> > > That's not going to happen.
> > >
> > > I've had a patch which does that, but people are concerned that it changes
> > > the behaviour of the functions by changing the access size, which could
> > > cause regressions. It seems people are far too worried about that to even
> > > consider trying. :(
> >
> > What about making the optimized implementation available via kconfig?
>
> I'd prefer not to. My personal feeling is to put the patch in and just be
> done with it - these functions are supposed to be used on IO areas which
> don't care about access size (in other words, are memory-like rather than
> being register-like.) Here's the rather old patch:
>
> From: Russell King <rmk+kernel@arm.linux.org.uk>
> Subject: [PATCH] ARM: optimize memset_io()/memcpy_fromio()/memcpy_toio()
>
> If we are building for a LE platform, and we haven't overriden the
> MMIO ops, then we can optimize the mem*io operations using the
> standard string functions.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Nicolas Pitre <nico@linaro.org>
> ---
> arch/arm/include/asm/io.h | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
> index d070741b2b37..358c8206419b 100644
> --- a/arch/arm/include/asm/io.h
> +++ b/arch/arm/include/asm/io.h
> @@ -23,6 +23,7 @@
>
> #ifdef __KERNEL__
>
> +#include <linux/string.h>
> #include <linux/types.h>
> #include <asm/byteorder.h>
> #include <asm/memory.h>
> @@ -312,9 +313,33 @@ extern void _memset_io(volatile void __iomem *, int, size_t);
> #define writesw(p,d,l) __raw_writesw(p,d,l)
> #define writesl(p,d,l) __raw_writesl(p,d,l)
>
> +#ifndef __ARMBE__
> +static inline void memset_io(volatile void __iomem *dst, unsigned c,
> + size_t count)
> +{
> + memset((void __force *)dst, c, count);
> +}
> +#define memset_io(dst,c,count) memset_io(dst,c,count)
> +
> +static inline void memcpy_fromio(void *to, const volatile void __iomem *from,
> + size_t count)
> +{
> + memcpy(to, (const void __force *)from, count);
> +}
> +#define memcpy_fromio(to,from,count) memcpy_fromio(to,from,count)
> +
> +static inline void memcpy_toio(volatile void __iomem *to, const void *from,
> + size_t count)
> +{
> + memcpy((void __force *)to, from, count);
> +}
> +#define memcpy_toio(to,from,count) memcpy_toio(to,from,count)
> +
> +#else
> #define memset_io(c,v,l) _memset_io(c,(v),(l))
> #define memcpy_fromio(a,c,l) _memcpy_fromio((a),c,(l))
> #define memcpy_toio(c,a,l) _memcpy_toio(c,(a),(l))
> +#endif
>
> #endif /* readl */
>
> --
> 1.8.3.1
>
>
>
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.
>
>
^ permalink raw reply
* Re: [PATCH v2 08/17] gpio: locomo: implement per-pin irq handling
From: Dmitry Eremin-Solenikov @ 2015-05-06 16:42 UTC (permalink / raw)
To: Linus Walleij
Cc: Russell King, Daniel Mack, Robert Jarzmik, Alexandre Courbot,
Wolfram Sang, Dmitry Torokhov, Bryan Wu, Richard Purdie,
Samuel Ortiz, Lee Jones, Mark Brown, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Liam Girdwood,
Andrea Adami, linux-arm-kernel@lists.infradead.org,
linux-gpio@vger.kernel.org, linux-i2c@vger.kernel.org,
Linux Input, linux-leds
In-Reply-To: <CACRpkdZt+rjzVSqXE6MDaY5S9gezeTu+2QWu31xKsg08TpXibw@mail.gmail.com>
2015-05-06 17:15 GMT+03:00 Linus Walleij <linus.walleij@linaro.org>:
> On Tue, Apr 28, 2015 at 1:55 AM, Dmitry Eremin-Solenikov
> <dbaryshkov@gmail.com> wrote:
>
>> LoCoMo has a possibility to generate per-GPIO edge irqs. Support for
>> that was there in old locomo driver, got 'cleaned up' during old driver
>> IRQ cascading cleanup and is now reimplemented. It is expected that
>> SL-5500 (collie) will use locomo gpio irqs for mmc detection irq.
>>
>> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Thanks for review of the patches.
> Assume this will also go through MFD.
>
>> + irq_set_chained_handler(lg->irq, NULL);
>> + irq_set_handler_data(lg->irq, NULL);
>
> Why is this needed? If the GPIOLIB_IRQCHIP code in
> gpiolib.c is not doing this then maybe it's the core code that
> needs fixing rather than having this in the driver.
I have skimmed through the rest of drivers using
gpiochip_set_chained_irqchip(). Indeed none of the drivers NULL
the chained handled and handler data. However I couldn't locate
the code where they would be cleared.
Should I still send the patch fixing the GPIOLIB_IRQCHIP?
>
> Yours,
> Linus Walleij
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 02/17] leds: port locomo leds driver to new locomo core
From: Jacek Anaszewski @ 2015-05-06 15:05 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: Russell King, Daniel Mack, Robert Jarzmik, Linus Walleij,
Alexandre Courbot, Wolfram Sang, Dmitry Torokhov, Bryan Wu,
Richard Purdie, Samuel Ortiz, Lee Jones, Mark Brown, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Liam Girdwood,
Andrea Adami, linux-arm-kernel, linux-gpio, linux-i2c,
linux-input, linux-leds, linux-spi, linux-fbdev, alsa-devel
In-Reply-To: <1430178954-11138-3-git-send-email-dbaryshkov@gmail.com>
On 04/28/2015 01:55 AM, Dmitry Eremin-Solenikov wrote:
> Adapt locomo leds driver to new locomo core setup.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> drivers/leds/Kconfig | 1 -
> drivers/leds/leds-locomo.c | 119 +++++++++++++++++++++++----------------------
> 2 files changed, 61 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 966b960..4b4650b 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -79,7 +79,6 @@ config LEDS_LM3642
> config LEDS_LOCOMO
> tristate "LED Support for Locomo device"
> depends on LEDS_CLASS
> - depends on SHARP_LOCOMO
Why do you remove this dependency?
> help
> This option enables support for the LEDs on Sharp Locomo.
> Zaurus models SL-5500 and SL-5600.
> diff --git a/drivers/leds/leds-locomo.c b/drivers/leds/leds-locomo.c
> index 80ba048..7fde812 100644
> --- a/drivers/leds/leds-locomo.c
> +++ b/drivers/leds/leds-locomo.c
> @@ -9,89 +9,92 @@
> */
>
> #include <linux/kernel.h>
> -#include <linux/init.h>
> -#include <linux/module.h>
> -#include <linux/device.h>
> #include <linux/leds.h>
> -
> -#include <mach/hardware.h>
> -#include <asm/hardware/locomo.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/mfd/locomo.h>
Please keep alphabetical order.
> +
> +struct locomo_led {
> + struct led_classdev led;
> + struct regmap *regmap;
> + unsigned int reg;
> +};
>
> static void locomoled_brightness_set(struct led_classdev *led_cdev,
> - enum led_brightness value, int offset)
> + enum led_brightness value)
> {
> - struct locomo_dev *locomo_dev = LOCOMO_DEV(led_cdev->dev->parent);
> - unsigned long flags;
> + struct locomo_led *led = container_of(led_cdev, struct locomo_led, led);
>
> - local_irq_save(flags);
> - if (value)
> - locomo_writel(LOCOMO_LPT_TOFH, locomo_dev->mapbase + offset);
> - else
> - locomo_writel(LOCOMO_LPT_TOFL, locomo_dev->mapbase + offset);
> - local_irq_restore(flags);
> + regmap_write(led->regmap, led->reg,
> + value ? LOCOMO_LPT_TOFH : LOCOMO_LPT_TOFL);
> }
Please use work queue for setting brightness. This is required for the
driver to be compatible with led triggers. You can refer to the
existing LED drivers on how to implement this.
>
> -static void locomoled_brightness_set0(struct led_classdev *led_cdev,
> - enum led_brightness value)
> +static int locomo_led_register(
> + struct device *dev,
> + struct locomo_led *led,
> + const char *name,
> + const char *trigger,
> + struct regmap *regmap,
> + unsigned int reg)
> {
> - locomoled_brightness_set(led_cdev, value, LOCOMO_LPT0);
> + led->led.name = name;
> + led->led.flags = LED_CORE_SUSPENDRESUME;
> + led->led.default_trigger = trigger;
> + led->led.brightness_set = locomoled_brightness_set;
> + led->regmap = regmap;
> + led->reg = reg;
> +
> + return devm_led_classdev_register(dev, &led->led);
> }
>
> -static void locomoled_brightness_set1(struct led_classdev *led_cdev,
> - enum led_brightness value)
> -{
> - locomoled_brightness_set(led_cdev, value, LOCOMO_LPT1);
> -}
> -
> -static struct led_classdev locomo_led0 = {
> - .name = "locomo:amber:charge",
> - .default_trigger = "main-battery-charging",
> - .brightness_set = locomoled_brightness_set0,
> -};
> -
> -static struct led_classdev locomo_led1 = {
> - .name = "locomo:green:mail",
> - .default_trigger = "nand-disk",
> - .brightness_set = locomoled_brightness_set1,
> -};
> -
> -static int locomoled_probe(struct locomo_dev *ldev)
> +static int locomoled_probe(struct platform_device *pdev)
> {
> int ret;
> -
> - ret = led_classdev_register(&ldev->dev, &locomo_led0);
> + struct locomo_led *leds;
> + struct regmap *regmap;
> +
> + leds = devm_kzalloc(&pdev->dev, 2 * sizeof(*leds), GFP_KERNEL);
> + if (!leds)
> + return -ENOMEM;
> +
> + regmap = dev_get_regmap(pdev->dev.parent, NULL);
> + if (!regmap)
> + return -ENODEV;
> +
> + ret = locomo_led_register(
> + &pdev->dev,
> + leds,
> + "locomo:amber:charge",
> + "main-battery-charging",
> + regmap,
> + LOCOMO_LPT0);
> if (ret < 0)
> return ret;
>
> - ret = led_classdev_register(&ldev->dev, &locomo_led1);
> + ret = locomo_led_register(
> + &pdev->dev,
> + leds + 1,
> + "locomo:green:mail",
> + "mmc0",
> + regmap,
> + LOCOMO_LPT1);
> if (ret < 0)
> - led_classdev_unregister(&locomo_led0);
> -
> - return ret;
> -}
> + return ret;
>
> -static int locomoled_remove(struct locomo_dev *dev)
> -{
> - led_classdev_unregister(&locomo_led0);
> - led_classdev_unregister(&locomo_led1);
> return 0;
> }
>
> -static struct locomo_driver locomoled_driver = {
> - .drv = {
> - .name = "locomoled"
> +static struct platform_driver locomoled_driver = {
> + .driver = {
> + .name = "locomo-led"
> },
> - .devid = LOCOMO_DEVID_LED,
> .probe = locomoled_probe,
> - .remove = locomoled_remove,
> };
>
> -static int __init locomoled_init(void)
> -{
> - return locomo_driver_register(&locomoled_driver);
> -}
> -module_init(locomoled_init);
> +module_platform_driver(locomoled_driver);
>
> MODULE_AUTHOR("John Lenz <lenz@cs.wisc.edu>");
> MODULE_DESCRIPTION("Locomo LED driver");
> MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:locomo-led");
>
--
Best Regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH v2 17/17] ARM: drop old LoCoMo driver
From: Linus Walleij @ 2015-05-06 14:22 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: Russell King, Daniel Mack, Robert Jarzmik, Alexandre Courbot,
Wolfram Sang, Dmitry Torokhov, Bryan Wu, Richard Purdie,
Samuel Ortiz, Lee Jones, Mark Brown, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Liam Girdwood,
Andrea Adami,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Input,
linux-leds-u79uwXL29TaqPxH82wqD4g
In-Reply-To: <1430178954-11138-18-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Apr 28, 2015 at 1:55 AM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> As there are no in-kernel users of old locomo driver, drop all
> alltogether. Remove Kconfig entry, driver and header.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Good riddance.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 14/17] ARM: pxa: poodle: use new LoCoMo driver
From: Linus Walleij @ 2015-05-06 14:20 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: Russell King, Daniel Mack, Robert Jarzmik, Alexandre Courbot,
Wolfram Sang, Dmitry Torokhov, Bryan Wu, Richard Purdie,
Samuel Ortiz, Lee Jones, Mark Brown, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Liam Girdwood,
Andrea Adami,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Input,
linux-leds-u79uwXL29TaqPxH82wqD4g
In-Reply-To: <1430178954-11138-15-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Apr 28, 2015 at 1:55 AM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> Convert poodle to use new mfd-based LoCoMo driver.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
This:
> +static struct gpiod_lookup_table poodle_audio_gpios_table = {
> + .dev_id = "poodle-audio",
> + .table = {
> + GPIO_LOOKUP("locomo-gpio", 10, "mute-l", GPIO_ACTIVE_LOW),
> + GPIO_LOOKUP("locomo-gpio", 11, "mute-r", GPIO_ACTIVE_LOW),
> + GPIO_LOOKUP("locomo-gpio", 8, "amp-on", GPIO_ACTIVE_LOW),
> + { },
> + },
> +},
Is very nice to see.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 13/17] ASoC: pxa: poodle: make use of new locomo GPIO interface
From: Linus Walleij @ 2015-05-06 14:19 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: Russell King, Daniel Mack, Robert Jarzmik, Alexandre Courbot,
Wolfram Sang, Dmitry Torokhov, Bryan Wu, Richard Purdie,
Samuel Ortiz, Lee Jones, Mark Brown, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Liam Girdwood,
Andrea Adami, linux-arm-kernel@lists.infradead.org,
linux-gpio@vger.kernel.org, linux-i2c@vger.kernel.org,
Linux Input, linux-leds
In-Reply-To: <1430178954-11138-14-git-send-email-dbaryshkov@gmail.com>
On Tue, Apr 28, 2015 at 1:55 AM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> Since LoCoMo driver has been converted to provide proper gpiolib
> interface, make poodle ASoC platform driver use gpiolib API.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 08/17] gpio: locomo: implement per-pin irq handling
From: Linus Walleij @ 2015-05-06 14:15 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: Russell King, Daniel Mack, Robert Jarzmik, Alexandre Courbot,
Wolfram Sang, Dmitry Torokhov, Bryan Wu, Richard Purdie,
Samuel Ortiz, Lee Jones, Mark Brown, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Liam Girdwood,
Andrea Adami, linux-arm-kernel@lists.infradead.org,
linux-gpio@vger.kernel.org, linux-i2c@vger.kernel.org,
Linux Input, linux-leds
In-Reply-To: <1430178954-11138-9-git-send-email-dbaryshkov@gmail.com>
On Tue, Apr 28, 2015 at 1:55 AM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> LoCoMo has a possibility to generate per-GPIO edge irqs. Support for
> that was there in old locomo driver, got 'cleaned up' during old driver
> IRQ cascading cleanup and is now reimplemented. It is expected that
> SL-5500 (collie) will use locomo gpio irqs for mmc detection irq.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Assume this will also go through MFD.
> + irq_set_chained_handler(lg->irq, NULL);
> + irq_set_handler_data(lg->irq, NULL);
Why is this needed? If the GPIOLIB_IRQCHIP code in
gpiolib.c is not doing this then maybe it's the core code that
needs fixing rather than having this in the driver.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 07/17] gpio: port LoCoMo gpio support from old driver
From: Linus Walleij @ 2015-05-06 14:12 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: Russell King, Daniel Mack, Robert Jarzmik, Alexandre Courbot,
Wolfram Sang, Dmitry Torokhov, Bryan Wu, Richard Purdie,
Samuel Ortiz, Lee Jones, Mark Brown, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Liam Girdwood,
Andrea Adami, linux-arm-kernel@lists.infradead.org,
linux-gpio@vger.kernel.org, linux-i2c@vger.kernel.org,
Linux Input, linux-leds
In-Reply-To: <1430178954-11138-8-git-send-email-dbaryshkov@gmail.com>
On Tue, Apr 28, 2015 at 1:55 AM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> Add gpiolib driver for gpio pins placed on the LoCoMo GA.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
I assume this will be funneled through the MFD tree?
Yours,
Linus Walleij
^ permalink raw reply
* Re: simple framebuffer slower by factor of 20, on socfpga (arm) platform
From: Russell King - ARM Linux @ 2015-05-06 10:45 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Geert Uytterhoeven, Tomi Valkeinen, Pavel Machek, Archit Taneja,
Marek Vasut, kernel list, Dinh Nguyen,
Jean-Christophe PLAGNIOL-VILLARD, Grant Likely, Rob Herring,
Jingoo Han, Rob Clark, Linux Fbdev development list,
devicetree@vger.kernel.org, Alexander Shiyan, H Hartley Sweeten
In-Reply-To: <alpine.LFD.2.11.1504281127200.1582@knanqh.ubzr>
On Tue, Apr 28, 2015 at 11:28:53AM -0400, Nicolas Pitre wrote:
> On Tue, 28 Apr 2015, Russell King - ARM Linux wrote:
>
> > On Fri, Apr 24, 2015 at 03:46:56PM +0200, Geert Uytterhoeven wrote:
> > > So please optimize ARM's _memcpy_fromio(), _memcpy_toio(), and _memset_io().
> > > That will benefit other drivers on ARM, too.
> >
> > That's not going to happen.
> >
> > I've had a patch which does that, but people are concerned that it changes
> > the behaviour of the functions by changing the access size, which could
> > cause regressions. It seems people are far too worried about that to even
> > consider trying. :(
>
> What about making the optimized implementation available via kconfig?
I'd prefer not to. My personal feeling is to put the patch in and just be
done with it - these functions are supposed to be used on IO areas which
don't care about access size (in other words, are memory-like rather than
being register-like.) Here's the rather old patch:
From: Russell King <rmk+kernel@arm.linux.org.uk>
Subject: [PATCH] ARM: optimize memset_io()/memcpy_fromio()/memcpy_toio()
If we are building for a LE platform, and we haven't overriden the
MMIO ops, then we can optimize the mem*io operations using the
standard string functions.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/include/asm/io.h | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index d070741b2b37..358c8206419b 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -23,6 +23,7 @@
#ifdef __KERNEL__
+#include <linux/string.h>
#include <linux/types.h>
#include <asm/byteorder.h>
#include <asm/memory.h>
@@ -312,9 +313,33 @@ extern void _memset_io(volatile void __iomem *, int, size_t);
#define writesw(p,d,l) __raw_writesw(p,d,l)
#define writesl(p,d,l) __raw_writesl(p,d,l)
+#ifndef __ARMBE__
+static inline void memset_io(volatile void __iomem *dst, unsigned c,
+ size_t count)
+{
+ memset((void __force *)dst, c, count);
+}
+#define memset_io(dst,c,count) memset_io(dst,c,count)
+
+static inline void memcpy_fromio(void *to, const volatile void __iomem *from,
+ size_t count)
+{
+ memcpy(to, (const void __force *)from, count);
+}
+#define memcpy_fromio(to,from,count) memcpy_fromio(to,from,count)
+
+static inline void memcpy_toio(volatile void __iomem *to, const void *from,
+ size_t count)
+{
+ memcpy((void __force *)to, from, count);
+}
+#define memcpy_toio(to,from,count) memcpy_toio(to,from,count)
+
+#else
#define memset_io(c,v,l) _memset_io(c,(v),(l))
#define memcpy_fromio(a,c,l) _memcpy_fromio((a),c,(l))
#define memcpy_toio(c,a,l) _memcpy_toio(c,(a),(l))
+#endif
#endif /* readl */
--
1.8.3.1
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply related
* Re: [PATCH v3 2/2] staging: sm750fb: cleanup indentation
From: Sudip Mukherjee @ 2015-05-06 7:38 UTC (permalink / raw)
To: Dan Carpenter
Cc: Charles Rose, teddy.wang, gregkh, linux-fbdev, devel,
linux-kernel
In-Reply-To: <20150506070621.GU14154@mwanda>
On Wed, May 06, 2015 at 10:06:21AM +0300, Dan Carpenter wrote:
> Looks good.
but its applying to linux-next and not applying to staging-testing.
There are a few patches which Greg applied to staging-testing before the
merge-window but they were not applied to staging-next. I guess he has
been busy.
regards
sudip
>
> regards,
> dan carpenter
>
^ permalink raw reply
* [RFC PATCH] video/logo: introduce new system state for checking if logos are freed
From: Heiko Schocher @ 2015-05-06 7:09 UTC (permalink / raw)
To: linux-kernel
Cc: Heiko Schocher, Geert Uytterhoeven, linux-fbdev,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen
commit 92b004d1aa9f ("video/logo: prevent use of logos after they have been freed")
added a late_initcall function to mark the logos as freed. In reality
the logos are freed later, and fbdev probe may be ran between this
late_initcall and the freeing of the logos. In that case the logos
would not be drawn. To prevent this introduced a new system_state
SYSTEM_FREEING_MEM and set this state before freeing memory. This
state could be checked now in fb_find_logo(). This system state
is maybe useful on other places too.
Signed-off-by: Heiko Schocher <hs@denx.de>
---
Found this issue on an imx6 based board with a display which needs
a spi initialization. With 3.18.2 I see a perfect logo, but with
current ml, bootlogo is missing, because drm gets probed before
spi display, which leads in drm probing is deferred until the
spi display is probed. After that drm is probed again ... but
this is too late for showing the bootlogo.
With this patch, bootlogo is drawn again. I am not sure, if it
is so easy to add a new system state ... but we should have a
possibility to detect if initdata is freed or not. this is maybe
also for other modules interesting. Maybe we add a
kernel_initdata_freed()
function instead of a new system state?
drivers/video/logo/logo.c | 15 ++++-----------
include/linux/kernel.h | 1 +
init/main.c | 1 +
3 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/video/logo/logo.c b/drivers/video/logo/logo.c
index 10fbfd8..d798a9f 100644
--- a/drivers/video/logo/logo.c
+++ b/drivers/video/logo/logo.c
@@ -26,16 +26,6 @@ MODULE_PARM_DESC(nologo, "Disables startup logo");
* Use late_init to mark the logos as freed to prevent any further use.
*/
-static bool logos_freed;
-
-static int __init fb_logo_late_init(void)
-{
- logos_freed = true;
- return 0;
-}
-
-late_initcall(fb_logo_late_init);
-
/* logo's are marked __initdata. Use __init_refok to tell
* modpost that it is intended that this function uses data
* marked __initdata.
@@ -44,7 +34,10 @@ const struct linux_logo * __init_refok fb_find_logo(int depth)
{
const struct linux_logo *logo = NULL;
- if (nologo || logos_freed)
+ if (system_state >= SYSTEM_FREEING_MEM)
+ return NULL;
+
+ if (nologo)
return NULL;
if (depth >= 1) {
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 3a5b48e..e5875bf 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -462,6 +462,7 @@ extern bool early_boot_irqs_disabled;
/* Values used for system_state */
extern enum system_states {
SYSTEM_BOOTING,
+ SYSTEM_FREEING_MEM,
SYSTEM_RUNNING,
SYSTEM_HALT,
SYSTEM_POWER_OFF,
diff --git a/init/main.c b/init/main.c
index 2115055..4965ed0 100644
--- a/init/main.c
+++ b/init/main.c
@@ -931,6 +931,7 @@ static int __ref kernel_init(void *unused)
kernel_init_freeable();
/* need to finish all async __init code before freeing the memory */
async_synchronize_full();
+ system_state = SYSTEM_FREEING_MEM;
free_initmem();
mark_rodata_ro();
system_state = SYSTEM_RUNNING;
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v3 2/2] staging: sm750fb: cleanup indentation
From: Dan Carpenter @ 2015-05-06 7:06 UTC (permalink / raw)
To: Charles Rose
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, devel,
linux-kernel
In-Reply-To: <1430881664-13727-2-git-send-email-charles.rose.linux@gmail.com>
Looks good.
regards,
dan carpenter
^ permalink raw reply
* [PATCH v3 2/2] staging: sm750fb: cleanup indentation
From: Charles Rose @ 2015-05-06 3:07 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, devel,
linux-kernel
Cc: charles.rose.linux
In-Reply-To: <1430881664-13727-1-git-send-email-charles.rose.linux@gmail.com>
This patch fixes indentation errors/warnings reported by checkpatch.pl.
Signed-off-by: Charles Rose <charles.rose.linux@gmail.com>
---
drivers/staging/sm750fb/ddk750_mode.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_mode.c b/drivers/staging/sm750fb/ddk750_mode.c
index 2e418fb..147273a 100644
--- a/drivers/staging/sm750fb/ddk750_mode.c
+++ b/drivers/staging/sm750fb/ddk750_mode.c
@@ -44,21 +44,29 @@ static unsigned long displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
/* Set bit 29:27 of display control register for the right clock */
/* Note that SM750LE only need to supported 7 resoluitons. */
if ( x = 800 && y = 600 )
- dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK, PLL41);
+ dispControl = FIELD_SET(dispControl,
+ CRT_DISPLAY_CTRL, CLK, PLL41);
else if (x = 1024 && y = 768)
- dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK, PLL65);
+ dispControl = FIELD_SET(dispControl,
+ CRT_DISPLAY_CTRL, CLK, PLL65);
else if (x = 1152 && y = 864)
- dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK, PLL80);
+ dispControl = FIELD_SET(dispControl,
+ CRT_DISPLAY_CTRL, CLK, PLL80);
else if (x = 1280 && y = 768)
- dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK, PLL80);
+ dispControl = FIELD_SET(dispControl,
+ CRT_DISPLAY_CTRL, CLK, PLL80);
else if (x = 1280 && y = 720)
- dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK, PLL74);
+ dispControl = FIELD_SET(dispControl,
+ CRT_DISPLAY_CTRL, CLK, PLL74);
else if (x = 1280 && y = 960)
- dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK, PLL108);
+ dispControl = FIELD_SET(dispControl,
+ CRT_DISPLAY_CTRL, CLK, PLL108);
else if (x = 1280 && y = 1024)
- dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK, PLL108);
+ dispControl = FIELD_SET(dispControl,
+ CRT_DISPLAY_CTRL, CLK, PLL108);
else /* default to VGA clock */
- dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK, PLL25);
+ dispControl = FIELD_SET(dispControl,
+ CRT_DISPLAY_CTRL, CLK, PLL25);
/* Set bit 25:24 of display controller */
dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CRTSELECT, CRT);
--
2.1.0
^ permalink raw reply related
* [PATCH v3 1/2] staging: sm750fb: cleanup white space
From: Charles Rose @ 2015-05-06 3:07 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, devel,
linux-kernel
Cc: charles.rose.linux
This patch fixes "space prohibited" errors reported by checkpatch.pl.
Signed-off-by: Charles Rose <charles.rose.linux@gmail.com>
---
drivers/staging/sm750fb/ddk750_chip.c | 12 ++++++------
drivers/staging/sm750fb/ddk750_power.c | 8 ++++----
drivers/staging/sm750fb/sm750_accel.c | 2 +-
drivers/staging/sm750fb/sm750_help.h | 2 +-
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_chip.c b/drivers/staging/sm750fb/ddk750_chip.c
index 7b28328..60ae39a 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -268,7 +268,7 @@ int ddk750_initHw(initchip_param_t *pInitParam)
#endif
- if (pInitParam->powerMode != 0 )
+ if (pInitParam->powerMode != 0)
pInitParam->powerMode = 0;
setPowerMode(pInitParam->powerMode);
@@ -285,7 +285,7 @@ int ddk750_initHw(initchip_param_t *pInitParam)
ulReg = FIELD_SET(ulReg, VGA_CONFIGURATION, MODE, GRAPHIC);
POKE32(VGA_CONFIGURATION, ulReg);
} else {
-#if defined(__i386__) || defined( __x86_64__)
+#if defined(__i386__) || defined(__x86_64__)
/* set graphic mode via IO method */
outb_p(0x88, 0x3d4);
outb_p(0x06, 0x3d5);
@@ -382,7 +382,7 @@ int ddk750_initHw(initchip_param_t *pInitParam)
unsigned int absDiff(unsigned int a, unsigned int b)
{
- if ( a > b )
+ if (a > b)
return(a - b);
else
return(b - a);
@@ -606,9 +606,9 @@ unsigned int formatPllReg(pll_value_t *pPLL)
On returning a 32 bit number, the value can be applied to any PLL in the calling function.
*/
ulPllReg - FIELD_SET( 0, PANEL_PLL_CTRL, BYPASS, OFF)
- | FIELD_SET( 0, PANEL_PLL_CTRL, POWER, ON)
- | FIELD_SET( 0, PANEL_PLL_CTRL, INPUT, OSC)
+ FIELD_SET(0, PANEL_PLL_CTRL, BYPASS, OFF)
+ | FIELD_SET(0, PANEL_PLL_CTRL, POWER, ON)
+ | FIELD_SET(0, PANEL_PLL_CTRL, INPUT, OSC)
#ifndef VALIDATION_CHIP
| FIELD_VALUE(0, PANEL_PLL_CTRL, POD, pPLL->POD)
#endif
diff --git a/drivers/staging/sm750fb/ddk750_power.c b/drivers/staging/sm750fb/ddk750_power.c
index cbb9767..0e3c028 100644
--- a/drivers/staging/sm750fb/ddk750_power.c
+++ b/drivers/staging/sm750fb/ddk750_power.c
@@ -59,17 +59,17 @@ void setPowerMode(unsigned int powerMode)
{
control_value #ifdef VALIDATION_CHIP
- FIELD_SET( control_value, POWER_MODE_CTRL, 336CLK, OFF) |
+ FIELD_SET(control_value, POWER_MODE_CTRL, 336CLK, OFF) |
#endif
- FIELD_SET( control_value, POWER_MODE_CTRL, OSC_INPUT, OFF);
+ FIELD_SET(control_value, POWER_MODE_CTRL, OSC_INPUT, OFF);
}
else
{
control_value #ifdef VALIDATION_CHIP
- FIELD_SET( control_value, POWER_MODE_CTRL, 336CLK, ON) |
+ FIELD_SET(control_value, POWER_MODE_CTRL, 336CLK, ON) |
#endif
- FIELD_SET( control_value, POWER_MODE_CTRL, OSC_INPUT, ON);
+ FIELD_SET(control_value, POWER_MODE_CTRL, OSC_INPUT, ON);
}
/* Program new power mode. */
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index c5a3726..e308646 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -364,7 +364,7 @@ int hw_imageblit(struct lynx_accel *accel,
Note that input pitch is BYTE value, but the 2D Pitch register uses
pixel values. Need Byte to pixel convertion.
*/
- if(bytePerPixel = 3 ){
+ if (bytePerPixel = 3) {
dx *= 3;
width *= 3;
startBit *= 3;
diff --git a/drivers/staging/sm750fb/sm750_help.h b/drivers/staging/sm750fb/sm750_help.h
index e0128d2..cdac9e2 100644
--- a/drivers/staging/sm750fb/sm750_help.h
+++ b/drivers/staging/sm750fb/sm750_help.h
@@ -57,7 +57,7 @@
#define FIELD_CLEAR(reg, field) \
( \
- ~ _F_MASK(reg ## _ ## field) \
+ ~_F_MASK(reg ## _ ## field) \
)
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] staging: sm750fb: cleanup indentation
From: Charles Rose @ 2015-05-06 3:00 UTC (permalink / raw)
To: Greg KH; +Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, devel, linux-kernel
In-Reply-To: <20150503193545.GA13104@kroah.com>
On 05/03/2015 03:35 PM, Greg KH wrote:
> On Fri, Apr 24, 2015 at 11:10:56AM -0400, Charles Rose wrote:
>> This patch fixes indentation errors/warnings reported by checkpatch.pl.
>>
>> Signed-off-by: Charles Rose <charles.rose.linux@gmail.com>
>> ---
>> drivers/staging/sm750fb/ddk750_mode.c | 24 ++++++++++++++++--------
>> 1 file changed, 16 insertions(+), 8 deletions(-)
>
> Does not apply to my tree :(
>
Apologies. Will re-send v3 shortly.
Thanks,
Charles
^ permalink raw reply
* [PATCH 24/27] fbdev: Allow compile test of GPIO consumers if !GPIOLIB
From: Geert Uytterhoeven @ 2015-05-05 16:32 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot, Arnd Bergmann
Cc: linux-gpio, linux-kernel, Geert Uytterhoeven,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev
In-Reply-To: <1430843563-18615-1-git-send-email-geert@linux-m68k.org>
The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is
not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer
functionality only, can still be compiled if GPIOLIB is not enabled.
Relax the dependency on GPIOLIB if COMPILE_TEST is enabled, where
appropriate.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
---
drivers/video/fbdev/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 1094623030879dcd..bc94c782370f2156 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2471,7 +2471,7 @@ config FB_SSD1307
tristate "Solomon SSD1307 framebuffer support"
depends on FB && I2C
depends on OF
- depends on GPIOLIB
+ depends on GPIOLIB || COMPILE_TEST
select FB_SYS_FOPS
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
--
1.9.1
^ permalink raw reply related
* [PATCH 23/27] backlight: Allow compile test of GPIO consumers if !GPIOLIB
From: Geert Uytterhoeven @ 2015-05-05 16:32 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot, Arnd Bergmann
Cc: linux-gpio, linux-kernel, Geert Uytterhoeven, Jingoo Han,
Lee Jones, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-fbdev
In-Reply-To: <1430843563-18615-1-git-send-email-geert@linux-m68k.org>
The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is
not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer
functionality only, can still be compiled if GPIOLIB is not enabled.
Relax the dependency on GPIOLIB if COMPILE_TEST is enabled, where
appropriate.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
---
drivers/video/backlight/Kconfig | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 2d9923a60076e380..0505b796d743250e 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -36,14 +36,16 @@ config LCD_CORGI
config LCD_L4F00242T03
tristate "Epson L4F00242T03 LCD"
- depends on SPI_MASTER && GPIOLIB
+ depends on SPI_MASTER
+ depends on GPIOLIB || COMPILE_TEST
help
SPI driver for Epson L4F00242T03. This provides basic support
for init and powering the LCD up/down through a sysfs interface.
config LCD_LMS283GF05
tristate "Samsung LMS283GF05 LCD"
- depends on SPI_MASTER && GPIOLIB
+ depends on SPI_MASTER
+ depends on GPIOLIB || COMPILE_TEST
help
SPI driver for Samsung LMS283GF05. This provides basic support
for powering the LCD up/down through a sysfs interface.
@@ -434,7 +436,7 @@ config BACKLIGHT_AS3711
config BACKLIGHT_GPIO
tristate "Generic GPIO based Backlight Driver"
- depends on GPIOLIB
+ depends on GPIOLIB || COMPILE_TEST
help
If you have a LCD backlight adjustable by GPIO, say Y to enable
this driver.
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] staging: sm750fb: Cleaning up a few return statements
From: Julian Gindi @ 2015-05-05 16:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150417204416.GA18202@rosebud>
On 05/04, Sudip Mukherjee wrote:
> On Sun, May 03, 2015 at 09:25:47PM +0200, Greg KH wrote:
> > On Fri, Apr 17, 2015 at 04:44:16PM -0400, Julian Gindi wrote:
> > > Signed-off-by: Julian Gindi <juliangindi@gmail.com>
> > >
> > >
> > > --
> > > 1.9.1
> >
> > This breaks the build, showing that you never even tested it :(
> sorry Greg, I should have buildtested after Julian has submitted the
> patch.
Apologies. Embarrasing mistake. I thought I tested, but was obviously
confused. Will fix and get everything working.
>
> regards
> sudip
^ permalink raw reply
* Re: [PATCH v3 00/17] framebuffer: simple conversions to arch_phys_wc_add()
From: Andy Lutomirski @ 2015-05-05 13:47 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1429647398-16983-1-git-send-email-mcgrof@do-not-panic.com>
On Mon, May 4, 2015 at 3:33 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 29/04/15 22:18, Luis R. Rodriguez wrote:
>> On Tue, Apr 21, 2015 at 1:16 PM, Luis R. Rodriguez
>> <mcgrof@do-not-panic.com> wrote:
>>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>>
>>> This series addresses simple changes to framebuffer drivers to use
>>> arch_phys_wc_add() and ioremap_wc() as well as fixing gbefb to add
>>> missing mtrr_del() calls. These changes are pretty straight forward.
>>>
>>> Luis R. Rodriguez (17):
>>> video: fbdev: radeonfb: use arch_phys_wc_add() and ioremap_wc()
>>> video: fbdev: gbefb: add missing mtrr_del() calls
>>> video: fbdev: gbefb: use arch_phys_wc_add() and devm_ioremap_wc()
>>> video: fbdev: intelfb: use arch_phys_wc_add() and ioremap_wc()
>>> video: fbdev: matrox: use arch_phys_wc_add() and ioremap_wc()
>>> video: fbdev: neofb: use arch_phys_wc_add() and ioremap_wc()
>>> video: fbdev: nvidia: use arch_phys_wc_add() and ioremap_wc()
>>> video: fbdev: savagefb: use arch_phys_wc_add() and ioremap_wc()
>>> video: fbdev: sisfb: use arch_phys_wc_add() and ioremap_wc()
>>> video: fbdev: aty: use arch_phys_wc_add() and ioremap_wc()
>>> video: fbdev: i810: use arch_phys_wc_add() and ioremap_wc()
>>> video: fbdev: pm2fb: use arch_phys_wc_add() and ioremap_wc()
>>> video: fbdev: pm3fb: use arch_phys_wc_add() and ioremap_wc()
>>> video: fbdev: rivafb: use arch_phys_wc_add() and ioremap_wc()
>>> video: fbdev: tdfxfb: use arch_phys_wc_add() and ioremap_wc()
>>> video: fbdev: atmel_lcdfb: use ioremap_wc() for framebuffer
>>> video: fbdev: geode gxfb: use ioremap_wc() for framebuffer
>>
>> Hey folks, these are all pretty straight forward, can anyone take them?
>
> I can take these to fbdev tree. Unfortunately I'm not familiar with x86
> nor mtrr, so I can't really say much about the patches themselves.
>
I'm on vacation and there's no way I'll be able to usefully review
these in the next two weeks. I can describe what's going on in case
it helps:
On x86 there are two ways to get a write-combining MMIO mapping. The
sane way is ioremap_wc, and the ridiculous way is mtrr_add.
ioremap_wc does exactly what it appears to do, whereas mtrr_add acts
on physical addresses, requires power-of-two alignment, and is
unreliable.
On all recent hardware, ioremap_wc works, and mtrr_add is problematic
on all hardware even if it often works. The silly thing is that
mtrr_add pokes at the registers it uses even on hardware with working
ioremap_wc. This causes problems (those resources are a very limited
resource).
The solution I came up with a couple years ago is a new API
arch_phys_wc_add. It is a hint that a physical address range should
be write-combining. On hardware with working ioremap_wc, it's a
no-op. On x86 hardware without working ioremap_wc, it just calls
mtrr_add.
The upshot is that changing mtrr_add with a WC type to
arch_phys_wc_add is OK as long as the driver also uses ioremap_wc or
similar _wc APIs. Once everything has been converted, we can unexport
mtrr_add, which will have all kinds of benefits.
--Andy
^ permalink raw reply
* Von Dr. Christopher Harrison (Bitte antworten)
From: Dr. Christopher Harrison @ 2015-05-05 10:18 UTC (permalink / raw)
To: linux-fbdev
Lieber Freund,
Wie geht es dir heute? Ich hoffe, in Ordnung, ich bin Dr. Christopher Harrison von NothWest London, England. Ich arbeite für Zweig Lloyds Bank London. Ich schreibe Ihnen aus meinem Büro, das aus einem großen immense Vorteil für uns beide sein wird. In meiner Abteilung, dass die Co-Trainer (Großregion London), entdeckte ich eine verlassene Summe von £ 16,5 Millionen Pfund (Sechzehn Millionen fünfhunderttausend Pfund und Pfund Sterling) in einem Konto, das Sie mit einem unserer ausländischen Kunden Späte Herr Ron Bramlage gehört , ein Amerikaner, der in Kansas Staaten lebt, die ein Opfer von einem Hubschrauberabsturz im vergangenen Jahr 8. Juni 2012, in Florida Sumpf ihn und Familienmitglieder zu töten war. Ron war 45 Jahre alt. Auch in der Chopper zum Zeitpunkt des Absturzes war seine Frau Rebecca, 43, und die Kinder des Paares - Brandon, 15; Boston, 13; Beau, 11; und 8-jährige Roxanne - wurden getötet. Der Pilot war auch tot.
Ich suche Ihre Partnerschaft und Zusammenarbeit zur Durchführung dieser Transaktion zusammen, weil der Lloyds Bank schließt einige ihrer Zweigstellen und den Zweig, wo dieser Fonds hinterlegt ist unter denen geschlossen werden, so dass ich möchte, dass wir diesen Fonds zu bekommen, bevor ihre Verschluss. Ich habe Sie kontaktiert, weil ich glaube, Sie werden nicht weglaufen mit eigenen Aktien dieses Fonds, wenn es Ihrem Konto eingeht, und die gemeinsame Nutzung Quote von 60% für mich und 40% für Ihre Zusammenarbeit. Für Sie die Lloyds Bank, um sicherzustellen, Schließen Niederlassungen besuchen Sie diese Seite:
https://uk.news.yahoo.com/lloyds-bank-more-200-branches-close-181000783--finance.html#4KVKdTh
Aufgrund der Sensibilität der Transaktion und die Vertraulichkeit hier, jetzt unsere Bank hat für keine der Verwandten warten zu kommen-up für die Behauptung, aber niemand hat in der Suche die Verwandten für eine lange Zeit jetzt getan, dass ich persönlich nicht erfolgreich waren . Mein lieber Freund, ich suche Ihre Zustimmung an Sie als nächsten Angehörigen / Will Begünstigter des Verstorbenen zu präsentieren, so dass die Erlöse aus diesem Konto bei £ 16,5 Millionen Pfund an Sie gezahlt werden bewertet.
Das wird für mich ausgezahlt oder geteilt in diese Prozentsätze, 60% und 40% zu Ihnen, ich habe alle notwendigen rechtlichen Dokumente, die wir verwendet werden, um diese Behauptung wir machen gesichert. Alles was ich brauche ist es, in Ihrem Namen zu den Dokumenten füllen und legalisiert es in den Hof und die Lloyds Bank hier, um Ihnen zu beweisen, als berechtigten Empfänger, ist Alles, was ich jetzt brauche Ihre ehrliche Zusammenarbeit, Verschwiegenheit und Vertrauen, damit wir sehen, diese Transaktion durch. Ich garantiere Ihnen, dass dies unter einer legitimen Anordnung, die Sie von einem Verstoß gegen das Gesetz hier in England und in Ihrem Land zu schützen wird ausgeführt.
Bitte, bitte senden Sie mir die folgenden: wir haben 7 Tage, um es zu durchlaufen, das ist sehr, sehr URGENT PLEASE.
1. Vollständiger Name: ......................
2. Ihre Telefonnummer: .................
3. Ihre Kontaktadresse: ..................
4. Alter / Geschlecht: ...................
5. Kern Job / Beruf: ..............
Bitte beantworten Sie meine E-Mail hier: harrisondr.christoph_office@yahoo.co.uk
Ich habe euch in Kontakt gebracht, zu glauben, dass Sie nicht weglaufen mit eigenen Aktien dieses Fonds, wenn es Ihrem Konto kommt, hoffe ich, können Sie auf diese vertrauen? Wie Sie wissen, diese Transaktion beinhalten sehr viel Geld. Bitte Standard freundlich zeigen Sie Ihr Interesse, indem sie mich mit Ihren Angaben wie oben, so kann ich Ihnen mehr Informationen darüber, wie die Bank gehen, um diesen Fonds zu Ihnen innerhalb von 5 Bankarbeitstagen übertragen bekommen zu erbringen. Endeavour zu antworten, dass sie nicht länger auf mich gewartet. Ok, mein lieber Freund?
Freundliche Grüße,
Dr. Christopher Harrison
^ permalink raw reply
* Re: [PATCH 4/4] video: fbdev: s3c-fb: Constify platform_device_id
From: Lee Jones @ 2015-05-05 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1430494721-30793-4-git-send-email-k.kozlowski.k@gmail.com>
On Sat, 02 May 2015, Krzysztof Kozlowski wrote:
> The platform_device_id is not modified by the driver and core uses it as
> const.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
> ---
> drivers/video/fbdev/s3c-fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
> diff --git a/drivers/video/fbdev/s3c-fb.c b/drivers/video/fbdev/s3c-fb.c
> index 7e3a05fc47aa..f72dd12456f9 100644
> --- a/drivers/video/fbdev/s3c-fb.c
> +++ b/drivers/video/fbdev/s3c-fb.c
> @@ -1938,7 +1938,7 @@ static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
> },
> };
>
> -static struct platform_device_id s3c_fb_driver_ids[] = {
> +static const struct platform_device_id s3c_fb_driver_ids[] = {
> {
> .name = "s3c-fb",
> .driver_data = (unsigned long)&s3c_fb_data_64xx,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 3/4] video: fbdev: mxsfb: Constify platform_device_id
From: Lee Jones @ 2015-05-05 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1430494721-30793-3-git-send-email-k.kozlowski.k@gmail.com>
On Sat, 02 May 2015, Krzysztof Kozlowski wrote:
> The platform_device_id is not modified by the driver and core uses it as
> const.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
> ---
> drivers/video/fbdev/mxsfb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
> diff --git a/drivers/video/fbdev/mxsfb.c b/drivers/video/fbdev/mxsfb.c
> index f8ac4a452f26..497971c82bb1 100644
> --- a/drivers/video/fbdev/mxsfb.c
> +++ b/drivers/video/fbdev/mxsfb.c
> @@ -814,7 +814,7 @@ static void mxsfb_free_videomem(struct mxsfb_info *host)
> free_pages_exact(fb_info->screen_base, fb_info->fix.smem_len);
> }
>
> -static struct platform_device_id mxsfb_devtype[] = {
> +static const struct platform_device_id mxsfb_devtype[] = {
> {
> .name = "imx23-fb",
> .driver_data = MXSFB_V3,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 2/4] video: fbdev: imxfb: Constify platform_device_id
From: Lee Jones @ 2015-05-05 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1430494721-30793-2-git-send-email-k.kozlowski.k@gmail.com>
On Sat, 02 May 2015, Krzysztof Kozlowski wrote:
> The platform_device_id is not modified by the driver and core uses it as
> const.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
> ---
> drivers/video/fbdev/imxfb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
> diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
> index 84d1d29e532c..cee88603efc9 100644
> --- a/drivers/video/fbdev/imxfb.c
> +++ b/drivers/video/fbdev/imxfb.c
> @@ -170,7 +170,7 @@ struct imxfb_info {
> struct regulator *lcd_pwr;
> };
>
> -static struct platform_device_id imxfb_devtype[] = {
> +static const struct platform_device_id imxfb_devtype[] = {
> {
> .name = "imx1-fb",
> .driver_data = IMX1_FB,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 1/4] video: backlight: da9052: Constify platform_device_id
From: Lee Jones @ 2015-05-05 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1430494721-30793-1-git-send-email-k.kozlowski.k@gmail.com>
On Sat, 02 May 2015, Krzysztof Kozlowski wrote:
> The platform_device_id is not modified by the driver and core uses it as
> const.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
> ---
> drivers/video/backlight/da9052_bl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
> diff --git a/drivers/video/backlight/da9052_bl.c b/drivers/video/backlight/da9052_bl.c
> index b1943e7735a1..fd2be417aa64 100644
> --- a/drivers/video/backlight/da9052_bl.c
> +++ b/drivers/video/backlight/da9052_bl.c
> @@ -152,7 +152,7 @@ static int da9052_backlight_remove(struct platform_device *pdev)
> return 0;
> }
>
> -static struct platform_device_id da9052_wled_ids[] = {
> +static const struct platform_device_id da9052_wled_ids[] = {
> {
> .name = "da9052-wled1",
> .driver_data = DA9052_TYPE_WLED1,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v4 2/6] x86: document WC MTRR effects on PAT / non-PAT pages
From: Borislav Petkov @ 2015-05-05 7:53 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Ville Syrjälä, luto, Randy Dunlap, Luis R. Rodriguez,
mingo, tglx, hpa, plagnioj, tomi.valkeinen, daniel.vetter,
airlied, dledford, awalls, mst, cocci, linux-kernel, Toshi Kani,
Jonathan Corbet, Dave Hansen, Suresh Siddha, Juergen Gross,
Daniel Vetter, Dave Airlie, Antonino Daplas, Mel Gorman,
Vlastimil Babka, Davidlohr Bueso, linux-fbdev
In-Reply-To: <20150505074634.GL5622@wotan.suse.de>
On Tue, May 05, 2015 at 09:46:34AM +0200, Luis R. Rodriguez wrote:
> If so since they depend on ioremap_uc() should it go through Boris as he's
> taking that in?
Let's slow down a bit first, ok? First let's have all the x86 changes
ready, in and tested. Drivers can convert to them in a following step.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox