* [patch] fbdev: ssd1307fb: potential ERR_PTR dereference
From: Dan Carpenter @ 2015-05-23 17:32 UTC (permalink / raw)
To: linux-fbdev
The error handling got shifted down a few lines from where it was
supposed to be for some reason.
Fixes: a14a7ba8cb0f ('fbdev: ssd1307fb: add backlight controls for setting the contrast')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 8fc224c..9c28a77 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -655,15 +655,16 @@ static int ssd1307fb_probe(struct i2c_client *client,
snprintf(bl_name, sizeof(bl_name), "ssd1307fb%d", info->node);
bl = backlight_device_register(bl_name, &client->dev, par,
&ssd1307fb_bl_ops, NULL);
- bl->props.brightness = par->contrast;
- bl->props.max_brightness = MAX_CONTRAST;
- info->bl_dev = bl;
-
if (IS_ERR(bl)) {
dev_err(&client->dev, "unable to register backlight device: %ld\n",
PTR_ERR(bl));
goto bl_init_error;
}
+
+ bl->props.brightness = par->contrast;
+ bl->props.max_brightness = MAX_CONTRAST;
+ info->bl_dev = bl;
+
dev_info(&client->dev, "fb%d: %s framebuffer device registered, using %d bytes of video memory\n", info->node, info->fix.id, vmem_size);
return 0;
^ permalink raw reply related
* re: fbdev: ssd1307fb: Unify init code and obtain hw specific bits from DT
From: Dan Carpenter @ 2015-05-23 17:32 UTC (permalink / raw)
To: linux-fbdev
Hello Thomas Niederprüm,
The patch a3998fe03e87: "fbdev: ssd1307fb: Unify init code and obtain
hw specific bits from DT" from Mar 31, 2015, leads to the following
static checker warning:
drivers/video/fbdev/ssd1307fb.c:371 ssd1307fb_init()
warn: add some parenthesis here?
drivers/video/fbdev/ssd1307fb.c
366 /* Set COM pins configuration */
367 ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_COM_PINS_CONFIG);
368 if (ret < 0)
369 return ret;
370
371 compins = 0x02 | (!par->com_seq & 0x1) << 4
372 | (par->com_lrremap & 0x1) << 5;
Smatch is complaining because it's normally "!par->com_seq & 0x1" is
a bug and "!(par->com_seq & 0x1)" is intended. I don't know what was
intended here though. If the current code is correct, you can silence
the static checker warning by writing it as "(!par->com_seq) & 0x1".
But I also have a hard time remembering if | or << is higher precedence
so that might be clearer with parenthesis as well even though the code
is clearly correct when I google for "order of operations" in C.
373 ret = ssd1307fb_write_cmd(par->client, compins);
374 if (ret < 0)
375 return ret;
regards,
dan carpenter
^ permalink raw reply
* Re: [patch] fbdev: ssd1307fb: potential ERR_PTR dereference
From: Maxime Ripard @ 2015-05-24 7:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150523173235.GA31595@mwanda>
[-- Attachment #1: Type: text/plain, Size: 518 bytes --]
On Sat, May 23, 2015 at 08:32:35PM +0300, Dan Carpenter wrote:
> The error handling got shifted down a few lines from where it was
> supposed to be for some reason.
>
> Fixes: a14a7ba8cb0f ('fbdev: ssd1307fb: add backlight controls for setting the contrast')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] fbdev: radeon: Remove 'struct timeval' usage
From: Tina Ruchandani @ 2015-05-25 4:19 UTC (permalink / raw)
To: Arnd Bergmann
Cc: y2038, Benjamin Herrenschmidt, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, linux-fbdev, linux-kernel
'struct timeval' uses a 32-bit representation for the
seconds field which will overflow in the year 2038 and beyond.
This patch replaces the usage of 'struct timeval' with
ktime_t which uses a 64-bit time representation and does not
suffer from the y2038 problem. This patch is part of a larger
effort to remove all instances of 'struct timeval', 'struct
timespec', time_t and other 32-bit timekeeping variables
from the kernel.
The patch also replaces the use of real time (do_gettimeofday)
with monotonic time (ktime_get).
Signed-off-by: Tina Ruchandani <ruchandani.tina@gmail.com>
---
drivers/video/fbdev/aty/radeon_base.c | 29 ++++++++++++++---------------
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/video/fbdev/aty/radeon_base.c b/drivers/video/fbdev/aty/radeon_base.c
index 01237c8..9747e9e 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -64,6 +64,7 @@
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/time.h>
+#include <linux/ktime.h>
#include <linux/fb.h>
#include <linux/ioport.h>
#include <linux/init.h>
@@ -461,8 +462,8 @@ static int radeon_probe_pll_params(struct radeonfb_info *rinfo)
int hTotal, vTotal, num, denom, m, n;
unsigned long long hz, vclk;
long xtal;
- struct timeval start_tv, stop_tv;
- long total_secs, total_usecs;
+ ktime_t start, stop;
+ s64 delta;
int i;
/* Ugh, we cut interrupts, bad bad bad, but we want some precision
@@ -478,7 +479,7 @@ static int radeon_probe_pll_params(struct radeonfb_info *rinfo)
if (((INREG(CRTC_VLINE_CRNT_VLINE) >> 16) & 0x3ff) = 0)
break;
- do_gettimeofday(&start_tv);
+ start = ktime_get();
for(i=0; i<1000000; i++)
if (((INREG(CRTC_VLINE_CRNT_VLINE) >> 16) & 0x3ff) != 0)
@@ -487,20 +488,18 @@ static int radeon_probe_pll_params(struct radeonfb_info *rinfo)
for(i=0; i<1000000; i++)
if (((INREG(CRTC_VLINE_CRNT_VLINE) >> 16) & 0x3ff) = 0)
break;
-
- do_gettimeofday(&stop_tv);
-
+
+ stop = ktime_get();
+
local_irq_enable();
- total_secs = stop_tv.tv_sec - start_tv.tv_sec;
- if (total_secs > 10)
+ delta = ktime_us_delta(stop, start);
+
+ /* Return -1 if more than 10 seconds have elapsed */
+ if (delta > (10*1000000))
return -1;
- total_usecs = stop_tv.tv_usec - start_tv.tv_usec;
- total_usecs += total_secs * 1000000;
- if (total_usecs < 0)
- total_usecs = -total_usecs;
- hz = 1000000/total_usecs;
-
+ hz = 1000000/delta;
+
hTotal = ((INREG(CRTC_H_TOTAL_DISP) & 0x1ff) + 1) * 8;
vTotal = ((INREG(CRTC_V_TOTAL_DISP) & 0x3ff) + 1);
vclk = (long long)hTotal * (long long)vTotal * hz;
@@ -548,7 +547,7 @@ static int radeon_probe_pll_params(struct radeonfb_info *rinfo)
denom *= 3;
break;
case 6:
- denom *= 6;
+ denom *= 6;
break;
case 7:
denom *= 12;
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* Re: fbdev: ssd1307fb: Unify init code and obtain hw specific bits from DT
From: Sudip Mukherjee @ 2015-05-25 5:12 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150523173245.GA31663@mwanda>
On Sat, May 23, 2015 at 08:32:45PM +0300, Dan Carpenter wrote:
> Hello Thomas Niederprüm,
> But I also have a hard time remembering if | or << is higher precedence
man page of operator (man operator) will show the precedence.
<< is higher precendence than |
regards
sudip
^ permalink raw reply
* Re: [patch] fbdev: ssd1307fb: potential ERR_PTR dereference
From: Tomi Valkeinen @ 2015-05-25 5:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150523173235.GA31595@mwanda>
[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]
On 23/05/15 20:32, Dan Carpenter wrote:
> The error handling got shifted down a few lines from where it was
> supposed to be for some reason.
>
> Fixes: a14a7ba8cb0f ('fbdev: ssd1307fb: add backlight controls for setting the contrast')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index 8fc224c..9c28a77 100644
> --- a/drivers/video/fbdev/ssd1307fb.c
> +++ b/drivers/video/fbdev/ssd1307fb.c
> @@ -655,15 +655,16 @@ static int ssd1307fb_probe(struct i2c_client *client,
> snprintf(bl_name, sizeof(bl_name), "ssd1307fb%d", info->node);
> bl = backlight_device_register(bl_name, &client->dev, par,
> &ssd1307fb_bl_ops, NULL);
> - bl->props.brightness = par->contrast;
> - bl->props.max_brightness = MAX_CONTRAST;
> - info->bl_dev = bl;
> -
> if (IS_ERR(bl)) {
> dev_err(&client->dev, "unable to register backlight device: %ld\n",
> PTR_ERR(bl));
> goto bl_init_error;
> }
> +
> + bl->props.brightness = par->contrast;
> + bl->props.max_brightness = MAX_CONTRAST;
> + info->bl_dev = bl;
> +
> dev_info(&client->dev, "fb%d: %s framebuffer device registered, using %d bytes of video memory\n", info->node, info->fix.id, vmem_size);
>
> return 0;
>
Thanks, queued for 4.2.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: omap/h3: fix tps65010 dependency
From: Tomi Valkeinen @ 2015-05-25 5:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4416278.oVFvT3Eyqf@wuerfel>
[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]
On 22/05/15 17:22, Arnd Bergmann wrote:
> The h3 LCD driver fails to link when tps65010 is configured
> as a loadable module:
>
> drivers/built-in.o: In function `h3_panel_disable':
> debugfs.c:(.text+0x206ac): undefined reference to `tps65010_set_gpio_out_value'
> debugfs.c:(.text+0x206cc): undefined reference to `tps65010_set_gpio_out_value'
> drivers/built-in.o: In function `h3_panel_enable':
> debugfs.c:(.text+0x206e0): undefined reference to `tps65010_set_gpio_out_value'
> debugfs.c:(.text+0x20704): undefined reference to `tps65010_set_gpio_out_value'
>
> This clarifies the dependency so we can only select it if
> the dependnecy is built-in.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/drivers/video/fbdev/omap/Kconfig b/drivers/video/fbdev/omap/Kconfig
> index 18c4cb0d5690..29d250da8a3e 100644
> --- a/drivers/video/fbdev/omap/Kconfig
> +++ b/drivers/video/fbdev/omap/Kconfig
> @@ -42,7 +42,7 @@ config FB_OMAP_LCD_MIPID
> config FB_OMAP_LCD_H3
> bool "TPS65010 LCD controller on OMAP-H3"
> depends on MACH_OMAP_H3
> - depends on TPS65010
> + depends on TPS65010=y
> default y
> help
> Say Y here if you want to have support for the LCD on the
>
Thanks, queued for 4.2.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] video/logo: introduce new system state for checking if logos are freed
From: Tomi Valkeinen @ 2015-05-25 5:57 UTC (permalink / raw)
To: Heiko Schocher, linux-kernel
Cc: Geert Uytterhoeven, linux-fbdev, Jean-Christophe Plagniol-Villard
In-Reply-To: <1430896145-8887-1-git-send-email-hs@denx.de>
[-- Attachment #1: Type: text/plain, Size: 3445 bytes --]
On 06/05/15 10:09, Heiko Schocher wrote:
> commit 92b004d1aa9f ("video/logo: prevent use of logos after they have been freed")
>
> added a late_initcall function to mark the logos as freed. In reality
> the logos are freed later, and fbdev probe may be ran between this
> late_initcall and the freeing of the logos. In that case the logos
> would not be drawn. To prevent this introduced a new system_state
> SYSTEM_FREEING_MEM and set this state before freeing memory. This
> state could be checked now in fb_find_logo(). This system state
> is maybe useful on other places too.
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
>
> ---
> Found this issue on an imx6 based board with a display which needs
> a spi initialization. With 3.18.2 I see a perfect logo, but with
> current ml, bootlogo is missing, because drm gets probed before
> spi display, which leads in drm probing is deferred until the
> spi display is probed. After that drm is probed again ... but
> this is too late for showing the bootlogo.
> With this patch, bootlogo is drawn again. I am not sure, if it
> is so easy to add a new system state ... but we should have a
> possibility to detect if initdata is freed or not. this is maybe
> also for other modules interesting. Maybe we add a
> kernel_initdata_freed()
> function instead of a new system state?
>
> drivers/video/logo/logo.c | 15 ++++-----------
> include/linux/kernel.h | 1 +
> init/main.c | 1 +
> 3 files changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/video/logo/logo.c b/drivers/video/logo/logo.c
> index 10fbfd8..d798a9f 100644
> --- a/drivers/video/logo/logo.c
> +++ b/drivers/video/logo/logo.c
> @@ -26,16 +26,6 @@ MODULE_PARM_DESC(nologo, "Disables startup logo");
> * Use late_init to mark the logos as freed to prevent any further use.
> */
>
> -static bool logos_freed;
> -
> -static int __init fb_logo_late_init(void)
> -{
> - logos_freed = true;
> - return 0;
> -}
> -
> -late_initcall(fb_logo_late_init);
> -
> /* logo's are marked __initdata. Use __init_refok to tell
> * modpost that it is intended that this function uses data
> * marked __initdata.
> @@ -44,7 +34,10 @@ const struct linux_logo * __init_refok fb_find_logo(int depth)
> {
> const struct linux_logo *logo = NULL;
>
> - if (nologo || logos_freed)
> + if (system_state >= SYSTEM_FREEING_MEM)
> + return NULL;
> +
> + if (nologo)
> return NULL;
>
> if (depth >= 1) {
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 3a5b48e..e5875bf 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -462,6 +462,7 @@ extern bool early_boot_irqs_disabled;
> /* Values used for system_state */
> extern enum system_states {
> SYSTEM_BOOTING,
> + SYSTEM_FREEING_MEM,
> SYSTEM_RUNNING,
> SYSTEM_HALT,
> SYSTEM_POWER_OFF,
> diff --git a/init/main.c b/init/main.c
> index 2115055..4965ed0 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -931,6 +931,7 @@ static int __ref kernel_init(void *unused)
> kernel_init_freeable();
> /* need to finish all async __init code before freeing the memory */
> async_synchronize_full();
> + system_state = SYSTEM_FREEING_MEM;
> free_initmem();
> mark_rodata_ro();
> system_state = SYSTEM_RUNNING;
Without locking, the initmem may be freed while fb_find_logo() is running.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: fbdev: ssd1307fb: Unify init code and obtain hw specific bits from DT
From: Thomas Niederprüm @ 2015-05-25 7:34 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150523173245.GA31663@mwanda>
Am Sat, 23 May 2015 20:32:45 +0300
schrieb Dan Carpenter <dan.carpenter@oracle.com>:
> Hello Thomas Niederprüm,
>
> The patch a3998fe03e87: "fbdev: ssd1307fb: Unify init code and obtain
> hw specific bits from DT" from Mar 31, 2015, leads to the following
> static checker warning:
>
> drivers/video/fbdev/ssd1307fb.c:371 ssd1307fb_init()
> warn: add some parenthesis here?
>
> drivers/video/fbdev/ssd1307fb.c
> 366 /* Set COM pins configuration */
> 367 ret = ssd1307fb_write_cmd(par->client,
> SSD1307FB_SET_COM_PINS_CONFIG); 368 if (ret < 0)
> 369 return ret;
> 370
> 371 compins = 0x02 | (!par->com_seq & 0x1) << 4
> 372 | (par->com_lrremap & 0x1)
> << 5;
>
> Smatch is complaining because it's normally "!par->com_seq & 0x1" is
> a bug and "!(par->com_seq & 0x1)" is intended. I don't know what was
> intended here though. If the current code is correct, you can silence
> the static checker warning by writing it as "(!par->com_seq) & 0x1".
Indeed "!(par->com_seq & 0x1)" is what I intended. Thanks for spotting
this.
What is the best way to handle this now? Will you send a fixup
patch as for the backlight code or will this be my task?
>
> But I also have a hard time remembering if | or << is higher
> precedence so that might be clearer with parenthesis as well even
> though the code is clearly correct when I google for "order of
> operations" in C.
>
> 373 ret = ssd1307fb_write_cmd(par->client, compins);
> 374 if (ret < 0)
> 375 return ret;
>
Thanks!
Thomas
^ permalink raw reply
* Re: fbdev: ssd1307fb: Unify init code and obtain hw specific bits from DT
From: Dan Carpenter @ 2015-05-25 9:48 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150523173245.GA31663@mwanda>
On Mon, May 25, 2015 at 10:30:38AM +0530, Sudip Mukherjee wrote:
> On Sat, May 23, 2015 at 08:32:45PM +0300, Dan Carpenter wrote:
> > Hello Thomas Niederprüm,
>
> > But I also have a hard time remembering if | or << is higher precedence
>
> man page of operator (man operator) will show the precedence.
> << is higher precendence than |
The point is that people should just use parenthesis when it's not
something that's obvious.
Also the more I think about it, writing "!par->com_seq & 0x1" is
nonsense. If that's really what was intended then just say
"!par->com_seq". I think it's a bug though and "!(par->com_seq & 0x1)"
is intended.
regards,
dan carpenter
^ permalink raw reply
* Re: fbdev: ssd1307fb: Unify init code and obtain hw specific bits from DT
From: Dan Carpenter @ 2015-05-25 10:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150523173245.GA31663@mwanda>
On Mon, May 25, 2015 at 09:34:32AM +0200, Thomas Niederprüm wrote:
> Am Sat, 23 May 2015 20:32:45 +0300
> schrieb Dan Carpenter <dan.carpenter@oracle.com>:
>
> > Hello Thomas Niederprüm,
> >
> > The patch a3998fe03e87: "fbdev: ssd1307fb: Unify init code and obtain
> > hw specific bits from DT" from Mar 31, 2015, leads to the following
> > static checker warning:
> >
> > drivers/video/fbdev/ssd1307fb.c:371 ssd1307fb_init()
> > warn: add some parenthesis here?
> >
> > drivers/video/fbdev/ssd1307fb.c
> > 366 /* Set COM pins configuration */
> > 367 ret = ssd1307fb_write_cmd(par->client,
> > SSD1307FB_SET_COM_PINS_CONFIG); 368 if (ret < 0)
> > 369 return ret;
> > 370
> > 371 compins = 0x02 | (!par->com_seq & 0x1) << 4
> > 372 | (par->com_lrremap & 0x1)
> > << 5;
> >
> > Smatch is complaining because it's normally "!par->com_seq & 0x1" is
> > a bug and "!(par->com_seq & 0x1)" is intended. I don't know what was
> > intended here though. If the current code is correct, you can silence
> > the static checker warning by writing it as "(!par->com_seq) & 0x1".
>
> Indeed "!(par->com_seq & 0x1)" is what I intended. Thanks for spotting
> this.
> What is the best way to handle this now? Will you send a fixup
> patch as for the backlight code or will this be my task?
Could you send a fix and give me a:
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
cookie?
regards,
dan carpenter
^ permalink raw reply
* [PATCH 00/21] On-demand device registration
From: Tomeu Vizoso @ 2015-05-25 14:53 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Stéphane Marchesin, Thierry Reding, Dmitry Torokhov,
Alexander Holler, Grant Likely, Rob Herring, Mark Rutland,
Tomeu Vizoso, Dan Williams, devicetree, dmaengine, dri-devel,
linux-clk, linux-fbdev, linux-gpio, linux-i2c, linux-kernel,
linux-pm, linux-pwm, linux-samsung-soc, linux-tegra, linux-usb
Hello,
I have a problem with the panel on my Tegra Chromebook taking longer than
expected to be ready during boot (Stéphane Marchesin reported what is
basically the same issue in [0]), and have looked into ordered probing as a
better way of solving this than moving nodes around in the DT or playing with
initcall levels.
While reading the thread [1] that Alexander Holler started with his series to
make probing order deterministic, it occurred to me that it should be possible
to achieve the same by registering devices as they are referenced by other
devices.
This basically reuses the information that is already implicit in the probe()
implementations, saving us from refactoring existing drivers or adding
information to DTBs.
Something I'm not completely happy with is that I have had to move the call to
of_platform_populate after all platform drivers have been registered.
Otherwise I don't see how I could register drivers on demand as we don't have
yet each driver's compatible strings.
For machs that don't move of_platform_populate() to a later point, these
patches shouldn't cause any problems but it's not guaranteed that we'll avoid
all the deferred probes as some drivers may not be registered yet.
I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these
patches were enough to eliminate all the deferred probes.
With this series I get the kernel to output to the panel in 0.5s, instead of 2.8s.
Regards,
Tomeu
[0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html
[1] https://lkml.org/lkml/2014/5/12/452
Tomeu Vizoso (21):
regulator: core: Reduce critical area in _regulator_get
ARM: tegra: Add gpio-ranges property
ARM: tegra: Register drivers before devices
ARM: EXYNOS: Register drivers before devices
ARM i.MX6q: Register drivers before devices
of/platform: Add of_platform_device_ensure()
of/platform: Ensure device registration on lookup
gpio: Probe GPIO drivers on demand
gpio: Probe pinctrl devices on demand
regulator: core: Probe regulators on demand
drm: Probe panels on demand
drm/tegra: Probe dpaux devices on demand
i2c: core: Probe i2c master devices on demand
pwm: Probe PWM chip devices on demand
backlight: Probe backlight devices on demand
usb: phy: Probe phy devices on demand
clk: Probe clk providers on demand
pinctrl: Probe pinctrl devices on demand
phy: core: Probe phy providers on demand
dma: of: Probe DMA controllers on demand
power-supply: Probe power supplies on demand
arch/arm/boot/dts/tegra124.dtsi | 1 +
arch/arm/mach-exynos/exynos.c | 4 +--
arch/arm/mach-imx/mach-imx6q.c | 12 ++++-----
arch/arm/mach-tegra/tegra.c | 21 ++++++---------
drivers/clk/clk.c | 3 +++
drivers/dma/of-dma.c | 3 +++
drivers/gpio/gpiolib-of.c | 5 ++++
drivers/gpu/drm/drm_panel.c | 3 +++
drivers/gpu/drm/tegra/dpaux.c | 3 +++
drivers/i2c/i2c-core.c | 3 +++
drivers/of/platform.c | 53 +++++++++++++++++++++++++++++++++++++
drivers/phy/phy-core.c | 3 +++
drivers/pinctrl/devicetree.c | 2 ++
drivers/power/power_supply_core.c | 3 +++
drivers/pwm/core.c | 3 +++
drivers/regulator/core.c | 45 +++++++++++++++----------------
drivers/usb/phy/phy.c | 3 +++
drivers/video/backlight/backlight.c | 3 +++
include/linux/of_platform.h | 2 ++
19 files changed, 130 insertions(+), 45 deletions(-)
--
2.4.1
^ permalink raw reply
* [PATCH 15/21] backlight: Probe backlight devices on demand
From: Tomeu Vizoso @ 2015-05-25 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1432565608-26036-1-git-send-email-tomeu.vizoso@collabora.com>
When looking up a backlight device through its DT node, ensure that the
corresponding device has been registered.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
---
drivers/video/backlight/backlight.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index bddc8b1..fe7833b 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -12,6 +12,7 @@
#include <linux/device.h>
#include <linux/backlight.h>
#include <linux/notifier.h>
+#include <linux/of_platform.h>
#include <linux/ctype.h>
#include <linux/err.h>
#include <linux/fb.h>
@@ -559,6 +560,8 @@ struct backlight_device *of_find_backlight_by_node(struct device_node *node)
{
struct device *dev;
+ of_platform_device_ensure(node);
+
dev = class_find_device(backlight_class, NULL, node, of_parent_match);
return dev ? to_backlight_device(dev) : NULL;
--
2.4.1
^ permalink raw reply related
* [PATCH] fbdev: ssd1307fb: fix logical error
From: Thomas Niederprüm @ 2015-05-25 19:29 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, maxime.ripard, kernel, dan.carpenter,
prabhakar.csengg
Cc: linux-fbdev, linux-kernel, Thomas Niederprüm
The logical not needs to be done after the bit masking.
Fixes: a3998fe03e87 ("fbdev: ssd1307fb: Unify init code and obtain
hw specific bits from DT")
Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
---
drivers/video/fbdev/ssd1307fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 8fc224c..9771d56 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -368,7 +368,7 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
if (ret < 0)
return ret;
- compins = 0x02 | (!par->com_seq & 0x1) << 4
+ compins = 0x02 | !(par->com_seq & 0x1) << 4
| (par->com_lrremap & 0x1) << 5;
ret = ssd1307fb_write_cmd(par->client, compins);
if (ret < 0)
--
2.3.0
^ permalink raw reply related
* Re: [PATCHv3 1/4] phy: phy-core: Make GENERIC_PHY an invisible option
From: Arun Ramamurthy @ 2015-05-25 21:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20150515005210.GA31534@saruman.tx.rr.com>
On 15-05-14 05:52 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Apr 22, 2015 at 04:04:10PM -0700, Arun Ramamurthy wrote:
>> Most of the phy providers use "select" to enable GENERIC_PHY. Since select
>> is only recommended when the config is not visible, GENERIC_PHY is changed
>> an invisible option. To maintain consistency, all phy providers are changed
>> to "select" GENERIC_PHY and all non-phy drivers use "depends on" when the
>> phy framework is explicity required. USB_MUSB_OMAP2PLUS has a cyclic
>> dependency, so it is left as "select".
>>
>> Signed-off-by: Arun Ramamurthy <arun.ramamurthy@broadcom.com>
>> ---
>> drivers/ata/Kconfig | 1 -
>> drivers/media/platform/exynos4-is/Kconfig | 2 +-
>> drivers/phy/Kconfig | 4 ++--
>> drivers/usb/host/Kconfig | 4 ++--
>> drivers/video/fbdev/exynos/Kconfig | 2 +-
>> 5 files changed, 6 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
>> index 5f60155..6d2e881 100644
>> --- a/drivers/ata/Kconfig
>> +++ b/drivers/ata/Kconfig
>> @@ -301,7 +301,6 @@ config SATA_MV
>> tristate "Marvell SATA support"
>> depends on PCI || ARCH_DOVE || ARCH_MV78XX0 || \
>> ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST
>> - select GENERIC_PHY
>> help
>> This option enables support for the Marvell Serial ATA family.
>> Currently supports 88SX[56]0[48][01] PCI(-X) chips,
>> diff --git a/drivers/media/platform/exynos4-is/Kconfig b/drivers/media/platform/exynos4-is/Kconfig
>> index b7b2e47..b6f3eaa 100644
>> --- a/drivers/media/platform/exynos4-is/Kconfig
>> +++ b/drivers/media/platform/exynos4-is/Kconfig
>> @@ -31,7 +31,7 @@ config VIDEO_S5P_FIMC
>> config VIDEO_S5P_MIPI_CSIS
>> tristate "S5P/EXYNOS MIPI-CSI2 receiver (MIPI-CSIS) driver"
>> depends on REGULATOR
>> - select GENERIC_PHY
>> + depends on GENERIC_PHY
>> help
>> This is a V4L2 driver for Samsung S5P and EXYNOS4 SoC MIPI-CSI2
>> receiver (MIPI-CSIS) devices.
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 2962de2..edecdb1 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -5,7 +5,7 @@
>> menu "PHY Subsystem"
>>
>> config GENERIC_PHY
>> - bool "PHY Core"
>> + bool
>> help
>> Generic PHY support.
>>
>> @@ -72,7 +72,7 @@ config PHY_MIPHY365X
>> config PHY_RCAR_GEN2
>> tristate "Renesas R-Car generation 2 USB PHY driver"
>> depends on ARCH_SHMOBILE
>> - depends on GENERIC_PHY
>> + select GENERIC_PHY
>
> so some you changed from depends to select...
>
>> help
>> Support for USB PHY found on Renesas R-Car generation 2 SoCs.
>>
>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>> index 5ad60e4..e2197e2 100644
>> --- a/drivers/usb/host/Kconfig
>> +++ b/drivers/usb/host/Kconfig
>> @@ -182,7 +182,7 @@ config USB_EHCI_HCD_SPEAR
>> config USB_EHCI_HCD_STI
>> tristate "Support for ST STiHxxx on-chip EHCI USB controller"
>> depends on ARCH_STI && OF
>> - select GENERIC_PHY
>> + depends on GENERIC_PHY
>
> while others you changed from select to depends.
>
> NAK.
>
Felipe, I dont understand your concern, could you please explain it more
detail? The logic behind the changes is that in cases where there was
an explicit dependency, I changed it to "depends on" and in other cases
I changed it to "selects". Thanks
^ permalink raw reply
* [PATCH v4 0/3] USB PHY driver for Broadcom's Cygnus chipset
From: Arun Ramamurthy @ 2015-05-25 22:36 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: devicetree, linux-kernel, linux-fbdev, Dmitry Torokhov,
Anatol Pomazau, Jonathan Richardson, Scott Branden, Ray Jui,
bcm-kernel-feedback-list, Arun Ramamurthy
This patchset adds the USB phy driver and documentation
for Broadom's Cygnus chipset. The phy is configurable from device tree
and is capable of both device and host functions. It also provides
a clock and reset to the host controller
History:
v1:
- Included Dmitry Torokhov's patch that addresed Kishon Vijay Abraham's
comments on multiple phy model
- Inlucded Dmitry Torokhov's patch to use phy regulator
- Addressed Arnd Bergmann's comments on usage of this phy driver by
ehci-platform and ohci-platform driver in a separate patchset.
v2:
- Addressed Kishon's comments on documentation and function names
- Dmitry Addressed Kishon's comments on per port phy regulators
v3:
- Addressed Kishon's comments on error code in phy driver and multi level
if else statements
- Corrected documentation to use defines for constants
- Corrected commit log for phy regulator patch
v4:
- Refactored define for constants in dt
- Removed reduant code in driver
Arun Ramamurthy (3):
phy: phy-core: allow specifying supply at port level
Phy: DT binding documentation for Broadcom Cygnus USB PHY driver
phy: cygnus-usbphy: Add Broadcom Cygnus USB phy driver
.../bindings/phy/brcm,cygnus-usb-phy.txt | 69 +++
drivers/phy/Kconfig | 12 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-bcm-cygnus-usb.c | 499 +++++++++++++++++++++
drivers/phy/phy-core.c | 23 +-
include/dt-bindings/phy/phy.h | 2 +
6 files changed, 593 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/brcm,cygnus-usb-phy.txt
create mode 100644 drivers/phy/phy-bcm-cygnus-usb.c
--
2.3.4
^ permalink raw reply
* [PATCH v4 1/3] phy: phy-core: allow specifying supply at port level
From: Arun Ramamurthy @ 2015-05-25 22:36 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: devicetree, linux-kernel, linux-fbdev, Dmitry Torokhov,
Anatol Pomazau, Jonathan Richardson, Scott Branden, Ray Jui,
bcm-kernel-feedback-list, Dmitry Torokhov, Arun Ramamurthy
In-Reply-To: <1432593370-14457-1-git-send-email-arun.ramamurthy@broadcom.com>
From: Dmitry Torokhov <dtor@chromium.org>
Multi-port phys may have per port power supplies. Let's change phy
core to look for supply at the port level when multiple ports are
specified. To keep compatibility with the existing device tree board
descriptions for single-port phys we will continue looking up the
power supply at the parent node level
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Signed-off-by: Arun Ramamurthy <arun.ramamurthy@broadcom.com>
Reviewed-by: Ray Jui <rjui@broadcom.com>
Reviewed-by: Scott Branden <sbranden@broadcom.com>
---
drivers/phy/phy-core.c | 23 ++++++++++-------------
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 3791838..c7aa297 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -651,16 +651,6 @@ struct phy *phy_create(struct device *dev, struct device_node *node,
goto free_phy;
}
- /* phy-supply */
- phy->pwr = regulator_get_optional(dev, "phy");
- if (IS_ERR(phy->pwr)) {
- if (PTR_ERR(phy->pwr) = -EPROBE_DEFER) {
- ret = -EPROBE_DEFER;
- goto free_ida;
- }
- phy->pwr = NULL;
- }
-
device_initialize(&phy->dev);
mutex_init(&phy->mutex);
@@ -674,6 +664,16 @@ struct phy *phy_create(struct device *dev, struct device_node *node,
if (ret)
goto put_dev;
+ /* phy-supply */
+ phy->pwr = regulator_get_optional(&phy->dev, "phy");
+ if (IS_ERR(phy->pwr)) {
+ ret = PTR_ERR(phy->pwr);
+ if (ret = -EPROBE_DEFER)
+ goto put_dev;
+
+ phy->pwr = NULL;
+ }
+
ret = device_add(&phy->dev);
if (ret)
goto put_dev;
@@ -689,9 +689,6 @@ put_dev:
put_device(&phy->dev); /* calls phy_release() which frees resources */
return ERR_PTR(ret);
-free_ida:
- ida_simple_remove(&phy_ida, phy->id);
-
free_phy:
kfree(phy);
return ERR_PTR(ret);
--
2.3.4
^ permalink raw reply related
* [PATCH v4 2/3] Phy: DT binding documentation for Broadcom Cygnus USB PHY driver
From: Arun Ramamurthy @ 2015-05-25 22:36 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Dmitry Torokhov,
Anatol Pomazau, Jonathan Richardson, Scott Branden, Ray Jui,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Arun Ramamurthy
In-Reply-To: <1432593370-14457-1-git-send-email-arun.ramamurthy-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Broadcom's Cygnus chip has a USB 2.0 host controller connected to
three separate phys. One of the phs (port 2) is also connectd to
a usb 2.0 device controller
Signed-off-by: Arun Ramamurthy <arun.ramamurthy@broadcom.com>
Reviewed-by: Ray Jui <rjui@broadcom.com>
Reviewed-by: Scott Branden <sbranden@broadcom.com>
---
.../bindings/phy/brcm,cygnus-usb-phy.txt | 69 ++++++++++++++++++++++
include/dt-bindings/phy/phy.h | 2 +
2 files changed, 71 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/brcm,cygnus-usb-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/brcm,cygnus-usb-phy.txt b/Documentation/devicetree/bindings/phy/brcm,cygnus-usb-phy.txt
new file mode 100644
index 0000000..ec62044
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,cygnus-usb-phy.txt
@@ -0,0 +1,69 @@
+BROADCOM CYGNUS USB PHY
+
+Required Properties:
+ - compatible: brcm,cygnus-usb-phy
+ - reg : usbphy_regs - Base address of phy registers
+ usb2h_idm_regs - Base address of host idm registers
+ usb2d_idm_regs - Base address of device idm registers
+ - phy-cells - must be 1 for each port declared. The node
+ that uses the phy must provide either PHY_CONFIG_DEVICE for device
+ or PHY_CONFIG_HOST for host
+
+NOTE: port 0 and port 1 are host only and port 2 can be configured for host or
+device.
+
+Example of phy :
+ usbphy0: usbphy@0x0301c000 {
+ compatible = "brcm,cygnus-usb-phy";
+ reg = <0x0301c000 0x2000>,
+ <0x18115000 0x1000>,
+ <0x18111000 0x1000>;
+ status = "okay";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ usbphy0_0: usbphy0@0 {
+ #phy-cells = <1>;
+ reg = <0>;
+ status = "okay";
+ phy-supply = <&vbus_p0>;
+ };
+
+ usbphy0_1: usbphy0@1 {
+ #phy-cells = <1>;
+ reg = <1>;
+ status = "okay";
+ };
+
+ usbphy0_2: usbphy0@2 {
+ #phy-cells = <1>;
+ reg = <2>;
+ status = "okay";
+ phy-supply = <&vbus_p2>;
+ };
+ };
+
+Example of node using the phy:
+
+ /* This nodes declares all three ports as host */
+
+ ehci0: usb@0x18048000 {
+ compatible = "generic-ehci";
+ reg = <0x18048000 0x100>;
+ interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&usbphy0_0 PHY_CONFIG_HOST &usbphy0_1 PHY_CONFIG_HOST &usbphy0_2 PHY_CONFIG_HOST>;
+ status = "okay";
+ };
+
+ /*
+ * This node declares port 2 phy
+ * and configures it for device
+ */
+
+ usbd_udc_dwc1: usbd_udc_dwc@0x1804c000 {
+ compatible = "iproc-udc";
+ reg = <0x1804c000 0x2000>;
+ interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&usbphy0_2 PHY_CONFIG_DEVICE>;
+ phy-names = "usb";
+ };
diff --git a/include/dt-bindings/phy/phy.h b/include/dt-bindings/phy/phy.h
index 6c90193..a5babbc 100644
--- a/include/dt-bindings/phy/phy.h
+++ b/include/dt-bindings/phy/phy.h
@@ -15,5 +15,7 @@
#define PHY_TYPE_PCIE 2
#define PHY_TYPE_USB2 3
#define PHY_TYPE_USB3 4
+#define PHY_USB2_CONFIG_HOST 0
+#define PHY_USB2_CONFIG_DEVICE 1
#endif /* _DT_BINDINGS_PHY */
--
2.3.4
^ permalink raw reply related
* [PATCH v4 3/3] phy: cygnus-usbphy: Add Broadcom Cygnus USB phy driver
From: Arun Ramamurthy @ 2015-05-25 22:36 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: devicetree, linux-kernel, linux-fbdev, Dmitry Torokhov,
Anatol Pomazau, Jonathan Richardson, Scott Branden, Ray Jui,
bcm-kernel-feedback-list, Arun Ramamurthy, Dmitry Torokhov
In-Reply-To: <1432593370-14457-1-git-send-email-arun.ramamurthy@broadcom.com>
This driver adds support for USB 2.0 host and device phy for
Broadcom's Cygnus chipset. The host controller is connected to
three separate phys and one of the phys (port 2) is connected to
the device controller
Signed-off-by: Arun Ramamurthy <arun.ramamurthy@broadcom.com>
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Ray Jui <rjui@broadcom.com>
Reviewed-by: Scott Branden <sbranden@broadcom.com>
---
drivers/phy/Kconfig | 12 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-bcm-cygnus-usb.c | 499 +++++++++++++++++++++++++++++++++++++++
3 files changed, 512 insertions(+)
create mode 100644 drivers/phy/phy-bcm-cygnus-usb.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index a53bd5b..c35a3fd 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -309,4 +309,16 @@ config PHY_QCOM_UFS
help
Support for UFS PHY on QCOM chipsets.
+config PHY_BCM_CYGNUS_USB
+ tristate "Broadcom Cygnus USB PHY support"
+ depends on OF
+ depends on ARCH_BCM_CYGNUS || COMPILE_TEST
+ select GENERIC_PHY
+ default ARCH_BCM_CYGNUS
+ help
+ Enable this to support the USB PHY in Broadcom's Cygnus chip.
+ The phys are capable of supporting host mode for all ports
+ and device mode for port 2. The host or device configuration is
+ read from the device tree.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index f126251..7f2a1c7 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
obj-$(CONFIG_PHY_BERLIN_SATA) += phy-berlin-sata.o
obj-$(CONFIG_PHY_DM816X_USB) += phy-dm816x-usb.o
obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
+obj-$(CONFIG_PHY_BCM_CYGNUS_USB) += phy-bcm-cygnus-usb.o
obj-$(CONFIG_BCM_KONA_USB2_PHY) += phy-bcm-kona-usb2.o
obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
diff --git a/drivers/phy/phy-bcm-cygnus-usb.c b/drivers/phy/phy-bcm-cygnus-usb.c
new file mode 100644
index 0000000..53c52e4
--- /dev/null
+++ b/drivers/phy/phy-bcm-cygnus-usb.c
@@ -0,0 +1,499 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/delay.h>
+
+#define CDRU_USBPHY_CLK_RST_SEL_OFFSET 0x11b4
+#define CDRU_USBPHY2_HOST_DEV_SEL_OFFSET 0x11b8
+#define CDRU_SPARE_REG_0_OFFSET 0x1238
+#define CRMU_USB_PHY_AON_CTRL_OFFSET 0x00028
+#define CDRU_USB_DEV_SUSPEND_RESUME_CTRL_OFFSET 0x1210
+#define CDRU_USBPHY_P0_STATUS_OFFSET 0x11D0
+#define CDRU_USBPHY_P1_STATUS_OFFSET 0x11E8
+#define CDRU_USBPHY_P2_STATUS_OFFSET 0x1200
+#define CDRU_USBPHY_USBPHY_ILDO_ON_FLAG 1
+#define CDRU_USBPHY_USBPHY_PLL_LOCK 0
+#define CDRU_USB_DEV_SUSPEND_RESUME_CTRL_DISABLE 0
+#define PHY2_DEV_HOST_CTRL_SEL_HOST 1
+
+#define CRMU_USBPHY_P0_AFE_CORERDY_VDDC 1
+#define CRMU_USBPHY_P0_RESETB 2
+#define CRMU_USBPHY_P1_AFE_CORERDY_VDDC 9
+#define CRMU_USBPHY_P1_RESETB 10
+#define CRMU_USBPHY_P2_AFE_CORERDY_VDDC 17
+#define CRMU_USBPHY_P2_RESETB 18
+
+#define USB2_IDM_IDM_IO_CONTROL_DIRECT_OFFSET 0x0408
+#define USB2_IDM_IDM_IO_CONTROL_DIRECT__CLK_ENABLE 0
+#define USB2_IDM_IDM_RESET_CONTROL_OFFSET 0x0800
+#define USB2_IDM_IDM_RESET_CONTROL__RESET 0
+
+#define PLL_LOCK_RETRY_COUNT 1000
+#define MAX_PHY_PORTS 3
+
+static int power_bit[] = {CRMU_USBPHY_P0_AFE_CORERDY_VDDC,
+ CRMU_USBPHY_P1_AFE_CORERDY_VDDC,
+ CRMU_USBPHY_P2_AFE_CORERDY_VDDC};
+static int reset_bit[] = {CRMU_USBPHY_P0_RESETB,
+ CRMU_USBPHY_P1_RESETB,
+ CRMU_USBPHY_P2_RESETB};
+static int status_reg[] = {CDRU_USBPHY_P0_STATUS_OFFSET,
+ CDRU_USBPHY_P1_STATUS_OFFSET,
+ CDRU_USBPHY_P2_STATUS_OFFSET};
+
+struct bcm_phy_instance;
+
+struct bcm_phy_driver {
+ void __iomem *usbphy_regs;
+ void __iomem *usb2h_idm_regs;
+ void __iomem *usb2d_idm_regs;
+ struct bcm_phy_instance *ports[MAX_PHY_PORTS];
+ spinlock_t lock;
+ bool idm_host_enabled;
+};
+
+struct bcm_phy_instance {
+ struct bcm_phy_driver *driver;
+ struct phy *generic_phy;
+ int port_no;
+ bool host_mode; /* true - Host, false - device */
+ bool power;
+};
+
+static inline int bcm_phy_cdru_usbphy_status_wait(u32 usb_reg, int reg_bit,
+ struct bcm_phy_driver *phy_driver)
+{
+ /* Wait for the PLL lock status */
+ int retry = PLL_LOCK_RETRY_COUNT;
+ u32 reg_val;
+
+ do {
+ udelay(1);
+ reg_val = readl(phy_driver->usbphy_regs +
+ usb_reg);
+ if (reg_val & (1 << reg_bit))
+ return 0;
+ } while (--retry > 0);
+
+ return -EBUSY;
+
+}
+
+static struct phy *bcm_usb_phy_xlate(struct device *dev,
+ struct of_phandle_args *args)
+{
+ struct bcm_phy_driver *phy_driver = dev_get_drvdata(dev);
+ struct bcm_phy_instance *port = NULL;
+ int i;
+
+ if (!phy_driver)
+ return ERR_PTR(-ENODEV);
+
+ if (WARN_ON(args->args_count != 1))
+ return ERR_PTR(-ENODEV);
+
+ if (WARN_ON(args->args[0] < 0 || args->args[0] > 1))
+ return ERR_PTR(-ENODEV);
+
+ for (i = 0; i < ARRAY_SIZE(phy_driver->ports); i++) {
+ struct bcm_phy_instance *p = phy_driver->ports[i];
+
+ if (p && p->generic_phy->dev.of_node = args->np) {
+ port = p;
+ break;
+ }
+ }
+
+ if (!port) {
+ dev_err(dev, "Failed to locate phy %s\n", args->np->name);
+ return ERR_PTR(-EINVAL);
+ }
+
+ port->host_mode = args->args[0];
+
+ return port->generic_phy;
+}
+
+static int bcm_phy_init(struct phy *generic_phy)
+{
+ struct bcm_phy_instance *port = phy_get_drvdata(generic_phy);
+ struct bcm_phy_driver *phy_driver = port->driver;
+ unsigned long flags;
+ u32 reg_val;
+
+ spin_lock_irqsave(&phy_driver->lock, flags);
+
+ /*
+ * Only PORT 2 is capable of being device and host
+ * Default setting is device, check if it is set to host.
+ */
+ if (port->port_no != 2)
+ goto exit;
+
+ if (port->host_mode) {
+ writel(PHY2_DEV_HOST_CTRL_SEL_HOST,
+ phy_driver->usbphy_regs +
+ CDRU_USBPHY2_HOST_DEV_SEL_OFFSET);
+ } else {
+ /*
+ * Disable suspend/resume signals to device controller
+ * when a port is in device mode.
+ */
+ reg_val = readl(phy_driver->usbphy_regs +
+ CDRU_USB_DEV_SUSPEND_RESUME_CTRL_OFFSET);
+ reg_val |+ 1 << CDRU_USB_DEV_SUSPEND_RESUME_CTRL_DISABLE;
+ writel(reg_val, phy_driver->usbphy_regs +
+ CDRU_USB_DEV_SUSPEND_RESUME_CTRL_OFFSET);
+ }
+exit:
+ spin_unlock_irqrestore(&phy_driver->lock, flags);
+ return 0;
+}
+
+static int bcm_phy_shutdown(struct phy *generic_phy)
+{
+ struct bcm_phy_instance *port = phy_get_drvdata(generic_phy);
+ struct bcm_phy_driver *phy_driver = port->driver;
+ unsigned long flags;
+ int i;
+ u32 reg_val, powered_on_phy = -1;
+ bool power_off_flag = true;
+
+ spin_lock_irqsave(&phy_driver->lock, flags);
+
+ /* power down the phy */
+ reg_val = readl(phy_driver->usbphy_regs +
+ CRMU_USB_PHY_AON_CTRL_OFFSET);
+ reg_val &= ~(1 << power_bit[port->port_no]);
+ reg_val &= ~(1 << reset_bit[port->port_no]);
+ writel(reg_val, phy_driver->usbphy_regs +
+ CRMU_USB_PHY_AON_CTRL_OFFSET);
+ port->power = false;
+
+ /*
+ * If a port is configured to device and it is being shutdown,
+ * turn off the clocks to the usb device controller.
+ */
+ if (port->port_no = 2 && !port->host_mode) {
+ reg_val = readl(phy_driver->usb2d_idm_regs +
+ USB2_IDM_IDM_IO_CONTROL_DIRECT_OFFSET);
+ reg_val &= ~(1 << USB2_IDM_IDM_IO_CONTROL_DIRECT__CLK_ENABLE);
+ writel(reg_val, phy_driver->usb2d_idm_regs +
+ USB2_IDM_IDM_IO_CONTROL_DIRECT_OFFSET);
+
+ reg_val = readl(phy_driver->usb2d_idm_regs +
+ USB2_IDM_IDM_RESET_CONTROL_OFFSET);
+ reg_val |= 1 << USB2_IDM_IDM_RESET_CONTROL__RESET;
+ writel(reg_val, phy_driver->usb2d_idm_regs +
+ USB2_IDM_IDM_RESET_CONTROL_OFFSET);
+
+ spin_unlock_irqrestore(&phy_driver->lock, flags);
+ return 0;
+ }
+
+ /*
+ * If the phy being shutdown provides clock and reset to
+ * the host controller, change it do a different powered on phy
+ * If all phys are powered off, shut of the host controller
+ */
+ reg_val = readl(phy_driver->usbphy_regs +
+ CDRU_USBPHY_CLK_RST_SEL_OFFSET);
+
+ if (reg_val = port->port_no) {
+ for (i = 0; i < ARRAY_SIZE(phy_driver->ports); i++) {
+ if (phy_driver->ports[i] &&
+ phy_driver->ports[i]->power &&
+ phy_driver->ports[i]->host_mode) {
+ power_off_flag = false;
+ powered_on_phy = i;
+ break;
+ }
+ }
+ }
+
+ if (power_off_flag) {
+ /*
+ * Put the host controller into reset state and
+ * disable clock.
+ */
+ reg_val = readl(phy_driver->usb2h_idm_regs +
+ USB2_IDM_IDM_IO_CONTROL_DIRECT_OFFSET);
+ reg_val &+ ~(1 << USB2_IDM_IDM_IO_CONTROL_DIRECT__CLK_ENABLE);
+ writel(reg_val, phy_driver->usb2h_idm_regs +
+ USB2_IDM_IDM_IO_CONTROL_DIRECT_OFFSET);
+
+ reg_val = readl(phy_driver->usb2h_idm_regs +
+ USB2_IDM_IDM_RESET_CONTROL_OFFSET);
+ reg_val |= (1 << USB2_IDM_IDM_RESET_CONTROL__RESET);
+ writel(reg_val, phy_driver->usb2h_idm_regs +
+ USB2_IDM_IDM_RESET_CONTROL_OFFSET);
+ phy_driver->idm_host_enabled = 0;
+ } else {
+ writel(powered_on_phy, phy_driver->usbphy_regs +
+ CDRU_USBPHY_CLK_RST_SEL_OFFSET);
+ }
+
+ spin_unlock_irqrestore(&phy_driver->lock, flags);
+
+ return 0;
+}
+
+static int bcm_phy_poweron(struct phy *generic_phy)
+{
+ struct bcm_phy_instance *port = phy_get_drvdata(generic_phy);
+ struct bcm_phy_driver *phy_driver = port->driver;
+ unsigned long flags;
+ int ret;
+ u32 reg_val;
+ bool clock_reset_flag = true;
+
+ spin_lock_irqsave(&phy_driver->lock, flags);
+
+ /* Bring the AFE block out of reset to start powering up the PHY */
+ reg_val = readl(phy_driver->usbphy_regs + CRMU_USB_PHY_AON_CTRL_OFFSET);
+ reg_val |= 1 << power_bit[port->port_no];
+ writel(reg_val, phy_driver->usbphy_regs + CRMU_USB_PHY_AON_CTRL_OFFSET);
+
+ /* Check for power on and PLL lock */
+ ret = bcm_phy_cdru_usbphy_status_wait(status_reg[port->port_no],
+ CDRU_USBPHY_USBPHY_ILDO_ON_FLAG, phy_driver);
+ if (ret < 0) {
+ dev_err(&generic_phy->dev,
+ "Timed out waiting for USBPHY_ILDO_ON_FLAG on port %d",
+ port->port_no);
+ goto err_shutdown;
+ }
+ ret = bcm_phy_cdru_usbphy_status_wait(status_reg[port->port_no],
+ CDRU_USBPHY_USBPHY_PLL_LOCK, phy_driver);
+ if (ret < 0) {
+ dev_err(&generic_phy->dev,
+ "Timed out waiting for USBPHY_PLL_LOCK on port %d",
+ port->port_no);
+ goto err_shutdown;
+ }
+ port->power = true;
+
+ /* Check if the port 2 is configured for device */
+ if (port->port_no = 2 && !port->host_mode) {
+ /*
+ * Enable clock to USB device and get the USB device
+ * out of reset.
+ */
+ reg_val = readl(phy_driver->usb2d_idm_regs +
+ USB2_IDM_IDM_IO_CONTROL_DIRECT_OFFSET);
+ reg_val |= 1 << USB2_IDM_IDM_IO_CONTROL_DIRECT__CLK_ENABLE;
+ writel(reg_val, phy_driver->usb2d_idm_regs +
+ USB2_IDM_IDM_IO_CONTROL_DIRECT_OFFSET);
+
+ reg_val = readl(phy_driver->usb2d_idm_regs +
+ USB2_IDM_IDM_RESET_CONTROL_OFFSET);
+ reg_val &= ~(1 << USB2_IDM_IDM_RESET_CONTROL__RESET);
+ writel(reg_val, phy_driver->usb2d_idm_regs +
+ USB2_IDM_IDM_RESET_CONTROL_OFFSET);
+
+ } else {
+ reg_val = readl(phy_driver->usbphy_regs +
+ CDRU_USBPHY_CLK_RST_SEL_OFFSET);
+
+ /*
+ * Check if the phy that is configured to provide clock
+ * and reset is powered on.
+ */
+ if (reg_val >= 0 && reg_val < ARRAY_SIZE(phy_driver->ports))
+ if (phy_driver->ports[reg_val])
+ if (phy_driver->ports[reg_val]->power)
+ clock_reset_flag = false;
+
+ /* if not set the current phy */
+ if (clock_reset_flag) {
+ reg_val = port->port_no;
+ writel(reg_val, phy_driver->usbphy_regs +
+ CDRU_USBPHY_CLK_RST_SEL_OFFSET);
+ }
+ }
+
+ if (!phy_driver->idm_host_enabled) {
+ /* Enable clock to USB and get the USB out of reset */
+ reg_val = readl(phy_driver->usb2h_idm_regs +
+ USB2_IDM_IDM_IO_CONTROL_DIRECT_OFFSET);
+ reg_val |= 1 << USB2_IDM_IDM_IO_CONTROL_DIRECT__CLK_ENABLE;
+ writel(reg_val, phy_driver->usb2h_idm_regs +
+ USB2_IDM_IDM_IO_CONTROL_DIRECT_OFFSET);
+
+ reg_val = readl(phy_driver->usb2h_idm_regs +
+ USB2_IDM_IDM_RESET_CONTROL_OFFSET);
+ reg_val &= ~(1 << USB2_IDM_IDM_RESET_CONTROL__RESET);
+ writel(reg_val, phy_driver->usb2h_idm_regs +
+ USB2_IDM_IDM_RESET_CONTROL_OFFSET);
+ phy_driver->idm_host_enabled = true;
+ }
+
+ spin_unlock_irqrestore(&phy_driver->lock, flags);
+ return 0;
+
+err_shutdown:
+ spin_unlock_irqrestore(&phy_driver->lock, flags);
+ phy_power_off(generic_phy);
+ return ret;
+}
+
+static struct phy_ops ops = {
+ .init = bcm_phy_init,
+ .power_on = bcm_phy_poweron,
+ .power_off = bcm_phy_shutdown,
+};
+
+static const struct of_device_id bcm_phy_dt_ids[] = {
+ { .compatible = "brcm,cygnus-usb-phy", },
+ { }
+};
+
+static int bcm_phy_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct bcm_phy_driver *phy_driver;
+ struct phy_provider *phy_provider;
+ struct device_node *child;
+ struct resource *res;
+ int error;
+ u32 reg_val;
+
+ phy_driver = devm_kzalloc(dev, sizeof(struct bcm_phy_driver),
+ GFP_KERNEL);
+ if (!phy_driver)
+ return -ENOMEM;
+
+ spin_lock_init(&phy_driver->lock);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "missing memory resource usbphy_regs\n");
+ return -EINVAL;
+ }
+ phy_driver->usbphy_regs = devm_ioremap_nocache(dev, res->start,
+ resource_size(res));
+ if (!phy_driver->usbphy_regs) {
+ dev_err(dev, "Failed to remap usbphy_regs\n");
+ return -ENOMEM;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!res) {
+ dev_err(&pdev->dev, "missing memory resource ubs2h_idm_regs\n");
+ return -EINVAL;
+ }
+ phy_driver->usb2h_idm_regs = devm_ioremap_nocache(dev, res->start,
+ resource_size(res));
+ if (!phy_driver->usb2h_idm_regs) {
+ dev_err(dev, "Failed to remap usb2h_idm_regs\n");
+ return -ENOMEM;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+ if (!res) {
+ dev_err(&pdev->dev, "missing memory resource ubs2d_idm_regs\n");
+ return -EINVAL;
+ }
+ phy_driver->usb2d_idm_regs = devm_ioremap_nocache(dev, res->start,
+ resource_size(res));
+ if (!phy_driver->usb2d_idm_regs) {
+ dev_err(dev, "Failed to remap usb2d_idm_regs\n");
+ return -ENOMEM;
+ }
+
+ phy_driver->idm_host_enabled = false;
+
+ /* Shut down all ports. They can be powered up as required */
+ reg_val = readl(phy_driver->usbphy_regs +
+ CRMU_USB_PHY_AON_CTRL_OFFSET);
+ reg_val &= ~(1 << CRMU_USBPHY_P0_AFE_CORERDY_VDDC);
+ reg_val &= ~(1 << CRMU_USBPHY_P0_RESETB);
+ reg_val &= ~(1 << CRMU_USBPHY_P1_AFE_CORERDY_VDDC);
+ reg_val &= ~(1 << CRMU_USBPHY_P1_RESETB);
+ reg_val &= ~(1 << CRMU_USBPHY_P2_AFE_CORERDY_VDDC);
+ reg_val &= ~(1 << CRMU_USBPHY_P2_RESETB);
+ writel(reg_val, phy_driver->usbphy_regs +
+ CRMU_USB_PHY_AON_CTRL_OFFSET);
+
+ for_each_available_child_of_node(dev->of_node, child) {
+ struct bcm_phy_instance *port;
+ u32 port_no;
+
+ if (of_property_read_u32(child, "reg", &port_no)) {
+ dev_err(dev, "missing reg property in node %s\n",
+ child->name);
+ return -EINVAL;
+ }
+
+ if (port_no >= ARRAY_SIZE(phy_driver->ports)) {
+ dev_err(dev, "invalid reg in node %s: %u\n",
+ child->name, port_no);
+ return -EINVAL;
+ }
+
+ port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
+ if (!port)
+ return -ENOMEM;
+
+ port->generic_phy = devm_phy_create(dev, child, &ops);
+ if (IS_ERR(port->generic_phy)) {
+ error = PTR_ERR(port->generic_phy);
+ dev_err(dev, "Failed to create phy %u: %d",
+ port_no, error);
+ return error;
+ }
+
+ port->port_no = port_no;
+ port->driver = phy_driver;
+ phy_set_drvdata(port->generic_phy, port);
+
+ phy_driver->ports[port_no] = port;
+ }
+
+ phy_provider = devm_of_phy_provider_register(dev, bcm_usb_phy_xlate);
+ if (IS_ERR(phy_provider)) {
+ error = PTR_ERR(phy_provider);
+ dev_err(dev, "Failed to register as phy provider: %d\n",
+ error);
+ return error;
+ }
+
+ dev_set_drvdata(dev, phy_driver);
+
+ return 0;
+
+}
+
+MODULE_DEVICE_TABLE(of, bcm_phy_dt_ids);
+
+static struct platform_driver bcm_phy_driver = {
+ .probe = bcm_phy_probe,
+ .driver = {
+ .name = "bcm-cygnus-usbphy",
+ .of_match_table = of_match_ptr(bcm_phy_dt_ids),
+ },
+};
+module_platform_driver(bcm_phy_driver);
+
+MODULE_ALIAS("platform:bcm-cygnus-usbphy");
+MODULE_AUTHOR("Broadcom");
+MODULE_DESCRIPTION("Broadcom Cygnus USB PHY driver");
+MODULE_LICENSE("GPL v2");
--
2.3.4
^ permalink raw reply related
* Re: [RFC PATCH] video/logo: introduce new system state for checking if logos are freed
From: Heiko Schocher @ 2015-05-26 3:56 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-kernel, Geert Uytterhoeven, linux-fbdev,
Jean-Christophe Plagniol-Villard
In-Reply-To: <5562B9CE.7050807@ti.com>
Hello Tomi,
Am 25.05.2015 07:57, schrieb Tomi Valkeinen:
>
>
> On 06/05/15 10:09, Heiko Schocher wrote:
>> commit 92b004d1aa9f ("video/logo: prevent use of logos after they have been freed")
>>
>> added a late_initcall function to mark the logos as freed. In reality
>> the logos are freed later, and fbdev probe may be ran between this
>> late_initcall and the freeing of the logos. In that case the logos
>> would not be drawn. To prevent this introduced a new system_state
>> SYSTEM_FREEING_MEM and set this state before freeing memory. This
>> state could be checked now in fb_find_logo(). This system state
>> is maybe useful on other places too.
>>
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>>
>> ---
>> Found this issue on an imx6 based board with a display which needs
>> a spi initialization. With 3.18.2 I see a perfect logo, but with
>> current ml, bootlogo is missing, because drm gets probed before
>> spi display, which leads in drm probing is deferred until the
>> spi display is probed. After that drm is probed again ... but
>> this is too late for showing the bootlogo.
>> With this patch, bootlogo is drawn again. I am not sure, if it
>> is so easy to add a new system state ... but we should have a
>> possibility to detect if initdata is freed or not. this is maybe
>> also for other modules interesting. Maybe we add a
>> kernel_initdata_freed()
>> function instead of a new system state?
>>
>> drivers/video/logo/logo.c | 15 ++++-----------
>> include/linux/kernel.h | 1 +
>> init/main.c | 1 +
>> 3 files changed, 6 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/video/logo/logo.c b/drivers/video/logo/logo.c
>> index 10fbfd8..d798a9f 100644
>> --- a/drivers/video/logo/logo.c
>> +++ b/drivers/video/logo/logo.c
>> @@ -26,16 +26,6 @@ MODULE_PARM_DESC(nologo, "Disables startup logo");
>> * Use late_init to mark the logos as freed to prevent any further use.
>> */
>>
>> -static bool logos_freed;
>> -
>> -static int __init fb_logo_late_init(void)
>> -{
>> - logos_freed = true;
>> - return 0;
>> -}
>> -
>> -late_initcall(fb_logo_late_init);
>> -
>> /* logo's are marked __initdata. Use __init_refok to tell
>> * modpost that it is intended that this function uses data
>> * marked __initdata.
>> @@ -44,7 +34,10 @@ const struct linux_logo * __init_refok fb_find_logo(int depth)
>> {
>> const struct linux_logo *logo = NULL;
>>
>> - if (nologo || logos_freed)
>> + if (system_state >= SYSTEM_FREEING_MEM)
>> + return NULL;
>> +
>> + if (nologo)
>> return NULL;
>>
>> if (depth >= 1) {
>> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
>> index 3a5b48e..e5875bf 100644
>> --- a/include/linux/kernel.h
>> +++ b/include/linux/kernel.h
>> @@ -462,6 +462,7 @@ extern bool early_boot_irqs_disabled;
>> /* Values used for system_state */
>> extern enum system_states {
>> SYSTEM_BOOTING,
>> + SYSTEM_FREEING_MEM,
>> SYSTEM_RUNNING,
>> SYSTEM_HALT,
>> SYSTEM_POWER_OFF,
>> diff --git a/init/main.c b/init/main.c
>> index 2115055..4965ed0 100644
>> --- a/init/main.c
>> +++ b/init/main.c
>> @@ -931,6 +931,7 @@ static int __ref kernel_init(void *unused)
>> kernel_init_freeable();
>> /* need to finish all async __init code before freeing the memory */
>> async_synchronize_full();
>> + system_state = SYSTEM_FREEING_MEM;
>> free_initmem();
>> mark_rodata_ro();
>> system_state = SYSTEM_RUNNING;
>
> Without locking, the initmem may be freed while fb_find_logo() is running.
Yes, you are right, that must be added ... but has such a change a
chance to go in mainline?
BTW: Could this not be currently a problem on multicore systems?
If lets say core 2 just draws the logo, another core 1 calls
fb_logo_late_init() and later core 1 free_initmem(), while the core 2
still draws it?
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [RFC PATCH] video/logo: introduce new system state for checking if logos are freed
From: Tomi Valkeinen @ 2015-05-26 6:54 UTC (permalink / raw)
To: hs
Cc: linux-kernel, Geert Uytterhoeven, linux-fbdev,
Jean-Christophe Plagniol-Villard
In-Reply-To: <5563EEF9.3080901@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]
On 26/05/15 06:56, Heiko Schocher wrote:
>> Without locking, the initmem may be freed while fb_find_logo() is
>> running.
>
> Yes, you are right, that must be added ... but has such a change a
> chance to go in mainline?
I don't know. To be honest, this whole thing feels a bit like hackery. I
think initdata should only be accessed from initcalls, never asynchronously.
> BTW: Could this not be currently a problem on multicore systems?
> If lets say core 2 just draws the logo, another core 1 calls
> fb_logo_late_init() and later core 1 free_initmem(), while the core 2
> still draws it?
Yes, I think so...
So, maybe it would be better to not even try to go forward with the
current approach. Two approaches come to my mind:
1) Keep the logos in the memory, and don't even try to free them. I
don't know many bytes they are in total, though.
2) Make a copy of the logos to a kmalloced area at some early boot
stage. Then manually free the logos at some point (after the first
access to the logos? after a certain time (urgh...)?).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: ssd1307fb: fix logical error
From: Tomi Valkeinen @ 2015-05-26 7:02 UTC (permalink / raw)
To: Thomas Niederprüm, plagnioj, maxime.ripard, kernel,
dan.carpenter, prabhakar.csengg
Cc: linux-fbdev, linux-kernel
In-Reply-To: <1432582161-14684-1-git-send-email-niederp@physik.uni-kl.de>
[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]
On 25/05/15 22:29, Thomas Niederprüm wrote:
> The logical not needs to be done after the bit masking.
>
> Fixes: a3998fe03e87 ("fbdev: ssd1307fb: Unify init code and obtain
> hw specific bits from DT")
>
> Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> drivers/video/fbdev/ssd1307fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index 8fc224c..9771d56 100644
> --- a/drivers/video/fbdev/ssd1307fb.c
> +++ b/drivers/video/fbdev/ssd1307fb.c
> @@ -368,7 +368,7 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
> if (ret < 0)
> return ret;
>
> - compins = 0x02 | (!par->com_seq & 0x1) << 4
> + compins = 0x02 | !(par->com_seq & 0x1) << 4
> | (par->com_lrremap & 0x1) << 5;
> ret = ssd1307fb_write_cmd(par->client, compins);
> if (ret < 0)
>
Thanks, queued for 4.2.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCHv6 05/10] ARM: mxs: fix in tree users of ssd1306
From: Tomi Valkeinen @ 2015-05-26 7:08 UTC (permalink / raw)
To: Maxime Ripard, Shawn Guo
Cc: Thomas Niederprüm, Sascha Hauer, plagnioj, robh+dt,
linux-fbdev, linux-kernel
In-Reply-To: <20150508133138.GS11057@lukather>
[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]
On 08/05/15 16:31, Maxime Ripard wrote:
> Hi Shawn,
>
> On Thu, May 07, 2015 at 07:28:01PM +0800, Shawn Guo wrote:
>> On Thu, May 07, 2015 at 01:55:35PM +0300, Tomi Valkeinen wrote:
>>> Hi,
>>>
>>> On 31/03/15 21:27, Thomas Niederprüm wrote:
>>>> This patch updates the in tree-users of the SSD1306 controller for using
>>>> the newly introduced DT properties.
>>>>
>>>> Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
>>>> ---
>>>> arch/arm/boot/dts/imx28-cfa10036.dts | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/imx28-cfa10036.dts b/arch/arm/boot/dts/imx28-cfa10036.dts
>>>> index b04b6b8..570aa33 100644
>>>> --- a/arch/arm/boot/dts/imx28-cfa10036.dts
>>>> +++ b/arch/arm/boot/dts/imx28-cfa10036.dts
>>>> @@ -99,6 +99,9 @@
>>>> solomon,height = <32>;
>>>> solomon,width = <128>;
>>>> solomon,page-offset = <0>;
>>>> + solomon,com-lrremap;
>>>> + solomon,com-invdir;
>>>> + solomon,com-offset = <32>;
>>>> };
>>>> };
>>>
>>> Should this patch be merged separately via proper tree? I can take the
>>> rest of the patches via fbdev tree. I can, of course, take this via
>>> fbdev also, if I get an ack.
>>
>> @Maxime
>>
>> I assume you're the person, right?
>
> I don't have this board right now to actually test, but the changes
> look good.
So should I take this via fbdev tree with the rest of the patches? If
so, I want an ack from a relevant dts maintainer. get_maintainers.pl
gives Shawn as the first contact for imx28-cfa10036.dts.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] video/logo: introduce new system state for checking if logos are freed
From: Geert Uytterhoeven @ 2015-05-26 7:08 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: hs, linux-kernel@vger.kernel.org, Linux Fbdev development list,
Jean-Christophe Plagniol-Villard
In-Reply-To: <556418A9.8010603@ti.com>
On Tue, May 26, 2015 at 8:54 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 26/05/15 06:56, Heiko Schocher wrote:
>>> Without locking, the initmem may be freed while fb_find_logo() is
>>> running.
Or afterwards. Drivers may keep the pointer around indefinitely.
>> Yes, you are right, that must be added ... but has such a change a
>> chance to go in mainline?
>
> I don't know. To be honest, this whole thing feels a bit like hackery. I
> think initdata should only be accessed from initcalls, never asynchronously.
>
>> BTW: Could this not be currently a problem on multicore systems?
>> If lets say core 2 just draws the logo, another core 1 calls
>> fb_logo_late_init() and later core 1 free_initmem(), while the core 2
>> still draws it?
>
> Yes, I think so...
I don't think that can happen. All initcalls should complete before initmem
is freed.
> So, maybe it would be better to not even try to go forward with the
> current approach. Two approaches come to my mind:
>
> 1) Keep the logos in the memory, and don't even try to free them. I
> don't know many bytes they are in total, though.
m68k/allmodconfig:
$ size drivers/video/logo/logo*o
text data bss dec hex filename
24 6961 0 6985 1b49 drivers/video/logo/logo_linux_clut224.o
24 800 0 824 338 drivers/video/logo/logo_linux_mono.o
24 3200 0 3224 c98 drivers/video/logo/logo_linux_vga16.o
24 6955 0 6979 1b43 drivers/video/logo/logo_mac_clut224.o
161 4 2 167 a7 drivers/video/logo/logo.o
Not that bad... Custom logos may be larger, though.
> 2) Make a copy of the logos to a kmalloced area at some early boot
> stage. Then manually free the logos at some point (after the first
> access to the logos? after a certain time (urgh...)?).
3) Draw the logos from an initcall on all frame buffers that exist at that
point in time. Yes, this will destroy (part of) the content that's
currently shown.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [RFC PATCH] video/logo: introduce new system state for checking if logos are freed
From: Tomi Valkeinen @ 2015-05-26 7:15 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: hs, linux-kernel@vger.kernel.org, Linux Fbdev development list,
Jean-Christophe Plagniol-Villard
In-Reply-To: <CAMuHMdWHP6i15Z2qZJBEW9uz7kh1_ET5N1VbOKoMw1EC7F3O0g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2832 bytes --]
On 26/05/15 10:08, Geert Uytterhoeven wrote:
> On Tue, May 26, 2015 at 8:54 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 26/05/15 06:56, Heiko Schocher wrote:
>>>> Without locking, the initmem may be freed while fb_find_logo() is
>>>> running.
>
> Or afterwards. Drivers may keep the pointer around indefinitely.
>
>>> Yes, you are right, that must be added ... but has such a change a
>>> chance to go in mainline?
>>
>> I don't know. To be honest, this whole thing feels a bit like hackery. I
>> think initdata should only be accessed from initcalls, never asynchronously.
>>
>>> BTW: Could this not be currently a problem on multicore systems?
>>> If lets say core 2 just draws the logo, another core 1 calls
>>> fb_logo_late_init() and later core 1 free_initmem(), while the core 2
>>> still draws it?
>>
>> Yes, I think so...
>
> I don't think that can happen. All initcalls should complete before initmem
> is freed.
Ah, true, the question was only about the initcalls. I was answering to
what actually can happen with the logo code as a whole.
The whole problem started when I fixed an issue where the logos were
accessed from a workqueue. I don't remember the details, but I think drm
always (?) sets up some console stuff via workthread. In that case we
could have the workthread accessing the logos, while initmem is being freed.
>> So, maybe it would be better to not even try to go forward with the
>> current approach. Two approaches come to my mind:
>>
>> 1) Keep the logos in the memory, and don't even try to free them. I
>> don't know many bytes they are in total, though.
>
> m68k/allmodconfig:
>
> $ size drivers/video/logo/logo*o
> text data bss dec hex filename
> 24 6961 0 6985 1b49 drivers/video/logo/logo_linux_clut224.o
> 24 800 0 824 338 drivers/video/logo/logo_linux_mono.o
> 24 3200 0 3224 c98 drivers/video/logo/logo_linux_vga16.o
> 24 6955 0 6979 1b43 drivers/video/logo/logo_mac_clut224.o
> 161 4 2 167 a7 drivers/video/logo/logo.o
>
> Not that bad... Custom logos may be larger, though.
I wonder how much a simple RLE would cut down the sizes...
>> 2) Make a copy of the logos to a kmalloced area at some early boot
>> stage. Then manually free the logos at some point (after the first
>> access to the logos? after a certain time (urgh...)?).
>
> 3) Draw the logos from an initcall on all frame buffers that exist at that
> point in time. Yes, this will destroy (part of) the content that's
> currently shown.
Isn't that almost the same as now? The problem is that the fb probes are
deferred to a very late stage, so we would not have the fbs when the
suggested initcall would be called.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ 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