* Re: [PATCH v2 1/4] mfd: add LM3533 lighting-power core driver
From: Samuel Ortiz @ 2012-05-11 13:32 UTC (permalink / raw)
To: Johan Hovold
Cc: Rob Landley, Richard Purdie, Jonathan Cameron, Greg Kroah-Hartman,
Florian Tobias Schandinat, Arnd Bergmann, Andrew Morton,
Mark Brown, linux-doc, linux-kernel, linux-iio, devel,
linux-fbdev
In-Reply-To: <20120510120742.GA29437@localhost>
Hi Johan,
On Thu, May 10, 2012 at 02:07:42PM +0200, Johan Hovold wrote:
> On Wed, May 09, 2012 at 04:42:18PM +0200, Samuel Ortiz wrote:
> > Hi Johan
> >
> > On Thu, May 03, 2012 at 12:26:36PM +0200, Johan Hovold wrote:
> > > Add support for National Semiconductor / TI LM3533 lighting power chips.
> > >
> > > This is the core driver which provides register access over I2C and
> > > registers the ambient-light-sensor, LED and backlight sub-drivers.
> > >
> > > Signed-off-by: Johan Hovold <jhovold@gmail.com>
> > > ---
> > >
> > > v2:
> > > - add sysfs-ABI documentation
> > > - merge i2c implementation with core
> > > - use regmap and kill custom debugfs interface
> > >
> > >
> > > .../ABI/testing/sysfs-bus-i2c-devices-lm3533 | 38 +
> > > drivers/mfd/Kconfig | 13 +
> > > drivers/mfd/Makefile | 1 +
> > > drivers/mfd/lm3533-core.c | 717 ++++++++++++++++++++
> > > drivers/mfd/lm3533-ctrlbank.c | 134 ++++
> > > include/linux/mfd/lm3533.h | 89 +++
> > > 6 files changed, 992 insertions(+), 0 deletions(-)
> > > create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-lm3533
> > > create mode 100644 drivers/mfd/lm3533-core.c
> > > create mode 100644 drivers/mfd/lm3533-ctrlbank.c
> > > create mode 100644 include/linux/mfd/lm3533.h
> > Patch applied to my for-next branch, thanks.
>
> I've been travelling for a few days and didn't have time to submit a
> discussed change to move two attributes to the platform data before I
> left.
>
> Could you please apply the following two patches on top of this one?
All of your 4 pending patches have been applied, thanks.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* [PATCH] drivers/video: fsl-diu-fb: don't initialize the THRESHOLDS registers
From: Timur Tabi @ 2012-05-10 21:57 UTC (permalink / raw)
To: linux-fbdev
The THRESHOLDS register configures thresholds for two interrupts, but
these interrupts are not used in the DIU driver. An early version of the
driver may have used the "lines before vsync" interrupt, which requires
the LS_BF_VS of THRESHOLDS to be initialized.
Unfortunately, the initialization of this register does not do a
read-modify-write to set only LS_BF_VS. On the MPC8610, the value
written is correct. On other chips, like the P1022, the value overwrites
some reserved bits. This results in a performance drop on the P1022.
Since the default value is acceptable as-is on all SOCs, we should just
avoid touching this register.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
drivers/video/fsl-diu-fb.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index 6af3f16..458c006 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -834,7 +834,6 @@ static void update_lcdc(struct fb_info *info)
diu_ops.set_pixel_clock(var->pixclock);
out_be32(&hw->syn_pol, 0); /* SYNC SIGNALS POLARITY */
- out_be32(&hw->thresholds, 0x00037800); /* The Thresholds */
out_be32(&hw->int_status, 0); /* INTERRUPT STATUS */
out_be32(&hw->plut, 0x01F5F666);
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] video/sis: Annotate SiS_DRAMType as __devinitconst
From: Peter Hüwe @ 2012-05-10 21:39 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: Thomas Winischhofer, linux-fbdev, linux-kernel
In-Reply-To: <4FAB0986.6090006@gmx.de>
Am Donnerstag 10 Mai 2012, 02:19:18 schrieb Florian Tobias Schandinat:
> Good that you did this one, it was more to be done than I expected. I
> ignored the checkpatch errors as you didn't introduce them but maybe it
> wouldn't be a bad idea to fix things up if you touch them. Applied.
Oh sorry, usually I do checkpatch, but I missed it on this one somehow.
If you want, I can do a checkpatch cleanup for the whole sis driver as
compensation ;)
Thanks,
Peter
^ permalink raw reply
* [PATCH v3] backlight: add LM3533 backlight driver
From: Johan Hovold @ 2012-05-10 18:29 UTC (permalink / raw)
To: Richard Purdie
Cc: Rob Landley, Samuel Ortiz, Jonathan Cameron, Greg Kroah-Hartman,
Florian Tobias Schandinat, Arnd Bergmann, Andrew Morton,
Mark Brown, linux-doc, linux-kernel, linux-fbdev, Johan Hovold
In-Reply-To: <1336040799-18433-5-git-send-email-jhovold@gmail.com>
Add sub-driver for the backlights on National Semiconductor / TI LM3533
lighting power chips.
The chip provides 256 brightness levels and ambient-light-sensor and pwm
input control.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
v2
- add sysfs-ABI documentation
- open code max_current/pwm macros
v3
- remove max_current attribute
.../testing/sysfs-class-backlight-driver-lm3533 | 41 ++
drivers/video/backlight/Kconfig | 12 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/lm3533_bl.c | 423 ++++++++++++++++++++
4 files changed, 477 insertions(+), 0 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533
create mode 100644 drivers/video/backlight/lm3533_bl.c
diff --git a/Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533 b/Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533
new file mode 100644
index 0000000..9fda257
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533
@@ -0,0 +1,41 @@
+What: /sys/class/backlight/<backlight>/als
+Date: April 2012
+KernelVersion: 3.5
+Contact: Johan Hovold <jhovold@gmail.com>
+Description:
+ Set the ALS-control mode (0,..2), where
+
+ 0 - disabled
+ 1 - ALS-mapper 1 (backlight 0)
+ 2 - ALS-mapper 2 (backlight 1)
+
+What: /sys/class/backlight/<backlight>/id
+Date: April 2012
+KernelVersion: 3.5
+Contact: Johan Hovold <jhovold@gmail.com>
+Description:
+ Get the id of this backlight (0, 1).
+
+What: /sys/class/backlight/<backlight>/linear
+Date: April 2012
+KernelVersion: 3.5
+Contact: Johan Hovold <jhovold@gmail.com>
+Description:
+ Set the brightness-mapping mode (0, 1), where
+
+ 0 - exponential mode
+ 1 - linear mode
+
+What: /sys/class/backlight/<backlight>/pwm
+Date: April 2012
+KernelVersion: 3.5
+Contact: Johan Hovold <jhovold@gmail.com>
+Description:
+ Set the PWM-input control mask (5 bits), where
+
+ bit 5 - PWM-input enabled in Zone 4
+ bit 4 - PWM-input enabled in Zone 3
+ bit 3 - PWM-input enabled in Zone 2
+ bit 2 - PWM-input enabled in Zone 1
+ bit 1 - PWM-input enabled in Zone 0
+ bit 0 - PWM-input enabled
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index af16884..fa2b037 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -184,6 +184,18 @@ config BACKLIGHT_GENERIC
known as the Corgi backlight driver. If you have a Sharp Zaurus
SL-C7xx, SL-Cxx00 or SL-6000x say y.
+config BACKLIGHT_LM3533
+ tristate "Backlight Driver for LM3533"
+ depends on BACKLIGHT_CLASS_DEVICE
+ depends on MFD_LM3533
+ help
+ Say Y to enable the backlight driver for National Semiconductor / TI
+ LM3533 Lighting Power chips.
+
+ The backlights can be controlled directly, through PWM input, or by
+ the ambient-light-sensor interface. The chip supports 256 brightness
+ levels.
+
config BACKLIGHT_LOCOMO
tristate "Sharp LOCOMO LCD/Backlight Driver"
depends on SHARP_LOCOMO
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 36855ae..a2ac9cf 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_BACKLIGHT_EP93XX) += ep93xx_bl.o
obj-$(CONFIG_BACKLIGHT_GENERIC) += generic_bl.o
obj-$(CONFIG_BACKLIGHT_HP700) += jornada720_bl.o
obj-$(CONFIG_BACKLIGHT_HP680) += hp680_bl.o
+obj-$(CONFIG_BACKLIGHT_LM3533) += lm3533_bl.o
obj-$(CONFIG_BACKLIGHT_LOCOMO) += locomolcd.o
obj-$(CONFIG_BACKLIGHT_LP855X) += lp855x_bl.o
obj-$(CONFIG_BACKLIGHT_OMAP1) += omap1_bl.o
diff --git a/drivers/video/backlight/lm3533_bl.c b/drivers/video/backlight/lm3533_bl.c
new file mode 100644
index 0000000..5abca65
--- /dev/null
+++ b/drivers/video/backlight/lm3533_bl.c
@@ -0,0 +1,423 @@
+/*
+ * lm3533-bl.c -- LM3533 Backlight driver
+ *
+ * Copyright (C) 2011-2012 Texas Instruments
+ *
+ * Author: Johan Hovold <jhovold@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/backlight.h>
+#include <linux/fb.h>
+#include <linux/slab.h>
+
+#include <linux/mfd/lm3533.h>
+
+
+#define LM3533_HVCTRLBANK_COUNT 2
+#define LM3533_BL_MAX_BRIGHTNESS 255
+
+#define LM3533_REG_CTRLBANK_AB_BCONF 0x1a
+
+
+struct lm3533_bl {
+ struct lm3533 *lm3533;
+ struct lm3533_ctrlbank cb;
+ struct backlight_device *bd;
+ int id;
+};
+
+
+static inline int lm3533_bl_get_ctrlbank_id(struct lm3533_bl *bl)
+{
+ return bl->id;
+}
+
+static int lm3533_bl_update_status(struct backlight_device *bd)
+{
+ struct lm3533_bl *bl = bl_get_data(bd);
+ int brightness = bd->props.brightness;
+
+ if (bd->props.power != FB_BLANK_UNBLANK)
+ brightness = 0;
+ if (bd->props.fb_blank != FB_BLANK_UNBLANK)
+ brightness = 0;
+
+ return lm3533_ctrlbank_set_brightness(&bl->cb, (u8)brightness);
+}
+
+static int lm3533_bl_get_brightness(struct backlight_device *bd)
+{
+ struct lm3533_bl *bl = bl_get_data(bd);
+ u8 val;
+ int ret;
+
+ ret = lm3533_ctrlbank_get_brightness(&bl->cb, &val);
+ if (ret)
+ return ret;
+
+ return val;
+}
+
+static const struct backlight_ops lm3533_bl_ops = {
+ .get_brightness = lm3533_bl_get_brightness,
+ .update_status = lm3533_bl_update_status,
+};
+
+static ssize_t show_id(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct lm3533_bl *bl = dev_get_drvdata(dev);
+
+ return scnprintf(buf, PAGE_SIZE, "%d\n", bl->id);
+}
+
+/*
+ * ALS-control setting:
+ *
+ * 0 - ALS disabled
+ * 1 - ALS-mapper 1 (backlight 0)
+ * 2 - ALS-mapper 2 (backlight 1)
+ */
+static ssize_t show_als(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct lm3533_bl *bl = dev_get_drvdata(dev);
+ int ctrlbank = lm3533_bl_get_ctrlbank_id(bl);
+ u8 val;
+ u8 mask;
+ int als;
+ int ret;
+
+ ret = lm3533_read(bl->lm3533, LM3533_REG_CTRLBANK_AB_BCONF, &val);
+ if (ret)
+ return ret;
+
+ mask = 2 * ctrlbank;
+ als = val & mask;
+ if (als)
+ als = ctrlbank + 1;
+
+ return scnprintf(buf, PAGE_SIZE, "%d\n", als);
+}
+
+static ssize_t store_als(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct lm3533_bl *bl = dev_get_drvdata(dev);
+ int ctrlbank = lm3533_bl_get_ctrlbank_id(bl);
+ int als;
+ u8 val;
+ u8 mask;
+ int ret;
+
+ if (kstrtoint(buf, 0, &als))
+ return -EINVAL;
+
+ if (als != 0 && (als != ctrlbank + 1))
+ return -EINVAL;
+
+ mask = 1 << (2 * ctrlbank);
+
+ if (als)
+ val = mask;
+ else
+ val = 0;
+
+ ret = lm3533_update(bl->lm3533, LM3533_REG_CTRLBANK_AB_BCONF, val,
+ mask);
+ if (ret)
+ return ret;
+
+ return len;
+}
+
+static ssize_t show_linear(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct lm3533_bl *bl = dev_get_drvdata(dev);
+ u8 val;
+ u8 mask;
+ int linear;
+ int ret;
+
+ ret = lm3533_read(bl->lm3533, LM3533_REG_CTRLBANK_AB_BCONF, &val);
+ if (ret)
+ return ret;
+
+ mask = 1 << (2 * lm3533_bl_get_ctrlbank_id(bl) + 1);
+
+ if (val & mask)
+ linear = 1;
+ else
+ linear = 0;
+
+ return scnprintf(buf, PAGE_SIZE, "%x\n", linear);
+}
+
+static ssize_t store_linear(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct lm3533_bl *bl = dev_get_drvdata(dev);
+ unsigned long linear;
+ u8 mask;
+ u8 val;
+ int ret;
+
+ if (kstrtoul(buf, 0, &linear))
+ return -EINVAL;
+
+ mask = 1 << (2 * lm3533_bl_get_ctrlbank_id(bl) + 1);
+
+ if (linear)
+ val = mask;
+ else
+ val = 0;
+
+ ret = lm3533_update(bl->lm3533, LM3533_REG_CTRLBANK_AB_BCONF, val,
+ mask);
+ if (ret)
+ return ret;
+
+ return len;
+}
+
+static ssize_t show_pwm(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct lm3533_bl *bl = dev_get_drvdata(dev);
+ u8 val;
+ int ret;
+
+ ret = lm3533_ctrlbank_get_pwm(&bl->cb, &val);
+ if (ret)
+ return ret;
+
+ return scnprintf(buf, PAGE_SIZE, "%u\n", val);
+}
+
+static ssize_t store_pwm(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct lm3533_bl *bl = dev_get_drvdata(dev);
+ u8 val;
+ int ret;
+
+ if (kstrtou8(buf, 0, &val))
+ return -EINVAL;
+
+ ret = lm3533_ctrlbank_set_pwm(&bl->cb, val);
+ if (ret)
+ return ret;
+
+ return len;
+}
+
+static LM3533_ATTR_RW(als);
+static LM3533_ATTR_RO(id);
+static LM3533_ATTR_RW(linear);
+static LM3533_ATTR_RW(pwm);
+
+static struct attribute *lm3533_bl_attributes[] = {
+ &dev_attr_als.attr,
+ &dev_attr_id.attr,
+ &dev_attr_linear.attr,
+ &dev_attr_pwm.attr,
+ NULL,
+};
+
+static mode_t lm3533_bl_attr_is_visible(struct kobject *kobj,
+ struct attribute *attr, int n)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct lm3533_bl *bl = dev_get_drvdata(dev);
+ mode_t mode = attr->mode;
+
+ if (attr = &dev_attr_als.attr) {
+ if (!bl->lm3533->have_als)
+ mode = 0;
+ }
+
+ return mode;
+};
+
+static struct attribute_group lm3533_bl_attribute_group = {
+ .is_visible = lm3533_bl_attr_is_visible,
+ .attrs = lm3533_bl_attributes
+};
+
+static int __devinit lm3533_bl_setup(struct lm3533_bl *bl,
+ struct lm3533_bl_platform_data *pdata)
+{
+ int ret;
+
+ ret = lm3533_ctrlbank_set_max_current(&bl->cb, pdata->max_current);
+ if (ret)
+ return ret;
+
+ return lm3533_ctrlbank_set_pwm(&bl->cb, pdata->pwm);
+}
+
+static int __devinit lm3533_bl_probe(struct platform_device *pdev)
+{
+ struct lm3533 *lm3533;
+ struct lm3533_bl_platform_data *pdata;
+ struct lm3533_bl *bl;
+ struct backlight_device *bd;
+ struct backlight_properties props;
+ int ret;
+
+ dev_dbg(&pdev->dev, "%s\n", __func__);
+
+ lm3533 = dev_get_drvdata(pdev->dev.parent);
+ if (!lm3533)
+ return -EINVAL;
+
+ pdata = pdev->dev.platform_data;
+ if (!pdata) {
+ dev_err(&pdev->dev, "no platform data\n");
+ return -EINVAL;
+ }
+
+ if (pdev->id < 0 || pdev->id >= LM3533_HVCTRLBANK_COUNT) {
+ dev_err(&pdev->dev, "illegal backlight id %d\n", pdev->id);
+ return -EINVAL;
+ }
+
+ bl = kzalloc(sizeof(*bl), GFP_KERNEL);
+ if (!bl) {
+ dev_err(&pdev->dev,
+ "failed to allocate memory for backlight\n");
+ return -ENOMEM;
+ }
+
+ bl->lm3533 = lm3533;
+ bl->id = pdev->id;
+
+ bl->cb.lm3533 = lm3533;
+ bl->cb.id = lm3533_bl_get_ctrlbank_id(bl);
+ bl->cb.dev = NULL; /* until registered */
+
+ memset(&props, 0, sizeof(props));
+ props.type = BACKLIGHT_RAW;
+ props.max_brightness = LM3533_BL_MAX_BRIGHTNESS;
+ props.brightness = pdata->default_brightness;
+ bd = backlight_device_register(pdata->name, pdev->dev.parent, bl,
+ &lm3533_bl_ops, &props);
+ if (IS_ERR(bd)) {
+ dev_err(&pdev->dev, "failed to register backlight device\n");
+ ret = PTR_ERR(bd);
+ goto err_free;
+ }
+
+ bl->bd = bd;
+ bl->cb.dev = &bl->bd->dev;
+
+ platform_set_drvdata(pdev, bl);
+
+ ret = sysfs_create_group(&bd->dev.kobj, &lm3533_bl_attribute_group);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to create sysfs attributes\n");
+ goto err_unregister;
+ }
+
+ backlight_update_status(bd);
+
+ ret = lm3533_bl_setup(bl, pdata);
+ if (ret)
+ goto err_sysfs_remove;
+
+ ret = lm3533_ctrlbank_enable(&bl->cb);
+ if (ret)
+ goto err_sysfs_remove;
+
+ return 0;
+
+err_sysfs_remove:
+ sysfs_remove_group(&bd->dev.kobj, &lm3533_bl_attribute_group);
+err_unregister:
+ backlight_device_unregister(bd);
+err_free:
+ kfree(bl);
+
+ return ret;
+}
+
+static int __devexit lm3533_bl_remove(struct platform_device *pdev)
+{
+ struct lm3533_bl *bl = platform_get_drvdata(pdev);
+ struct backlight_device *bd = bl->bd;
+
+ dev_dbg(&bd->dev, "%s\n", __func__);
+
+ bd->props.power = FB_BLANK_POWERDOWN;
+ bd->props.brightness = 0;
+
+ lm3533_ctrlbank_disable(&bl->cb);
+ sysfs_remove_group(&bd->dev.kobj, &lm3533_bl_attribute_group);
+ backlight_device_unregister(bd);
+ kfree(bl);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+static int lm3533_bl_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct lm3533_bl *bl = platform_get_drvdata(pdev);
+
+ dev_dbg(&pdev->dev, "%s\n", __func__);
+
+ return lm3533_ctrlbank_disable(&bl->cb);
+}
+
+static int lm3533_bl_resume(struct platform_device *pdev)
+{
+ struct lm3533_bl *bl = platform_get_drvdata(pdev);
+
+ dev_dbg(&pdev->dev, "%s\n", __func__);
+
+ return lm3533_ctrlbank_enable(&bl->cb);
+}
+#else
+#define lm3533_bl_suspend NULL
+#define lm3533_bl_resume NULL
+#endif
+
+static void lm3533_bl_shutdown(struct platform_device *pdev)
+{
+ struct lm3533_bl *bl = platform_get_drvdata(pdev);
+
+ dev_dbg(&pdev->dev, "%s\n", __func__);
+
+ lm3533_ctrlbank_disable(&bl->cb);
+}
+
+static struct platform_driver lm3533_bl_driver = {
+ .driver = {
+ .name = "lm3533-backlight",
+ .owner = THIS_MODULE,
+ },
+ .probe = lm3533_bl_probe,
+ .remove = __devexit_p(lm3533_bl_remove),
+ .shutdown = lm3533_bl_shutdown,
+ .suspend = lm3533_bl_suspend,
+ .resume = lm3533_bl_resume,
+};
+module_platform_driver(lm3533_bl_driver);
+
+MODULE_AUTHOR("Johan Hovold <jhovold@gmail.com>");
+MODULE_DESCRIPTION("LM3533 Backlight driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:lm3533-backlight");
--
1.7.8.5
^ permalink raw reply related
* Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
From: Tony Lindgren @ 2012-05-10 16:16 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Russ Dill, linux-omap, linux-fbdev
In-Reply-To: <1336632790.5182.8.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120509 23:56]:
> On Wed, 2012-05-09 at 16:37 -0700, Tony Lindgren wrote:
> > * Russ Dill <Russ.Dill@ti.com> [120509 15:53]:
> > > On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > > * Russ Dill <Russ.Dill@ti.com> [120509 15:12]:
> > > >> The Beagleboard xM gpio used for TFP410 powerdown is connected through
> > > >> an I2C attached chip which means setting the GPIO can sleep. Code that
> > > >> calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
> > > >
> > > > What's the error without this patch? Or just no display?
> > > >
> > > > Just wondering if it's safe to merge Tomi's clean up series to
> > > > arm-soc tree..
> > >
> > > The only platform that has a problem is Beagleboard xM, and that is
> > > only after 'ARM: OMAP: Cleanup Beagleboard DVI reset gpio' is applied.
> > > Since the context actually can sleep, the only consequence is a
> > > WARN_ON statement.
> > >
> > > So yes, it should be safe.
> >
> > Well since I have not actually merged it with other branches yet, I'll wait
> > for Tomi to apply that and repull his for-l-o-3.5 branch.
>
> You can pull for-l-o-3.5 as it is now, there's no need to change it.
> This _cansleep change is a separate dss specific change.
>
> So to summarize:
>
> Currently the powerdown GPIO for tfp410 is handled in the board files
> (and called reset gpio), with gpio_set_value(). My cleanup series moves
> this to the tfp410 driver.
>
> BB-xM needs to use gpio_set_value_cansleep() in tfp410 to function
> properly, so the tfp410 driver needs to be changed, as this patch does.
> I will take this patch to the dss tree.
>
> So it's safe to pull my cleanup series, but if I understood correctly,
> applying Russ's "[PATCH v4] ARM: OMAP: Cleanup Beagleboard DVI reset
> gpio" will cause WARN_ONs on BB-xM until this patch to tfp410 is also
> applied.
>
> But it doesn't sound too serious, so I think it's safe to apply the
> "cleanup beagleboard dvi" patch also. The warning will go away when both
> l-o and dss trees are pulled in the merge window.
OK thanks will use for-l-o-3.5 as it is now then.
Tony
^ permalink raw reply
* Re: [PATCH 00/25] OMAPDSS: DT preparation patches v2
From: Tony Lindgren @ 2012-05-10 16:13 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1336633888.5182.19.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120510 00:15]:
> On Wed, 2012-05-09 at 08:45 -0700, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [120509 01:12]:
> > >
> > > Below is the pull request for board file related changes. Tested on
> > > panda & 4430sdp.
> >
> > Thanks, I've merged that into clenaup-dss branch and will send it
> > along with other still pending cleanup branches.
> >
> > > How should I manage my tree related to this... Should I rebase my
> > > original DT preparation series on top of this new branch, or can I just
> > > ignore the new branch for now, as long as I merge it at some point
> > > before sending a pull request to mainline?
> >
> > Yes you need to rebase on this now. And not touch these commits.
> >
> > Otherwise we'll end up with duplicate commits in the mainline tree,
> > which is a big no-no. If something shows up that needs fixing in this
> > series, it must now be separate patches on top of this series.
> >
> > When doing pull requests we both just have to make note that there's
> > a dependency to this branch, and it will find it's way to mainline
> > via arm-soc pull request. Or if no conflicts need sorting out, then
> > it will just get merged with your pull request.
>
> Hmm, I'm still not totally sure how to proceed. What do you mean with
> "make a note"?
Well let's say I had some conflicting platform data clean up patches,
I would pull in your branch, then when sending a pull request I would
mention that it depends on your branch being pulled in.
> I understand that I can't change the commits, but is it ok for me to now
> merge the for-l-o-3.5 branch into my master branch (which is my "stable"
> branch, for which I'll send a pull request)?
Yes. But I suggest you first add add that panda xm gpio fix into your
for-l-o-3.5 and that way it's safer for me to merge too.
> If the same commits are both in my tree and in l-o (or arm-soc), doesn't
> it mean that the commits seem to come into Linus's tree from whoever
> happens to send their pull request first? Then again, does it matter..
Yes, that's OK.
> And if there are conflicts in the board files between for-l-o-3.5 and
> some other commits, and you or Arnd resolve those for l-o or arm-soc,
> what happens when the same, but unresolved, commits come from my pull
> request?
Well in that case it makes sense to get the arm-soc changes merged
first, who wants to resolve conflicts multiple times? Of course more
branches can be pulled into both trees as needed too.
> Sorry if this should be obvious, but I haven't done such merging before
> and I'd rather not mess it up =).
Yeah np :)
Tony
^ permalink raw reply
* Re: [PATCH v2 1/4] mfd: add LM3533 lighting-power core driver
From: Johan Hovold @ 2012-05-10 12:07 UTC (permalink / raw)
To: Samuel Ortiz
Cc: Rob Landley, Richard Purdie, Jonathan Cameron, Greg Kroah-Hartman,
Florian Tobias Schandinat, Arnd Bergmann, Andrew Morton,
Mark Brown, linux-doc, linux-kernel, linux-iio, devel,
linux-fbdev
In-Reply-To: <20120509144218.GI1794@sortiz-mobl>
On Wed, May 09, 2012 at 04:42:18PM +0200, Samuel Ortiz wrote:
> Hi Johan
>
> On Thu, May 03, 2012 at 12:26:36PM +0200, Johan Hovold wrote:
> > Add support for National Semiconductor / TI LM3533 lighting power chips.
> >
> > This is the core driver which provides register access over I2C and
> > registers the ambient-light-sensor, LED and backlight sub-drivers.
> >
> > Signed-off-by: Johan Hovold <jhovold@gmail.com>
> > ---
> >
> > v2:
> > - add sysfs-ABI documentation
> > - merge i2c implementation with core
> > - use regmap and kill custom debugfs interface
> >
> >
> > .../ABI/testing/sysfs-bus-i2c-devices-lm3533 | 38 +
> > drivers/mfd/Kconfig | 13 +
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/lm3533-core.c | 717 ++++++++++++++++++++
> > drivers/mfd/lm3533-ctrlbank.c | 134 ++++
> > include/linux/mfd/lm3533.h | 89 +++
> > 6 files changed, 992 insertions(+), 0 deletions(-)
> > create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-lm3533
> > create mode 100644 drivers/mfd/lm3533-core.c
> > create mode 100644 drivers/mfd/lm3533-ctrlbank.c
> > create mode 100644 include/linux/mfd/lm3533.h
> Patch applied to my for-next branch, thanks.
I've been travelling for a few days and didn't have time to submit a
discussed change to move two attributes to the platform data before I
left.
Could you please apply the following two patches on top of this one?
mfd: lm3533: add boost frequency and ovp to platform data
mfd: lm3533: remove boost attributes
Thanks,
Johan
^ permalink raw reply
* [PATCH v2] OMAPDSS: OMAPFB: always allow to configure overlay
From: Grazvydas Ignotas @ 2012-05-10 11:19 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-omap, Tomi Valkeinen, Grazvydas Ignotas
Currently when multiple overlays are active, OMAPFB_SETUP_PLANE fails.
Instead of failing, allow it to configure the first overlay as if there
was only one overlay, the remaining ones will have to be configured in
other ways (sysfs).
This allows overlay-controlling programs (like video players) to function
properly when framebuffer is cloned to another display (like TV).
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
---
drivers/video/omap2/omapfb/omapfb-ioctl.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 6a09ef8..8af7e17 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -70,7 +70,7 @@ static int omapfb_setup_plane(struct fb_info *fbi, struct omapfb_plane_info *pi)
DBG("omapfb_setup_plane\n");
- if (ofbi->num_overlays != 1) {
+ if (ofbi->num_overlays = 0) {
r = -EINVAL;
goto out;
}
@@ -185,7 +185,7 @@ static int omapfb_query_plane(struct fb_info *fbi, struct omapfb_plane_info *pi)
{
struct omapfb_info *ofbi = FB2OFB(fbi);
- if (ofbi->num_overlays != 1) {
+ if (ofbi->num_overlays = 0) {
memset(pi, 0, sizeof(*pi));
} else {
struct omap_overlay *ovl;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] OMAPDSS: OMAPFB: always allow to configure overlay
From: Grazvydas Ignotas @ 2012-05-10 10:58 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1336144581-25151-1-git-send-email-notasas@gmail.com>
On Thu, May 10, 2012 at 1:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Fri, 2012-05-04 at 18:16 +0300, Grazvydas Ignotas wrote:
>> Currently when multiple overlays are active, OMAPFB_SETUP_PLANE fails.
>> Instead of failing, allow it to configure the first overlay as if there
>> was only one overlay, the remaining ones will have to be configured in
>> other ways (sysfs).
>>
>> This allows overlay-controlling programs (like video players) to function
>> properly when framebuffer is cloned to another display (like TV).
>>
>> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
>> ---
>> drivers/video/omap2/omapfb/omapfb-ioctl.c | 36 ++++++++++------------------
>> 1 files changed, 13 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c b/drivers/video/omap2/omapfb/omapfb-ioctl.c
>> index 6a09ef8..58b7f2d 100644
>> --- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
>> +++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
>> @@ -70,11 +70,6 @@ static int omapfb_setup_plane(struct fb_info *fbi, struct omapfb_plane_info *pi)
>>
>> DBG("omapfb_setup_plane\n");
>>
>> - if (ofbi->num_overlays != 1) {
>> - r = -EINVAL;
>> - goto out;
>> - }
>> -
>> /* XXX uses only the first overlay */
>> ovl = ofbi->overlays[0];
>
> What if there are no overlays? I'm not quite sure about it, but I think
> it's possible.
Hmm, I guess you are right, will send v2.
--
Gražvydas
^ permalink raw reply
* Re: [PATCH] OMAPDSS: OMAPFB: always allow to configure overlay
From: Tomi Valkeinen @ 2012-05-10 10:28 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1336144581-25151-1-git-send-email-notasas@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]
On Fri, 2012-05-04 at 18:16 +0300, Grazvydas Ignotas wrote:
> Currently when multiple overlays are active, OMAPFB_SETUP_PLANE fails.
> Instead of failing, allow it to configure the first overlay as if there
> was only one overlay, the remaining ones will have to be configured in
> other ways (sysfs).
>
> This allows overlay-controlling programs (like video players) to function
> properly when framebuffer is cloned to another display (like TV).
>
> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
> ---
> drivers/video/omap2/omapfb/omapfb-ioctl.c | 36 ++++++++++------------------
> 1 files changed, 13 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c b/drivers/video/omap2/omapfb/omapfb-ioctl.c
> index 6a09ef8..58b7f2d 100644
> --- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
> +++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
> @@ -70,11 +70,6 @@ static int omapfb_setup_plane(struct fb_info *fbi, struct omapfb_plane_info *pi)
>
> DBG("omapfb_setup_plane\n");
>
> - if (ofbi->num_overlays != 1) {
> - r = -EINVAL;
> - goto out;
> - }
> -
> /* XXX uses only the first overlay */
> ovl = ofbi->overlays[0];
What if there are no overlays? I'm not quite sure about it, but I think
it's possible.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 00/25] OMAPDSS: DT preparation patches v2
From: Tomi Valkeinen @ 2012-05-10 7:11 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <20120509154543.GK5088@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]
On Wed, 2012-05-09 at 08:45 -0700, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [120509 01:12]:
> >
> > Below is the pull request for board file related changes. Tested on
> > panda & 4430sdp.
>
> Thanks, I've merged that into clenaup-dss branch and will send it
> along with other still pending cleanup branches.
>
> > How should I manage my tree related to this... Should I rebase my
> > original DT preparation series on top of this new branch, or can I just
> > ignore the new branch for now, as long as I merge it at some point
> > before sending a pull request to mainline?
>
> Yes you need to rebase on this now. And not touch these commits.
>
> Otherwise we'll end up with duplicate commits in the mainline tree,
> which is a big no-no. If something shows up that needs fixing in this
> series, it must now be separate patches on top of this series.
>
> When doing pull requests we both just have to make note that there's
> a dependency to this branch, and it will find it's way to mainline
> via arm-soc pull request. Or if no conflicts need sorting out, then
> it will just get merged with your pull request.
Hmm, I'm still not totally sure how to proceed. What do you mean with
"make a note"?
I understand that I can't change the commits, but is it ok for me to now
merge the for-l-o-3.5 branch into my master branch (which is my "stable"
branch, for which I'll send a pull request)?
If the same commits are both in my tree and in l-o (or arm-soc), doesn't
it mean that the commits seem to come into Linus's tree from whoever
happens to send their pull request first? Then again, does it matter..
And if there are conflicts in the board files between for-l-o-3.5 and
some other commits, and you or Arnd resolve those for l-o or arm-soc,
what happens when the same, but unresolved, commits come from my pull
request?
Sorry if this should be obvious, but I haven't done such merging before
and I'd rather not mess it up =).
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
From: Tomi Valkeinen @ 2012-05-10 6:54 UTC (permalink / raw)
To: Russ Dill; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1336601288-27848-1-git-send-email-Russ.Dill@ti.com>
[-- Attachment #1: Type: text/plain, Size: 494 bytes --]
On Wed, 2012-05-09 at 15:08 -0700, Russ Dill wrote:
> The Beagleboard xM gpio used for TFP410 powerdown is connected through
> an I2C attached chip which means setting the GPIO can sleep. Code that
> calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
>
> Signed-off-by: Russ Dill <Russ.Dill@ti.com>
> ---
> drivers/video/omap2/displays/panel-tfp410.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
I'll apply this to dss tree, thanks.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
From: Tomi Valkeinen @ 2012-05-10 6:53 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Russ Dill, linux-omap, linux-fbdev
In-Reply-To: <20120509233745.GZ5088@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]
On Wed, 2012-05-09 at 16:37 -0700, Tony Lindgren wrote:
> * Russ Dill <Russ.Dill@ti.com> [120509 15:53]:
> > On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > * Russ Dill <Russ.Dill@ti.com> [120509 15:12]:
> > >> The Beagleboard xM gpio used for TFP410 powerdown is connected through
> > >> an I2C attached chip which means setting the GPIO can sleep. Code that
> > >> calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
> > >
> > > What's the error without this patch? Or just no display?
> > >
> > > Just wondering if it's safe to merge Tomi's clean up series to
> > > arm-soc tree..
> >
> > The only platform that has a problem is Beagleboard xM, and that is
> > only after 'ARM: OMAP: Cleanup Beagleboard DVI reset gpio' is applied.
> > Since the context actually can sleep, the only consequence is a
> > WARN_ON statement.
> >
> > So yes, it should be safe.
>
> Well since I have not actually merged it with other branches yet, I'll wait
> for Tomi to apply that and repull his for-l-o-3.5 branch.
You can pull for-l-o-3.5 as it is now, there's no need to change it.
This _cansleep change is a separate dss specific change.
So to summarize:
Currently the powerdown GPIO for tfp410 is handled in the board files
(and called reset gpio), with gpio_set_value(). My cleanup series moves
this to the tfp410 driver.
BB-xM needs to use gpio_set_value_cansleep() in tfp410 to function
properly, so the tfp410 driver needs to be changed, as this patch does.
I will take this patch to the dss tree.
So it's safe to pull my cleanup series, but if I understood correctly,
applying Russ's "[PATCH v4] ARM: OMAP: Cleanup Beagleboard DVI reset
gpio" will cause WARN_ONs on BB-xM until this patch to tfp410 is also
applied.
But it doesn't sound too serious, so I think it's safe to apply the
"cleanup beagleboard dvi" patch also. The warning will go away when both
l-o and dss trees are pulled in the merge window.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] video: EXYNOS: enable interrupt again after sw reset
From: Florian Tobias Schandinat @ 2012-05-10 0:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4FA3622A.7060401@samsung.com>
On 05/04/2012 04:59 AM, Donghwa Lee wrote:
> When exynos_mipi_update_cfg() is called, mipi dsi registers were become
> sw reset. So, It needs to enable interrupt again.
>
> Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
> Signed-off-by: Inki Dae <inki.dae@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/exynos/exynos_mipi_dsi.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
> index 557091d..49c7351 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi.c
> @@ -102,6 +102,8 @@ static void exynos_mipi_update_cfg(struct mipi_dsim_device *dsim)
> /* set display timing. */
> exynos_mipi_dsi_set_display_mode(dsim, dsim->dsim_config);
>
> + exynos_mipi_dsi_init_interrupt(dsim);
> +
> /*
> * data from Display controller(FIMD) is transferred in video mode
> * but in case of command mode, all settigs is updated to registers.
^ permalink raw reply
* Re: [PATCH] video: exynos_dp: fix max loop count in EQ sequence of link training
From: Florian Tobias Schandinat @ 2012-05-10 0:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <003201cd2998$2ee3eef0$8cabccd0$%han@samsung.com>
On 05/04/2012 01:49 AM, Jingoo Han wrote:
> This patch fixes max loop count in EQ(Channel Equalization) sequence
> of link training. According to DP(displayport) specification,
> the max loop count in this sequence should be 5.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> include/video/exynos_dp.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/video/exynos_dp.h b/include/video/exynos_dp.h
> index 8847a9d..bd8cabd 100644
> --- a/include/video/exynos_dp.h
> +++ b/include/video/exynos_dp.h
> @@ -14,7 +14,7 @@
>
> #define DP_TIMEOUT_LOOP_COUNT 100
> #define MAX_CR_LOOP 5
> -#define MAX_EQ_LOOP 4
> +#define MAX_EQ_LOOP 5
>
> enum link_rate_type {
> LINK_RATE_1_62GBPS = 0x06,
^ permalink raw reply
* Re: [PATCH v2] video/via: Convert to kstrtou8_from_user
From: Florian Tobias Schandinat @ 2012-05-10 0:19 UTC (permalink / raw)
To: Peter Huewe; +Cc: Alexey Dobriyan, linux-fbdev, linux-kernel, kernel-janitors
In-Reply-To: <1336090997-23727-1-git-send-email-peterhuewe@gmx.de>
On 05/04/2012 12:23 AM, Peter Huewe wrote:
> This patch replaces the code for getting an number from a
> userspace buffer by a simple call to kstrou8_from_user.
> This makes it easier to read and less error prone.
>
> v2:
> removed initialization of reg_val and dropped check if count < 1
>
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> @Alexey: Thanks for the review/feedback!
> drivers/video/via/viafbdev.c | 34 ++++++++++++----------------------
> 1 files changed, 12 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
> index a13c258..88bf5ba 100644
> --- a/drivers/video/via/viafbdev.c
> +++ b/drivers/video/via/viafbdev.c
> @@ -1279,17 +1279,12 @@ static int viafb_dfph_proc_open(struct inode *inode, struct file *file)
> static ssize_t viafb_dfph_proc_write(struct file *file,
> const char __user *buffer, size_t count, loff_t *pos)
> {
> - char buf[20];
> - u8 reg_val = 0;
> - unsigned long length;
> - if (count < 1)
> - return -EINVAL;
> - length = count > 20 ? 20 : count;
> - if (copy_from_user(&buf[0], buffer, length))
> - return -EFAULT;
> - buf[length - 1] = '\0'; /*Ensure end string */
> - if (kstrtou8(buf, 0, ®_val) < 0)
> - return -EINVAL;
> + int err;
> + u8 reg_val;
> + err = kstrtou8_from_user(buffer, count, 0, ®_val);
> + if (err)
> + return err;
> +
> viafb_write_reg_mask(CR97, VIACR, reg_val, 0x0f);
> return count;
> }
> @@ -1319,17 +1314,12 @@ static int viafb_dfpl_proc_open(struct inode *inode, struct file *file)
> static ssize_t viafb_dfpl_proc_write(struct file *file,
> const char __user *buffer, size_t count, loff_t *pos)
> {
> - char buf[20];
> - u8 reg_val = 0;
> - unsigned long length;
> - if (count < 1)
> - return -EINVAL;
> - length = count > 20 ? 20 : count;
> - if (copy_from_user(&buf[0], buffer, length))
> - return -EFAULT;
> - buf[length - 1] = '\0'; /*Ensure end string */
> - if (kstrtou8(buf, 0, ®_val) < 0)
> - return -EINVAL;
> + int err;
> + u8 reg_val;
> + err = kstrtou8_from_user(buffer, count, 0, ®_val);
> + if (err)
> + return err;
> +
> viafb_write_reg_mask(CR99, VIACR, reg_val, 0x0f);
> return count;
> }
^ permalink raw reply
* Re: [PATCH] video/sis: Annotate SiS_DRAMType as __devinitconst
From: Florian Tobias Schandinat @ 2012-05-10 0:19 UTC (permalink / raw)
To: Peter Huewe; +Cc: Thomas Winischhofer, linux-fbdev, linux-kernel
In-Reply-To: <1336083295-7327-1-git-send-email-peterhuewe@gmx.de>
On 05/03/2012 10:14 PM, Peter Huewe wrote:
> SiS_DRAMType is const and only used by sisfb_post_300_rwtest which is
> marked __devinit we can annotate SiS_DRAMType with __devinitconst and
> move it into the file scope in order to not have it created on the
> stack.
> This patch decreases the compiled module size by about 100bytes.
>
> And since hardcoded values are bad we use ARRAY_SIZE for determining
> the size of SiS_DRAMType ;)
>
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Good that you did this one, it was more to be done than I expected. I
ignored the checkpatch errors as you didn't introduce them but maybe it
wouldn't be a bad idea to fix things up if you touch them. Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/sis/sis_main.c | 41 +++++++++++++++++++++--------------------
> 1 files changed, 21 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/video/sis/sis_main.c b/drivers/video/sis/sis_main.c
> index 078ca21..a7a48db 100644
> --- a/drivers/video/sis/sis_main.c
> +++ b/drivers/video/sis/sis_main.c
> @@ -4222,6 +4222,26 @@ sisfb_post_300_buswidth(struct sis_video_info *ivideo)
> return 1; /* 32bit */
> }
>
> +static const unsigned short __devinitconst SiS_DRAMType[17][5] = {
> + {0x0C,0x0A,0x02,0x40,0x39},
> + {0x0D,0x0A,0x01,0x40,0x48},
> + {0x0C,0x09,0x02,0x20,0x35},
> + {0x0D,0x09,0x01,0x20,0x44},
> + {0x0C,0x08,0x02,0x10,0x31},
> + {0x0D,0x08,0x01,0x10,0x40},
> + {0x0C,0x0A,0x01,0x20,0x34},
> + {0x0C,0x09,0x01,0x08,0x32},
> + {0x0B,0x08,0x02,0x08,0x21},
> + {0x0C,0x08,0x01,0x08,0x30},
> + {0x0A,0x08,0x02,0x04,0x11},
> + {0x0B,0x0A,0x01,0x10,0x28},
> + {0x09,0x08,0x02,0x02,0x01},
> + {0x0B,0x09,0x01,0x08,0x24},
> + {0x0B,0x08,0x01,0x04,0x20},
> + {0x0A,0x08,0x01,0x02,0x10},
> + {0x09,0x08,0x01,0x01,0x00}
> +};
> +
> static int __devinit
> sisfb_post_300_rwtest(struct sis_video_info *ivideo, int iteration, int buswidth,
> int PseudoRankCapacity, int PseudoAdrPinCount,
> @@ -4231,27 +4251,8 @@ sisfb_post_300_rwtest(struct sis_video_info *ivideo, int iteration, int buswidth
> unsigned short sr14;
> unsigned int k, RankCapacity, PageCapacity, BankNumHigh, BankNumMid;
> unsigned int PhysicalAdrOtherPage, PhysicalAdrHigh, PhysicalAdrHalfPage;
> - static const unsigned short SiS_DRAMType[17][5] = {
> - {0x0C,0x0A,0x02,0x40,0x39},
> - {0x0D,0x0A,0x01,0x40,0x48},
> - {0x0C,0x09,0x02,0x20,0x35},
> - {0x0D,0x09,0x01,0x20,0x44},
> - {0x0C,0x08,0x02,0x10,0x31},
> - {0x0D,0x08,0x01,0x10,0x40},
> - {0x0C,0x0A,0x01,0x20,0x34},
> - {0x0C,0x09,0x01,0x08,0x32},
> - {0x0B,0x08,0x02,0x08,0x21},
> - {0x0C,0x08,0x01,0x08,0x30},
> - {0x0A,0x08,0x02,0x04,0x11},
> - {0x0B,0x0A,0x01,0x10,0x28},
> - {0x09,0x08,0x02,0x02,0x01},
> - {0x0B,0x09,0x01,0x08,0x24},
> - {0x0B,0x08,0x01,0x04,0x20},
> - {0x0A,0x08,0x01,0x02,0x10},
> - {0x09,0x08,0x01,0x01,0x00}
> - };
>
> - for(k = 0; k <= 16; k++) {
> + for(k = 0; k < ARRAY_SIZE(SiS_DRAMType); k++) {
>
> RankCapacity = buswidth * SiS_DRAMType[k][3];
>
^ permalink raw reply
* Re: [PATCH] video: s3c-fb: s3c_fb_missing_pixclock() can't be __devinit
From: Mark Brown @ 2012-05-10 0:16 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1334486344-24073-1-git-send-email-broonie@opensource.wolfsonmicro.com>
[-- Attachment #1: Type: text/plain, Size: 706 bytes --]
On Thu, May 10, 2012 at 12:10:13AM +0000, Florian Tobias Schandinat wrote:
> On 04/15/2012 10:39 AM, Mark Brown wrote:
> > Since s3c_fb_missing_pixclock() is called from s3c_fb_set_rgb_timing()
> > which is used in the suspend/resume paths it can't be marked __devinit
> > as this could result in it being discarded after boot.
> > Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> I'm not sure that this can actually happen. But the code looks saner
> with the patch applied so I applied it.
Thanks. To trigger you'd need to disable CONFIG_HOTPLUG and modules
(possibly some other stuff too) but the main motiviation is that the
build system complains loudly about section mismatches.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] video/sis: Remove unused structs SiS_SDRDRAM_TYPE/SiS_DDRDRAM_TYPE/SiS_DRAMType
From: Florian Tobias Schandinat @ 2012-05-10 0:13 UTC (permalink / raw)
To: Peter Huewe; +Cc: Thomas Winischhofer, linux-fbdev, linux-kernel
In-Reply-To: <1336081359-5643-1-git-send-email-peterhuewe@gmx.de>
On 05/03/2012 09:42 PM, Peter Huewe wrote:
> This patch removes the unused structs SiS_SDRDRAM_TYPE and SiS_DDRDRAM_TYPE
> from init.h
>
> These are not used anywhere so we can delete them.
>
> The SiS_DRAMType is identically defined in sis_main.c and only used
> there so we can remove it here.
>
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/sis/init.h | 45 ---------------------------------------------
> 1 files changed, 0 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/video/sis/init.h b/drivers/video/sis/init.h
> index aff7384..85d6738 100644
> --- a/drivers/video/sis/init.h
> +++ b/drivers/video/sis/init.h
> @@ -105,51 +105,6 @@ static const unsigned short ModeIndex_1920x1440[] = {0x68, 0x69, 0x00, 0x6b};
> static const unsigned short ModeIndex_300_2048x1536[]= {0x6c, 0x6d, 0x00, 0x00};
> static const unsigned short ModeIndex_310_2048x1536[]= {0x6c, 0x6d, 0x00, 0x6e};
>
> -static const unsigned short SiS_DRAMType[17][5]={
> - {0x0C,0x0A,0x02,0x40,0x39},
> - {0x0D,0x0A,0x01,0x40,0x48},
> - {0x0C,0x09,0x02,0x20,0x35},
> - {0x0D,0x09,0x01,0x20,0x44},
> - {0x0C,0x08,0x02,0x10,0x31},
> - {0x0D,0x08,0x01,0x10,0x40},
> - {0x0C,0x0A,0x01,0x20,0x34},
> - {0x0C,0x09,0x01,0x08,0x32},
> - {0x0B,0x08,0x02,0x08,0x21},
> - {0x0C,0x08,0x01,0x08,0x30},
> - {0x0A,0x08,0x02,0x04,0x11},
> - {0x0B,0x0A,0x01,0x10,0x28},
> - {0x09,0x08,0x02,0x02,0x01},
> - {0x0B,0x09,0x01,0x08,0x24},
> - {0x0B,0x08,0x01,0x04,0x20},
> - {0x0A,0x08,0x01,0x02,0x10},
> - {0x09,0x08,0x01,0x01,0x00}
> -};
> -
> -static const unsigned short SiS_SDRDRAM_TYPE[13][5] > -{
> - { 2,12, 9,64,0x35},
> - { 1,13, 9,64,0x44},
> - { 2,12, 8,32,0x31},
> - { 2,11, 9,32,0x25},
> - { 1,12, 9,32,0x34},
> - { 1,13, 8,32,0x40},
> - { 2,11, 8,16,0x21},
> - { 1,12, 8,16,0x30},
> - { 1,11, 9,16,0x24},
> - { 1,11, 8, 8,0x20},
> - { 2, 9, 8, 4,0x01},
> - { 1,10, 8, 4,0x10},
> - { 1, 9, 8, 2,0x00}
> -};
> -
> -static const unsigned short SiS_DDRDRAM_TYPE[4][5] > -{
> - { 2,12, 9,64,0x35},
> - { 2,12, 8,32,0x31},
> - { 2,11, 8,16,0x21},
> - { 2, 9, 8, 4,0x01}
> -};
> -
> static const unsigned char SiS_MDA_DAC[] > {
> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
^ permalink raw reply
* Re: [PATCH] video: mb862xxfbdrv.c: local functions should not be exposed globally
From: Florian Tobias Schandinat @ 2012-05-10 0:12 UTC (permalink / raw)
To: H Hartley Sweeten; +Cc: Linux Kernel, linux-fbdev, agust
In-Reply-To: <201205021737.35719.hartleys@visionengravers.com>
On 05/03/2012 12:37 AM, H Hartley Sweeten wrote:
> Functions not referenced outside of a source file should be marked
> static to prevent them from being exposed globally.
>
> Quiets the sparse warnings:
>
> warning: symbol 'mb862xx_intr' was not declared. Should it be static?
>
> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: Anatolij Gustschin <agust@denx.de>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
>
> diff --git a/drivers/video/mb862xx/mb862xxfbdrv.c b/drivers/video/mb862xx/mb862xxfbdrv.c
> index 11a7a33..00ce1f3 100644
> --- a/drivers/video/mb862xx/mb862xxfbdrv.c
> +++ b/drivers/video/mb862xx/mb862xxfbdrv.c
> @@ -579,7 +579,7 @@ static ssize_t mb862xxfb_show_dispregs(struct device *dev,
>
> static DEVICE_ATTR(dispregs, 0444, mb862xxfb_show_dispregs, NULL);
>
> -irqreturn_t mb862xx_intr(int irq, void *dev_id)
> +static irqreturn_t mb862xx_intr(int irq, void *dev_id)
> {
> struct mb862xxfb_par *par = (struct mb862xxfb_par *) dev_id;
> unsigned long reg_ist, mask;
>
^ permalink raw reply
* Re: [PATCH] video: mb862xx-i2c: local functions should not be exposed globally
From: Florian Tobias Schandinat @ 2012-05-10 0:12 UTC (permalink / raw)
To: H Hartley Sweeten; +Cc: Linux Kernel, linux-fbdev, agust
In-Reply-To: <201205021734.16988.hartleys@visionengravers.com>
On 05/03/2012 12:34 AM, H Hartley Sweeten wrote:
> Functions not referenced outside of a source file should be marked
> static to prevent them from being exposed globally.
>
> Quiets the sparse warnings:
>
> warning: symbol 'mb862xx_i2c_stop' was not declared. Should it be static?
>
> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: Anatolij Gustschin <agust@denx.de>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
>
> diff --git a/drivers/video/mb862xx/mb862xx-i2c.c b/drivers/video/mb862xx/mb862xx-i2c.c
> index 273769b..c87e17a 100644
> --- a/drivers/video/mb862xx/mb862xx-i2c.c
> +++ b/drivers/video/mb862xx/mb862xx-i2c.c
> @@ -68,7 +68,7 @@ static int mb862xx_i2c_read_byte(struct i2c_adapter *adap, u8 *byte, int last)
> return 1;
> }
>
> -void mb862xx_i2c_stop(struct i2c_adapter *adap)
> +static void mb862xx_i2c_stop(struct i2c_adapter *adap)
> {
> struct mb862xxfb_par *par = adap->algo_data;
>
>
^ permalink raw reply
* Re: [PATCH] video: fb_defio.c: local functions should not be exposed globally
From: Florian Tobias Schandinat @ 2012-05-10 0:11 UTC (permalink / raw)
To: H Hartley Sweeten; +Cc: Linux Kernel, linux-fbdev
In-Reply-To: <201205021723.40801.hartleys@visionengravers.com>
On 05/03/2012 12:23 AM, H Hartley Sweeten wrote:
> Functions not referenced outside of a source file should be marked
> static to prevent them from being exposed globally.
>
> Quiets the sparse warning:
>
> warning: symbol 'fb_deferred_io_page' was not declared. Should it be static?
>
> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: Jaya Kumar <jayalk@intworks.biz>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
>
> diff --git a/drivers/video/fb_defio.c b/drivers/video/fb_defio.c
> index 070f26f..1ddeb11 100644
> --- a/drivers/video/fb_defio.c
> +++ b/drivers/video/fb_defio.c
> @@ -23,7 +23,7 @@
> #include <linux/rmap.h>
> #include <linux/pagemap.h>
>
> -struct page *fb_deferred_io_page(struct fb_info *info, unsigned long offs)
> +static struct page *fb_deferred_io_page(struct fb_info *info, unsigned long offs)
> {
> void *screen_base = (void __force *) info->screen_base;
> struct page *page;
>
^ permalink raw reply
* Re: [PATCH] video: smscufx.c: local functions should not be exposed globally
From: Florian Tobias Schandinat @ 2012-05-10 0:11 UTC (permalink / raw)
To: H Hartley Sweeten; +Cc: Linux Kernel, linux-fbdev, steve.glendinning
In-Reply-To: <201205021717.23749.hartleys@visionengravers.com>
On 05/03/2012 12:17 AM, H Hartley Sweeten wrote:
> Functions not referenced outside of a source file should be marked
> static to prevent them from being exposed globally.
>
> Quiets the sparse warnings:
>
> warning: symbol 'ufx_handle_damage' was not declared. Should it be static?
>
> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: Steve Glendinning <steve.glendinning@smsc.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
>
> diff --git a/drivers/video/smscufx.c b/drivers/video/smscufx.c
> index 9985785..af3ef27 100644
> --- a/drivers/video/smscufx.c
> +++ b/drivers/video/smscufx.c
> @@ -846,7 +846,7 @@ static void ufx_raw_rect(struct ufx_data *dev, u16 *cmd, int x, int y,
> }
> }
>
> -int ufx_handle_damage(struct ufx_data *dev, int x, int y,
> +static int ufx_handle_damage(struct ufx_data *dev, int x, int y,
> int width, int height)
> {
> size_t packed_line_len = ALIGN((width * 2), 4);
>
^ permalink raw reply
* Re: [PATCH] video: s3c-fb: s3c_fb_missing_pixclock() can't be __devinit
From: Florian Tobias Schandinat @ 2012-05-10 0:10 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1334486344-24073-1-git-send-email-broonie@opensource.wolfsonmicro.com>
On 04/15/2012 10:39 AM, Mark Brown wrote:
> Since s3c_fb_missing_pixclock() is called from s3c_fb_set_rgb_timing()
> which is used in the suspend/resume paths it can't be marked __devinit
> as this could result in it being discarded after boot.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
I'm not sure that this can actually happen. But the code looks saner
with the patch applied so I applied it.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/s3c-fb.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 18c84b8..d8f0018 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -1056,7 +1056,7 @@ static struct fb_ops s3c_fb_ops = {
> *
> * Calculate the pixel clock when none has been given through platform data.
> */
> -static void __devinit s3c_fb_missing_pixclock(struct fb_videomode *mode)
> +static void s3c_fb_missing_pixclock(struct fb_videomode *mode)
> {
> u64 pixclk = 1000000000000ULL;
> u32 div;
^ permalink raw reply
* Re: [PATCH] OMAPDSS: TFP410: use gpio_set_value_cansleep
From: Tony Lindgren @ 2012-05-09 23:37 UTC (permalink / raw)
To: Russ Dill; +Cc: linux-omap, linux-fbdev, Tomi Valkeinen
In-Reply-To: <CA+Bv8Xa+1RJ5QTn=vO4GSw1VtUZc3xX0J5qBVshvV5Dj+9uZVA@mail.gmail.com>
* Russ Dill <Russ.Dill@ti.com> [120509 15:53]:
> On Wed, May 9, 2012 at 3:14 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Russ Dill <Russ.Dill@ti.com> [120509 15:12]:
> >> The Beagleboard xM gpio used for TFP410 powerdown is connected through
> >> an I2C attached chip which means setting the GPIO can sleep. Code that
> >> calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
> >
> > What's the error without this patch? Or just no display?
> >
> > Just wondering if it's safe to merge Tomi's clean up series to
> > arm-soc tree..
>
> The only platform that has a problem is Beagleboard xM, and that is
> only after 'ARM: OMAP: Cleanup Beagleboard DVI reset gpio' is applied.
> Since the context actually can sleep, the only consequence is a
> WARN_ON statement.
>
> So yes, it should be safe.
Well since I have not actually merged it with other branches yet, I'll wait
for Tomi to apply that and repull his for-l-o-3.5 branch.
Tony
^ 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