* Re: [PATCH 1/2] video/fsl: make the diu driver work without platform hooks
From: Timur Tabi @ 2014-03-27 3:35 UTC (permalink / raw)
To: Jason.Jin@freescale.com
Cc: Scott Wood, linux-fbdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <f6883c3f759a4544936acec5dc7e542b@BLUPR03MB373.namprd03.prod.outlook.com>
Jason.Jin@freescale.com wrote:
>>>>> However, the DIU is already initialized in u-boot and we can
>>>>> rely on the settings in u-boot for corenet platform,
>>>
>>> I don't like that at all.
> [Jason Jin-R64188] What's the potential issue of this? Most of the
> IPs need the platform initialization in u-boot. For example, the
> hwconfig in u-boot used for board specific settings for most
> platform.
The potential problem is that it's not stable. Power management breaks
your code.
I won't NACK your patch, but it feels like a band-aid rather than a real
solution.
^ permalink raw reply
* RE: [PATCH 1/2] video/fsl: make the diu driver work without platform hooks
From: Jason.Jin @ 2014-03-27 3:38 UTC (permalink / raw)
To: Timur Tabi
Cc: Scott Wood, linux-fbdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <53339C96.3070406@tabi.org>
> Jason.Jin@freescale.com wrote:
> >>>>> However, the DIU is already initialized in u-boot and we can rely
> >>>>> on the settings in u-boot for corenet platform,
> >>>
> >>> I don't like that at all.
> > [Jason Jin-R64188] What's the potential issue of this? Most of the IPs
> > need the platform initialization in u-boot. For example, the hwconfig
> > in u-boot used for board specific settings for most platform.
>
> The potential problem is that it's not stable. Power management breaks
> your code.
>
> I won't NACK your patch, but it feels like a band-aid rather than a real
> solution.
>
[Jason Jin-R64188] Thanks. The power management will break the pixel clock only. We can try to fix it separately. I'll try to explain it in that mail.
^ permalink raw reply
* RE: [PATCH 2/2] video/fsl: Fix the sleep function for FSL DIU module
From: Jason.Jin @ 2014-03-27 3:42 UTC (permalink / raw)
To: Timur Tabi
Cc: Scott Wood, linux-fbdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Dongsheng.Wang@freescale.com
In-Reply-To: <53332168.5050805@tabi.org>
>
> On 03/26/2014 12:41 PM, Jason Jin wrote:
> > + if (!diu_ops.set_pixel_clock) {
> > + data->saved_pixel_clock = 0;
> > + if (of_address_to_resource(ofdev->dev.of_node, 1, &res))
> > + pr_err(KERN_ERR "No pixel clock set func and no pixel
> node!\n");
> > + else {
> > + data->pixelclk_ptr > > + devm_ioremap(&ofdev->dev, res.start,
> resource_size(&res));
> > + if (!data->pixelclk_ptr) {
> > + pr_err(KERN_ERR "fslfb: could not map pixelclk
> register!\n");
> > + ret = -ENOMEM;
> > + } else
> > + data->saved_pixel_clock = in_be32(data-
> >pixelclk_ptr);
> > + }
> > + }
>
> This seems very hackish. What node does ofdev point to? I wonder if
> this code should be in the platform file instead.
>
[Jason Jin-R64188] It's not hackish, we can provide the pixel clock register in the DIU node, I did not provide the dts update as this is only tested on T1040 platform. For other platforms such as p1022 and 8610, we still can use the pixel clock setting function in the platform.
The dts node update for T1040 is:
display:display@180000 {
compatible = "fsl,t1040-diu", "fsl,diu";
- reg = <0x180000 1000>;
+ reg = <0x180000 1000 0xfc028 4>;
interrupts = <74 2 0 0>;
};
If saving the pixel clock register likes a hackish. We can provide more information in the node to move the pixel clock settings to the driver. It seems that we only need to provide another parameter(the ratio) for pixel clock setting.
> Also, use dev_info() instead of pr_err, and never use exclamation marks
> in driver messages.
Ok, Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] video/fsl: Fix the sleep function for FSL DIU module
From: Timur Tabi @ 2014-03-27 3:46 UTC (permalink / raw)
To: Jason.Jin@freescale.com
Cc: Scott Wood, linux-fbdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Dongsheng.Wang@freescale.com
In-Reply-To: <e3e45edb388c482eb53474e18575f227@BLUPR03MB373.namprd03.prod.outlook.com>
Jason.Jin@freescale.com wrote:
> [Jason Jin-R64188] It's not hackish, we can provide the pixel clock register in the DIU node, I did not provide the dts update as this is only tested on T1040 platform. For other platforms such as p1022 and 8610, we still can use the pixel clock setting function in the platform.
>
> The dts node update for T1040 is:
> display:display@180000 {
> compatible = "fsl,t1040-diu", "fsl,diu";
> - reg = <0x180000 1000>;
> + reg = <0x180000 1000 0xfc028 4>;
> interrupts = <74 2 0 0>;
> };
This is hackish because you're specifying a single register that you
want to preserve in the DTS file, instead of a platform function which
is where it's supposed to be.
I will think about this some more. I think you are trying too hard to
avoid a platform file, which is why some of this code is hackish to me.
^ permalink raw reply
* RE: [PATCH 2/2] video/fsl: Fix the sleep function for FSL DIU module
From: Jason.Jin @ 2014-03-27 3:57 UTC (permalink / raw)
To: Timur Tabi
Cc: Scott Wood, linux-fbdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Dongsheng.Wang@freescale.com
In-Reply-To: <53339F03.7010004@tabi.org>
> Jason.Jin@freescale.com wrote:
> > [Jason Jin-R64188] It's not hackish, we can provide the pixel clock
> register in the DIU node, I did not provide the dts update as this is
> only tested on T1040 platform. For other platforms such as p1022 and 8610,
> we still can use the pixel clock setting function in the platform.
> >
> > The dts node update for T1040 is:
> > display:display@180000 {
> > compatible = "fsl,t1040-diu", "fsl,diu";
> > - reg = <0x180000 1000>;
> > + reg = <0x180000 1000 0xfc028 4>;
> > interrupts = <74 2 0 0>;
> > };
>
> This is hackish because you're specifying a single register that you want
> to preserve in the DTS file, instead of a platform function which is
> where it's supposed to be.
>
[Jason Jin-R64188] The pixel clock register is actually part of the DIU registers although it is not implemented in the diu module. Actually we can use it to set pixel clock in the driver not just saving it in suspend. We can provide the patch for discussion.
> I will think about this some more. I think you are trying too hard to
> avoid a platform file, which is why some of this code is hackish to me.
[Jason Jin-R64188] Thanks. Could you please share you thinking for how to setup the platform file then?
^ permalink raw reply
* [PATCH 1/2] video/fsl: Fix the sleep function for FSL DIU module
From: Jason Jin @ 2014-03-27 11:37 UTC (permalink / raw)
To: b07421, timur
Cc: linux-fbdev, linuxppc-dev, r58472, jason.jin, Wang Dongsheng
For deep sleep, the diu module will power off, when wake up from the deep
sleep, more registers need to be reinitialized.
Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
Signed-off-by: Jason Jin <Jason.Jin@freescale.com>
---
V2: Coding style clean up based on Timur's comments.
drivers/video/fsl-diu-fb.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index e8758b9..4bc4730 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -1628,9 +1628,15 @@ static int fsl_diu_suspend(struct platform_device *ofdev, pm_message_t state)
static int fsl_diu_resume(struct platform_device *ofdev)
{
struct fsl_diu_data *data;
+ unsigned int i;
data = dev_get_drvdata(&ofdev->dev);
- enable_lcdc(data->fsl_diu_info);
+ fsl_diu_enable_interrupts(data);
+ update_lcdc(data->fsl_diu_info);
+ for (i = 0; i < NUM_AOIS; i++) {
+ if (data->mfb[i].count)
+ fsl_diu_enable_panel(&data->fsl_diu_info[i]);
+ }
return 0;
}
--
1.8.0
^ permalink raw reply related
* [PATCH 2/2] Make the diu driver work without board level initilization
From: Jason Jin @ 2014-03-27 11:38 UTC (permalink / raw)
To: b07421, timur; +Cc: linux-fbdev, linuxppc-dev, r58472, jason.jin
So far the DIU driver does not have a mechanism to do the
board specific initialization. So on some platforms,
such as P1022, 8610 and 5121, The board specific initialization
is implmented in the platform file such p10222_ds.
Actually, the DIU is already intialized in the u-boot, the pin sharing
and the signal routing are also set in u-boot. So we can leverage that
in kernel driver to avoid board sepecific initialization, especially
for the corenet platform, which is the abstraction for serveral
platfroms.
The potential problem is that when the system wakeup from the deep
sleep, some platform settings may need to be re-initialized. The CPLD
and FPGA settings will be kept, but the pixel clock register which
usually locate at the global utility space need to be reinitialized.
Generally, the pixel clock setting was implemented in the platform
file, But the pixel clock register itself should be part of the DIU
module, And for P1022,8610 and T1040, the pixel clock register have the
same structure, So we can consider to move the pixel clock setting
from the platform to the diu driver. This patch provide the options
set the pixel clock in the diu driver. But the original platform pixel
clock setting stil can be used for P1022,8610 and 512x without any
update. To implement the pixel clock setting in the diu driver. the
following update in the diu dts node was needed.
display:display@180000 {
compatible = "fsl,t1040-diu", "fsl,diu";
- reg = <0x180000 1000>;
+ reg = <0x180000 1000 0xfc028 4>;
+ pixclk = <0 255 0>;
interrupts = <74 2 0 0>;
}
The 0xfc028 is the offset for pixel clock register. the 3 segment of
the pixclk stand for the PXCKDLYDIR, the max of PXCK and the PXCKDLY
which will be used by the pixel clock register setting.
This was tested on T1040 platform. For other platform, the original
node together with the platform settings still can work.
Signed-off-by: Jason Jin <Jason.Jin@freescale.com>
---
V2: Remove the pixel clock register saving for suspend.
add the pixel clock setting in driver.
drivers/video/fsl-diu-fb.c | 61 ++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 59 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index 4bc4730..792038f 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -50,6 +50,7 @@
#define INT_PARERR 0x08 /* Display parameters error interrupt */
#define INT_LS_BF_VS 0x10 /* Lines before vsync. interrupt */
+#define PIXCLKCR_PXCKEN 0x80000000
/*
* List of supported video modes
*
@@ -372,6 +373,8 @@ struct fsl_diu_data {
unsigned int irq;
enum fsl_diu_monitor_port monitor_port;
struct diu __iomem *diu_reg;
+ void __iomem *pixelclk_reg;
+ u32 pixclkcr[3];
spinlock_t reg_lock;
u8 dummy_aoi[4 * 4 * 4];
struct diu_ad dummy_ad __aligned(8);
@@ -479,7 +482,10 @@ static enum fsl_diu_monitor_port fsl_diu_name_to_port(const char *s)
port = FSL_DIU_PORT_DLVDS;
}
- return diu_ops.valid_monitor_port(port);
+ if (diu_ops.valid_monitor_port)
+ return diu_ops.valid_monitor_port(port);
+ else
+ return port;
}
/*
@@ -798,6 +804,35 @@ static void set_fix(struct fb_info *info)
fix->ypanstep = 1;
}
+static void set_pixel_clock(struct fsl_diu_data *data, unsigned int pixclock)
+{
+ unsigned long freq;
+ u64 temp;
+ u32 pxclk;
+ u32 pxclkdl_dir, pxckmax, pxclk_delay;
+
+ /* Convert pixclock from a wavelength to a frequency */
+ temp = 1000000000000ULL;
+ do_div(temp, pixclock);
+ freq = temp;
+
+ pxclkdl_dir = data->pixclkcr[0] << 30;
+ pxckmax = data->pixclkcr[1];
+ pxclk_delay = data->pixclkcr[2] << 8;
+
+ /*
+ * 'pxclk' is the ratio of the platform clock to the pixel clock.
+ * This number is programmed into the PIXCLKCR register, and the valid
+ * range of values is 2- pxckmax.
+ */
+ pxclk = DIV_ROUND_CLOSEST(fsl_get_sys_freq(), freq);
+ pxclk = clamp_t(u32, pxclk, 2, pxckmax);
+
+ out_be32(data->pixelclk_reg, 0);
+ out_be32(data->pixelclk_reg, PIXCLKCR_PXCKEN
+ | pxclkdl_dir | (pxclk << 16) | pxclk_delay);
+}
+
static void update_lcdc(struct fb_info *info)
{
struct fb_var_screeninfo *var = &info->var;
@@ -846,7 +881,13 @@ static void update_lcdc(struct fb_info *info)
out_be32(&hw->vsyn_para, temp);
- diu_ops.set_pixel_clock(var->pixclock);
+ /* If the pixel clock setting function can not be used on the platform,
+ * then use the platform one.
+ */
+ if (diu_ops.set_pixel_clock)
+ diu_ops.set_pixel_clock(var->pixclock);
+ else
+ set_pixel_clock(data, var->pixclock);
#ifndef CONFIG_PPC_MPC512x
/*
@@ -1752,6 +1793,22 @@ static int fsl_diu_probe(struct platform_device *pdev)
goto error;
}
+ if (!diu_ops.set_pixel_clock) {
+ data->pixelclk_reg = of_iomap(np, 1);
+ if (!data->pixelclk_reg) {
+ dev_err(&pdev->dev, "Cannot map pixelclk registers, please \
+ provide the diu_ops for pixclk setting instead.\n");
+ ret = -EFAULT;
+ goto error;
+ }
+ /*Get the pixclkcr settings: PXCKDLYDIR; MAXPXCK, PXCKDLY*/
+ ret = of_property_read_u32_array(np, "pixclk", data->pixclkcr, 3);
+ if (ret) {
+ dev_err(&pdev->dev, "Cannot get pixelclk registers information.\n");
+ goto error;
+ }
+ }
+
/* Get the IRQ of the DIU */
data->irq = irq_of_parse_and_map(np, 0);
--
1.8.0
^ permalink raw reply related
* [PATCH 1/1] video: imxfb: Driver depends on status of LCD class device
From: Gaëtan Carlier @ 2014-03-27 15:20 UTC (permalink / raw)
To: linux-fbdev
If LCD_CLASS_DEVICE is disabled, symbol devm_lcd_device_register is
undefined
Signed-off-by: Gaëtan Carlier <gcembed@gmail.com>
---
drivers/video/fbdev/imxfb.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
index f6e6216..b979b61 100644
--- a/drivers/video/fbdev/imxfb.c
+++ b/drivers/video/fbdev/imxfb.c
@@ -30,7 +30,9 @@
#include <linux/platform_device.h>
#include <linux/dma-mapping.h>
#include <linux/io.h>
+#ifdef CONFIG_LCD_CLASS_DEVICE
#include <linux/lcd.h>
+#endif
#include <linux/math64.h>
#include <linux/of.h>
#include <linux/of_device.h>
@@ -718,6 +720,7 @@ static int imxfb_of_read_mode(struct device *dev, struct device_node *np,
return 0;
}
+#ifdef CONFIG_LCD_CLASS_DEVICE
static int imxfb_lcd_check_fb(struct lcd_device *lcddev, struct fb_info *fi)
{
struct imxfb_info *fbi = dev_get_drvdata(&lcddev->dev);
@@ -785,6 +788,7 @@ static struct lcd_ops imxfb_lcd_ops = {
.get_power = imxfb_lcd_get_power,
.set_power = imxfb_lcd_set_power,
};
+#endif
static int imxfb_setup(void)
{
@@ -809,7 +813,9 @@ static int imxfb_setup(void)
static int imxfb_probe(struct platform_device *pdev)
{
struct imxfb_info *fbi;
+#ifdef CONFIG_LCD_CLASS_DEVICE
struct lcd_device *lcd;
+#endif
struct fb_info *info;
struct imx_fb_platform_data *pdata;
struct resource *res;
@@ -967,6 +973,7 @@ static int imxfb_probe(struct platform_device *pdev)
goto failed_lcd;
}
+#ifdef CONFIG_LCD_CLASS_DEVICE
lcd = devm_lcd_device_register(&pdev->dev, "imxfb-lcd", &pdev->dev, fbi,
&imxfb_lcd_ops);
if (IS_ERR(lcd)) {
@@ -975,6 +982,7 @@ static int imxfb_probe(struct platform_device *pdev)
}
lcd->props.max_contrast = 0xff;
+#endif
imxfb_enable_controller(fbi);
fbi->pdev = pdev;
--
1.7.7.4
^ permalink raw reply related
* Re: [PATCH 15/16] leds: atmel-pwm: remove obsolete driver
From: Bryan Wu @ 2014-03-27 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1395234209-15546-16-git-send-email-alexandre.belloni@free-electrons.com>
On Wed, Mar 19, 2014 at 6:03 AM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
> The leds-atmel-pwmdriver is now obsolete. It is not used by any mainlined boards
> and is replaced by the generic leds_pwm with the pawm-atmel driver using the
> generic PWM framework.
>
Good to remove.
Acked-by: Bryan Wu <cooloney@gmail.com>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
> drivers/leds/Kconfig | 8 ---
> drivers/leds/Makefile | 1 -
> drivers/leds/leds-atmel-pwm.c | 149 ------------------------------------------
> 3 files changed, 158 deletions(-)
> delete mode 100644 drivers/leds/leds-atmel-pwm.c
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 72156c123033..e7aca5f1e396 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -32,14 +32,6 @@ config LEDS_88PM860X
> This option enables support for on-chip LED drivers found on Marvell
> Semiconductor 88PM8606 PMIC.
>
> -config LEDS_ATMEL_PWM
> - tristate "LED Support using Atmel PWM outputs"
> - depends on LEDS_CLASS
> - depends on ATMEL_PWM
> - help
> - This option enables support for LEDs driven using outputs
> - of the dedicated PWM controller found on newer Atmel SOCs.
> -
> config LEDS_LM3530
> tristate "LCD Backlight driver for LM3530"
> depends on LEDS_CLASS
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 3cd76dbd9be2..6ee06559db45 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -6,7 +6,6 @@ obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o
>
> # LED Platform Drivers
> obj-$(CONFIG_LEDS_88PM860X) += leds-88pm860x.o
> -obj-$(CONFIG_LEDS_ATMEL_PWM) += leds-atmel-pwm.o
> obj-$(CONFIG_LEDS_BD2802) += leds-bd2802.o
> obj-$(CONFIG_LEDS_LOCOMO) += leds-locomo.o
> obj-$(CONFIG_LEDS_LM3530) += leds-lm3530.o
> diff --git a/drivers/leds/leds-atmel-pwm.c b/drivers/leds/leds-atmel-pwm.c
> deleted file mode 100644
> index 56cec8d6a2ac..000000000000
> --- a/drivers/leds/leds-atmel-pwm.c
> +++ /dev/null
> @@ -1,149 +0,0 @@
> -#include <linux/kernel.h>
> -#include <linux/platform_device.h>
> -#include <linux/leds.h>
> -#include <linux/io.h>
> -#include <linux/atmel_pwm.h>
> -#include <linux/slab.h>
> -#include <linux/module.h>
> -
> -
> -struct pwmled {
> - struct led_classdev cdev;
> - struct pwm_channel pwmc;
> - struct gpio_led *desc;
> - u32 mult;
> - u8 active_low;
> -};
> -
> -
> -/*
> - * For simplicity, we use "brightness" as if it were a linear function
> - * of PWM duty cycle. However, a logarithmic function of duty cycle is
> - * probably a better match for perceived brightness: two is half as bright
> - * as four, four is half as bright as eight, etc
> - */
> -static void pwmled_brightness(struct led_classdev *cdev, enum led_brightness b)
> -{
> - struct pwmled *led;
> -
> - /* update the duty cycle for the *next* period */
> - led = container_of(cdev, struct pwmled, cdev);
> - pwm_channel_writel(&led->pwmc, PWM_CUPD, led->mult * (unsigned) b);
> -}
> -
> -/*
> - * NOTE: we reuse the platform_data structure of GPIO leds,
> - * but repurpose its "gpio" number as a PWM channel number.
> - */
> -static int pwmled_probe(struct platform_device *pdev)
> -{
> - const struct gpio_led_platform_data *pdata;
> - struct pwmled *leds;
> - int i;
> - int status;
> -
> - pdata = dev_get_platdata(&pdev->dev);
> - if (!pdata || pdata->num_leds < 1)
> - return -ENODEV;
> -
> - leds = devm_kzalloc(&pdev->dev, pdata->num_leds * sizeof(*leds),
> - GFP_KERNEL);
> - if (!leds)
> - return -ENOMEM;
> -
> - for (i = 0; i < pdata->num_leds; i++) {
> - struct pwmled *led = leds + i;
> - const struct gpio_led *dat = pdata->leds + i;
> - u32 tmp;
> -
> - led->cdev.name = dat->name;
> - led->cdev.brightness = LED_OFF;
> - led->cdev.brightness_set = pwmled_brightness;
> - led->cdev.default_trigger = dat->default_trigger;
> -
> - led->active_low = dat->active_low;
> -
> - status = pwm_channel_alloc(dat->gpio, &led->pwmc);
> - if (status < 0)
> - goto err;
> -
> - /*
> - * Prescale clock by 2^x, so PWM counts in low MHz.
> - * Start each cycle with the LED active, so increasing
> - * the duty cycle gives us more time on (= brighter).
> - */
> - tmp = 5;
> - if (!led->active_low)
> - tmp |= PWM_CPR_CPOL;
> - pwm_channel_writel(&led->pwmc, PWM_CMR, tmp);
> -
> - /*
> - * Pick a period so PWM cycles at 100+ Hz; and a multiplier
> - * for scaling duty cycle: brightness * mult.
> - */
> - tmp = (led->pwmc.mck / (1 << 5)) / 100;
> - tmp /= 255;
> - led->mult = tmp;
> - pwm_channel_writel(&led->pwmc, PWM_CDTY,
> - led->cdev.brightness * 255);
> - pwm_channel_writel(&led->pwmc, PWM_CPRD,
> - LED_FULL * tmp);
> -
> - pwm_channel_enable(&led->pwmc);
> -
> - /* Hand it over to the LED framework */
> - status = led_classdev_register(&pdev->dev, &led->cdev);
> - if (status < 0) {
> - pwm_channel_free(&led->pwmc);
> - goto err;
> - }
> - }
> -
> - platform_set_drvdata(pdev, leds);
> - return 0;
> -
> -err:
> - if (i > 0) {
> - for (i = i - 1; i >= 0; i--) {
> - led_classdev_unregister(&leds[i].cdev);
> - pwm_channel_free(&leds[i].pwmc);
> - }
> - }
> -
> - return status;
> -}
> -
> -static int pwmled_remove(struct platform_device *pdev)
> -{
> - const struct gpio_led_platform_data *pdata;
> - struct pwmled *leds;
> - unsigned i;
> -
> - pdata = dev_get_platdata(&pdev->dev);
> - leds = platform_get_drvdata(pdev);
> -
> - for (i = 0; i < pdata->num_leds; i++) {
> - struct pwmled *led = leds + i;
> -
> - led_classdev_unregister(&led->cdev);
> - pwm_channel_free(&led->pwmc);
> - }
> -
> - return 0;
> -}
> -
> -static struct platform_driver pwmled_driver = {
> - .driver = {
> - .name = "leds-atmel-pwm",
> - .owner = THIS_MODULE,
> - },
> - /* REVISIT add suspend() and resume() methods */
> - .probe = pwmled_probe,
> - .remove = pwmled_remove,
> -};
> -
> -module_platform_driver(pwmled_driver);
> -
> -MODULE_DESCRIPTION("Driver for LEDs with PWM-controlled brightness");
> -MODULE_LICENSE("GPL");
> -MODULE_ALIAS("platform:leds-atmel-pwm");
> --
> 1.8.3.2
>
^ permalink raw reply
* Re: [PATCH 00/16] move at91 and avr32 to the PWM framework, remove obsolete drivers
From: Nicolas Ferre @ 2014-03-27 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1395234209-15546-1-git-send-email-alexandre.belloni@free-electrons.com>
On 19/03/2014 14:03, Alexandre Belloni :
> Hi,
>
> This patch set swtiches the at91 and avr32 SoCs and board to the generic PWM
> framework. This allows to remove the obsolete leds-atmel-pwm, atmel-pwm-bl and
> atmel_pwm drivers.
>
> The first 6 patches take care of the AT91 boards and removes a useless function
> in the process.
>
> Patch 7 makes pwm-ateml buildable for AVR32
>
> Patch 8 allows setting the pwm polarity for pwm_bl when using platform data.
> This is required afterwards for the favr-32
>
> Patches 9-13 take care of the AVR32 boards. This has only been compile tested as
> I don't own any of those boards.
>
> And the last 3 patches are removing the now obsolete drivers.
>
> As a note, the atmel_pwm driver has two features not yet available through
> pwm-atmel:
> - it is possible to pass an IRQ handler that will get called each time one of
> the channel period has been acheived.
> - it was possible to set clka and clkb, two clock that divided mck before
> feeding the pwm controller.
>
> Those features are not used by anything in the mainline. I'm not sure we can
> implement the first one. We'll get back the second one once all the boards have
> swtiched to the common clock framework.
>
>
> Alexandre Belloni (16):
> ARM: at91: at91sam9g45: switch to generic PWM framework
> ARM: at91: sam9m10g45ek: use generic leds_pwm driver
> ARM: at91: at91sam9263: switch to generic PWM framework
> ARM: at91: sam9263ek: use generic leds_pwm driver
> ARM: at91: at91sam9rl: switch to generic PWM framework
> ARM: at91: remove useless at91_pwm_leds()
> PWM: atmel: allow building for AVR32
> backlight: pwm_bl: set pwm polarity when using platform data
> avr32/at32ap: switch to the generic PWM framework
> avr32: MRMT: use generic leds_pwm driver
> avr32: merisc: use generic leds_pwm driver
> avr32: favr-32: use generic pwm_bl driver
> avr32: update defconfig to use the generic PWM framework
> backlight: atmel-pwm-bl: remove obsolete driver
> leds: atmel-pwm: remove obsolete driver
> misc: atmel_pwm: remove obsolete driver
I am fine with the whole series. For the AT91 specific bits, you can add my:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
It is a very nice cleanup and I can take the series with me in the AT91
git tree (likely the at91-3.16-cleanup or at91-3.16-drivers branch) if
everybody agree.
Bye,
> arch/arm/mach-at91/at91sam9263.c | 1 +
> arch/arm/mach-at91/at91sam9263_devices.c | 11 +-
> arch/arm/mach-at91/at91sam9g45.c | 1 +
> arch/arm/mach-at91/at91sam9g45_devices.c | 11 +-
> arch/arm/mach-at91/at91sam9rl.c | 1 +
> arch/arm/mach-at91/at91sam9rl_devices.c | 11 +-
> arch/arm/mach-at91/board-sam9263ek.c | 56 +++-
> arch/arm/mach-at91/board-sam9m10g45ek.c | 43 ++-
> arch/arm/mach-at91/board.h | 1 -
> arch/arm/mach-at91/leds.c | 37 ---
> arch/avr32/boards/atngw100/mrmt.c | 35 ++-
> arch/avr32/boards/favr-32/setup.c | 49 ++--
> arch/avr32/boards/merisc/setup.c | 34 ++-
> arch/avr32/configs/atngw100_mrmt_defconfig | 5 +-
> arch/avr32/configs/atstk1002_defconfig | 5 +-
> arch/avr32/configs/atstk1003_defconfig | 5 +-
> arch/avr32/configs/atstk1004_defconfig | 5 +-
> arch/avr32/configs/atstk1006_defconfig | 5 +-
> arch/avr32/configs/favr-32_defconfig | 6 +-
> arch/avr32/configs/merisc_defconfig | 5 +-
> arch/avr32/mach-at32ap/at32ap700x.c | 7 +-
> drivers/leds/Kconfig | 8 -
> drivers/leds/Makefile | 1 -
> drivers/leds/leds-atmel-pwm.c | 149 -----------
> drivers/misc/Kconfig | 9 -
> drivers/misc/Makefile | 1 -
> drivers/misc/atmel_pwm.c | 402 -----------------------------
> drivers/pwm/Kconfig | 2 +-
> drivers/video/backlight/Kconfig | 11 -
> drivers/video/backlight/Makefile | 1 -
> drivers/video/backlight/atmel-pwm-bl.c | 223 ----------------
> drivers/video/backlight/pwm_bl.c | 8 +
> include/linux/atmel-pwm-bl.h | 43 ---
> include/linux/atmel_pwm.h | 70 -----
> include/linux/pwm_backlight.h | 1 +
> 35 files changed, 199 insertions(+), 1064 deletions(-)
> delete mode 100644 drivers/leds/leds-atmel-pwm.c
> delete mode 100644 drivers/misc/atmel_pwm.c
> delete mode 100644 drivers/video/backlight/atmel-pwm-bl.c
> delete mode 100644 include/linux/atmel-pwm-bl.h
> delete mode 100644 include/linux/atmel_pwm.h
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 00/16] move at91 and avr32 to the PWM framework, remove obsolete drivers
From: Alexandre Belloni @ 2014-03-27 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5334633E.6050708@atmel.com>
Hi,
On 27/03/2014 at 18:43:26 +0100, Nicolas Ferre wrote :
> On 19/03/2014 14:03, Alexandre Belloni :
> > Alexandre Belloni (16):
> > ARM: at91: at91sam9g45: switch to generic PWM framework
> > ARM: at91: sam9m10g45ek: use generic leds_pwm driver
> > ARM: at91: at91sam9263: switch to generic PWM framework
> > ARM: at91: sam9263ek: use generic leds_pwm driver
> > ARM: at91: at91sam9rl: switch to generic PWM framework
> > ARM: at91: remove useless at91_pwm_leds()
> > PWM: atmel: allow building for AVR32
> > backlight: pwm_bl: set pwm polarity when using platform data
Please wait for Thierry Reding to comment on this one...
> > avr32/at32ap: switch to the generic PWM framework
> > avr32: MRMT: use generic leds_pwm driver
> > avr32: merisc: use generic leds_pwm driver
> > avr32: favr-32: use generic pwm_bl driver
> > avr32: update defconfig to use the generic PWM framework
> > backlight: atmel-pwm-bl: remove obsolete driver
> > leds: atmel-pwm: remove obsolete driver
...watch out for the small typo (pawm-atmel) I made there...
> > misc: atmel_pwm: remove obsolete driver
>
> I am fine with the whole series. For the AT91 specific bits, you can add my:
>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> It is a very nice cleanup and I can take the series with me in the AT91
> git tree (likely the at91-3.16-cleanup or at91-3.16-drivers branch) if
> everybody agree.
>
... but I believe you can take it through your tree as it mostly depends
on AT91 and Hans-Christian seemed fine with the modifications on avr32.
Regards,
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/2] backlight: platform_lcd: Remove DT compatibility string
From: Alexander Shiyan @ 2014-03-29 10:00 UTC (permalink / raw)
To: linux-fbdev
Driver is written for using platform callback functions and it cannot
be used without these functions, so having "platform-lcd" in the device
tree do nothing. This patch removes DT compatibility string.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
---
drivers/video/backlight/platform_lcd.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/drivers/video/backlight/platform_lcd.c b/drivers/video/backlight/platform_lcd.c
index c3d2e20..4afc21f 100644
--- a/drivers/video/backlight/platform_lcd.c
+++ b/drivers/video/backlight/platform_lcd.c
@@ -16,8 +16,6 @@
#include <linux/fb.h>
#include <linux/backlight.h>
#include <linux/lcd.h>
-#include <linux/of.h>
-#include <linux/slab.h>
#include <video/platform_lcd.h>
@@ -137,20 +135,11 @@ static int platform_lcd_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(platform_lcd_pm_ops, platform_lcd_suspend,
platform_lcd_resume);
-#ifdef CONFIG_OF
-static const struct of_device_id platform_lcd_of_match[] = {
- { .compatible = "platform-lcd" },
- {},
-};
-MODULE_DEVICE_TABLE(of, platform_lcd_of_match);
-#endif
-
static struct platform_driver platform_lcd_driver = {
.driver = {
.name = "platform-lcd",
.owner = THIS_MODULE,
.pm = &platform_lcd_pm_ops,
- .of_match_table = of_match_ptr(platform_lcd_of_match),
},
.probe = platform_lcd_probe,
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/2] backlight: platform_lcd: Remove #ifdef CONFIG_PM_SLEEP
From: Alexander Shiyan @ 2014-03-29 10:00 UTC (permalink / raw)
To: linux-fbdev
This patch removes #ifdef CONFIG_PM_SLEEP to improve compile coverage.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
---
drivers/video/backlight/platform_lcd.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/platform_lcd.c b/drivers/video/backlight/platform_lcd.c
index 4afc21f..986f46a 100644
--- a/drivers/video/backlight/platform_lcd.c
+++ b/drivers/video/backlight/platform_lcd.c
@@ -110,8 +110,7 @@ static int platform_lcd_probe(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM_SLEEP
-static int platform_lcd_suspend(struct device *dev)
+static int __maybe_unused platform_lcd_suspend(struct device *dev)
{
struct platform_lcd *plcd = dev_get_drvdata(dev);
@@ -121,7 +120,7 @@ static int platform_lcd_suspend(struct device *dev)
return 0;
}
-static int platform_lcd_resume(struct device *dev)
+static int __maybe_unused platform_lcd_resume(struct device *dev)
{
struct platform_lcd *plcd = dev_get_drvdata(dev);
@@ -130,7 +129,6 @@ static int platform_lcd_resume(struct device *dev)
return 0;
}
-#endif
static SIMPLE_DEV_PM_OPS(platform_lcd_pm_ops, platform_lcd_suspend,
platform_lcd_resume);
--
1.8.3.2
^ permalink raw reply related
* [PATCH] backlight: pwm_bl: Use SIMPLE_DEV_PM_OPS()
From: Alexander Shiyan @ 2014-03-29 10:11 UTC (permalink / raw)
To: linux-fbdev
Use the SIMPLE_DEV_PM_OPS() macro to declare the driver's pm_ops.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
---
drivers/video/backlight/pwm_bl.c | 17 ++++-------------
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index b75201f..d5e1f5b 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -359,8 +359,7 @@ static int pwm_backlight_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM_SLEEP
-static int pwm_backlight_suspend(struct device *dev)
+static int __maybe_unused pwm_bl_suspend(struct device *dev)
{
struct backlight_device *bl = dev_get_drvdata(dev);
struct pwm_bl_data *pb = bl_get_data(bl);
@@ -376,7 +375,7 @@ static int pwm_backlight_suspend(struct device *dev)
return 0;
}
-static int pwm_backlight_resume(struct device *dev)
+static int __maybe_unused pwm_bl_resume(struct device *dev)
{
struct backlight_device *bl = dev_get_drvdata(dev);
@@ -384,22 +383,14 @@ static int pwm_backlight_resume(struct device *dev)
return 0;
}
-#endif
-static const struct dev_pm_ops pwm_backlight_pm_ops = {
-#ifdef CONFIG_PM_SLEEP
- .suspend = pwm_backlight_suspend,
- .resume = pwm_backlight_resume,
- .poweroff = pwm_backlight_suspend,
- .restore = pwm_backlight_resume,
-#endif
-};
+static SIMPLE_DEV_PM_OPS(pwm_bl_pm_ops, pwm_bl_suspend, pwm_bl_resume);
static struct platform_driver pwm_backlight_driver = {
.driver = {
.name = "pwm-backlight",
.owner = THIS_MODULE,
- .pm = &pwm_backlight_pm_ops,
+ .pm = &pwm_bl_pm_ops,
.of_match_table = of_match_ptr(pwm_backlight_of_match),
},
.probe = pwm_backlight_probe,
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH] backlight: pwm_bl: Use SIMPLE_DEV_PM_OPS()
From: Lee Jones @ 2014-03-31 7:38 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1396087871-9091-1-git-send-email-shc_work@mail.ru>
> Use the SIMPLE_DEV_PM_OPS() macro to declare the driver's pm_ops.
>
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
> ---
> drivers/video/backlight/pwm_bl.c | 17 ++++-------------
> 1 file changed, 4 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index b75201f..d5e1f5b 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
[...]
> -static int pwm_backlight_resume(struct device *dev)
> +static int __maybe_unused pwm_bl_resume(struct device *dev)
What's the __maybe_unused attribute for?
In include/linux/compiler-gcc.h it redefines the attribute as 'unused':
#define __maybe_unused __attribute__((unused))
... are you sure this is what you want?
--
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/2] backlight: platform_lcd: Remove DT compatibility string
From: Lee Jones @ 2014-03-31 7:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1396087220-1564-1-git-send-email-shc_work@mail.ru>
> Driver is written for using platform callback functions and it cannot
> be used without these functions, so having "platform-lcd" in the device
> tree do nothing. This patch removes DT compatibility string.
>
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
> ---
> drivers/video/backlight/platform_lcd.c | 11 -----------
> 1 file changed, 11 deletions(-)
>
> diff --git a/drivers/video/backlight/platform_lcd.c b/drivers/video/backlight/platform_lcd.c
> index c3d2e20..4afc21f 100644
> --- a/drivers/video/backlight/platform_lcd.c
> +++ b/drivers/video/backlight/platform_lcd.c
> @@ -16,8 +16,6 @@
> #include <linux/fb.h>
> #include <linux/backlight.h>
> #include <linux/lcd.h>
> -#include <linux/of.h>
> -#include <linux/slab.h>
>
> #include <video/platform_lcd.h>
>
> @@ -137,20 +135,11 @@ static int platform_lcd_resume(struct device *dev)
> static SIMPLE_DEV_PM_OPS(platform_lcd_pm_ops, platform_lcd_suspend,
> platform_lcd_resume);
>
> -#ifdef CONFIG_OF
> -static const struct of_device_id platform_lcd_of_match[] = {
> - { .compatible = "platform-lcd" },
> - {},
> -};
> -MODULE_DEVICE_TABLE(of, platform_lcd_of_match);
> -#endif
> -
Rather than remove DT support, we should look into what these
call-back functions to and work to rid those instead. What exactly do
these routines provide?
> static struct platform_driver platform_lcd_driver = {
> .driver = {
> .name = "platform-lcd",
> .owner = THIS_MODULE,
> .pm = &platform_lcd_pm_ops,
> - .of_match_table = of_match_ptr(platform_lcd_of_match),
> },
> .probe = platform_lcd_probe,
> };
--
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] backlight: pwm_bl: Use SIMPLE_DEV_PM_OPS()
From: Alexander Shiyan @ 2014-03-31 7:41 UTC (permalink / raw)
To: linux-fbdev
TW9uLCAzMSBNYXIgMjAxNCAwODozODo0OCArMDEwMCDQvtGCIExlZSBKb25lcyA8bGVlLmpvbmVz
QGxpbmFyby5vcmc+Ogo+ID4gVXNlIHRoZSBTSU1QTEVfREVWX1BNX09QUygpIG1hY3JvIHRvIGRl
Y2xhcmUgdGhlIGRyaXZlcidzIHBtX29wcy4KPiA+IAo+ID4gU2lnbmVkLW9mZi1ieTogQWxleGFu
ZGVyIFNoaXlhbiA8c2hjX3dvcmtAbWFpbC5ydT4KPiA+IC0tLQo+ID4gIGRyaXZlcnMvdmlkZW8v
YmFja2xpZ2h0L3B3bV9ibC5jIHwgMTcgKysrKy0tLS0tLS0tLS0tLS0KPiA+ICAxIGZpbGUgY2hh
bmdlZCwgNCBpbnNlcnRpb25zKCspLCAxMyBkZWxldGlvbnMoLSkKPiA+IAo+ID4gZGlmZiAtLWdp
dCBhL2RyaXZlcnMvdmlkZW8vYmFja2xpZ2h0L3B3bV9ibC5jIGIvZHJpdmVycy92aWRlby9iYWNr
bGlnaHQvcHdtX2JsLmMKPiA+IGluZGV4IGI3NTIwMWYuLmQ1ZTFmNWIgMTAwNjQ0Cj4gPiAtLS0g
YS9kcml2ZXJzL3ZpZGVvL2JhY2tsaWdodC9wd21fYmwuYwo+ID4gKysrIGIvZHJpdmVycy92aWRl
by9iYWNrbGlnaHQvcHdtX2JsLmMKPiAKPiBbLi4uXQo+IAo+ID4gLXN0YXRpYyBpbnQgcHdtX2Jh
Y2tsaWdodF9yZXN1bWUoc3RydWN0IGRldmljZSAqZGV2KQo+ID4gK3N0YXRpYyBpbnQgX19tYXli
ZV91bnVzZWQgcHdtX2JsX3Jlc3VtZShzdHJ1Y3QgZGV2aWNlICpkZXYpCj4gCj4gV2hhdCdzIHRo
ZSBfX21heWJlX3VudXNlZCBhdHRyaWJ1dGUgZm9yPwo+IAo+IEluIGluY2x1ZGUvbGludXgvY29t
cGlsZXItZ2NjLmggaXQgcmVkZWZpbmVzIHRoZSBhdHRyaWJ1dGUgYXMgJ3VudXNlZCc6IAo+IAo+
ICAgI2RlZmluZSBfX21heWJlX3VudXNlZCAgICAgICAgICAgICAgICAgIF9fYXR0cmlidXRlX18o
KHVudXNlZCkpCj4gCj4gLi4uIGFyZSB5b3Ugc3VyZSB0aGlzIGlzIHdoYXQgeW91IHdhbnQ/CgpZ
ZXMuIFRoaXMgYXZvaWRzIGNvbXBpbGVyIHdhcm5pbmdzIGlmIENPTkZJR19QTSBpcyB1bnNldC4K
Ci0tLQoK
^ permalink raw reply
* Re: [PATCH 2/2] backlight: platform_lcd: Remove #ifdef CONFIG_PM_SLEEP
From: Lee Jones @ 2014-03-31 7:43 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1396087220-1564-2-git-send-email-shc_work@mail.ru>
> This patch removes #ifdef CONFIG_PM_SLEEP to improve compile coverage.
Compile coverage would improve if we removed all in-file CONFIG
stipulations, but that's not helpful. What's the reason for removing
them in this case?
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
> ---
> drivers/video/backlight/platform_lcd.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/backlight/platform_lcd.c b/drivers/video/backlight/platform_lcd.c
> index 4afc21f..986f46a 100644
> --- a/drivers/video/backlight/platform_lcd.c
> +++ b/drivers/video/backlight/platform_lcd.c
> @@ -110,8 +110,7 @@ static int platform_lcd_probe(struct platform_device *pdev)
> return 0;
> }
>
> -#ifdef CONFIG_PM_SLEEP
> -static int platform_lcd_suspend(struct device *dev)
> +static int __maybe_unused platform_lcd_suspend(struct device *dev)
> {
> struct platform_lcd *plcd = dev_get_drvdata(dev);
>
> @@ -121,7 +120,7 @@ static int platform_lcd_suspend(struct device *dev)
> return 0;
> }
>
> -static int platform_lcd_resume(struct device *dev)
> +static int __maybe_unused platform_lcd_resume(struct device *dev)
> {
> struct platform_lcd *plcd = dev_get_drvdata(dev);
>
> @@ -130,7 +129,6 @@ static int platform_lcd_resume(struct device *dev)
>
> return 0;
> }
> -#endif
>
> static SIMPLE_DEV_PM_OPS(platform_lcd_pm_ops, platform_lcd_suspend,
> platform_lcd_resume);
--
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] backlight: pwm_bl: Use SIMPLE_DEV_PM_OPS()
From: Lee Jones @ 2014-03-31 8:16 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1396087871-9091-1-git-send-email-shc_work@mail.ru>
> > > Use the SIMPLE_DEV_PM_OPS() macro to declare the driver's pm_ops.
> > >
> > > Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
> > > ---
> > > drivers/video/backlight/pwm_bl.c | 17 ++++-------------
> > > 1 file changed, 4 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> > > index b75201f..d5e1f5b 100644
> > > --- a/drivers/video/backlight/pwm_bl.c
> > > +++ b/drivers/video/backlight/pwm_bl.c
> >
> > [...]
> >
> > > -static int pwm_backlight_resume(struct device *dev)
> > > +static int __maybe_unused pwm_bl_resume(struct device *dev)
> >
> > What's the __maybe_unused attribute for?
> >
> > In include/linux/compiler-gcc.h it redefines the attribute as 'unused':
> >
> > #define __maybe_unused __attribute__((unused))
> >
> > ... are you sure this is what you want?
>
> Yes. This avoids compiler warnings if CONFIG_PM is unset.
What are the advantages of this over the config option? Besides 2
lines of code?
--
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] backlight: pwm_bl: Use SIMPLE_DEV_PM_OPS()
From: Alexander Shiyan @ 2014-03-31 8:18 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1396251711.522321843@f325.i.mail.ru>
TW9uLCAzMSBNYXIgMjAxNCAwOToxNjozOCArMDEwMCDQvtGCIExlZSBKb25lcyA8bGVlLmpvbmVz
QGxpbmFyby5vcmc+Ogo+ID4gPiA+IFVzZSB0aGUgU0lNUExFX0RFVl9QTV9PUFMoKSBtYWNybyB0
byBkZWNsYXJlIHRoZSBkcml2ZXIncyBwbV9vcHMuCj4gPiA+ID4gCj4gPiA+ID4gU2lnbmVkLW9m
Zi1ieTogQWxleGFuZGVyIFNoaXlhbiA8c2hjX3dvcmtAbWFpbC5ydT4KPiA+ID4gPiAtLS0KPiA+
ID4gPiAgZHJpdmVycy92aWRlby9iYWNrbGlnaHQvcHdtX2JsLmMgfCAxNyArKysrLS0tLS0tLS0t
LS0tLQo+ID4gPiA+ICAxIGZpbGUgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspLCAxMyBkZWxldGlv
bnMoLSkKPiA+ID4gPiAKPiA+ID4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy92aWRlby9iYWNrbGln
aHQvcHdtX2JsLmMgYi9kcml2ZXJzL3ZpZGVvL2JhY2tsaWdodC9wd21fYmwuYwo+ID4gPiA+IGlu
ZGV4IGI3NTIwMWYuLmQ1ZTFmNWIgMTAwNjQ0Cj4gPiA+ID4gLS0tIGEvZHJpdmVycy92aWRlby9i
YWNrbGlnaHQvcHdtX2JsLmMKPiA+ID4gPiArKysgYi9kcml2ZXJzL3ZpZGVvL2JhY2tsaWdodC9w
d21fYmwuYwo+ID4gPiAKPiA+ID4gWy4uLl0KPiA+ID4gCj4gPiA+ID4gLXN0YXRpYyBpbnQgcHdt
X2JhY2tsaWdodF9yZXN1bWUoc3RydWN0IGRldmljZSAqZGV2KQo+ID4gPiA+ICtzdGF0aWMgaW50
IF9fbWF5YmVfdW51c2VkIHB3bV9ibF9yZXN1bWUoc3RydWN0IGRldmljZSAqZGV2KQo+ID4gPiAK
PiA+ID4gV2hhdCdzIHRoZSBfX21heWJlX3VudXNlZCBhdHRyaWJ1dGUgZm9yPwo+ID4gPiAKPiA+
ID4gSW4gaW5jbHVkZS9saW51eC9jb21waWxlci1nY2MuaCBpdCByZWRlZmluZXMgdGhlIGF0dHJp
YnV0ZSBhcyAndW51c2VkJzogCj4gPiA+IAo+ID4gPiAgICNkZWZpbmUgX19tYXliZV91bnVzZWQg
ICAgICAgICAgICAgICAgICBfX2F0dHJpYnV0ZV9fKCh1bnVzZWQpKQo+ID4gPiAKPiA+ID4gLi4u
IGFyZSB5b3Ugc3VyZSB0aGlzIGlzIHdoYXQgeW91IHdhbnQ/Cj4gPiAKPiA+IFllcy4gVGhpcyBh
dm9pZHMgY29tcGlsZXIgd2FybmluZ3MgaWYgQ09ORklHX1BNIGlzIHVuc2V0Lgo+IAo+IFdoYXQg
YXJlIHRoZSBhZHZhbnRhZ2VzIG9mIHRoaXMgb3ZlciB0aGUgY29uZmlnIG9wdGlvbj8gQmVzaWRl
cyAyCj4gbGluZXMgb2YgY29kZT8KCkp1c3QgYW4gaW5jcmVhc2UgY29tcGlsZSBjb3ZlcmFnZS4K
Ci0tLQoK
^ permalink raw reply
* Re: [PATCH] backlight: pwm_bl: Use SIMPLE_DEV_PM_OPS()
From: Lee Jones @ 2014-03-31 8:50 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1396087871-9091-1-git-send-email-shc_work@mail.ru>
> > > > > Use the SIMPLE_DEV_PM_OPS() macro to declare the driver's pm_ops.
> > > > >
> > > > > Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
> > > > > ---
> > > > > drivers/video/backlight/pwm_bl.c | 17 ++++-------------
> > > > > 1 file changed, 4 insertions(+), 13 deletions(-)
> > > > >
> > > > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> > > > > index b75201f..d5e1f5b 100644
> > > > > --- a/drivers/video/backlight/pwm_bl.c
> > > > > +++ b/drivers/video/backlight/pwm_bl.c
> > > >
> > > > [...]
> > > >
> > > > > -static int pwm_backlight_resume(struct device *dev)
> > > > > +static int __maybe_unused pwm_bl_resume(struct device *dev)
> > > >
> > > > What's the __maybe_unused attribute for?
> > > >
> > > > In include/linux/compiler-gcc.h it redefines the attribute as 'unused':
> > > >
> > > > #define __maybe_unused __attribute__((unused))
> > > >
> > > > ... are you sure this is what you want?
> > >
> > > Yes. This avoids compiler warnings if CONFIG_PM is unset.
> >
> > What are the advantages of this over the config option? Besides 2
> > lines of code?
>
> Just an increase compile coverage.
What does this mean? I replied to another one of your patches with the
same question.
--
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] backlight: pwm_bl: Use SIMPLE_DEV_PM_OPS()
From: Alexander Shiyan @ 2014-03-31 10:36 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1396251711.522321843@f325.i.mail.ru>
TW9uLCAzMSBNYXIgMjAxNCAwOTo1MDo0NyArMDEwMCDQvtGCIExlZSBKb25lcyA8bGVlLmpvbmVz
QGxpbmFyby5vcmc+Ogo+ID4gPiA+ID4gPiBVc2UgdGhlIFNJTVBMRV9ERVZfUE1fT1BTKCkgbWFj
cm8gdG8gZGVjbGFyZSB0aGUgZHJpdmVyJ3MgcG1fb3BzLgo+ID4gPiA+ID4gPiAKPiA+ID4gPiA+
ID4gU2lnbmVkLW9mZi1ieTogQWxleGFuZGVyIFNoaXlhbiA8c2hjX3dvcmtAbWFpbC5ydT4KPiA+
ID4gPiA+ID4gLS0tCj4gPiA+ID4gPiA+ICBkcml2ZXJzL3ZpZGVvL2JhY2tsaWdodC9wd21fYmwu
YyB8IDE3ICsrKystLS0tLS0tLS0tLS0tCj4gPiA+ID4gPiA+ICAxIGZpbGUgY2hhbmdlZCwgNCBp
bnNlcnRpb25zKCspLCAxMyBkZWxldGlvbnMoLSkKPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+IGRp
ZmYgLS1naXQgYS9kcml2ZXJzL3ZpZGVvL2JhY2tsaWdodC9wd21fYmwuYyBiL2RyaXZlcnMvdmlk
ZW8vYmFja2xpZ2h0L3B3bV9ibC5jCj4gPiA+ID4gPiA+IGluZGV4IGI3NTIwMWYuLmQ1ZTFmNWIg
MTAwNjQ0Cj4gPiA+ID4gPiA+IC0tLSBhL2RyaXZlcnMvdmlkZW8vYmFja2xpZ2h0L3B3bV9ibC5j
Cj4gPiA+ID4gPiA+ICsrKyBiL2RyaXZlcnMvdmlkZW8vYmFja2xpZ2h0L3B3bV9ibC5jCj4gPiA+
ID4gPiAKPiA+ID4gPiA+IFsuLi5dCj4gPiA+ID4gPiAKPiA+ID4gPiA+ID4gLXN0YXRpYyBpbnQg
cHdtX2JhY2tsaWdodF9yZXN1bWUoc3RydWN0IGRldmljZSAqZGV2KQo+ID4gPiA+ID4gPiArc3Rh
dGljIGludCBfX21heWJlX3VudXNlZCBwd21fYmxfcmVzdW1lKHN0cnVjdCBkZXZpY2UgKmRldikK
PiA+ID4gPiA+IAo+ID4gPiA+ID4gV2hhdCdzIHRoZSBfX21heWJlX3VudXNlZCBhdHRyaWJ1dGUg
Zm9yPwo+ID4gPiA+ID4gCj4gPiA+ID4gPiBJbiBpbmNsdWRlL2xpbnV4L2NvbXBpbGVyLWdjYy5o
IGl0IHJlZGVmaW5lcyB0aGUgYXR0cmlidXRlIGFzICd1bnVzZWQnOiAKPiA+ID4gPiA+IAo+ID4g
PiA+ID4gICAjZGVmaW5lIF9fbWF5YmVfdW51c2VkICAgICAgICAgICAgICAgICAgX19hdHRyaWJ1
dGVfXygodW51c2VkKSkKPiA+ID4gPiA+IAo+ID4gPiA+ID4gLi4uIGFyZSB5b3Ugc3VyZSB0aGlz
IGlzIHdoYXQgeW91IHdhbnQ/Cj4gPiA+ID4gCj4gPiA+ID4gWWVzLiBUaGlzIGF2b2lkcyBjb21w
aWxlciB3YXJuaW5ncyBpZiBDT05GSUdfUE0gaXMgdW5zZXQuCj4gPiA+IAo+ID4gPiBXaGF0IGFy
ZSB0aGUgYWR2YW50YWdlcyBvZiB0aGlzIG92ZXIgdGhlIGNvbmZpZyBvcHRpb24/IEJlc2lkZXMg
Mgo+ID4gPiBsaW5lcyBvZiBjb2RlPwo+ID4gCj4gPiBKdXN0IGFuIGluY3JlYXNlIGNvbXBpbGUg
Y292ZXJhZ2UuCj4gCj4gV2hhdCBkb2VzIHRoaXMgbWVhbj8gSSByZXBsaWVkIHRvIGFub3RoZXIg
b25lIG9mIHlvdXIgcGF0Y2hlcyB3aXRoIHRoZQo+IHNhbWUgcXVlc3Rpb24uCgpDb2RlIHBhcnRz
IGZvciBzdXNwZW5kKCkgYW5kIHJlc3VtZSgpIHdpbGwgYmUgY29tcGlsZWQgcmVnYXJkbGVzcyBv
ZgpDT05GSUdfUE0gb3B0aW9uIGFuZCB3aWxsIGJlIGRpc2NhcmRlZCBieSBsaW5rZXIgaWYgQ09O
RklHX1BNIGlzIG5vdCBzZXQuCgotLS0KCg=
^ permalink raw reply
* Re: [PATCH] backlight: pwm_bl: Use SIMPLE_DEV_PM_OPS()
From: Jingoo Han @ 2014-04-01 0:08 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1396087871-9091-1-git-send-email-shc_work@mail.ru>
On Monday, March 31, 2014 7:37 PM, Lee Jones wrote:
> Mon, 31 Mar 2014 09:50:47 +0100 от Lee Jones <lee.jones@linaro.org>:
> > > > > > > Use the SIMPLE_DEV_PM_OPS() macro to declare the driver's pm_ops.
> > > > > > >
> > > > > > > Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
> > > > > > > ---
> > > > > > > drivers/video/backlight/pwm_bl.c | 17 ++++-------------
> > > > > > > 1 file changed, 4 insertions(+), 13 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> > > > > > > index b75201f..d5e1f5b 100644
> > > > > > > --- a/drivers/video/backlight/pwm_bl.c
> > > > > > > +++ b/drivers/video/backlight/pwm_bl.c
> > > > > >
> > > > > > [...]
> > > > > >
> > > > > > > -static int pwm_backlight_resume(struct device *dev)
> > > > > > > +static int __maybe_unused pwm_bl_resume(struct device *dev)
> > > > > >
> > > > > > What's the __maybe_unused attribute for?
> > > > > >
> > > > > > In include/linux/compiler-gcc.h it redefines the attribute as 'unused':
> > > > > >
> > > > > > #define __maybe_unused __attribute__((unused))
> > > > > >
> > > > > > ... are you sure this is what you want?
> > > > >
> > > > > Yes. This avoids compiler warnings if CONFIG_PM is unset.
> > > >
> > > > What are the advantages of this over the config option? Besides 2
> > > > lines of code?
> > >
> > > Just an increase compile coverage.
> >
> > What does this mean? I replied to another one of your patches with the
> > same question.
>
> Code parts for suspend() and resume() will be compiled regardless of
> CONFIG_PM option and will be discarded by linker if CONFIG_PM is not set.
(+cc Joe Perches, Dan Carpenter)
Original patch is
http://www.spinics.net/lists/linux-fbdev/msg14177.html
I don't think that __maybe_unused is good.
Currently, SIMPLE_DEV_PM_OPS is using "#ifdef CONFIG_PM_SLEEP" as below.
So, suspend_fn, resume_fn should be protected by "#ifdef CONFIG_PM_SLEEP".
Maybe, it is necessary to fix SET_SYSTEM_SLEEP_PM_OPS define,
in order to increase compile coverage.
./include/linux/pm.h
#define SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \
const struct dev_pm_ops name = { \
SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
}
#ifdef CONFIG_PM_SLEEP
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
.suspend = suspend_fn, \
.resume = resume_fn, \
.freeze = suspend_fn, \
.thaw = resume_fn, \
.poweroff = suspend_fn, \
.restore = resume_fn,
#else
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
#endif
Please, don’t remove "#ifdef CONFIG_PM_SLEEP".
Your patch can be modified as below:
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -386,14 +386,7 @@ static int pwm_backlight_resume(struct device *dev)
}
#endif
-static const struct dev_pm_ops pwm_backlight_pm_ops = {
-#ifdef CONFIG_PM_SLEEP
- .suspend = pwm_backlight_suspend,
- .resume = pwm_backlight_resume,
- .poweroff = pwm_backlight_suspend,
- .restore = pwm_backlight_resume,
-#endif
-};
+static SIMPLE_DEV_PM_OPS(pwm_bl_pm_ops, pwm_bl_suspend, pwm_bl_resume);
Best regards,
Jingoo Han
^ permalink raw reply
* RE: [PATCH 2/2] Make the diu driver work without board level initilization
From: Dongsheng.Wang @ 2014-04-01 2:42 UTC (permalink / raw)
To: Jason.Jin@freescale.com, Scott Wood, timur@tabi.org
Cc: linux-fbdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1395920287-5204-1-git-send-email-Jason.Jin@freescale.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTGludXhwcGMtZGV2IFtt
YWlsdG86bGludXhwcGMtZGV2LQ0KPiBib3VuY2VzK2I0MDUzND1mcmVlc2NhbGUuY29tQGxpc3Rz
Lm96bGFicy5vcmddIE9uIEJlaGFsZiBPZiBKYXNvbiBKaW4NCj4gU2VudDogVGh1cnNkYXksIE1h
cmNoIDI3LCAyMDE0IDc6MzggUE0NCj4gVG86IFdvb2QgU2NvdHQtQjA3NDIxOyB0aW11ckB0YWJp
Lm9yZw0KPiBDYzogbGludXgtZmJkZXZAdmdlci5rZXJuZWwub3JnOyBsaW51eHBwYy1kZXZAbGlz
dHMub3psYWJzLm9yZzsgTGkgWWFuZy1MZW8tDQo+IFI1ODQ3MjsgSmluIFpoZW5neGlvbmctUjY0
MTg4DQo+IFN1YmplY3Q6IFtQQVRDSCAyLzJdIE1ha2UgdGhlIGRpdSBkcml2ZXIgd29yayB3aXRo
b3V0IGJvYXJkIGxldmVsIGluaXRpbGl6YXRpb24NCj4gDQo+IFNvIGZhciB0aGUgRElVIGRyaXZl
ciBkb2VzIG5vdCBoYXZlIGEgbWVjaGFuaXNtIHRvIGRvIHRoZQ0KPiBib2FyZCBzcGVjaWZpYyBp
bml0aWFsaXphdGlvbi4gU28gb24gc29tZSBwbGF0Zm9ybXMsDQo+IHN1Y2ggYXMgUDEwMjIsIDg2
MTAgYW5kIDUxMjEsIFRoZSBib2FyZCBzcGVjaWZpYyBpbml0aWFsaXphdGlvbg0KPiBpcyBpbXBs
bWVudGVkIGluIHRoZSBwbGF0Zm9ybSBmaWxlIHN1Y2ggcDEwMjIyX2RzLg0KPiANCj4gQWN0dWFs
bHksIHRoZSBESVUgaXMgYWxyZWFkeSBpbnRpYWxpemVkIGluIHRoZSB1LWJvb3QsIHRoZSBwaW4g
c2hhcmluZw0KPiBhbmQgdGhlIHNpZ25hbCByb3V0aW5nIGFyZSBhbHNvIHNldCBpbiB1LWJvb3Qu
IFNvIHdlIGNhbiBsZXZlcmFnZSB0aGF0DQo+IGluIGtlcm5lbCBkcml2ZXIgdG8gYXZvaWQgYm9h
cmQgc2VwZWNpZmljIGluaXRpYWxpemF0aW9uLCBlc3BlY2lhbGx5DQo+IGZvciB0aGUgY29yZW5l
dCBwbGF0Zm9ybSwgd2hpY2ggaXMgdGhlIGFic3RyYWN0aW9uIGZvciBzZXJ2ZXJhbA0KPiBwbGF0
ZnJvbXMuDQo+IA0KPiBUaGUgcG90ZW50aWFsIHByb2JsZW0gaXMgdGhhdCB3aGVuIHRoZSBzeXN0
ZW0gd2FrZXVwIGZyb20gdGhlIGRlZXANCj4gc2xlZXAsIHNvbWUgcGxhdGZvcm0gc2V0dGluZ3Mg
bWF5IG5lZWQgdG8gYmUgcmUtaW5pdGlhbGl6ZWQuIFRoZSBDUExEDQo+IGFuZCBGUEdBIHNldHRp
bmdzIHdpbGwgYmUga2VwdCwgYnV0IHRoZSBwaXhlbCBjbG9jayByZWdpc3RlciB3aGljaA0KPiB1
c3VhbGx5IGxvY2F0ZSBhdCB0aGUgZ2xvYmFsIHV0aWxpdHkgc3BhY2UgbmVlZCB0byBiZSByZWlu
aXRpYWxpemVkLg0KPiANCj4gR2VuZXJhbGx5LCB0aGUgcGl4ZWwgY2xvY2sgc2V0dGluZyB3YXMg
aW1wbGVtZW50ZWQgaW4gdGhlIHBsYXRmb3JtDQo+IGZpbGUsIEJ1dCB0aGUgcGl4ZWwgY2xvY2sg
cmVnaXN0ZXIgaXRzZWxmIHNob3VsZCBiZSBwYXJ0IG9mIHRoZSBESVUNCj4gbW9kdWxlLCBBbmQg
Zm9yIFAxMDIyLDg2MTAgYW5kIFQxMDQwLCB0aGUgcGl4ZWwgY2xvY2sgcmVnaXN0ZXIgaGF2ZSB0
aGUNCj4gc2FtZSBzdHJ1Y3R1cmUsIFNvIHdlIGNhbiBjb25zaWRlciB0byBtb3ZlIHRoZSBwaXhl
bCBjbG9jayBzZXR0aW5nDQo+IGZyb20gdGhlIHBsYXRmb3JtIHRvIHRoZSBkaXUgZHJpdmVyLiBU
aGlzIHBhdGNoIHByb3ZpZGUgdGhlIG9wdGlvbnMNCj4gc2V0IHRoZSBwaXhlbCBjbG9jayBpbiB0
aGUgZGl1IGRyaXZlci4gQnV0IHRoZSBvcmlnaW5hbCBwbGF0Zm9ybSBwaXhlbA0KPiBjbG9jayBz
ZXR0aW5nIHN0aWwgY2FuIGJlIHVzZWQgZm9yIFAxMDIyLDg2MTAgYW5kIDUxMnggd2l0aG91dCBh
bnkNCj4gdXBkYXRlLiBUbyBpbXBsZW1lbnQgdGhlIHBpeGVsIGNsb2NrIHNldHRpbmcgaW4gdGhl
IGRpdSBkcml2ZXIuIHRoZQ0KPiBmb2xsb3dpbmcgdXBkYXRlIGluIHRoZSBkaXUgZHRzIG5vZGUg
d2FzIG5lZWRlZC4NCj4gZGlzcGxheTpkaXNwbGF5QDE4MDAwMCB7DQo+IAljb21wYXRpYmxlID0g
ImZzbCx0MTA0MC1kaXUiLCAiZnNsLGRpdSI7DQo+IC0JcmVnID0gPDB4MTgwMDAwIDEwMDA+Ow0K
PiArCXJlZyA9IDwweDE4MDAwMCAxMDAwIDB4ZmMwMjggND47DQo+ICsJcGl4Y2xrID0gPDAgMjU1
IDA+Ow0KPiAgCWludGVycnVwdHMgPSA8NzQgMiAwIDA+Ow0KPiB9DQo+IFRoZSAweGZjMDI4IGlz
IHRoZSBvZmZzZXQgZm9yIHBpeGVsIGNsb2NrIHJlZ2lzdGVyLiB0aGUgMyBzZWdtZW50IG9mDQo+
IHRoZSBwaXhjbGsgc3RhbmQgZm9yIHRoZSBQWENLRExZRElSLCB0aGUgbWF4IG9mIFBYQ0sgYW5k
IHRoZSBQWENLRExZDQo+IHdoaWNoIHdpbGwgYmUgdXNlZCBieSB0aGUgcGl4ZWwgY2xvY2sgcmVn
aXN0ZXIgc2V0dGluZy4NCj4gDQo+IFRoaXMgd2FzIHRlc3RlZCBvbiBUMTA0MCBwbGF0Zm9ybS4g
Rm9yIG90aGVyIHBsYXRmb3JtLCB0aGUgb3JpZ2luYWwNCj4gbm9kZSB0b2dldGhlciB3aXRoIHRo
ZSBwbGF0Zm9ybSBzZXR0aW5ncyBzdGlsbCBjYW4gd29yay4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6
IEphc29uIEppbiA8SmFzb24uSmluQGZyZWVzY2FsZS5jb20+DQo+IC0tLQ0KPiBWMjogUmVtb3Zl
IHRoZSBwaXhlbCBjbG9jayByZWdpc3RlciBzYXZpbmcgZm9yIHN1c3BlbmQuDQo+IGFkZCB0aGUg
cGl4ZWwgY2xvY2sgc2V0dGluZyBpbiBkcml2ZXIuDQo+IA0KPiAgZHJpdmVycy92aWRlby9mc2wt
ZGl1LWZiLmMgfCA2MSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
Ky0tDQo+ICAxIGZpbGUgY2hhbmdlZCwgNTkgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkN
Cj4gDQo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3ZpZGVvL2ZzbC1kaXUtZmIuYyBiL2RyaXZlcnMv
dmlkZW8vZnNsLWRpdS1mYi5jDQo+IGluZGV4IDRiYzQ3MzAuLjc5MjAzOGYgMTAwNjQ0DQo+IC0t
LSBhL2RyaXZlcnMvdmlkZW8vZnNsLWRpdS1mYi5jDQo+ICsrKyBiL2RyaXZlcnMvdmlkZW8vZnNs
LWRpdS1mYi5jDQo+IEBAIC01MCw2ICs1MCw3IEBADQo+ICAjZGVmaW5lIElOVF9QQVJFUlIJMHgw
OAkvKiBEaXNwbGF5IHBhcmFtZXRlcnMgZXJyb3IgaW50ZXJydXB0ICovDQo+ICAjZGVmaW5lIElO
VF9MU19CRl9WUwkweDEwCS8qIExpbmVzIGJlZm9yZSB2c3luYy4gaW50ZXJydXB0ICovDQo+IA0K
PiArI2RlZmluZSBQSVhDTEtDUl9QWENLRU4gMHg4MDAwMDAwMA0KPiAgLyoNCj4gICAqIExpc3Qg
b2Ygc3VwcG9ydGVkIHZpZGVvIG1vZGVzDQo+ICAgKg0KPiBAQCAtMzcyLDYgKzM3Myw4IEBAIHN0
cnVjdCBmc2xfZGl1X2RhdGEgew0KPiAgCXVuc2lnbmVkIGludCBpcnE7DQo+ICAJZW51bSBmc2xf
ZGl1X21vbml0b3JfcG9ydCBtb25pdG9yX3BvcnQ7DQo+ICAJc3RydWN0IGRpdSBfX2lvbWVtICpk
aXVfcmVnOw0KPiArCXZvaWQgX19pb21lbSAqcGl4ZWxjbGtfcmVnOw0KPiArCXUzMiBwaXhjbGtj
clszXTsNCj4gIAlzcGlubG9ja190IHJlZ19sb2NrOw0KPiAgCXU4IGR1bW15X2FvaVs0ICogNCAq
IDRdOw0KPiAgCXN0cnVjdCBkaXVfYWQgZHVtbXlfYWQgX19hbGlnbmVkKDgpOw0KPiBAQCAtNDc5
LDcgKzQ4MiwxMCBAQCBzdGF0aWMgZW51bSBmc2xfZGl1X21vbml0b3JfcG9ydCBmc2xfZGl1X25h
bWVfdG9fcG9ydChjb25zdA0KPiBjaGFyICpzKQ0KPiAgCQkJcG9ydCA9IEZTTF9ESVVfUE9SVF9E
TFZEUzsNCj4gIAl9DQo+IA0KPiAtCXJldHVybiBkaXVfb3BzLnZhbGlkX21vbml0b3JfcG9ydChw
b3J0KTsNCj4gKwlpZiAoZGl1X29wcy52YWxpZF9tb25pdG9yX3BvcnQpDQo+ICsJCXJldHVybiBk
aXVfb3BzLnZhbGlkX21vbml0b3JfcG9ydChwb3J0KTsNCj4gKwllbHNlDQpSZW1vdmUgdGhpcyAi
ZWxzZSIsIG90aGVyd2lzZSBsb29rcyBnb29kLg0KDQpSZWdhcmRzLA0KLURvbmdzaGVuZw0KPiAr
CQlyZXR1cm4gcG9ydDsNCj4gIH0NCj4gDQoNCg=
^ permalink raw reply
* RE: [PATCH 2/2] Make the diu driver work without board level initilization
From: Li.Xiubo @ 2014-04-01 2:57 UTC (permalink / raw)
To: Jason.Jin@freescale.com, Scott Wood, timur@tabi.org
Cc: linux-fbdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1395920287-5204-1-git-send-email-Jason.Jin@freescale.com>
> @@ -1752,6 +1793,22 @@ static int fsl_diu_probe(struct platform_device *pdev)
> goto error;
> }
>
> + if (!diu_ops.set_pixel_clock) {
> + data->pixelclk_reg = of_iomap(np, 1);
> + if (!data->pixelclk_reg) {
> + dev_err(&pdev->dev, "Cannot map pixelclk registers, please \
> + provide the diu_ops for pixclk setting instead.\n");
The error message should be in one line if possible, or it will hard to grep.
If cannot, should split it into two or more lines, like:
+ dev_err(&pdev->dev, "Cannot map pixelclk registers,\n"
+ "please provide the diu_ops for pixclk setting instead.\n");
Thanks,
BRs
Xiubo
^ 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