* Re: [PATCH] pwm: Call pwm_enable() before pwm_config()
From: Lars-Peter Clausen @ 2012-08-23 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <36966374.2768747.1345741025741.JavaMail.root@advansee.com>
On 08/23/2012 06:57 PM, Benoît Thébaudeau wrote:
> On Thursday, August 23, 2012 5:43:32 PM, Lars-Peter Clausen wrote:
>> On 08/23/2012 04:19 PM, Benoît Thébaudeau wrote:
>>> Some PWM drivers enable the clock of the PWM peripheral in
>>> pwm_enable(). Hence,
>>> for these drivers, a call to pwm_config() does not have any effect
>>> before
>>> pwm_enable() has been called.
>>>
>>> This patch fixes the PWM users to make sure that they call
>>> pwm_enable() before
>>> pwm_config().
>>>
>>> This fixes the first setting of brightness through sysfs that had
>>> no effect with
>>> leds-pwm and the i.MX PWM driver.
>>
>> But isn't this a bug in the PWM peripheral driver? With this change
>> the PWM
>> will start with the old settings first. While this is not so much of
>> a problem
>> for a backlight (although it might cause a short flickering) it might
>> cause
>> problems for other applications, like using the PWM pin as a timing
>> generator.
>> In my opinion it's better to fix the PWM peripheral drivers which
>> have this
>> problem instead of trying to work around it in every user of the PWM
>> API.
>
> I don't know. See my detailed description of this issue here:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/115667.html
>
> Where the bug is depends on the detailed definition of the PWM API, which I
> don't find documented anywhere.
>
> If pwm_enable() means "start PWM timer with the configured settings", then the
> bug is in the drivers. If it means "enable the PWM peripheral so that we can
> work with it", then the bug is in the PWM users.
It really is the former. See the description of pwm_enable() in drivers/pwm/core.c
>
> I don't really have time to work on this, so I suggested this patch as a simple
> solution. Otherwise, it means reworking several PWM drivers for different
> hardware that is not available to everyone for testing.
>
> If we decide to only change the i.MX PWM driver, the fix would be:
> pwm_config()
> {
> save passed config in private data;
> if (pwm enabled)
> apply passed config;
> }
>
> pwm_enable()
> {
> if (!(pwm enabled)) {
> enable pwm ip clk;
> apply config from private data;
> }
> }
Another option is to enable the clock if it is disabled when the device is
configured. E.g. that's what tegra does.
>
> If we fix only this driver, we must not forget that the same issue probably
> exists with several other PWM drivers.
>
Since this seems to be a common pattern in a number of PWM drivers it might
make sense to simply add support for enabling/disabling a clk to the pwm core.
Or maybe just use the runtime pm API for this. This probably makes even more
sense and grab a reference to the pm context when the enable() is called,
release it when disable() is called and also grab it before calling the
device's config callback and release it afterward.
- Lars
^ permalink raw reply
* Re: [PATCH] pwm: Call pwm_enable() before pwm_config()
From: Lars-Peter Clausen @ 2012-08-23 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50366464.4070801@metafoo.de>
On 08/23/2012 07:12 PM, Lars-Peter Clausen wrote:
>[...]
> Or maybe just use the runtime pm API for this. This probably makes even more
> sense and grab a reference to the pm context when the enable() is called,
> release it when disable() is called and also grab it before calling the
> device's config callback and release it afterward.
Btw. this seems to be exactly what the pwm-tiecap and pwm-tiehrpwm drivers
already do today. I'd just make that a core PWM framework feature.
^ permalink raw reply
* Re: [PATCH] pwm: Call pwm_enable() before pwm_config()
From: Thierry Reding @ 2012-08-23 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50366628.5020007@metafoo.de>
[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]
On Thu, Aug 23, 2012 at 07:19:36PM +0200, Lars-Peter Clausen wrote:
> On 08/23/2012 07:12 PM, Lars-Peter Clausen wrote:
> >[...]
> > Or maybe just use the runtime pm API for this. This probably makes even more
> > sense and grab a reference to the pm context when the enable() is called,
> > release it when disable() is called and also grab it before calling the
> > device's config callback and release it afterward.
>
> Btw. this seems to be exactly what the pwm-tiecap and pwm-tiehrpwm drivers
> already do today. I'd just make that a core PWM framework feature.
Using runtime PM for this sounds indeed like the most generic approach.
I'm not very familiar with the API, but I thought it required explicit
architecture or bus support (or the driver itself can provide hooks via
pm_ops), so it might be difficult to implement for platforms that don't
have working runtime PM support. I'll have to look into this some more.
Anyway, if we add this kind of support to the PWM core we should take it
through next first. For drivers that are currently broken, they should
be, as you said, fixed by enabling the clock before reconfiguring and
disable it after (unless the PWM is enabled) like Tegra does.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] pwm: Call pwm_enable() before pwm_config()
From: Thierry Reding @ 2012-08-23 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50366464.4070801@metafoo.de>
[-- Attachment #1: Type: text/plain, Size: 3954 bytes --]
On Thu, Aug 23, 2012 at 07:12:04PM +0200, Lars-Peter Clausen wrote:
> On 08/23/2012 06:57 PM, Benoît Thébaudeau wrote:
> > On Thursday, August 23, 2012 5:43:32 PM, Lars-Peter Clausen wrote:
> >> On 08/23/2012 04:19 PM, Benoît Thébaudeau wrote:
> >>> Some PWM drivers enable the clock of the PWM peripheral in
> >>> pwm_enable(). Hence,
> >>> for these drivers, a call to pwm_config() does not have any effect
> >>> before
> >>> pwm_enable() has been called.
> >>>
> >>> This patch fixes the PWM users to make sure that they call
> >>> pwm_enable() before
> >>> pwm_config().
> >>>
> >>> This fixes the first setting of brightness through sysfs that had
> >>> no effect with
> >>> leds-pwm and the i.MX PWM driver.
> >>
> >> But isn't this a bug in the PWM peripheral driver? With this change
> >> the PWM
> >> will start with the old settings first. While this is not so much of
> >> a problem
> >> for a backlight (although it might cause a short flickering) it might
> >> cause
> >> problems for other applications, like using the PWM pin as a timing
> >> generator.
> >> In my opinion it's better to fix the PWM peripheral drivers which
> >> have this
> >> problem instead of trying to work around it in every user of the PWM
> >> API.
> >
> > I don't know. See my detailed description of this issue here:
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/115667.html
> >
> > Where the bug is depends on the detailed definition of the PWM API, which I
> > don't find documented anywhere.
> >
> > If pwm_enable() means "start PWM timer with the configured settings", then the
> > bug is in the drivers. If it means "enable the PWM peripheral so that we can
> > work with it", then the bug is in the PWM users.
>
> It really is the former. See the description of pwm_enable() in drivers/pwm/core.c
Yes. pwm_enable() is only for starting the PWM and *not* the peripheral.
I should update the documentation to make this clearer.
> > I don't really have time to work on this, so I suggested this patch as a simple
> > solution. Otherwise, it means reworking several PWM drivers for different
> > hardware that is not available to everyone for testing.
> >
> > If we decide to only change the i.MX PWM driver, the fix would be:
> > pwm_config()
> > {
> > save passed config in private data;
> > if (pwm enabled)
> > apply passed config;
> > }
> >
> > pwm_enable()
> > {
> > if (!(pwm enabled)) {
> > enable pwm ip clk;
> > apply config from private data;
> > }
> > }
>
> Another option is to enable the clock if it is disabled when the device is
> configured. E.g. that's what tegra does.
Yes, that would have been my proposal as well.
> > If we fix only this driver, we must not forget that the same issue probably
> > exists with several other PWM drivers.
>
> Since this seems to be a common pattern in a number of PWM drivers it might
> make sense to simply add support for enabling/disabling a clk to the pwm core.
> Or maybe just use the runtime pm API for this. This probably makes even more
> sense and grab a reference to the pm context when the enable() is called,
> release it when disable() is called and also grab it before calling the
> device's config callback and release it afterward.
The problem with adding this kind of support in the core is that the
device or platform doesn't necessarily support runtime PM. Perhaps
adding a flag to mark compatible drivers would be an option. If the
runtime PM API gracefully handles cases where no callbacks are
implemented (and therefore assumed unneeded) things should also work.
On the other hand this really is very driver-specific stuff. A lot of
hardware doesn't require an explicit clock being enabled to write
registers so those wouldn't need the implicit PM calls either.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] fbcon: prevent possible buffer overflow.
From: Florian Tobias Schandinat @ 2012-08-23 20:28 UTC (permalink / raw)
To: Paul Cercueil; +Cc: linux-kernel, linux-fbdev
In-Reply-To: <1343091626-11435-2-git-send-email-paul@crapouillou.net>
On 07/24/2012 01:00 AM, Paul Cercueil wrote:
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/console/fbcon.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
> index a0b1818..3ffab97 100644
> --- a/drivers/video/console/fbcon.c
> +++ b/drivers/video/console/fbcon.c
> @@ -442,7 +442,7 @@ static int __init fb_console_setup(char *this_opt)
>
> while ((options = strsep(&this_opt, ",")) != NULL) {
> if (!strncmp(options, "font:", 5))
> - strcpy(fontname, options + 5);
> + strlcpy(fontname, options + 5, sizeof(fontname));
>
> if (!strncmp(options, "scrollback:", 11)) {
> char *k;
^ permalink raw reply
* Re: [PATCH] fbcon: Fix bit_putcs() call to kmalloc(s, GFP_KERNEL)
From: Florian Tobias Schandinat @ 2012-08-23 20:29 UTC (permalink / raw)
To: Bruno Prémont; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <20120730210949.5ccc5164@neptune.home>
On 07/30/2012 07:09 PM, Bruno Prémont wrote:
> Switch to kmalloc(,GFP_ATOMIC) in bit_putcs to fix below trace:
>
> [ 9.771812] BUG: sleeping function called from invalid context at /usr/src/linux-git/mm/slub.c:943
> [ 9.771814] in_atomic(): 1, irqs_disabled(): 1, pid: 1063, name: mount
> [ 9.771818] Pid: 1063, comm: mount Not tainted 3.5.0-jupiter-00003-g8d858b1-dirty #2
> [ 9.771819] Call Trace:
> [ 9.771838] [<c104f79b>] __might_sleep+0xcb/0xe0
> [ 9.771844] [<c10c00d4>] __kmalloc+0xb4/0x1c0
> [ 9.771851] [<c1041d4a>] ? queue_work+0x1a/0x30
> [ 9.771854] [<c1041dcf>] ? queue_delayed_work+0xf/0x30
> [ 9.771862] [<c1205832>] ? bit_putcs+0xf2/0x3e0
> [ 9.771865] [<c1041e01>] ? schedule_delayed_work+0x11/0x20
> [ 9.771868] [<c1205832>] bit_putcs+0xf2/0x3e0
> [ 9.771875] [<c12002b8>] ? get_color.clone.14+0x28/0x100
> [ 9.771878] [<c1200d2f>] fbcon_putcs+0x11f/0x130
> [ 9.771882] [<c1205740>] ? bit_clear+0xe0/0xe0
> [ 9.771885] [<c1200f6d>] fbcon_redraw.clone.21+0x11d/0x160
> [ 9.771889] [<c120383d>] fbcon_scroll+0x79d/0xe10
> [ 9.771892] [<c12002b8>] ? get_color.clone.14+0x28/0x100
> [ 9.771897] [<c124c0b4>] scrup+0x64/0xd0
> [ 9.771900] [<c124c22b>] lf+0x2b/0x60
> [ 9.771903] [<c124cc95>] vt_console_print+0x1d5/0x2f0
> [ 9.771907] [<c124cac0>] ? register_vt_notifier+0x20/0x20
> [ 9.771913] [<c102b335>] call_console_drivers.clone.5+0xa5/0xc0
> [ 9.771916] [<c102c58e>] console_unlock+0x2fe/0x3c0
> [ 9.771920] [<c102ca16>] vprintk_emit+0x2e6/0x300
> [ 9.771924] [<c13f01ae>] printk+0x38/0x3a
> [ 9.771931] [<c112e8fe>] reiserfs_remount+0x2ae/0x3e0
> [ 9.771934] [<c112e650>] ? reiserfs_fill_super+0xb00/0xb00
> [ 9.771939] [<c10ca0ab>] do_remount_sb+0xab/0x150
> [ 9.771943] [<c1034476>] ? ns_capable+0x46/0x70
> [ 9.771948] [<c10e059c>] do_mount+0x20c/0x6b0
> [ 9.771955] [<c10a7044>] ? strndup_user+0x34/0x50
> [ 9.771958] [<c10e0acc>] sys_mount+0x6c/0xa0
> [ 9.771964] [<c13f2557>] sysenter_do_call+0x12/0x26
>
> According to comment in bit_putcs() that kammloc() call only happens
> when fbcon is drawing to a monochrome framebuffer (which is my case with
> hid-picolcd).
>
> Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/console/bitblit.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/console/bitblit.c b/drivers/video/console/bitblit.c
> index 28b1a83..61b182b 100644
> --- a/drivers/video/console/bitblit.c
> +++ b/drivers/video/console/bitblit.c
> @@ -162,7 +162,7 @@ static void bit_putcs(struct vc_data *vc, struct fb_info *info,
> image.depth = 1;
>
> if (attribute) {
> - buf = kmalloc(cellsize, GFP_KERNEL);
> + buf = kmalloc(cellsize, GFP_ATOMIC);
> if (!buf)
> return;
> }
^ permalink raw reply
* Re: [PATCH 1/3] drivers/video/auo_k190x.c: drop kfree of devm_kzalloc's data
From: Florian Tobias Schandinat @ 2012-08-23 20:30 UTC (permalink / raw)
To: Julia Lawall; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1344081632-4729-1-git-send-email-Julia.Lawall@lip6.fr>
On 08/04/2012 12:00 PM, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Using kfree to free data allocated with devm_kzalloc causes double frees.
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression x;
> @@
>
> x = devm_kzalloc(...)
> ...
> ?-kfree(x);
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> drivers/video/auo_k190x.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/video/auo_k190x.c b/drivers/video/auo_k190x.c
> index 77da6a2..c03ecdd 100644
> --- a/drivers/video/auo_k190x.c
> +++ b/drivers/video/auo_k190x.c
> @@ -987,7 +987,6 @@ err_regfb:
> fb_dealloc_cmap(&info->cmap);
> err_cmap:
> fb_deferred_io_cleanup(info);
> - kfree(info->fbdefio);
> err_defio:
> vfree((void *)info->screen_base);
> err_irq:
> @@ -1022,7 +1021,6 @@ int __devexit auok190x_common_remove(struct platform_device *pdev)
> fb_dealloc_cmap(&info->cmap);
>
> fb_deferred_io_cleanup(info);
> - kfree(info->fbdefio);
>
> vfree((void *)info->screen_base);
>
>
>
^ permalink raw reply
* Re: [patch] video: mb862xxfb: prevent divide by zero bug
From: Florian Tobias Schandinat @ 2012-08-23 20:30 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20120818155541.GB22424@elgon.mountain>
On 08/18/2012 03:55 PM, Dan Carpenter wrote:
> Do a sanity check on these before using them as divisors.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
Thanks,
Florian Tobias Schandinat
>
> diff --git a/drivers/video/mb862xx/mb862xxfbdrv.c b/drivers/video/mb862xx/mb862xxfbdrv.c
> index 00ce1f3..57d940b 100644
> --- a/drivers/video/mb862xx/mb862xxfbdrv.c
> +++ b/drivers/video/mb862xx/mb862xxfbdrv.c
> @@ -328,6 +328,8 @@ static int mb862xxfb_ioctl(struct fb_info *fbi, unsigned int cmd,
> case MB862XX_L1_SET_CFG:
> if (copy_from_user(l1_cfg, argp, sizeof(*l1_cfg)))
> return -EFAULT;
> + if (l1_cfg->dh = 0 || l1_cfg->dw = 0)
> + return -EINVAL;
> if ((l1_cfg->sw >= l1_cfg->dw) && (l1_cfg->sh >= l1_cfg->dh)) {
> /* downscaling */
> outreg(cap, GC_CAP_CSC,
>
^ permalink raw reply
* Re: [PATCH 0/2] OMAPDSS: fixes for -rc
From: Florian Tobias Schandinat @ 2012-08-23 20:34 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1345529388-3509-1-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
On 08/21/2012 06:09 AM, Tomi Valkeinen wrote:
> Hi Florian,
>
> Here are two small fixes for omapfb and omapdss. The first one fixes an old bug
> that causes colors to be wrong on fb console. The other fixes SDI output that
> got broken in the previous merge window.
Applied both patches. ("The first" is actually 2/2)
Thanks,
Florian Tobias Schandinat
>
> Tomi
>
> Grazvydas Ignotas (1):
> OMAPFB: fix framebuffer console colors
>
> Tomi Valkeinen (1):
> OMAPDSS: Fix SDI PLL locking
>
> drivers/video/omap2/dss/sdi.c | 14 ++++++++++++++
> drivers/video/omap2/omapfb/omapfb-main.c | 2 +-
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
^ permalink raw reply
* Re: [PATCH] video: exynos_dp: adjust voltage swing and pre-emphasis during Link Training
From: Florian Tobias Schandinat @ 2012-08-23 20:34 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <001101cd656a$5ea25c90$1be715b0$%han@samsung.com>
On 07/19/2012 04:52 AM, Jingoo Han wrote:
> This patch adds adjustement for voltage swing and pre-emphasis during
> Link Training procedure. According to the DP specification, unless all
> the LANEx_CR_DONE bits are set, the transmitter must read
> the ADJUST_REQUEST_LANEx_x, increase the voltage swing according to
> the request, and update the TRAINING_LANEx_SET bytes to match the new
> voltage swing setting.
>
> Refer to the DP specification v1.1a, Section 3.5.1.3 Link Training.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/exynos/exynos_dp_core.c | 282 +++++++++++++++++----------------
> drivers/video/exynos/exynos_dp_core.h | 2 +-
> 2 files changed, 144 insertions(+), 140 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
> index c6c016a..9c0140f 100644
> --- a/drivers/video/exynos/exynos_dp_core.c
> +++ b/drivers/video/exynos/exynos_dp_core.c
> @@ -260,7 +260,7 @@ static void exynos_dp_set_lane_lane_pre_emphasis(struct exynos_dp_device *dp,
>
> static void exynos_dp_link_start(struct exynos_dp_device *dp)
> {
> - u8 buf[5];
> + u8 buf[4];
> int lane;
> int lane_count;
>
> @@ -295,10 +295,10 @@ static void exynos_dp_link_start(struct exynos_dp_device *dp)
> exynos_dp_set_training_pattern(dp, TRAINING_PTN1);
>
> /* Set RX training pattern */
> - buf[0] = DPCD_SCRAMBLING_DISABLED |
> - DPCD_TRAINING_PATTERN_1;
> exynos_dp_write_byte_to_dpcd(dp,
> - DPCD_ADDR_TRAINING_PATTERN_SET, buf[0]);
> + DPCD_ADDR_TRAINING_PATTERN_SET,
> + DPCD_SCRAMBLING_DISABLED |
> + DPCD_TRAINING_PATTERN_1);
>
> for (lane = 0; lane < lane_count; lane++)
> buf[lane] = DPCD_PRE_EMPHASIS_PATTERN2_LEVEL0 |
> @@ -308,7 +308,7 @@ static void exynos_dp_link_start(struct exynos_dp_device *dp)
> lane_count, buf);
> }
>
> -static unsigned char exynos_dp_get_lane_status(u8 link_status[6], int lane)
> +static unsigned char exynos_dp_get_lane_status(u8 link_status[2], int lane)
> {
> int shift = (lane & 1) * 4;
> u8 link_value = link_status[lane>>1];
> @@ -316,7 +316,7 @@ static unsigned char exynos_dp_get_lane_status(u8 link_status[6], int lane)
> return (link_value >> shift) & 0xf;
> }
>
> -static int exynos_dp_clock_recovery_ok(u8 link_status[6], int lane_count)
> +static int exynos_dp_clock_recovery_ok(u8 link_status[2], int lane_count)
> {
> int lane;
> u8 lane_status;
> @@ -329,22 +329,23 @@ static int exynos_dp_clock_recovery_ok(u8 link_status[6], int lane_count)
> return 0;
> }
>
> -static int exynos_dp_channel_eq_ok(u8 link_status[6], int lane_count)
> +static int exynos_dp_channel_eq_ok(u8 link_align[3], int lane_count)
> {
> int lane;
> u8 lane_align;
> u8 lane_status;
>
> - lane_align = link_status[2];
> + lane_align = link_align[2];
> if ((lane_align & DPCD_INTERLANE_ALIGN_DONE) = 0)
> return -EINVAL;
>
> for (lane = 0; lane < lane_count; lane++) {
> - lane_status = exynos_dp_get_lane_status(link_status, lane);
> + lane_status = exynos_dp_get_lane_status(link_align, lane);
> lane_status &= DPCD_CHANNEL_EQ_BITS;
> if (lane_status != DPCD_CHANNEL_EQ_BITS)
> return -EINVAL;
> }
> +
> return 0;
> }
>
> @@ -417,69 +418,17 @@ static unsigned int exynos_dp_get_lane_link_training(
>
> static void exynos_dp_reduce_link_rate(struct exynos_dp_device *dp)
> {
> - if (dp->link_train.link_rate = LINK_RATE_2_70GBPS) {
> - /* set to reduced bit rate */
> - dp->link_train.link_rate = LINK_RATE_1_62GBPS;
> - dev_err(dp->dev, "set to bandwidth %.2x\n",
> - dp->link_train.link_rate);
> - dp->link_train.lt_state = START;
> - } else {
> - exynos_dp_training_pattern_dis(dp);
> - /* set enhanced mode if available */
> - exynos_dp_set_enhanced_mode(dp);
> - dp->link_train.lt_state = FAILED;
> - }
> -}
> -
> -static void exynos_dp_get_adjust_train(struct exynos_dp_device *dp,
> - u8 adjust_request[2])
> -{
> - int lane;
> - int lane_count;
> - u8 voltage_swing;
> - u8 pre_emphasis;
> - u8 training_lane;
> + exynos_dp_training_pattern_dis(dp);
> + exynos_dp_set_enhanced_mode(dp);
>
> - lane_count = dp->link_train.lane_count;
> - for (lane = 0; lane < lane_count; lane++) {
> - voltage_swing = exynos_dp_get_adjust_request_voltage(
> - adjust_request, lane);
> - pre_emphasis = exynos_dp_get_adjust_request_pre_emphasis(
> - adjust_request, lane);
> - training_lane = DPCD_VOLTAGE_SWING_SET(voltage_swing) |
> - DPCD_PRE_EMPHASIS_SET(pre_emphasis);
> -
> - if (voltage_swing = VOLTAGE_LEVEL_3 ||
> - pre_emphasis = PRE_EMPHASIS_LEVEL_3) {
> - training_lane |= DPCD_MAX_SWING_REACHED;
> - training_lane |= DPCD_MAX_PRE_EMPHASIS_REACHED;
> - }
> - dp->link_train.training_lane[lane] = training_lane;
> - }
> -}
> -
> -static int exynos_dp_check_max_cr_loop(struct exynos_dp_device *dp,
> - u8 voltage_swing)
> -{
> - int lane;
> - int lane_count;
> -
> - lane_count = dp->link_train.lane_count;
> - for (lane = 0; lane < lane_count; lane++) {
> - if (voltage_swing = VOLTAGE_LEVEL_3 ||
> - dp->link_train.cr_loop[lane] = MAX_CR_LOOP)
> - return -EINVAL;
> - }
> - return 0;
> + dp->link_train.lt_state = FAILED;
> }
>
> static int exynos_dp_process_clock_recovery(struct exynos_dp_device *dp)
> {
> - u8 data;
> - u8 link_status[6];
> + u8 link_status[2];
> int lane;
> int lane_count;
> - u8 buf[5];
>
> u8 adjust_request[2];
> u8 voltage_swing;
> @@ -488,98 +437,152 @@ static int exynos_dp_process_clock_recovery(struct exynos_dp_device *dp)
>
> usleep_range(100, 101);
>
> - exynos_dp_read_bytes_from_dpcd(dp, DPCD_ADDR_LANE0_1_STATUS,
> - 6, link_status);
> lane_count = dp->link_train.lane_count;
>
> + exynos_dp_read_bytes_from_dpcd(dp, DPCD_ADDR_LANE0_1_STATUS,
> + 2, link_status);
> +
> if (exynos_dp_clock_recovery_ok(link_status, lane_count) = 0) {
> /* set training pattern 2 for EQ */
> exynos_dp_set_training_pattern(dp, TRAINING_PTN2);
>
> - adjust_request[0] = link_status[4];
> - adjust_request[1] = link_status[5];
> + for (lane = 0; lane < lane_count; lane++) {
> + exynos_dp_read_bytes_from_dpcd(dp,
> + DPCD_ADDR_ADJUST_REQUEST_LANE0_1,
> + 2, adjust_request);
> + voltage_swing = exynos_dp_get_adjust_request_voltage(
> + adjust_request, lane);
> + pre_emphasis = exynos_dp_get_adjust_request_pre_emphasis(
> + adjust_request, lane);
> + training_lane = DPCD_VOLTAGE_SWING_SET(voltage_swing) |
> + DPCD_PRE_EMPHASIS_SET(pre_emphasis);
>
> - exynos_dp_get_adjust_train(dp, adjust_request);
> + if (voltage_swing = VOLTAGE_LEVEL_3)
> + training_lane |= DPCD_MAX_SWING_REACHED;
> + if (pre_emphasis = PRE_EMPHASIS_LEVEL_3)
> + training_lane |= DPCD_MAX_PRE_EMPHASIS_REACHED;
>
> - buf[0] = DPCD_SCRAMBLING_DISABLED |
> - DPCD_TRAINING_PATTERN_2;
> - exynos_dp_write_byte_to_dpcd(dp,
> - DPCD_ADDR_TRAINING_PATTERN_SET,
> - buf[0]);
> + dp->link_train.training_lane[lane] = training_lane;
>
> - for (lane = 0; lane < lane_count; lane++) {
> exynos_dp_set_lane_link_training(dp,
> dp->link_train.training_lane[lane],
> lane);
> - buf[lane] = dp->link_train.training_lane[lane];
> - exynos_dp_write_byte_to_dpcd(dp,
> - DPCD_ADDR_TRAINING_LANE0_SET + lane,
> - buf[lane]);
> }
> - dp->link_train.lt_state = EQUALIZER_TRAINING;
> - } else {
> - exynos_dp_read_byte_from_dpcd(dp,
> - DPCD_ADDR_ADJUST_REQUEST_LANE0_1,
> - &data);
> - adjust_request[0] = data;
>
> - exynos_dp_read_byte_from_dpcd(dp,
> - DPCD_ADDR_ADJUST_REQUEST_LANE2_3,
> - &data);
> - adjust_request[1] = data;
> + exynos_dp_write_byte_to_dpcd(dp,
> + DPCD_ADDR_TRAINING_PATTERN_SET,
> + DPCD_SCRAMBLING_DISABLED |
> + DPCD_TRAINING_PATTERN_2);
> +
> + exynos_dp_write_bytes_to_dpcd(dp,
> + DPCD_ADDR_TRAINING_LANE0_SET,
> + lane_count,
> + dp->link_train.training_lane);
>
> + dev_info(dp->dev, "Link Training Clock Recovery success\n");
> + dp->link_train.lt_state = EQUALIZER_TRAINING;
> + } else {
> for (lane = 0; lane < lane_count; lane++) {
> training_lane = exynos_dp_get_lane_link_training(
> dp, lane);
> + exynos_dp_read_bytes_from_dpcd(dp,
> + DPCD_ADDR_ADJUST_REQUEST_LANE0_1,
> + 2, adjust_request);
> voltage_swing = exynos_dp_get_adjust_request_voltage(
> adjust_request, lane);
> pre_emphasis = exynos_dp_get_adjust_request_pre_emphasis(
> adjust_request, lane);
> - if ((DPCD_VOLTAGE_SWING_GET(training_lane) = voltage_swing) &&
> - (DPCD_PRE_EMPHASIS_GET(training_lane) = pre_emphasis))
> - dp->link_train.cr_loop[lane]++;
> - dp->link_train.training_lane[lane] = training_lane;
> - }
>
> - if (exynos_dp_check_max_cr_loop(dp, voltage_swing) != 0) {
> - exynos_dp_reduce_link_rate(dp);
> - } else {
> - exynos_dp_get_adjust_train(dp, adjust_request);
> + if (voltage_swing = VOLTAGE_LEVEL_3 ||
> + pre_emphasis = PRE_EMPHASIS_LEVEL_3) {
> + dev_err(dp->dev, "voltage or pre emphasis reached max level\n");
> + goto reduce_link_rate;
> + }
>
> - for (lane = 0; lane < lane_count; lane++) {
> - exynos_dp_set_lane_link_training(dp,
> - dp->link_train.training_lane[lane],
> - lane);
> - buf[lane] = dp->link_train.training_lane[lane];
> - exynos_dp_write_byte_to_dpcd(dp,
> - DPCD_ADDR_TRAINING_LANE0_SET + lane,
> - buf[lane]);
> + if ((DPCD_VOLTAGE_SWING_GET(training_lane) =
> + voltage_swing) &&
> + (DPCD_PRE_EMPHASIS_GET(training_lane) =
> + pre_emphasis)) {
> + dp->link_train.cr_loop[lane]++;
> + if (dp->link_train.cr_loop[lane] = MAX_CR_LOOP) {
> + dev_err(dp->dev, "CR Max loop\n");
> + goto reduce_link_rate;
> + }
> }
> +
> + training_lane = DPCD_VOLTAGE_SWING_SET(voltage_swing) |
> + DPCD_PRE_EMPHASIS_SET(pre_emphasis);
> +
> + if (voltage_swing = VOLTAGE_LEVEL_3)
> + training_lane |= DPCD_MAX_SWING_REACHED;
> + if (pre_emphasis = PRE_EMPHASIS_LEVEL_3)
> + training_lane |= DPCD_MAX_PRE_EMPHASIS_REACHED;
> +
> + dp->link_train.training_lane[lane] = training_lane;
> +
> + exynos_dp_set_lane_link_training(dp,
> + dp->link_train.training_lane[lane], lane);
> }
> +
> + exynos_dp_write_bytes_to_dpcd(dp,
> + DPCD_ADDR_TRAINING_LANE0_SET,
> + lane_count,
> + dp->link_train.training_lane);
> }
>
> return 0;
> +
> +reduce_link_rate:
> + exynos_dp_reduce_link_rate(dp);
> + return -EIO;
> }
>
> static int exynos_dp_process_equalizer_training(struct exynos_dp_device *dp)
> {
> - u8 link_status[6];
> + u8 link_status[2];
> + u8 link_align[3];
> int lane;
> int lane_count;
> - u8 buf[5];
> u32 reg;
>
> u8 adjust_request[2];
> + u8 voltage_swing;
> + u8 pre_emphasis;
> + u8 training_lane;
>
> usleep_range(400, 401);
>
> - exynos_dp_read_bytes_from_dpcd(dp, DPCD_ADDR_LANE0_1_STATUS,
> - 6, link_status);
> lane_count = dp->link_train.lane_count;
>
> + exynos_dp_read_bytes_from_dpcd(dp, DPCD_ADDR_LANE0_1_STATUS,
> + 2, link_status);
> +
> if (exynos_dp_clock_recovery_ok(link_status, lane_count) = 0) {
> - adjust_request[0] = link_status[4];
> - adjust_request[1] = link_status[5];
> + link_align[0] = link_status[0];
> + link_align[1] = link_status[1];
> +
> + exynos_dp_read_byte_from_dpcd(dp,
> + DPCD_ADDR_LANE_ALIGN_STATUS_UPDATED,
> + &link_align[2]);
> +
> + for (lane = 0; lane < lane_count; lane++) {
> + exynos_dp_read_bytes_from_dpcd(dp,
> + DPCD_ADDR_ADJUST_REQUEST_LANE0_1,
> + 2, adjust_request);
> + voltage_swing = exynos_dp_get_adjust_request_voltage(
> + adjust_request, lane);
> + pre_emphasis = exynos_dp_get_adjust_request_pre_emphasis(
> + adjust_request, lane);
> + training_lane = DPCD_VOLTAGE_SWING_SET(voltage_swing) |
> + DPCD_PRE_EMPHASIS_SET(pre_emphasis);
> +
> + if (voltage_swing = VOLTAGE_LEVEL_3)
> + training_lane |= DPCD_MAX_SWING_REACHED;
> + if (pre_emphasis = PRE_EMPHASIS_LEVEL_3)
> + training_lane |= DPCD_MAX_PRE_EMPHASIS_REACHED;
> +
> + dp->link_train.training_lane[lane] = training_lane;
> + }
>
> if (exynos_dp_channel_eq_ok(link_status, lane_count) = 0) {
> /* traing pattern Set to Normal */
> @@ -596,39 +599,42 @@ static int exynos_dp_process_equalizer_training(struct exynos_dp_device *dp)
> dp->link_train.lane_count = reg;
> dev_dbg(dp->dev, "final lane count = %.2x\n",
> dp->link_train.lane_count);
> +
> /* set enhanced mode if available */
> exynos_dp_set_enhanced_mode(dp);
> -
> dp->link_train.lt_state = FINISHED;
> } else {
> /* not all locked */
> dp->link_train.eq_loop++;
>
> if (dp->link_train.eq_loop > MAX_EQ_LOOP) {
> - exynos_dp_reduce_link_rate(dp);
> - } else {
> - exynos_dp_get_adjust_train(dp, adjust_request);
> -
> - for (lane = 0; lane < lane_count; lane++) {
> - exynos_dp_set_lane_link_training(dp,
> - dp->link_train.training_lane[lane],
> - lane);
> - buf[lane] = dp->link_train.training_lane[lane];
> - exynos_dp_write_byte_to_dpcd(dp,
> - DPCD_ADDR_TRAINING_LANE0_SET + lane,
> - buf[lane]);
> - }
> + dev_err(dp->dev, "EQ Max loop\n");
> + goto reduce_link_rate;
> }
> +
> + for (lane = 0; lane < lane_count; lane++)
> + exynos_dp_set_lane_link_training(dp,
> + dp->link_train.training_lane[lane],
> + lane);
> +
> + exynos_dp_write_bytes_to_dpcd(dp,
> + DPCD_ADDR_TRAINING_LANE0_SET,
> + lane_count,
> + dp->link_train.training_lane);
> }
> } else {
> - exynos_dp_reduce_link_rate(dp);
> + goto reduce_link_rate;
> }
>
> return 0;
> +
> +reduce_link_rate:
> + exynos_dp_reduce_link_rate(dp);
> + return -EIO;
> }
>
> static void exynos_dp_get_max_rx_bandwidth(struct exynos_dp_device *dp,
> - u8 *bandwidth)
> + u8 *bandwidth)
> {
> u8 data;
>
> @@ -641,7 +647,7 @@ static void exynos_dp_get_max_rx_bandwidth(struct exynos_dp_device *dp,
> }
>
> static void exynos_dp_get_max_rx_lane_count(struct exynos_dp_device *dp,
> - u8 *lane_count)
> + u8 *lane_count)
> {
> u8 data;
>
> @@ -693,13 +699,7 @@ static void exynos_dp_init_training(struct exynos_dp_device *dp,
> static int exynos_dp_sw_link_training(struct exynos_dp_device *dp)
> {
> int retval = 0;
> - int training_finished;
> -
> - /* Turn off unnecessary lane */
> - if (dp->link_train.lane_count = 1)
> - exynos_dp_set_analog_power_down(dp, CH1_BLOCK, 1);
> -
> - training_finished = 0;
> + int training_finished = 0;
>
> dp->link_train.lt_state = START;
>
> @@ -710,10 +710,14 @@ static int exynos_dp_sw_link_training(struct exynos_dp_device *dp)
> exynos_dp_link_start(dp);
> break;
> case CLOCK_RECOVERY:
> - exynos_dp_process_clock_recovery(dp);
> + retval = exynos_dp_process_clock_recovery(dp);
> + if (retval)
> + dev_err(dp->dev, "LT CR failed!\n");
> break;
> case EQUALIZER_TRAINING:
> - exynos_dp_process_equalizer_training(dp);
> + retval = exynos_dp_process_equalizer_training(dp);
> + if (retval)
> + dev_err(dp->dev, "LT EQ failed!\n");
> break;
> case FINISHED:
> training_finished = 1;
> diff --git a/drivers/video/exynos/exynos_dp_core.h b/drivers/video/exynos/exynos_dp_core.h
> index 8526e54..44c11e1 100644
> --- a/drivers/video/exynos/exynos_dp_core.h
> +++ b/drivers/video/exynos/exynos_dp_core.h
> @@ -144,7 +144,7 @@ void exynos_dp_disable_scrambling(struct exynos_dp_device *dp);
> #define DPCD_ADDR_TRAINING_PATTERN_SET 0x0102
> #define DPCD_ADDR_TRAINING_LANE0_SET 0x0103
> #define DPCD_ADDR_LANE0_1_STATUS 0x0202
> -#define DPCD_ADDR_LANE_ALIGN__STATUS_UPDATED 0x0204
> +#define DPCD_ADDR_LANE_ALIGN_STATUS_UPDATED 0x0204
> #define DPCD_ADDR_ADJUST_REQUEST_LANE0_1 0x0206
> #define DPCD_ADDR_ADJUST_REQUEST_LANE2_3 0x0207
> #define DPCD_ADDR_TEST_REQUEST 0x0218
^ permalink raw reply
* Re: [PATCH 5/5] drivers/video/ep93xx-fb.c: use devm_ functions
From: Florian Tobias Schandinat @ 2012-08-23 20:35 UTC (permalink / raw)
To: Damien Cassou; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1343742860-16213-2-git-send-email-damien.cassou@lifl.fr>
On 07/31/2012 01:54 PM, Damien Cassou wrote:
> From: Damien Cassou <damien.cassou@lifl.fr>
>
> The various devm_ functions allocate memory that is released when a driver
> detaches. This patch uses these functions for data that is allocated in
> the probe function of a platform device and is only freed in the remove
> function.
>
> Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> drivers/video/ep93xx-fb.c | 17 ++++++-----------
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/video/ep93xx-fb.c b/drivers/video/ep93xx-fb.c
> index 345d962..69c89f2 100644
> --- a/drivers/video/ep93xx-fb.c
> +++ b/drivers/video/ep93xx-fb.c
> @@ -529,7 +529,8 @@ static int __devinit ep93xxfb_probe(struct platform_device *pdev)
> * any of the framebuffer registers.
> */
> fbi->res = res;
> - fbi->mmio_base = ioremap(res->start, resource_size(res));
> + fbi->mmio_base = devm_ioremap(&pdev->dev, res->start,
> + resource_size(res));
> if (!fbi->mmio_base) {
> err = -ENXIO;
> goto failed_resource;
> @@ -553,20 +554,20 @@ static int __devinit ep93xxfb_probe(struct platform_device *pdev)
> if (err = 0) {
> dev_err(info->dev, "No suitable video mode found\n");
> err = -EINVAL;
> - goto failed_mode;
> + goto failed_resource;
> }
>
> if (mach_info->setup) {
> err = mach_info->setup(pdev);
> if (err)
> - goto failed_mode;
> + goto failed_resource;
> }
>
> err = ep93xxfb_check_var(&info->var, info);
> if (err)
> goto failed_check;
>
> - fbi->clk = clk_get(info->dev, NULL);
> + fbi->clk = devm_clk_get(&pdev->dev, NULL);
> if (IS_ERR(fbi->clk)) {
> err = PTR_ERR(fbi->clk);
> fbi->clk = NULL;
> @@ -578,19 +579,15 @@ static int __devinit ep93xxfb_probe(struct platform_device *pdev)
>
> err = register_framebuffer(info);
> if (err)
> - goto failed;
> + goto failed_check;
>
> dev_info(info->dev, "registered. Mode = %dx%d-%d\n",
> info->var.xres, info->var.yres, info->var.bits_per_pixel);
> return 0;
>
> -failed:
> - clk_put(fbi->clk);
> failed_check:
> if (fbi->mach_info->teardown)
> fbi->mach_info->teardown(pdev);
> -failed_mode:
> - iounmap(fbi->mmio_base);
> failed_resource:
> ep93xxfb_dealloc_videomem(info);
> failed_videomem:
> @@ -609,8 +606,6 @@ static int __devexit ep93xxfb_remove(struct platform_device *pdev)
>
> unregister_framebuffer(info);
> clk_disable(fbi->clk);
> - clk_put(fbi->clk);
> - iounmap(fbi->mmio_base);
> ep93xxfb_dealloc_videomem(info);
> fb_dealloc_cmap(&info->cmap);
>
>
>
^ permalink raw reply
* Re: [PATCH 3/5] drivers/video/cobalt_lcdfb.c: use devm_ functions
From: Florian Tobias Schandinat @ 2012-08-23 20:36 UTC (permalink / raw)
To: Damien Cassou; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1343742860-16213-4-git-send-email-damien.cassou@lifl.fr>
On 07/31/2012 01:54 PM, Damien Cassou wrote:
> From: Damien Cassou <damien.cassou@lifl.fr>
>
> The various devm_ functions allocate memory that is released when a driver
> detaches. This patch uses these functions for data that is allocated in
> the probe function of a platform device and is only freed in the remove
> function.
>
> Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> drivers/video/cobalt_lcdfb.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/cobalt_lcdfb.c b/drivers/video/cobalt_lcdfb.c
> index eae46f6..01a4ee7 100644
> --- a/drivers/video/cobalt_lcdfb.c
> +++ b/drivers/video/cobalt_lcdfb.c
> @@ -348,7 +348,8 @@ static int __devinit cobalt_lcdfb_probe(struct platform_device *dev)
> }
>
> info->screen_size = resource_size(res);
> - info->screen_base = ioremap(res->start, info->screen_size);
> + info->screen_base = devm_ioremap(&dev->dev, res->start,
> + info->screen_size);
> info->fbops = &cobalt_lcd_fbops;
> info->fix = cobalt_lcdfb_fix;
> info->fix.smem_start = res->start;
> @@ -359,7 +360,6 @@ static int __devinit cobalt_lcdfb_probe(struct platform_device *dev)
>
> retval = register_framebuffer(info);
> if (retval < 0) {
> - iounmap(info->screen_base);
> framebuffer_release(info);
> return retval;
> }
> @@ -380,7 +380,6 @@ static int __devexit cobalt_lcdfb_remove(struct platform_device *dev)
>
> info = platform_get_drvdata(dev);
> if (info) {
> - iounmap(info->screen_base);
> unregister_framebuffer(info);
> framebuffer_release(info);
> }
>
>
^ permalink raw reply
* Re: [PATCH 1/5] drivers/video/bf537-lq035.c: use devm_ functions
From: Florian Tobias Schandinat @ 2012-08-23 20:36 UTC (permalink / raw)
To: Damien Cassou; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1343742860-16213-6-git-send-email-damien.cassou@lifl.fr>
On 07/31/2012 01:54 PM, Damien Cassou wrote:
> From: Damien Cassou <damien.cassou@lifl.fr>
>
> The various devm_ functions allocate memory that is released when a driver
> detaches. This patch uses these functions for data that is allocated in
> the probe function of a platform device and is only freed in the remove
> function.
>
> Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> drivers/video/bf537-lq035.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/bf537-lq035.c b/drivers/video/bf537-lq035.c
> index befbc80..7347aa1 100644
> --- a/drivers/video/bf537-lq035.c
> +++ b/drivers/video/bf537-lq035.c
> @@ -760,18 +760,20 @@ static int __devinit bfin_lq035_probe(struct platform_device *pdev)
> bfin_lq035_fb.flags = FBINFO_DEFAULT;
>
>
> - bfin_lq035_fb.pseudo_palette = kzalloc(sizeof(u32) * 16, GFP_KERNEL);
> + bfin_lq035_fb.pseudo_palette = devm_kzalloc(&pdev->dev,
> + sizeof(u32) * 16,
> + GFP_KERNEL);
> if (bfin_lq035_fb.pseudo_palette = NULL) {
> pr_err("failed to allocate pseudo_palette\n");
> ret = -ENOMEM;
> - goto out_palette;
> + goto out_table;
> }
>
> if (fb_alloc_cmap(&bfin_lq035_fb.cmap, NBR_PALETTE, 0) < 0) {
> pr_err("failed to allocate colormap (%d entries)\n",
> NBR_PALETTE);
> ret = -EFAULT;
> - goto out_cmap;
> + goto out_table;
> }
>
> if (register_framebuffer(&bfin_lq035_fb) < 0) {
> @@ -804,9 +806,6 @@ out_lcd:
> unregister_framebuffer(&bfin_lq035_fb);
> out_reg:
> fb_dealloc_cmap(&bfin_lq035_fb.cmap);
> -out_cmap:
> - kfree(bfin_lq035_fb.pseudo_palette);
> -out_palette:
> out_table:
> dma_free_coherent(NULL, TOTAL_VIDEO_MEM_SIZE, fb_buffer, 0);
> fb_buffer = NULL;
> @@ -834,7 +833,6 @@ static int __devexit bfin_lq035_remove(struct platform_device *pdev)
> free_dma(CH_PPI);
>
>
> - kfree(bfin_lq035_fb.pseudo_palette);
> fb_dealloc_cmap(&bfin_lq035_fb.cmap);
>
>
>
>
^ permalink raw reply
* Re: [PATCH 3/5] drivers/video/mbx/mbxfb.c: use devm_ functions
From: Florian Tobias Schandinat @ 2012-08-23 20:37 UTC (permalink / raw)
To: Damien Cassou; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1343752762-16861-2-git-send-email-damien.cassou@lifl.fr>
On 07/31/2012 04:39 PM, Damien Cassou wrote:
> From: Damien Cassou <damien.cassou@lifl.fr>
>
> The various devm_ functions allocate memory that is released when a driver
> detaches. This patch uses these functions for data that is allocated in
> the probe function of a platform device and is only freed in the remove
> function.
>
> Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> drivers/video/mbx/mbxfb.c | 22 ++++++++--------------
> 1 file changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/video/mbx/mbxfb.c b/drivers/video/mbx/mbxfb.c
> index 85e4f44..9229acf 100644
> --- a/drivers/video/mbx/mbxfb.c
> +++ b/drivers/video/mbx/mbxfb.c
> @@ -939,8 +939,9 @@ static int __devinit mbxfb_probe(struct platform_device *dev)
> }
> mfbi->reg_phys_addr = mfbi->reg_res->start;
>
> - mfbi->reg_virt_addr = ioremap_nocache(mfbi->reg_phys_addr,
> - res_size(mfbi->reg_req));
> + mfbi->reg_virt_addr = devm_ioremap_nocache(&dev->dev,
> + mfbi->reg_phys_addr,
> + res_size(mfbi->reg_req));
> if (!mfbi->reg_virt_addr) {
> dev_err(&dev->dev, "failed to ioremap Marathon registers\n");
> ret = -EINVAL;
> @@ -948,12 +949,12 @@ static int __devinit mbxfb_probe(struct platform_device *dev)
> }
> virt_base_2700 = mfbi->reg_virt_addr;
>
> - mfbi->fb_virt_addr = ioremap_nocache(mfbi->fb_phys_addr,
> - res_size(mfbi->fb_req));
> + mfbi->fb_virt_addr = devm_ioremap_nocache(&dev->dev, mfbi->fb_phys_addr,
> + res_size(mfbi->fb_req));
> if (!mfbi->fb_virt_addr) {
> dev_err(&dev->dev, "failed to ioremap frame buffer\n");
> ret = -EINVAL;
> - goto err4;
> + goto err3;
> }
>
> fbi->screen_base = (char __iomem *)(mfbi->fb_virt_addr + 0x60000);
> @@ -971,7 +972,7 @@ static int __devinit mbxfb_probe(struct platform_device *dev)
> if (ret < 0) {
> dev_err(&dev->dev, "fb_alloc_cmap failed\n");
> ret = -EINVAL;
> - goto err5;
> + goto err3;
> }
>
> platform_set_drvdata(dev, fbi);
> @@ -996,10 +997,6 @@ static int __devinit mbxfb_probe(struct platform_device *dev)
>
> err6:
> fb_dealloc_cmap(&fbi->cmap);
> -err5:
> - iounmap(mfbi->fb_virt_addr);
> -err4:
> - iounmap(mfbi->reg_virt_addr);
> err3:
> release_mem_region(mfbi->reg_res->start, res_size(mfbi->reg_res));
> err2:
> @@ -1026,10 +1023,7 @@ static int __devexit mbxfb_remove(struct platform_device *dev)
> if (mfbi->platform_remove)
> mfbi->platform_remove(fbi);
>
> - if (mfbi->fb_virt_addr)
> - iounmap(mfbi->fb_virt_addr);
> - if (mfbi->reg_virt_addr)
> - iounmap(mfbi->reg_virt_addr);
> +
> if (mfbi->reg_req)
> release_mem_region(mfbi->reg_req->start,
> res_size(mfbi->reg_req));
>
>
^ permalink raw reply
* Re: [PATCH 2/5] drivers/video/gbefb.c: use devm_ functions
From: Florian Tobias Schandinat @ 2012-08-23 20:37 UTC (permalink / raw)
To: Damien Cassou; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1343752762-16861-3-git-send-email-damien.cassou@lifl.fr>
On 07/31/2012 04:39 PM, Damien Cassou wrote:
> From: Damien Cassou <damien.cassou@lifl.fr>
>
> The various devm_ functions allocate memory that is released when a driver
> detaches. This patch uses these functions for data that is allocated in
> the probe function of a platform device and is only freed in the remove
> function.
>
> Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> drivers/video/gbefb.c | 15 +++++----------
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/video/gbefb.c b/drivers/video/gbefb.c
> index 7e7b7a9..9b79d38 100644
> --- a/drivers/video/gbefb.c
> +++ b/drivers/video/gbefb.c
> @@ -1156,7 +1156,8 @@ static int __devinit gbefb_probe(struct platform_device *p_dev)
> goto out_release_framebuffer;
> }
>
> - gbe = (struct sgi_gbe *) ioremap(GBE_BASE, sizeof(struct sgi_gbe));
> + gbe = (struct sgi_gbe *) devm_ioremap(&p_dev->dev, GBE_BASE,
> + sizeof(struct sgi_gbe));
> if (!gbe) {
> printk(KERN_ERR "gbefb: couldn't map mmio region\n");
> ret = -ENXIO;
> @@ -1170,12 +1171,13 @@ static int __devinit gbefb_probe(struct platform_device *p_dev)
> if (!gbe_tiles.cpu) {
> printk(KERN_ERR "gbefb: couldn't allocate tiles table\n");
> ret = -ENOMEM;
> - goto out_unmap;
> + goto out_release_mem_region;
> }
>
> if (gbe_mem_phys) {
> /* memory was allocated at boot time */
> - gbe_mem = ioremap_nocache(gbe_mem_phys, gbe_mem_size);
> + gbe_mem = devm_ioremap_nocache(&p_dev->dev, gbe_mem_phys,
> + gbe_mem_size);
> if (!gbe_mem) {
> printk(KERN_ERR "gbefb: couldn't map framebuffer\n");
> ret = -ENOMEM;
> @@ -1241,13 +1243,9 @@ static int __devinit gbefb_probe(struct platform_device *p_dev)
> out_gbe_unmap:
> if (gbe_dma_addr)
> dma_free_coherent(NULL, gbe_mem_size, gbe_mem, gbe_mem_phys);
> - else
> - iounmap(gbe_mem);
> out_tiles_free:
> dma_free_coherent(NULL, GBE_TLB_SIZE * sizeof(uint16_t),
> (void *)gbe_tiles.cpu, gbe_tiles.dma);
> -out_unmap:
> - iounmap(gbe);
> out_release_mem_region:
> release_mem_region(GBE_BASE, sizeof(struct sgi_gbe));
> out_release_framebuffer:
> @@ -1264,12 +1262,9 @@ static int __devexit gbefb_remove(struct platform_device* p_dev)
> gbe_turn_off();
> if (gbe_dma_addr)
> dma_free_coherent(NULL, gbe_mem_size, gbe_mem, gbe_mem_phys);
> - else
> - iounmap(gbe_mem);
> dma_free_coherent(NULL, GBE_TLB_SIZE * sizeof(uint16_t),
> (void *)gbe_tiles.cpu, gbe_tiles.dma);
> release_mem_region(GBE_BASE, sizeof(struct sgi_gbe));
> - iounmap(gbe);
> gbefb_remove_sysfs(&p_dev->dev);
> framebuffer_release(info);
>
>
>
^ permalink raw reply
* Re: [PATCH 1/5] drivers/video/fsl-diu-fb.c: use devm_ functions
From: Florian Tobias Schandinat @ 2012-08-23 20:38 UTC (permalink / raw)
To: Damien Cassou; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1343752762-16861-4-git-send-email-damien.cassou@lifl.fr>
On 07/31/2012 04:39 PM, Damien Cassou wrote:
> From: Damien Cassou <damien.cassou@lifl.fr>
>
> The various devm_ functions allocate memory that is released when a driver
> detaches. This patch uses these functions for data that is allocated in
> the probe function of a platform device and is only freed in the remove
> function.
>
> Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> drivers/video/fsl-diu-fb.c | 11 ++---------
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
> index 458c006..19194c5 100644
> --- a/drivers/video/fsl-diu-fb.c
> +++ b/drivers/video/fsl-diu-fb.c
> @@ -1501,8 +1501,8 @@ static int __devinit fsl_diu_probe(struct platform_device *pdev)
> unsigned int i;
> int ret;
>
> - data = dma_alloc_coherent(&pdev->dev, sizeof(struct fsl_diu_data),
> - &dma_addr, GFP_DMA | __GFP_ZERO);
> + data = dmam_alloc_coherent(&pdev->dev, sizeof(struct fsl_diu_data),
> + &dma_addr, GFP_DMA | __GFP_ZERO);
> if (!data)
> return -ENOMEM;
> data->dma_addr = dma_addr;
> @@ -1628,9 +1628,6 @@ error:
>
> iounmap(data->diu_reg);
>
> - dma_free_coherent(&pdev->dev, sizeof(struct fsl_diu_data), data,
> - data->dma_addr);
> -
> return ret;
> }
>
> @@ -1648,9 +1645,6 @@ static int fsl_diu_remove(struct platform_device *pdev)
>
> iounmap(data->diu_reg);
>
> - dma_free_coherent(&pdev->dev, sizeof(struct fsl_diu_data), data,
> - data->dma_addr);
> -
> return 0;
> }
>
^ permalink raw reply
* Re: [PATCH v2] video: exynos_dp: use devm_clk_get function
From: Florian Tobias Schandinat @ 2012-08-23 20:38 UTC (permalink / raw)
To: Damien Cassou; +Cc: Jingoo Han, linux-fbdev, linux-kernel, Sachin Kamat
In-Reply-To: <877gti1t48.fsf@gmail.com>
On 08/01/2012 04:20 PM, Damien Cassou wrote:
> From: Damien Cassou <damien.cassou@lifl.fr>
>
> The devm_clk_get function allocates memory that is released when a driver
> detaches. This patch uses this function for data that is allocated in the probe
> function of a platform device and is only freed in the remove function.
>
> Additionally, this patch removes a null check after platform_get_resource that
> is redundant with the one done by devm_request_and_ioremap.
>
> Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> Changed subject line and description
> drivers/video/exynos/exynos_dp_core.c | 27 +++++++--------------------
> 1 file changed, 7 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
> index c6c016a..00fe4f0 100644
> --- a/drivers/video/exynos/exynos_dp_core.c
> +++ b/drivers/video/exynos/exynos_dp_core.c
> @@ -872,7 +872,7 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
>
> dp->dev = &pdev->dev;
>
> - dp->clock = clk_get(&pdev->dev, "dp");
> + dp->clock = devm_clk_get(&pdev->dev, "dp");
> if (IS_ERR(dp->clock)) {
> dev_err(&pdev->dev, "failed to get clock\n");
> return PTR_ERR(dp->clock);
> @@ -881,31 +881,24 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
> clk_enable(dp->clock);
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(&pdev->dev, "failed to get registers\n");
> - ret = -EINVAL;
> - goto err_clock;
> - }
>
> dp->reg_base = devm_request_and_ioremap(&pdev->dev, res);
> if (!dp->reg_base) {
> dev_err(&pdev->dev, "failed to ioremap\n");
> - ret = -ENOMEM;
> - goto err_clock;
> + return -ENOMEM;
> }
>
> dp->irq = platform_get_irq(pdev, 0);
> if (!dp->irq) {
> dev_err(&pdev->dev, "failed to get irq\n");
> - ret = -ENODEV;
> - goto err_clock;
> + return -ENODEV;
> }
>
> ret = devm_request_irq(&pdev->dev, dp->irq, exynos_dp_irq_handler, 0,
> "exynos-dp", dp);
> if (ret) {
> dev_err(&pdev->dev, "failed to request irq\n");
> - goto err_clock;
> + return ret;
> }
>
> dp->video_info = pdata->video_info;
> @@ -917,7 +910,7 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
> ret = exynos_dp_detect_hpd(dp);
> if (ret) {
> dev_err(&pdev->dev, "unable to detect hpd\n");
> - goto err_clock;
> + return ret;
> }
>
> exynos_dp_handle_edid(dp);
> @@ -926,7 +919,7 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
> dp->video_info->link_rate);
> if (ret) {
> dev_err(&pdev->dev, "unable to do link train\n");
> - goto err_clock;
> + return ret;
> }
>
> exynos_dp_enable_scramble(dp, 1);
> @@ -940,17 +933,12 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
> ret = exynos_dp_config_video(dp, dp->video_info);
> if (ret) {
> dev_err(&pdev->dev, "unable to config video\n");
> - goto err_clock;
> + return ret;
> }
>
> platform_set_drvdata(pdev, dp);
>
> return 0;
> -
> -err_clock:
> - clk_put(dp->clock);
> -
> - return ret;
> }
>
> static int __devexit exynos_dp_remove(struct platform_device *pdev)
> @@ -962,7 +950,6 @@ static int __devexit exynos_dp_remove(struct platform_device *pdev)
> pdata->phy_exit();
>
> clk_disable(dp->clock);
> - clk_put(dp->clock);
>
> return 0;
> }
>
>
^ permalink raw reply
* Re: [PATCH] video: exynos-mipi-dsi: Add missing static storage class specifiers
From: Florian Tobias Schandinat @ 2012-08-23 20:39 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1343888051-406-1-git-send-email-sachin.kamat@linaro.org>
On 08/02/2012 06:14 AM, Sachin Kamat wrote:
> Fixes the following sparse warnings:
> drivers/video/exynos/exynos_mipi_dsi.c:208:22: warning:
> symbol 'exynos_mipi_dsi_find_lcd_device' was not declared. Should it be static?
> drivers/video/exynos/exynos_mipi_dsi.c:268:22: warning:
> symbol 'exynos_mipi_dsi_bind_lcd_ddi' was not declared. Should it be static?
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/exynos/exynos_mipi_dsi.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
> index 4bc2b8a..ef68228 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi.c
> @@ -205,7 +205,8 @@ int exynos_mipi_dsi_register_lcd_device(struct mipi_dsim_lcd_device *lcd_dev)
> return 0;
> }
>
> -struct mipi_dsim_ddi *exynos_mipi_dsi_find_lcd_device(struct mipi_dsim_lcd_driver *lcd_drv)
> +static struct mipi_dsim_ddi *exynos_mipi_dsi_find_lcd_device(
> + struct mipi_dsim_lcd_driver *lcd_drv)
> {
> struct mipi_dsim_ddi *dsim_ddi, *next;
> struct mipi_dsim_lcd_device *lcd_dev;
> @@ -265,7 +266,8 @@ int exynos_mipi_dsi_register_lcd_driver(struct mipi_dsim_lcd_driver *lcd_drv)
>
> }
>
> -struct mipi_dsim_ddi *exynos_mipi_dsi_bind_lcd_ddi(struct mipi_dsim_device *dsim,
> +static struct mipi_dsim_ddi *exynos_mipi_dsi_bind_lcd_ddi(
> + struct mipi_dsim_device *dsim,
> const char *name)
> {
> struct mipi_dsim_ddi *dsim_ddi, *next;
^ permalink raw reply
* Re: [PATCH] video: s3c-fb: use devm_clk_get()
From: Florian Tobias Schandinat @ 2012-08-23 20:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <000101cd707c$4e574450$eb05ccf0$%han@samsung.com>
On 08/02/2012 06:59 AM, Jingoo Han wrote:
> The devm_ functions allocate memory that is released when a driver
> detaches. This patch uses devm_clk_get() for these functions.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/s3c-fb.c | 24 +++++-------------------
> 1 files changed, 5 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 69bf9d0..6c95126 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -1398,17 +1398,16 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
>
> spin_lock_init(&sfb->slock);
>
> - sfb->bus_clk = clk_get(dev, "lcd");
> + sfb->bus_clk = devm_clk_get(dev, "lcd");
> if (IS_ERR(sfb->bus_clk)) {
> dev_err(dev, "failed to get bus clock\n");
> - ret = PTR_ERR(sfb->bus_clk);
> - goto err_sfb;
> + return PTR_ERR(sfb->bus_clk);
> }
>
> clk_enable(sfb->bus_clk);
>
> if (!sfb->variant.has_clksel) {
> - sfb->lcd_clk = clk_get(dev, "sclk_fimd");
> + sfb->lcd_clk = devm_clk_get(dev, "sclk_fimd");
> if (IS_ERR(sfb->lcd_clk)) {
> dev_err(dev, "failed to get lcd clock\n");
> ret = PTR_ERR(sfb->lcd_clk);
> @@ -1421,12 +1420,6 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
> pm_runtime_enable(sfb->dev);
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(dev, "failed to find registers\n");
> - ret = -ENOENT;
> - goto err_lcd_clk;
> - }
> -
> sfb->regs = devm_request_and_ioremap(dev, res);
> if (!sfb->regs) {
> dev_err(dev, "failed to map registers\n");
> @@ -1510,16 +1503,12 @@ err_pm_runtime:
> err_lcd_clk:
> pm_runtime_disable(sfb->dev);
>
> - if (!sfb->variant.has_clksel) {
> + if (!sfb->variant.has_clksel)
> clk_disable(sfb->lcd_clk);
> - clk_put(sfb->lcd_clk);
> - }
>
> err_bus_clk:
> clk_disable(sfb->bus_clk);
> - clk_put(sfb->bus_clk);
>
> -err_sfb:
> return ret;
> }
>
> @@ -1541,13 +1530,10 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
> if (sfb->windows[win])
> s3c_fb_release_win(sfb, sfb->windows[win]);
>
> - if (!sfb->variant.has_clksel) {
> + if (!sfb->variant.has_clksel)
> clk_disable(sfb->lcd_clk);
> - clk_put(sfb->lcd_clk);
> - }
>
> clk_disable(sfb->bus_clk);
> - clk_put(sfb->bus_clk);
>
> pm_runtime_put_sync(sfb->dev);
> pm_runtime_disable(sfb->dev);
^ permalink raw reply
* Re: [PATCH 1/5] drivers/video/epson1355fb.c: use devm_ functions
From: Florian Tobias Schandinat @ 2012-08-23 20:40 UTC (permalink / raw)
To: Damien Cassou
Cc: Christopher Hoover, kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1344008414-2894-2-git-send-email-damien.cassou@lifl.fr>
On 08/03/2012 03:40 PM, Damien Cassou wrote:
> From: Damien Cassou <damien.cassou@lifl.fr>
>
> The various devm_ functions allocate memory that is released when a driver
> detaches. This patch uses these functions for data that is allocated in the
> probe function of a platform device and is only freed in the remove function.
>
> Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> drivers/video/epson1355fb.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/video/epson1355fb.c b/drivers/video/epson1355fb.c
> index 68b9b51..246da1e 100644
> --- a/drivers/video/epson1355fb.c
> +++ b/drivers/video/epson1355fb.c
> @@ -592,12 +592,8 @@ static int epson1355fb_remove(struct platform_device *dev)
>
> if (info) {
> fb_dealloc_cmap(&info->cmap);
> - if (info->screen_base)
> - iounmap(info->screen_base);
> framebuffer_release(info);
> }
> - release_mem_region(EPSON1355FB_FB_PHYS, EPSON1355FB_FB_LEN);
> - release_mem_region(EPSON1355FB_REGS_PHYS, EPSON1355FB_REGS_LEN);
> return 0;
> }
>
> @@ -608,15 +604,18 @@ static int __devinit epson1355fb_probe(struct platform_device *dev)
> u8 revision;
> int rc = 0;
>
> - if (!request_mem_region(EPSON1355FB_REGS_PHYS, EPSON1355FB_REGS_LEN, "S1D13505 registers")) {
> + if (!devm_request_mem_region(&dev->dev, EPSON1355FB_REGS_PHYS,
> + EPSON1355FB_REGS_LEN,
> + "S1D13505 registers")) {
> printk(KERN_ERR "epson1355fb: unable to reserve "
> "registers at 0x%0x\n", EPSON1355FB_REGS_PHYS);
> rc = -EBUSY;
> goto bail;
> }
>
> - if (!request_mem_region(EPSON1355FB_FB_PHYS, EPSON1355FB_FB_LEN,
> - "S1D13505 framebuffer")) {
> + if (!devm_request_mem_region(&dev->dev, EPSON1355FB_FB_PHYS,
> + EPSON1355FB_FB_LEN,
> + "S1D13505 framebuffer")) {
> printk(KERN_ERR "epson1355fb: unable to reserve "
> "framebuffer at 0x%0x\n", EPSON1355FB_FB_PHYS);
> rc = -EBUSY;
> @@ -638,7 +637,8 @@ static int __devinit epson1355fb_probe(struct platform_device *dev)
> }
> info->pseudo_palette = default_par->pseudo_palette;
>
> - info->screen_base = ioremap(EPSON1355FB_FB_PHYS, EPSON1355FB_FB_LEN);
> + info->screen_base = devm_ioremap(&dev->dev, EPSON1355FB_FB_PHYS,
> + EPSON1355FB_FB_LEN);
> if (!info->screen_base) {
> printk(KERN_ERR "epson1355fb: unable to map framebuffer\n");
> rc = -ENOMEM;
>
^ permalink raw reply
* Re: [PATCH 3/5] drivers/video/jz4740_fb.c: use devm_ functions
From: Florian Tobias Schandinat @ 2012-08-23 20:41 UTC (permalink / raw)
To: Damien Cassou; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1344008414-2894-3-git-send-email-damien.cassou@lifl.fr>
On 08/03/2012 03:40 PM, Damien Cassou wrote:
> From: Damien Cassou <damien.cassou@lifl.fr>
>
> The various devm_ functions allocate memory that is released when a driver
> detaches. This patch uses these functions for data that is allocated in the
> probe function of a platform device and is only freed in the remove function.
>
> Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> drivers/video/jz4740_fb.c | 22 ++++++----------------
> 1 file changed, 6 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/video/jz4740_fb.c b/drivers/video/jz4740_fb.c
> index de36693..7669770 100644
> --- a/drivers/video/jz4740_fb.c
> +++ b/drivers/video/jz4740_fb.c
> @@ -659,25 +659,25 @@ static int __devinit jzfb_probe(struct platform_device *pdev)
> jzfb->pdata = pdata;
> jzfb->mem = mem;
>
> - jzfb->ldclk = clk_get(&pdev->dev, "lcd");
> + jzfb->ldclk = devm_clk_get(&pdev->dev, "lcd");
> if (IS_ERR(jzfb->ldclk)) {
> ret = PTR_ERR(jzfb->ldclk);
> dev_err(&pdev->dev, "Failed to get lcd clock: %d\n", ret);
> goto err_framebuffer_release;
> }
>
> - jzfb->lpclk = clk_get(&pdev->dev, "lcd_pclk");
> + jzfb->lpclk = devm_clk_get(&pdev->dev, "lcd_pclk");
> if (IS_ERR(jzfb->lpclk)) {
> ret = PTR_ERR(jzfb->lpclk);
> dev_err(&pdev->dev, "Failed to get lcd pixel clock: %d\n", ret);
> - goto err_put_ldclk;
> + goto err_framebuffer_release;
> }
>
> - jzfb->base = ioremap(mem->start, resource_size(mem));
> + jzfb->base = devm_ioremap(&pdev->dev, mem->start, resource_size(mem));
> if (!jzfb->base) {
> dev_err(&pdev->dev, "Failed to ioremap register memory region\n");
> ret = -EBUSY;
> - goto err_put_lpclk;
> + goto err_framebuffer_release;
> }
>
> platform_set_drvdata(pdev, jzfb);
> @@ -693,7 +693,7 @@ static int __devinit jzfb_probe(struct platform_device *pdev)
> ret = jzfb_alloc_devmem(jzfb);
> if (ret) {
> dev_err(&pdev->dev, "Failed to allocate video memory\n");
> - goto err_iounmap;
> + goto err_framebuffer_release;
> }
>
> fb->fix = jzfb_fix;
> @@ -734,12 +734,6 @@ err_free_devmem:
>
> fb_dealloc_cmap(&fb->cmap);
> jzfb_free_devmem(jzfb);
> -err_iounmap:
> - iounmap(jzfb->base);
> -err_put_lpclk:
> - clk_put(jzfb->lpclk);
> -err_put_ldclk:
> - clk_put(jzfb->ldclk);
> err_framebuffer_release:
> framebuffer_release(fb);
> err_release_mem_region:
> @@ -756,7 +750,6 @@ static int __devexit jzfb_remove(struct platform_device *pdev)
> jz_gpio_bulk_free(jz_lcd_ctrl_pins, jzfb_num_ctrl_pins(jzfb));
> jz_gpio_bulk_free(jz_lcd_data_pins, jzfb_num_data_pins(jzfb));
>
> - iounmap(jzfb->base);
> release_mem_region(jzfb->mem->start, resource_size(jzfb->mem));
>
> fb_dealloc_cmap(&jzfb->fb->cmap);
> @@ -764,9 +757,6 @@ static int __devexit jzfb_remove(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, NULL);
>
> - clk_put(jzfb->lpclk);
> - clk_put(jzfb->ldclk);
> -
> framebuffer_release(jzfb->fb);
>
> return 0;
>
^ permalink raw reply
* Re: [PATCH 2/5] drivers/video/bf54x-lq043fb.c: use devm_ functions
From: Florian Tobias Schandinat @ 2012-08-23 20:41 UTC (permalink / raw)
To: Damien Cassou; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1344008414-2894-4-git-send-email-damien.cassou@lifl.fr>
On 08/03/2012 03:40 PM, Damien Cassou wrote:
> From: Damien Cassou <damien.cassou@lifl.fr>
>
> The various devm_ functions allocate memory that is released when a driver
> detaches. This patch replaces the use of kzalloc by devm_kzalloc.
>
> Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> drivers/video/bf54x-lq043fb.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/bf54x-lq043fb.c b/drivers/video/bf54x-lq043fb.c
> index dc2f004..47702ee 100644
> --- a/drivers/video/bf54x-lq043fb.c
> +++ b/drivers/video/bf54x-lq043fb.c
> @@ -601,7 +601,8 @@ static int __devinit bfin_bf54x_probe(struct platform_device *pdev)
>
> fbinfo->fbops = &bfin_bf54x_fb_ops;
>
> - fbinfo->pseudo_palette = kzalloc(sizeof(u32) * 16, GFP_KERNEL);
> + fbinfo->pseudo_palette = devm_kzalloc(&pdev->dev, sizeof(u32) * 16,
> + GFP_KERNEL);
> if (!fbinfo->pseudo_palette) {
> printk(KERN_ERR DRIVER_NAME
> "Fail to allocate pseudo_palette\n");
> @@ -616,7 +617,7 @@ static int __devinit bfin_bf54x_probe(struct platform_device *pdev)
> "Fail to allocate colormap (%d entries)\n",
> BFIN_LCD_NBR_PALETTE_ENTRIES);
> ret = -EFAULT;
> - goto out5;
> + goto out4;
> }
>
> if (request_ports(info)) {
> @@ -671,8 +672,6 @@ out7:
> free_ports(info);
> out6:
> fb_dealloc_cmap(&fbinfo->cmap);
> -out5:
> - kfree(fbinfo->pseudo_palette);
> out4:
> dma_free_coherent(NULL, fbinfo->fix.smem_len, info->fb_buffer,
> info->dma_handle);
> @@ -699,7 +698,6 @@ static int __devexit bfin_bf54x_remove(struct platform_device *pdev)
> dma_free_coherent(NULL, fbinfo->fix.smem_len, info->fb_buffer,
> info->dma_handle);
>
> - kfree(fbinfo->pseudo_palette);
> fb_dealloc_cmap(&fbinfo->cmap);
>
> #ifndef NO_BL_SUPPORT
>
^ permalink raw reply
* Re: [PATCH 5/5] drivers/video/msm/mddi_client_nt35399.c: use devm_ functions
From: Florian Tobias Schandinat @ 2012-08-23 20:42 UTC (permalink / raw)
To: Damien Cassou
Cc: David Brown, kernel-janitors, Daniel Walker, Bryan Huntsman,
linux-arm-msm, linux-fbdev, linux-kernel
In-Reply-To: <1344008414-2894-5-git-send-email-damien.cassou@lifl.fr>
On 08/03/2012 03:40 PM, Damien Cassou wrote:
> From: Damien Cassou <damien.cassou@lifl.fr>
>
> The various devm_ functions allocate memory that is released when a driver
> detaches. This patch replaces the use of kzalloc by devm_kzalloc.
>
> Additionally, this patch fixes a memory leak: some memory was allocated for
> 'panel' but not released when the subsequent call to setup_vsync fails.
>
> Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> drivers/video/msm/mddi_client_nt35399.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/msm/mddi_client_nt35399.c b/drivers/video/msm/mddi_client_nt35399.c
> index 7fcd67e..66b314e 100644
> --- a/drivers/video/msm/mddi_client_nt35399.c
> +++ b/drivers/video/msm/mddi_client_nt35399.c
> @@ -189,8 +189,9 @@ static int mddi_nt35399_probe(struct platform_device *pdev)
>
> int ret;
>
> - struct panel_info *panel = kzalloc(sizeof(struct panel_info),
> - GFP_KERNEL);
> + struct panel_info *panel = devm_kzalloc(&pdev->dev,
> + sizeof(struct panel_info),
> + GFP_KERNEL);
>
> printk(KERN_DEBUG "%s: enter.\n", __func__);
>
> @@ -233,7 +234,6 @@ static int mddi_nt35399_remove(struct platform_device *pdev)
> struct panel_info *panel = platform_get_drvdata(pdev);
>
> setup_vsync(panel, 0);
> - kfree(panel);
> return 0;
> }
>
^ permalink raw reply
* Re: [PATCH] video: exynos_dp: check time loop for RPLY_RECEIV
From: Florian Tobias Schandinat @ 2012-08-23 20:42 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <003901cd7502$abac1ba0$030452e0$%han@samsung.com>
On 08/08/2012 01:10 AM, Jingoo Han wrote:
> This patch checks time loop for RPLY_RECEIV which means that
> AUX channel command reply is received.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/exynos/exynos_dp_reg.c | 10 +++++++++-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_dp_reg.c b/drivers/video/exynos/exynos_dp_reg.c
> index 2db5b9a..174c445 100644
> --- a/drivers/video/exynos/exynos_dp_reg.c
> +++ b/drivers/video/exynos/exynos_dp_reg.c
> @@ -401,6 +401,7 @@ int exynos_dp_start_aux_transaction(struct exynos_dp_device *dp)
> {
> int reg;
> int retval = 0;
> + int timeout_loop = 0;
>
> /* Enable AUX CH operation */
> reg = readl(dp->reg_base + EXYNOS_DP_AUX_CH_CTL_2);
> @@ -409,8 +410,15 @@ int exynos_dp_start_aux_transaction(struct exynos_dp_device *dp)
>
> /* Is AUX CH command reply received? */
> reg = readl(dp->reg_base + EXYNOS_DP_INT_STA);
> - while (!(reg & RPLY_RECEIV))
> + while (!(reg & RPLY_RECEIV)) {
> + timeout_loop++;
> + if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
> + dev_err(dp->dev, "AUX CH command reply failed!\n");
> + return -ETIMEDOUT;
> + }
> reg = readl(dp->reg_base + EXYNOS_DP_INT_STA);
> + usleep_range(10, 11);
> + }
>
> /* Clear interrupt source for AUX CH command reply */
> writel(RPLY_RECEIV, dp->reg_base + EXYNOS_DP_INT_STA);
^ permalink raw reply
* Re: [PATCH] video:uvesafb: check the return value of kzalloc
From: Florian Tobias Schandinat @ 2012-08-23 20:43 UTC (permalink / raw)
To: Wang YanQing, linux-fbdev, linux-kernel, spock
In-Reply-To: <20120813100232.GA16363@udknight>
On 08/13/2012 10:02 AM, Wang YanQing wrote:
>
> Michal maybe forgot it merely, we should add code
> to check the return value of kzalloc to make the
> code more robust.
>
> Signed-off-by: Wang YanQing <udknight@gmail.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/uvesafb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
> index b0e2a42..2f8f82d 100644
> --- a/drivers/video/uvesafb.c
> +++ b/drivers/video/uvesafb.c
> @@ -659,6 +659,8 @@ static int __devinit uvesafb_vbe_getedid(struct uvesafb_ktask *task,
> task->t.flags = TF_BUF_RET | TF_BUF_ESDI;
> task->t.buf_len = EDID_LENGTH;
> task->buf = kzalloc(EDID_LENGTH, GFP_KERNEL);
> + if (!task->buf)
> + return -ENOMEM;
>
> err = uvesafb_exec(task);
>
^ 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