* Re: [PATCH] video: constify geode ops structures
From: Joe Perches @ 2015-11-10 20:49 UTC (permalink / raw)
To: Kees Cook, Christoph Hellwig
Cc: Dan Carpenter, Julia Lawall, Jean-Christophe Plagniol-Villard,
kernel-janitors, Tomi Valkeinen, linux-geode, linux-fbdev, LKML
In-Reply-To: <CAGXu5j+59jPqd5QWq38KH--i=gBzq2d5j_Z0c2ygG=pfr2+tzw@mail.gmail.com>
On Tue, 2015-11-10 at 12:34 -0800, Kees Cook wrote:
> We can't make everything work just by static
> analyzers and checkpatch.pl runs (meaning the "backstop" comment
> above).
>
> Additionally, having the plugin infrastructure gets us the ability to
> do things that aren't presently possible (see the thread on the
> initify plugin, which can't be done in source alone).
#define __do_const __attribute__((do_const))
...
#ifndef __do_const
#define __do_const
#endif
I think it's always better for the reader to know that a
const struct declaration is used over a non-const struct
when the compiler, via plug-in extension, could convert
the declaration to const.
Is there a warning/info message produced by gcc and the
plug-in when a non-const declaration is converted to
const because of this attribute?
^ permalink raw reply
* Re: [PATCH] video: constify geode ops structures
From: Dan Carpenter @ 2015-11-10 22:02 UTC (permalink / raw)
To: Joe Perches
Cc: Kees Cook, Christoph Hellwig, Julia Lawall,
Jean-Christophe Plagniol-Villard, kernel-janitors, Tomi Valkeinen,
linux-geode, linux-fbdev, LKML
In-Reply-To: <1447188569.2701.91.camel@perches.com>
On Tue, Nov 10, 2015 at 12:49:29PM -0800, Joe Perches wrote:
> Is there a warning/info message produced by gcc and the
> plug-in when a non-const declaration is converted to
> const because of this attribute?
I'm not sure I understand the question. What would the warning say?
We'll hopefully automatically make over 3000 structs const. I
understand warning that people should make structs const when possible
but I don't understand why we would want to remove auto consting?
Putting __do_const in the .h file is basically the same as marking
every struct of that type as const in the .c file. The errors are
caught at compile time.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] video: constify geode ops structures
From: Joe Perches @ 2015-11-10 22:17 UTC (permalink / raw)
To: Dan Carpenter
Cc: Kees Cook, Christoph Hellwig, Julia Lawall,
Jean-Christophe Plagniol-Villard, kernel-janitors, Tomi Valkeinen,
linux-geode, linux-fbdev, LKML
In-Reply-To: <20151110220244.GU7289@mwanda>
On Wed, 2015-11-11 at 01:02 +0300, Dan Carpenter wrote:
> On Tue, Nov 10, 2015 at 12:49:29PM -0800, Joe Perches wrote:
> > Is there a warning/info message produced by gcc and the
> > plug-in when a non-const declaration is converted to
> > const because of this attribute?
>
> I'm not sure I understand the question. What would the warning say?
Perhaps something like:
declaration of struct <foo> converted to const by __attribute__((do_const))
> We'll hopefully automatically make over 3000 structs const. I
> understand warning that people should make structs const when possible
> but I don't understand why we would want to remove auto consting?
I'm not suggesting removing the attribute.
It seems sensible enough.
I just think the plug-in should at least optionally
note the instances when non-const declarations are
converted to const.
> Putting __do_const in the .h file is basically the same as marking
> every struct of that type as const in the .c file.
Not for a reader of the code that doesn't first
inspect the header files.
^ permalink raw reply
* Re: [PATCH] video: constify geode ops structures
From: Dan Carpenter @ 2015-11-10 22:34 UTC (permalink / raw)
To: Joe Perches
Cc: Kees Cook, Christoph Hellwig, Julia Lawall,
Jean-Christophe Plagniol-Villard, kernel-janitors, Tomi Valkeinen,
linux-geode, linux-fbdev, LKML
In-Reply-To: <1447193832.2701.102.camel@perches.com>
On Tue, Nov 10, 2015 at 02:17:12PM -0800, Joe Perches wrote:
> On Wed, 2015-11-11 at 01:02 +0300, Dan Carpenter wrote:
> > On Tue, Nov 10, 2015 at 12:49:29PM -0800, Joe Perches wrote:
> > > Is there a warning/info message produced by gcc and the
> > > plug-in when a non-const declaration is converted to
> > > const because of this attribute?
> >
> > I'm not sure I understand the question. What would the warning say?
>
> Perhaps something like:
>
> declaration of struct <foo> converted to const by __attribute__((do_const))
No one will ever think to turn on that output. By the time they think
of turning it on, it means they have already figured out the issue.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] video: constify geode ops structures
From: Joe Perches @ 2015-11-10 22:39 UTC (permalink / raw)
To: Dan Carpenter
Cc: Kees Cook, Christoph Hellwig, Julia Lawall,
Jean-Christophe Plagniol-Villard, kernel-janitors, Tomi Valkeinen,
linux-geode, linux-fbdev, LKML
In-Reply-To: <20151110223400.GX18797@mwanda>
On Wed, 2015-11-11 at 01:34 +0300, Dan Carpenter wrote:
> On Tue, Nov 10, 2015 at 02:17:12PM -0800, Joe Perches wrote:
> > On Wed, 2015-11-11 at 01:02 +0300, Dan Carpenter wrote:
> > > On Tue, Nov 10, 2015 at 12:49:29PM -0800, Joe Perches wrote:
> > > > Is there a warning/info message produced by gcc and the
> > > > plug-in when a non-const declaration is converted to
> > > > const because of this attribute?
> > >
> > > I'm not sure I understand the question. What would the warning
> > > say?
> >
> > Perhaps something like:
> >
> > declaration of struct <foo> converted to const by
> > __attribute__((do_const))
>
> No one will ever think to turn on that output. By the time they think
> of turning it on, it means they have already figured out the issue.
Dubious assertion.
^ permalink raw reply
* [PATCH] fbdev: ssd1307fb: Fix chargepump setting
From: Julian Scheel @ 2015-11-12 14:07 UTC (permalink / raw)
To: linux-fbdev
The charge pump setting must have bit D4 set all time according to the SSD1306
App Note. Instead of doing an logical and off shifted setting bit with 0x14 it
must be an logical or with 0x10 to ensure D4 is set.
Signed-off-by: Julian Scheel <julian@jusst.de>
---
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 1611215..5965a9b 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -389,7 +389,7 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
return ret;
ret = ssd1307fb_write_cmd(par->client,
- (par->device_info->need_chargepump & 0x1 << 2) & 0x14);
+ 0x10 | ((par->device_info->need_chargepump & 0x01) << 2));
if (ret < 0)
return ret;
--
2.6.2
^ permalink raw reply related
* [PATCH 0/2] Fix omap VENC (PAL/NTSC TV out) operation with omapdrm driver
From: H. Nikolaus Schaller @ 2015-11-13 10:29 UTC (permalink / raw)
To: David Airlie, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Laurent Pinchart
Cc: dri-devel, linux-kernel, linux-omap, linux-fbdev, gta04-owner,
notasas, H. Nikolaus Schaller
This patch set fixes some issues with the OMAP VENC
when used with the omapdrm driver.
Tested on: BeagleBoard XM, GTA04 and OpenPandora
H. Nikolaus Schaller (2):
video:omap2:dss: fix timings for VENC to match what omapdrm expects
video:omapdrm: make omapdrm assume the tv-out cable is always
connected
drivers/gpu/drm/omapdrm/omap_connector.c | 1 +
drivers/video/fbdev/omap2/dss/venc.c | 12 ++++++++++++
2 files changed, 13 insertions(+)
--
2.5.1
^ permalink raw reply
* [PATCH 1/2] video:omap2:dss: fix timings for VENC to match what omapdrm expects
From: H. Nikolaus Schaller @ 2015-11-13 10:29 UTC (permalink / raw)
To: David Airlie, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Laurent Pinchart
Cc: dri-devel, linux-kernel, linux-omap, linux-fbdev, gta04-owner,
notasas, H. Nikolaus Schaller
In-Reply-To: <cover.1447410543.git.hns@goldelico.com>
Otherwise check_timings fails and we get a "has no modes" message
from xrandr.
This fix makes the venc assume PAL and NTSC timings that match the
timings synthetized by copy_timings_drm_to_omap() from omapdrm
mode settings so that check_timings() succeeds.
Tested on: BeagleBoard XM, GTA04 and OpenPandora
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
drivers/video/fbdev/omap2/dss/venc.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/video/fbdev/omap2/dss/venc.c b/drivers/video/fbdev/omap2/dss/venc.c
index 99ca268..d05a549 100644
--- a/drivers/video/fbdev/omap2/dss/venc.c
+++ b/drivers/video/fbdev/omap2/dss/venc.c
@@ -275,6 +275,12 @@ const struct omap_video_timings omap_dss_pal_timings = {
.vbp = 41,
.interlace = true,
+
+ .hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
+ .vsync_level = OMAPDSS_SIG_ACTIVE_LOW,
+ .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
+ .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
+ .sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
};
EXPORT_SYMBOL(omap_dss_pal_timings);
@@ -290,6 +296,12 @@ const struct omap_video_timings omap_dss_ntsc_timings = {
.vbp = 31,
.interlace = true,
+
+ .hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
+ .vsync_level = OMAPDSS_SIG_ACTIVE_LOW,
+ .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
+ .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
+ .sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
};
EXPORT_SYMBOL(omap_dss_ntsc_timings);
--
2.5.1
^ permalink raw reply related
* [PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected
From: H. Nikolaus Schaller @ 2015-11-13 10:29 UTC (permalink / raw)
To: David Airlie, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Laurent Pinchart
Cc: dri-devel, linux-kernel, linux-omap, linux-fbdev, gta04-owner,
notasas, H. Nikolaus Schaller
In-Reply-To: <cover.1447410543.git.hns@goldelico.com>
Include VENC in the set of drivers where it is assimed that the cable
is always connected. Like DPI, DSI, DBI and SDI do.
Otherwise, the VENC will return cable status "unknown" and is not enabled
by the X-server. So there is no video output signal.
Tested on: BeagleBoard XM, GTA04 and OpenPandora
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
drivers/gpu/drm/omapdrm/omap_connector.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c b/drivers/gpu/drm/omapdrm/omap_connector.c
index 83f2a91..98ddb5d 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -120,6 +120,7 @@ static enum drm_connector_status omap_connector_detect(
else
ret = connector_status_disconnected;
} else if (dssdev->type = OMAP_DISPLAY_TYPE_DPI ||
+ dssdev->type = OMAP_DISPLAY_TYPE_VENC ||
dssdev->type = OMAP_DISPLAY_TYPE_DBI ||
dssdev->type = OMAP_DISPLAY_TYPE_SDI ||
dssdev->type = OMAP_DISPLAY_TYPE_DSI) {
--
2.5.1
^ permalink raw reply related
* Re: [PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected
From: Tomi Valkeinen @ 2015-11-13 11:46 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: linux-fbdev, linux-kernel, dri-devel, gta04-owner,
Laurent Pinchart, linux-omap, Jean-Christophe Plagniol-Villard
In-Reply-To: <5942ddb7ab4f42f207c6c2b54be31a3d9fe3b912.1447410544.git.hns@goldelico.com>
[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]
On 13/11/15 12:29, H. Nikolaus Schaller wrote:
> Include VENC in the set of drivers where it is assimed that the cable
> is always connected. Like DPI, DSI, DBI and SDI do.
>
> Otherwise, the VENC will return cable status "unknown" and is not enabled
> by the X-server. So there is no video output signal.
>
> Tested on: BeagleBoard XM, GTA04 and OpenPandora
>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
> drivers/gpu/drm/omapdrm/omap_connector.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c b/drivers/gpu/drm/omapdrm/omap_connector.c
> index 83f2a91..98ddb5d 100644
> --- a/drivers/gpu/drm/omapdrm/omap_connector.c
> +++ b/drivers/gpu/drm/omapdrm/omap_connector.c
> @@ -120,6 +120,7 @@ static enum drm_connector_status omap_connector_detect(
> else
> ret = connector_status_disconnected;
> } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
> + dssdev->type == OMAP_DISPLAY_TYPE_VENC ||
> dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
> dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
> dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
>
I have no idea why VENC is not working for you when using
connector_status_unknown, but I just tested DPI with
connector_status_unknown (i.e. changed the above func to return unknown
for DPI), and it works fine with X and X omap driver. And xrandr
confirms that the connection status is unknown:
# xrandr
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 2048 x 2048
HDMI-1 disconnected (normal left inverted right x axis y axis)
None-1 unknown connection 1920x1200+0+0 (normal left inverted right x
axis y axis) 0mm x 0mm
1920x1200 60.00*+ 60.00 +
Grep also shows that there are many drivers using
connector_status_unknown, so I'm guessing it should work fine...
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected
From: Laurent Pinchart @ 2015-11-13 12:01 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev, H. Nikolaus Schaller, linux-kernel, dri-devel,
gta04-owner, linux-omap, Jean-Christophe Plagniol-Villard
In-Reply-To: <5645CD79.5040107@ti.com>
On Friday 13 November 2015 13:46:01 Tomi Valkeinen wrote:
> On 13/11/15 12:29, H. Nikolaus Schaller wrote:
> > Include VENC in the set of drivers where it is assimed that the cable
> > is always connected. Like DPI, DSI, DBI and SDI do.
> >
> > Otherwise, the VENC will return cable status "unknown" and is not enabled
> > by the X-server. So there is no video output signal.
> >
> > Tested on: BeagleBoard XM, GTA04 and OpenPandora
> >
> > Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> > ---
> >
> > drivers/gpu/drm/omapdrm/omap_connector.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
> > b/drivers/gpu/drm/omapdrm/omap_connector.c index 83f2a91..98ddb5d 100644
> > --- a/drivers/gpu/drm/omapdrm/omap_connector.c
> > +++ b/drivers/gpu/drm/omapdrm/omap_connector.c
> > @@ -120,6 +120,7 @@ static enum drm_connector_status
> > omap_connector_detect(
> > else
> > ret = connector_status_disconnected;
> > } else if (dssdev->type = OMAP_DISPLAY_TYPE_DPI ||
> > + dssdev->type = OMAP_DISPLAY_TYPE_VENC ||
> > dssdev->type = OMAP_DISPLAY_TYPE_DBI ||
> > dssdev->type = OMAP_DISPLAY_TYPE_SDI ||
> > dssdev->type = OMAP_DISPLAY_TYPE_DSI) {
>
> I have no idea why VENC is not working for you when using
> connector_status_unknown, but I just tested DPI with
> connector_status_unknown (i.e. changed the above func to return unknown
> for DPI), and it works fine with X and X omap driver. And xrandr
> confirms that the connection status is unknown:
>
> # xrandr
> Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 2048 x 2048
> HDMI-1 disconnected (normal left inverted right x axis y axis)
> None-1 unknown connection 1920x1200+0+0 (normal left inverted right x
> axis y axis) 0mm x 0mm
> 1920x1200 60.00*+ 60.00 +
>
> Grep also shows that there are many drivers using
> connector_status_unknown, so I'm guessing it should work fine...
And beside it's not right to consider VENC as always connected, as it isn't.
The unknown status is there for a reason, to describe connectors for which we
can't get any status information. The situation is different for DPI, DBI, SDI
and DSI as those are on-board busses that connect to a non-removable panel, so
we can say with a good confidence that the panel is connected (the situation
could be changed with a hammer and a chisel, but that's unlikely to happen,
hence the confidence).
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] backlight: tps65217_bl: Add MODULE_DEVICE_TABLE.
From: Enric Balletbo i Serra @ 2015-11-13 12:19 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: jingoohan1-Re5JQEeQqe8AvxtiuMwx3w,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, plagnioj-sclMFOaUSTBWk0Htik3J/w,
tomi.valkeinen-l0cyMroinI0, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
The device table is required to load modules based on modaliases.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
drivers/video/backlight/tps65217_bl.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/video/backlight/tps65217_bl.c b/drivers/video/backlight/tps65217_bl.c
index 61d72bf..37a9731 100644
--- a/drivers/video/backlight/tps65217_bl.c
+++ b/drivers/video/backlight/tps65217_bl.c
@@ -320,10 +320,21 @@ static int tps65217_bl_probe(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id tps65217_bl_of_match[] = {
+ { .compatible = "ti,tps65217-bl", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, tps65217_bl_of_match);
+#endif
+
static struct platform_driver tps65217_bl_driver = {
.probe = tps65217_bl_probe,
.driver = {
.name = "tps65217-bl",
+#ifdef CONFIG_OF
+ .of_match_table = tps65217_bl_of_match,
+#endif
},
};
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected
From: H. Nikolaus Schaller @ 2015-11-13 13:31 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Tomi Valkeinen, David Airlie, Jean-Christophe Plagniol-Villard,
dri-devel, linux-kernel, linux-omap, linux-fbdev, gta04-owner,
notasas
In-Reply-To: <3973104.FPbEEICOqe@avalon>
Hi Laurent and Tomi,
Am 13.11.2015 um 13:01 schrieb Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> On Friday 13 November 2015 13:46:01 Tomi Valkeinen wrote:
>> On 13/11/15 12:29, H. Nikolaus Schaller wrote:
>>> Include VENC in the set of drivers where it is assimed that the cable
>>> is always connected. Like DPI, DSI, DBI and SDI do.
>>>
>>> Otherwise, the VENC will return cable status "unknown" and is not enabled
>>> by the X-server. So there is no video output signal.
>>>
>>> Tested on: BeagleBoard XM, GTA04 and OpenPandora
>>>
>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>> ---
>>>
>>> drivers/gpu/drm/omapdrm/omap_connector.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
>>> b/drivers/gpu/drm/omapdrm/omap_connector.c index 83f2a91..98ddb5d 100644
>>> --- a/drivers/gpu/drm/omapdrm/omap_connector.c
>>> +++ b/drivers/gpu/drm/omapdrm/omap_connector.c
>>> @@ -120,6 +120,7 @@ static enum drm_connector_status
>>> omap_connector_detect(
>>> else
>>> ret = connector_status_disconnected;
>>> } else if (dssdev->type = OMAP_DISPLAY_TYPE_DPI ||
>>> + dssdev->type = OMAP_DISPLAY_TYPE_VENC ||
>>> dssdev->type = OMAP_DISPLAY_TYPE_DBI ||
>>> dssdev->type = OMAP_DISPLAY_TYPE_SDI ||
>>> dssdev->type = OMAP_DISPLAY_TYPE_DSI) {
>>
>> I have no idea why VENC is not working for you when using
>> connector_status_unknown,
I agree that it should...
>> but I just tested DPI with
>> connector_status_unknown (i.e. changed the above func to return unknown
>> for DPI
Good hint. I can do the same check. Maybe it highlights the real issue.
>> ), and it works fine with X and X omap driver. And xrandr
>> confirms that the connection status is unknown:
>>
>> # xrandr
>> Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 2048 x 2048
>> HDMI-1 disconnected (normal left inverted right x axis y axis)
>> None-1 unknown connection 1920x1200+0+0 (normal left inverted right x
>> axis y axis) 0mm x 0mm
>> 1920x1200 60.00*+ 60.00 +
Which configs, drivers and system are you using for this results?
>>
>> Grep also shows that there are many drivers using
>> connector_status_unknown, so I'm guessing it should work fine...
>
> And beside it's not right to consider VENC as always connected, as it isn't.
Hm. Well, the VENC (meaning the D/A converter inside the OMAP3 chip)
is always connected. But the monitor or cable isn't.
> The unknown status is there for a reason, to describe connectors for which we
> can't get any status information. The situation is different for DPI, DBI, SDI
> and DSI as those are on-board busses that connect to a non-removable panel, so
> we can say with a good confidence that the panel is connected (the situation
> could be changed with a hammer and a chisel, but that's unlikely to happen,
> hence the confidence).
Well, it may be that the omapdrm and X11 combination (unfortuantely I don't
understand either and have not found a good description how they interwork),
keeps the VENC disabled if the connector is unknown.
And since there is no code to detect that a cable has been connected, there
might be missing some trigger to enable the interface.
The symptom I see is that the status of this card is "disabled" while the LCD
panel is "enabled". After doing my proposed patch, both come up "enabled".
So my patch appears to be a work around some other still hidden problem.
Any hint from the experts how to debug / find the real issue & solution is welcome.
BR,
Nikolaus
^ permalink raw reply
* Re: [PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected
From: H. Nikolaus Schaller @ 2015-11-13 16:45 UTC (permalink / raw)
To: Laurent Pinchart, Tomi Valkeinen
Cc: David Airlie, Jean-Christophe Plagniol-Villard, dri-devel, LKML,
linux-omap, linux-fbdev,
List for communicating with real GTA04 owners,
Gražvydas Ignotas
In-Reply-To: <3973104.FPbEEICOqe@avalon>
Here the test results:
Am 13.11.2015 um 13:01 schrieb Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> On Friday 13 November 2015 13:46:01 Tomi Valkeinen wrote:
>> On 13/11/15 12:29, H. Nikolaus Schaller wrote:
>>> Include VENC in the set of drivers where it is assimed that the cable
>>> is always connected. Like DPI, DSI, DBI and SDI do.
>>>
>>> Otherwise, the VENC will return cable status "unknown" and is not enabled
>>> by the X-server. So there is no video output signal.
>>>
>>> Tested on: BeagleBoard XM, GTA04 and OpenPandora
>>>
>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>> ---
>>>
>>> drivers/gpu/drm/omapdrm/omap_connector.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
>>> b/drivers/gpu/drm/omapdrm/omap_connector.c index 83f2a91..98ddb5d 100644
>>> --- a/drivers/gpu/drm/omapdrm/omap_connector.c
>>> +++ b/drivers/gpu/drm/omapdrm/omap_connector.c
>>> @@ -120,6 +120,7 @@ static enum drm_connector_status
>>> omap_connector_detect(
>>> else
>>> ret = connector_status_disconnected;
>>> } else if (dssdev->type = OMAP_DISPLAY_TYPE_DPI ||
>>> + dssdev->type = OMAP_DISPLAY_TYPE_VENC ||
>>> dssdev->type = OMAP_DISPLAY_TYPE_DBI ||
>>> dssdev->type = OMAP_DISPLAY_TYPE_SDI ||
>>> dssdev->type = OMAP_DISPLAY_TYPE_DSI) {
>>
>> I have no idea why VENC is not working for you when using
>> connector_status_unknown, but I just tested DPI with
>> connector_status_unknown (i.e. changed the above func to return unknown
>> for DPI), and it works fine with X and X omap driver. And xrandr
>> confirms that the connection status is unknown:
>>
>> # xrandr
>> Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 2048 x 2048
>> HDMI-1 disconnected (normal left inverted right x axis y axis)
>> None-1 unknown connection 1920x1200+0+0 (normal left inverted right x
>> axis y axis) 0mm x 0mm
>> 1920x1200 60.00*+ 60.00 +
A) with this VENC patch:
root@letux:~# xrandr
Screen 0: minimum 320 x 200, current 720 x 640, maximum 2048 x 2048
None-1 connected 720x574+0+0 0mm x 0mm
720x574i 50.00*+
None-2 connected 480x640+0+0 0mm x 0mm
480x640 65.74*+
root@letux:~# cat /sys/class/drm/card0-Unknown-*/enabled
enabled
enabled
root@letux:~# cat /sys/class/drm/card0-Unknown-*/status
connected
connected
B) w/o VENC patch (VENC returns returning connector_status_unknown):
root@letux:~# xrandr
Screen 0: minimum 320 x 200, current 480 x 640, maximum 2048 x 2048
None-1 connected 480x640+0+0 0mm x 0mm
480x640 65.74*+
None-2 unknown connection
720x574i 50.00 +
root@letux:~# cat /sys/class/drm/card0-Unknown-*/enabled
enabled
disabled
root@letux:~# cat /sys/class/drm/card0-Unknown-*/status
connected
unknown
C) with DPI (also) returning connector_status_unknown
root@letux:~# xrandr
Screen 0: minimum 320 x 200, current 720 x 640, maximum 2048 x 2048
None-1 unknown connection 720x574+0+0 0mm x 0mm
720x574i 50.00*+
None-2 unknown connection 480x640+0+0 0mm x 0mm
480x640 65.74*+
root@letux:~# cat /sys/class/drm/card0-Unknown-*/enabled
enabled
enabled
root@letux:~# cat /sys/class/drm/card0-Unknown-*/status
unknown
unknown
root@letux:~#
D) VENC patch but DPI returning connector_status_unknown
rroot@letux:~# xrandr
Screen 0: minimum 320 x 200, current 720 x 574, maximum 2048 x 2048
None-1 unknown connection
480x640 65.74 +
None-2 connected 720x574+0+0 0mm x 0mm
720x574i 50.00*+oot@letux:~# cat /sys/class/drm/card0-Unknown-*/enabled
disabled
enabled
root@letux:~# cat /sys/class/drm/card0-Unknown-*/status
unknown
connected
In case B) I have no TV out and in case D) I have no LCD.
So it looks as if it works if my LCD and VENC report the same
connection status. And fails if they differ.
Anyone with an explanation or even vague idea where to search
for the real bug?
BR and thanks,
Nikolaus
^ permalink raw reply
* [PATCH] [media] hdmi: added functions for MPEG InfoFrames
From: Enric Balletbo i Serra @ 2015-11-14 18:38 UTC (permalink / raw)
To: linux-fbdev
Cc: Mauro Carvalho Chehab, linux-kernel, dri-devel, Tomi Valkeinen,
Hans Verkuil, Martin Bugge, Thierry Reding,
Jean-Christophe Plagniol-Villard
The MPEG Source (MS) InfoFrame is in EIA/CEA-861B. It describes aspects of
the compressed video stream that were used to produce the uncompressed
video.
The patch adds functions to work with MPEG InfoFrames.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
drivers/video/hdmi.c | 156 +++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/hdmi.h | 24 ++++++++
2 files changed, 180 insertions(+)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1626892..d37e821 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -388,6 +388,81 @@ ssize_t hdmi_vendor_infoframe_pack(struct hdmi_vendor_infoframe *frame,
}
EXPORT_SYMBOL(hdmi_vendor_infoframe_pack);
+/**
+ * hdmi_mpeg_infoframe_init() - initialize an HDMI MPEG infoframe
+ * @frame: HDMI MPEG infoframe
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_mpeg_infoframe_init(struct hdmi_mpeg_infoframe *frame)
+{
+ memset(frame, 0, sizeof(*frame));
+
+ frame->type = HDMI_INFOFRAME_TYPE_MPEG;
+ frame->version = 1;
+ frame->length = HDMI_MPEG_INFOFRAME_SIZE;
+
+ return 0;
+}
+EXPORT_SYMBOL(hdmi_mpeg_infoframe_init);
+
+/**
+ * hdmi_mpeg_infoframe_pack() - write HDMI MPEG infoframe to binary buffer
+ * @frame: HDMI MPEG infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Packs the information contained in the @frame structure into a binary
+ * representation that can be written into the corresponding controller
+ * registers. Also computes the checksum as required by section 5.3.5 of
+ * the HDMI 1.4 specification.
+ *
+ * Returns the number of bytes packed into the binary buffer or a negative
+ * error code on failure.
+ */
+ssize_t hdmi_mpeg_infoframe_pack(struct hdmi_mpeg_infoframe *frame,
+ void *buffer, size_t size)
+{
+ u8 *ptr = buffer;
+ size_t length;
+
+ length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
+
+ if (size < length)
+ return -ENOSPC;
+
+ memset(buffer, 0, size);
+
+ ptr[0] = frame->type;
+ ptr[1] = frame->version;
+ ptr[2] = frame->length;
+ ptr[3] = 0; /* checksum */
+
+ /* start infoframe payload */
+ ptr += HDMI_INFOFRAME_HEADER_SIZE;
+
+ /*
+ * The MPEG Bit Rate is stored as a 32-bit number and is expressed in
+ * Hertz. MB#0 contains the least significant byte while MB#3 contains
+ * the most significant byte. If the MPEG Bit Rate is unknown or this
+ * field doesn’t apply, then all of the bits in Data Bytes 1-4 shall
+ * be set to 0.
+ */
+ ptr[0] = frame->bitrate & 0x000000ff;
+ ptr[1] = (frame->bitrate & 0x0000ff00) >> 8;
+ ptr[2] = (frame->bitrate & 0x00ff0000) >> 16;
+ ptr[3] = (frame->bitrate & 0xff000000) >> 24;
+
+ ptr[4] = frame->picture_type;
+ if (frame->repeated)
+ ptr[4] |= BIT(4);
+
+ hdmi_infoframe_set_checksum(buffer, length);
+
+ return length;
+}
+EXPORT_SYMBOL(hdmi_mpeg_infoframe_pack);
+
/*
* hdmi_vendor_any_infoframe_pack() - write a vendor infoframe to binary buffer
*/
@@ -435,6 +510,8 @@ hdmi_infoframe_pack(union hdmi_infoframe *frame, void *buffer, size_t size)
length = hdmi_vendor_any_infoframe_pack(&frame->vendor,
buffer, size);
break;
+ case HDMI_INFOFRAME_TYPE_MPEG:
+ length = hdmi_mpeg_infoframe_pack(&frame->mpeg, buffer, size);
default:
WARN(1, "Bad infoframe type %d\n", frame->any.type);
length = -EINVAL;
@@ -457,6 +534,8 @@ static const char *hdmi_infoframe_type_get_name(enum hdmi_infoframe_type type)
return "Source Product Description (SPD)";
case HDMI_INFOFRAME_TYPE_AUDIO:
return "Audio";
+ case HDMI_INFOFRAME_TYPE_MPEG:
+ return "MPEG";
}
return "Reserved";
}
@@ -899,6 +978,41 @@ static void hdmi_audio_infoframe_log(const char *level,
frame->downmix_inhibit ? "Yes" : "No");
}
+static const char *hdmi_mpeg_picture_get_name(enum hdmi_mpeg_picture_type type)
+{
+ switch (type) {
+ case HDMI_MPEG_PICTURE_TYPE_UNKNOWN:
+ return "Unknown";
+ case HDMI_MPEG_PICTURE_TYPE_I:
+ return "Intra-coded picture";
+ case HDMI_MPEG_PICTURE_TYPE_B:
+ return "Bi-predictive picture";
+ case HDMI_MPEG_PICTURE_TYPE_P:
+ return "Predicted picture";
+ }
+ return "Reserved";
+}
+
+/**
+ * hdmi_mpeg_infoframe_log() - log info of HDMI MPEG infoframe
+ * @level: logging level
+ * @dev: device
+ * @frame: HDMI MPEG infoframe
+ */
+static void hdmi_mpeg_infoframe_log(const char *level,
+ struct device *dev,
+ struct hdmi_mpeg_infoframe *frame)
+{
+ hdmi_infoframe_log_header(level, dev,
+ (struct hdmi_any_infoframe *)frame);
+
+ hdmi_log(" bit rate: %d Hz\n", frame->bitrate);
+ hdmi_log(" frame type: %s\n",
+ hdmi_mpeg_picture_get_name(frame->picture_type));
+ hdmi_log(" repeated frame: %s\n",
+ frame->repeated ? "Yes" : "No");
+}
+
static const char *
hdmi_3d_structure_get_name(enum hdmi_3d_structure s3d_struct)
{
@@ -987,6 +1101,9 @@ void hdmi_infoframe_log(const char *level,
case HDMI_INFOFRAME_TYPE_VENDOR:
hdmi_vendor_any_infoframe_log(level, dev, &frame->vendor);
break;
+ case HDMI_INFOFRAME_TYPE_MPEG:
+ hdmi_mpeg_infoframe_log(level, dev, &frame->mpeg);
+ break;
}
}
EXPORT_SYMBOL(hdmi_infoframe_log);
@@ -1138,6 +1255,42 @@ static int hdmi_audio_infoframe_unpack(struct hdmi_audio_infoframe *frame,
}
/**
+ * hdmi_mpeg_infoframe_unpack() - unpack binary buffer to a HDMI MPEG infoframe
+ * @buffer: source buffer
+ * @frame: HDMI MPEG infoframe
+ *
+ * Unpacks the information contained in binary @buffer into a structured
+ * @frame of the HDMI MPEG information frame. Also verifies the checksum as
+ * required by section 5.3.5 of the HDMI 1.4 specification.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+static int hdmi_mpeg_infoframe_unpack(struct hdmi_mpeg_infoframe *frame,
+ void *buffer)
+{
+ u8 *ptr = buffer;
+
+ if (ptr[0] != HDMI_INFOFRAME_TYPE_MPEG ||
+ ptr[1] != 1 ||
+ ptr[2] != HDMI_MPEG_INFOFRAME_SIZE) {
+ return -EINVAL;
+ }
+
+ if (hdmi_infoframe_checksum(buffer, HDMI_INFOFRAME_SIZE(MPEG)) != 0)
+ return -EINVAL;
+
+ ptr += HDMI_INFOFRAME_HEADER_SIZE;
+
+ frame->bitrate = (ptr[3] << 24) | (ptr[2] << 16) |
+ (ptr[1] << 8) | ptr[0];
+
+ frame->picture_type = ptr[4] & 0x03;
+ frame->repeated = ptr[4] & BIT(4) ? true : false;
+
+ return 0;
+}
+
+/**
* hdmi_vendor_infoframe_unpack() - unpack binary buffer to a HDMI vendor infoframe
* @buffer: source buffer
* @frame: HDMI Vendor infoframe
@@ -1234,6 +1387,9 @@ int hdmi_infoframe_unpack(union hdmi_infoframe *frame, void *buffer)
case HDMI_INFOFRAME_TYPE_VENDOR:
ret = hdmi_vendor_any_infoframe_unpack(&frame->vendor, buffer);
break;
+ case HDMI_INFOFRAME_TYPE_MPEG:
+ ret = hdmi_mpeg_infoframe_unpack(&frame->mpeg, buffer);
+ break;
default:
ret = -EINVAL;
break;
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index e974420..f480373 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -32,11 +32,13 @@ enum hdmi_infoframe_type {
HDMI_INFOFRAME_TYPE_AVI = 0x82,
HDMI_INFOFRAME_TYPE_SPD = 0x83,
HDMI_INFOFRAME_TYPE_AUDIO = 0x84,
+ HDMI_INFOFRAME_TYPE_MPEG = 0x85,
};
#define HDMI_IEEE_OUI 0x000c03
#define HDMI_INFOFRAME_HEADER_SIZE 4
#define HDMI_AVI_INFOFRAME_SIZE 13
+#define HDMI_MPEG_INFOFRAME_SIZE 10
#define HDMI_SPD_INFOFRAME_SIZE 25
#define HDMI_AUDIO_INFOFRAME_SIZE 10
@@ -297,6 +299,26 @@ int hdmi_vendor_infoframe_init(struct hdmi_vendor_infoframe *frame);
ssize_t hdmi_vendor_infoframe_pack(struct hdmi_vendor_infoframe *frame,
void *buffer, size_t size);
+enum hdmi_mpeg_picture_type {
+ HDMI_MPEG_PICTURE_TYPE_UNKNOWN = 0x00,
+ HDMI_MPEG_PICTURE_TYPE_I = 0x01,
+ HDMI_MPEG_PICTURE_TYPE_B = 0x02,
+ HDMI_MPEG_PICTURE_TYPE_P = 0x03,
+};
+
+struct hdmi_mpeg_infoframe {
+ enum hdmi_infoframe_type type;
+ unsigned char version;
+ unsigned char length;
+ u32 bitrate;
+ enum hdmi_mpeg_picture_type picture_type;
+ bool repeated;
+};
+
+int hdmi_mpeg_infoframe_init(struct hdmi_mpeg_infoframe *frame);
+ssize_t hdmi_mpeg_infoframe_pack(struct hdmi_mpeg_infoframe *frame,
+ void *buffer, size_t size);
+
union hdmi_vendor_any_infoframe {
struct {
enum hdmi_infoframe_type type;
@@ -314,6 +336,7 @@ union hdmi_vendor_any_infoframe {
* @spd: spd infoframe
* @vendor: union of all vendor infoframes
* @audio: audio infoframe
+ * @mpeg: mpeg infoframe
*
* This is used by the generic pack function. This works since all infoframes
* have the same header which also indicates which type of infoframe should be
@@ -325,6 +348,7 @@ union hdmi_infoframe {
struct hdmi_spd_infoframe spd;
union hdmi_vendor_any_infoframe vendor;
struct hdmi_audio_infoframe audio;
+ struct hdmi_mpeg_infoframe mpeg;
};
ssize_t
--
2.1.0
^ permalink raw reply related
* [PATCH] fbdev: ssd1307fb: Fix chargepump setting
From: Julian Scheel @ 2015-11-15 13:36 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1447337257-31232-1-git-send-email-julian@jusst.de>
The charge pump setting must have bit D4 set all time according to the SSD1306
App Note. Instead of doing an logical and off shifted setting bit with 0x14 it
must be an logical or with 0x10 to ensure D4 is set.
Signed-off-by: Julian Scheel <julian@jusst.de>
---
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 1611215..5965a9b 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -389,7 +389,7 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
return ret;
ret = ssd1307fb_write_cmd(par->client,
- (par->device_info->need_chargepump & 0x1 << 2) & 0x14);
+ 0x10 | ((par->device_info->need_chargepump & 0x01) << 2));
if (ret < 0)
return ret;
--
2.6.2
^ permalink raw reply related
* [PATCH v4 00/24] pwm: add support for atomic update
From: Boris Brezillon @ 2015-11-16 8:56 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This series adds support for atomic PWM update, or IOW, the capability
to update all the parameters of a PWM device (enabled/disabled, period,
duty and polarity) in one go.
Best Regards,
Boris
Changes since v3:
- rebased on pwm/for-next after pulling 4.4-rc1
- replace direct access to pwm fields by pwm_get/set_xxx() helpers, thus
fixing some build errors
- split changes to allow each maintainer to review/ack or take the
modification through its subsystem
Changes since v2:
- rebased on top of 4.3-rc2
- reintroduced pwm-regulator patches
Changes since v1:
- dropped applied patches
- squashed Heiko's fixes into the rockchip driver changes
- made a few cosmetic changes
- added kerneldoc comments
- added Heiko's patch to display more information in debugfs
- dropped pwm-regulator patches (should be submitted separately)
Boris Brezillon (23):
pwm: rcar: make use of pwm_is_enabled()
pwm: use pwm_get_xxx() helpers where appropriate
clk: pwm: use pwm_get_xxx() helpers where appropriate
hwmon: pwm-fan: use pwm_get_xxx() helpers where appropriate
misc: max77693-haptic: use pwm_get_xxx() helpers where appropriate
pwm: introduce default period and polarity concepts
pwm: use pwm_get/set_default_xxx() helpers where appropriate
leds: pwm: use pwm_get/set_default_xxx() helpers where appropriate
regulator: pwm: use pwm_get/set_default_xxx() helpers where
appropriate
backlight: pwm: use pwm_get/set_default_xxx() helpers where
appropriate
fbdev: use pwm_get/set_default_xxx() helpers where appropriate
misc: max77693: use pwm_get/set_default_xxx() helpers where
appropriate
hwmon: pwm-fan: use pwm_get/set_default_xxx() helpers where
appropriate
clk: pwm: use pwm_get/set_default_xxx() helpers where appropriate
pwm: define a new pwm_state struct
pwm: move the enabled/disabled info to pwm_state struct
backlight: pwm_bl: remove useless call to pwm_set_period
pwm: declare a default PWM state
pwm: add the PWM initial state retrieval infra
pwm: add the core infrastructure to allow atomic update
pwm: rockchip: add initial state retrieval
pwm: rockchip: add support for atomic update
regulator: pwm: properly initialize the ->state field
Heiko Stübner (1):
pwm: add information about polarity, duty cycle and period to debugfs
drivers/clk/clk-pwm.c | 11 +--
drivers/hwmon/pwm-fan.c | 16 ++--
drivers/input/misc/max77693-haptic.c | 9 +-
drivers/leds/leds-pwm.c | 2 +-
drivers/pwm/core.c | 169 +++++++++++++++++++++++++++++++----
drivers/pwm/pwm-crc.c | 2 +-
drivers/pwm/pwm-lpc18xx-sct.c | 2 +-
drivers/pwm/pwm-pxa.c | 2 +-
drivers/pwm/pwm-rcar.c | 2 +-
drivers/pwm/pwm-rockchip.c | 119 +++++++++++++++++++-----
drivers/pwm/pwm-sun4i.c | 3 +-
drivers/regulator/pwm-regulator.c | 30 ++++++-
drivers/video/backlight/lm3630a_bl.c | 4 +-
drivers/video/backlight/pwm_bl.c | 10 ++-
drivers/video/fbdev/ssd1307fb.c | 2 +-
include/linux/pwm.h | 89 +++++++++++++++---
16 files changed, 386 insertions(+), 86 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH v4 01/24] pwm: rcar: make use of pwm_is_enabled()
From: Boris Brezillon @ 2015-11-16 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1447664207-24370-1-git-send-email-boris.brezillon@free-electrons.com>
Commit 5c31252c4a86 ("pwm: Add the pwm_is_enabled() helper") introduced a
new function to test whether a PWM device is enabled or not without
manipulating PWM internal fields.
Hiding this is necessary if we want to smoothly move to the atomic PWM
config approach without impacting PWM drivers.
Fix this driver to use pwm_is_enabled() instead of directly accessing the
->flags field.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
drivers/pwm/pwm-rcar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
index 6e99a63..70899c9 100644
--- a/drivers/pwm/pwm-rcar.c
+++ b/drivers/pwm/pwm-rcar.c
@@ -157,7 +157,7 @@ static int rcar_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
return div;
/* Let the core driver set pwm->period if disabled and duty_ns = 0 */
- if (!test_bit(PWMF_ENABLED, &pwm->flags) && !duty_ns)
+ if (!pwm_is_enabled(pwm) && !duty_ns)
return 0;
rcar_pwm_update(rp, RCAR_PWMCR_SYNC, RCAR_PWMCR_SYNC, RCAR_PWMCR);
--
2.1.4
^ permalink raw reply related
* [PATCH v4 02/24] pwm: use pwm_get_xxx() helpers where appropriate
From: Boris Brezillon @ 2015-11-16 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1447664207-24370-1-git-send-email-boris.brezillon@free-electrons.com>
Use pwm_get_xxx() helpers instead of directly accessing the pwm->xxx field.
Doing that will ease adaptation of the PWM framework to support atomic
update.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
Patch generated with the following coccinelle script:
--->8---
virtual patch
@@
struct pwm_device *p;
expression e;
@@
(
-(p)->polarity = e;
+pwm_set_polarity((p), e);
|
-(p)->polarity
+pwm_get_polarity((p))
|
-(p)->period = e;
+pwm_set_period((p), e);
|
-(p)->period
+pwm_get_period((p))
|
-(p)->duty_cycle = e;
+pwm_set_duty_cycle((p), e);
|
-(p)->duty_cycle
+pwm_get_duty_cycle((p))
)
--->8---
---
drivers/pwm/pwm-crc.c | 2 +-
drivers/pwm/pwm-lpc18xx-sct.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 7101c70..2f88543 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -75,7 +75,7 @@ static int crc_pwm_config(struct pwm_chip *c, struct pwm_device *pwm,
return -EINVAL;
}
- if (pwm->period != period_ns) {
+ if (pwm_get_period((pwm)) != period_ns) {
int clk_div;
/* changing the clk divisor, need to disable fisrt */
diff --git a/drivers/pwm/pwm-lpc18xx-sct.c b/drivers/pwm/pwm-lpc18xx-sct.c
index 9163085..091fa13 100644
--- a/drivers/pwm/pwm-lpc18xx-sct.c
+++ b/drivers/pwm/pwm-lpc18xx-sct.c
@@ -249,7 +249,7 @@ static int lpc18xx_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
LPC18XX_PWM_EVSTATEMSK(lpc18xx_data->duty_event),
LPC18XX_PWM_EVSTATEMSK_ALL);
- if (pwm->polarity = PWM_POLARITY_NORMAL) {
+ if (pwm_get_polarity((pwm)) = PWM_POLARITY_NORMAL) {
set_event = lpc18xx_pwm->period_event;
clear_event = lpc18xx_data->duty_event;
res_action = LPC18XX_PWM_RES_SET;
--
2.1.4
^ permalink raw reply related
* [PATCH v4 03/24] clk: pwm: use pwm_get_xxx() helpers where appropriate
From: Boris Brezillon @ 2015-11-16 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1447664207-24370-1-git-send-email-boris.brezillon@free-electrons.com>
Use pwm_get_xxx() helpers instead of directly accessing the pwm->xxx field.
Doing that will ease adaptation of the PWM framework to support atomic
update.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
Patch generated with the following coccinelle script:
--->8---
virtual patch
@@
struct pwm_device *p;
expression e;
@@
(
-(p)->polarity = e;
+pwm_set_polarity((p), e);
|
-(p)->polarity
+pwm_get_polarity((p))
|
-(p)->period = e;
+pwm_set_period((p), e);
|
-(p)->period
+pwm_get_period((p))
|
-(p)->duty_cycle = e;
+pwm_set_duty_cycle((p), e);
|
-(p)->duty_cycle
+pwm_get_duty_cycle((p))
)
--->8---
---
drivers/clk/clk-pwm.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
index 328fcfc..b6306a2 100644
--- a/drivers/clk/clk-pwm.c
+++ b/drivers/clk/clk-pwm.c
@@ -71,22 +71,23 @@ static int clk_pwm_probe(struct platform_device *pdev)
if (IS_ERR(pwm))
return PTR_ERR(pwm);
- if (!pwm->period) {
+ if (!pwm_get_period((pwm))) {
dev_err(&pdev->dev, "invalid PWM period\n");
return -EINVAL;
}
if (of_property_read_u32(node, "clock-frequency", &clk_pwm->fixed_rate))
- clk_pwm->fixed_rate = NSEC_PER_SEC / pwm->period;
+ clk_pwm->fixed_rate = NSEC_PER_SEC / pwm_get_period((pwm));
- if (pwm->period != NSEC_PER_SEC / clk_pwm->fixed_rate &&
- pwm->period != DIV_ROUND_UP(NSEC_PER_SEC, clk_pwm->fixed_rate)) {
+ if (pwm_get_period((pwm)) != NSEC_PER_SEC / clk_pwm->fixed_rate &&
+ pwm_get_period((pwm)) != DIV_ROUND_UP(NSEC_PER_SEC, clk_pwm->fixed_rate)) {
dev_err(&pdev->dev,
"clock-frequency does not match PWM period\n");
return -EINVAL;
}
- ret = pwm_config(pwm, (pwm->period + 1) >> 1, pwm->period);
+ ret = pwm_config(pwm, (pwm_get_period((pwm)) + 1) >> 1,
+ pwm_get_period((pwm)));
if (ret < 0)
return ret;
--
2.1.4
^ permalink raw reply related
* [PATCH v4 04/24] hwmon: pwm-fan: use pwm_get_xxx() helpers where appropriate
From: Boris Brezillon @ 2015-11-16 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1447664207-24370-1-git-send-email-boris.brezillon@free-electrons.com>
Use pwm_get_xxx() helpers instead of directly accessing the pwm->xxx field.
Doing that will ease adaptation of the PWM framework to support atomic
update.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
Patch generated with the following coccinelle script:
--->8---
virtual patch
@@
struct pwm_device *p;
expression e;
@@
(
-(p)->polarity = e;
+pwm_set_polarity((p), e);
|
-(p)->polarity
+pwm_get_polarity((p))
|
-(p)->period = e;
+pwm_set_period((p), e);
|
-(p)->period
+pwm_get_period((p))
|
-(p)->duty_cycle = e;
+pwm_set_duty_cycle((p), e);
|
-(p)->duty_cycle
+pwm_get_duty_cycle((p))
)
--->8---
---
drivers/hwmon/pwm-fan.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 3e23003..105b964 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -47,8 +47,8 @@ static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
if (ctx->pwm_value = pwm)
goto exit_set_pwm_err;
- duty = DIV_ROUND_UP(pwm * (ctx->pwm->period - 1), MAX_PWM);
- ret = pwm_config(ctx->pwm, duty, ctx->pwm->period);
+ duty = DIV_ROUND_UP(pwm * (pwm_get_period((ctx->pwm)) - 1), MAX_PWM);
+ ret = pwm_config(ctx->pwm, duty, pwm_get_period((ctx->pwm)));
if (ret)
goto exit_set_pwm_err;
@@ -234,10 +234,10 @@ static int pwm_fan_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ctx);
/* Set duty cycle to maximum allowed */
- duty_cycle = ctx->pwm->period - 1;
+ duty_cycle = pwm_get_period((ctx->pwm)) - 1;
ctx->pwm_value = MAX_PWM;
- ret = pwm_config(ctx->pwm, duty_cycle, ctx->pwm->period);
+ ret = pwm_config(ctx->pwm, duty_cycle, pwm_get_period((ctx->pwm)));
if (ret) {
dev_err(&pdev->dev, "Failed to configure PWM\n");
return ret;
@@ -309,8 +309,9 @@ static int pwm_fan_resume(struct device *dev)
if (ctx->pwm_value = 0)
return 0;
- duty = DIV_ROUND_UP(ctx->pwm_value * (ctx->pwm->period - 1), MAX_PWM);
- ret = pwm_config(ctx->pwm, duty, ctx->pwm->period);
+ duty = DIV_ROUND_UP(ctx->pwm_value * (pwm_get_period((ctx->pwm)) - 1),
+ MAX_PWM);
+ ret = pwm_config(ctx->pwm, duty, pwm_get_period((ctx->pwm)));
if (ret)
return ret;
return pwm_enable(ctx->pwm);
--
2.1.4
^ permalink raw reply related
* [PATCH v4 05/24] misc: max77693-haptic: use pwm_get_xxx() helpers where appropriate
From: Boris Brezillon @ 2015-11-16 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1447664207-24370-1-git-send-email-boris.brezillon@free-electrons.com>
Use pwm_get_xxx() helpers instead of directly accessing the pwm->xxx field.
Doing that will ease adaptation of the PWM framework to support atomic
update.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
Patch generated with the following coccinelle script:
--->8---
virtual patch
@@
struct pwm_device *p;
expression e;
@@
(
-(p)->polarity = e;
+pwm_set_polarity((p), e);
|
-(p)->polarity
+pwm_get_polarity((p))
|
-(p)->period = e;
+pwm_set_period((p), e);
|
-(p)->period
+pwm_get_period((p))
|
-(p)->duty_cycle = e;
+pwm_set_duty_cycle((p), e);
|
-(p)->duty_cycle
+pwm_get_duty_cycle((p))
)
--->8---
---
drivers/input/misc/max77693-haptic.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/input/misc/max77693-haptic.c b/drivers/input/misc/max77693-haptic.c
index 6d96bff..a038fb3 100644
--- a/drivers/input/misc/max77693-haptic.c
+++ b/drivers/input/misc/max77693-haptic.c
@@ -70,10 +70,11 @@ struct max77693_haptic {
static int max77693_haptic_set_duty_cycle(struct max77693_haptic *haptic)
{
- int delta = (haptic->pwm_dev->period + haptic->pwm_duty) / 2;
+ int delta = (pwm_get_period((haptic->pwm_dev)) + haptic->pwm_duty) / 2;
int error;
- error = pwm_config(haptic->pwm_dev, delta, haptic->pwm_dev->period);
+ error = pwm_config(haptic->pwm_dev, delta,
+ pwm_get_period((haptic->pwm_dev)));
if (error) {
dev_err(haptic->dev, "failed to configure pwm: %d\n", error);
return error;
@@ -245,7 +246,7 @@ static int max77693_haptic_play_effect(struct input_dev *dev, void *data,
* The formula to convert magnitude to pwm_duty as follows:
* - pwm_duty = (magnitude * pwm_period) / MAX_MAGNITUDE(0xFFFF)
*/
- period_mag_multi = (u64)haptic->pwm_dev->period * haptic->magnitude;
+ period_mag_multi = (u64)pwm_get_period((haptic->pwm_dev)) * haptic->magnitude;
haptic->pwm_duty = (unsigned int)(period_mag_multi >>
MAX_MAGNITUDE_SHIFT);
--
2.1.4
^ permalink raw reply related
* [PATCH v4 06/24] pwm: introduce default period and polarity concepts
From: Boris Brezillon @ 2015-11-16 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1447664207-24370-1-git-send-email-boris.brezillon@free-electrons.com>
When requested by a user, the PWM is assigned a default period and polarity
extracted from the DT, the platform data or statically set by the driver.
Those default values are currently stored in the period and polarity
fields of the pwm_device struct, but they will be stored somewhere else
once we have introduced the architecture allowing for hardware state
retrieval.
The pwm_set_default_polarity and pwm_set_default_period should only be
used by PWM drivers or the PWM core infrastructure to specify the
default period and polarity values.
PWM users might call the pwm_get_default_period to query the default
period value. There is currently no helper to query the default
polarity, but it might be added later on if there is a need for it.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
---
include/linux/pwm.h | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index cfc3ed4..8ba57fc 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -118,11 +118,22 @@ static inline void pwm_set_period(struct pwm_device *pwm, unsigned int period)
pwm->period = period;
}
+static inline void pwm_set_default_period(struct pwm_device *pwm,
+ unsigned int period)
+{
+ pwm_set_period(pwm, period);
+}
+
static inline unsigned int pwm_get_period(const struct pwm_device *pwm)
{
return pwm ? pwm->period : 0;
}
+static inline unsigned int pwm_get_default_period(const struct pwm_device *pwm)
+{
+ return pwm_get_period(pwm);
+}
+
static inline void pwm_set_duty_cycle(struct pwm_device *pwm, unsigned int duty)
{
if (pwm)
@@ -139,6 +150,12 @@ static inline unsigned int pwm_get_duty_cycle(const struct pwm_device *pwm)
*/
int pwm_set_polarity(struct pwm_device *pwm, enum pwm_polarity polarity);
+static inline void pwm_set_default_polarity(struct pwm_device *pwm,
+ enum pwm_polarity polarity)
+{
+ pwm_set_polarity(pwm, polarity);
+}
+
static inline enum pwm_polarity pwm_get_polarity(const struct pwm_device *pwm)
{
return pwm ? pwm->polarity : PWM_POLARITY_NORMAL;
--
2.1.4
^ permalink raw reply related
* [PATCH v4 07/24] pwm: use pwm_get/set_default_xxx() helpers where appropriate
From: Boris Brezillon @ 2015-11-16 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1447664207-24370-1-git-send-email-boris.brezillon@free-electrons.com>
pwm_set/get_default_xxx() helpers have been introduced to differentiate
the default PWM states (those retrieved through DT, PWM lookup table or
statically assigned by the driver) and the current PWM ones.
Make use of those helpers where appropriate.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
drivers/pwm/core.c | 14 +++++++-------
drivers/pwm/pwm-pxa.c | 2 +-
drivers/pwm/pwm-sun4i.c | 3 ++-
3 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index d24ca5f..59073a1 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -146,12 +146,12 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct of_phandle_args *args)
if (IS_ERR(pwm))
return pwm;
- pwm_set_period(pwm, args->args[1]);
+ pwm_set_default_period(pwm, args->args[1]);
if (args->args[2] & PWM_POLARITY_INVERTED)
- pwm_set_polarity(pwm, PWM_POLARITY_INVERSED);
+ pwm_set_default_polarity(pwm, PWM_POLARITY_INVERSED);
else
- pwm_set_polarity(pwm, PWM_POLARITY_NORMAL);
+ pwm_set_default_polarity(pwm, PWM_POLARITY_NORMAL);
return pwm;
}
@@ -172,7 +172,7 @@ of_pwm_simple_xlate(struct pwm_chip *pc, const struct of_phandle_args *args)
if (IS_ERR(pwm))
return pwm;
- pwm_set_period(pwm, args->args[1]);
+ pwm_set_default_period(pwm, args->args[1]);
return pwm;
}
@@ -268,7 +268,7 @@ int pwmchip_add_with_polarity(struct pwm_chip *chip,
pwm->chip = chip;
pwm->pwm = chip->base + i;
pwm->hwpwm = i;
- pwm->polarity = polarity;
+ pwm_set_default_polarity(pwm, polarity);
mutex_init(&pwm->lock);
radix_tree_insert(&pwm_tree, pwm->pwm, pwm);
@@ -751,8 +751,8 @@ struct pwm_device *pwm_get(struct device *dev, const char *con_id)
if (IS_ERR(pwm))
goto out;
- pwm_set_period(pwm, chosen->period);
- pwm_set_polarity(pwm, chosen->polarity);
+ pwm_set_default_period(pwm, chosen->period);
+ pwm_set_default_polarity(pwm, chosen->polarity);
out:
mutex_unlock(&pwm_lookup_lock);
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index cb2f702..65b80aa 100644
--- a/drivers/pwm/pwm-pxa.c
+++ b/drivers/pwm/pwm-pxa.c
@@ -160,7 +160,7 @@ pxa_pwm_of_xlate(struct pwm_chip *pc, const struct of_phandle_args *args)
if (IS_ERR(pwm))
return pwm;
- pwm_set_period(pwm, args->args[0]);
+ pwm_set_default_period(pwm, args->args[0]);
return pwm;
}
diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index 67af9f6..f6a7451 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -354,7 +354,8 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
val = sun4i_pwm_readl(pwm, PWM_CTRL_REG);
for (i = 0; i < pwm->chip.npwm; i++)
if (!(val & BIT_CH(PWM_ACT_STATE, i)))
- pwm->chip.pwms[i].polarity = PWM_POLARITY_INVERSED;
+ pwm_set_default_polarity(&pwm->chip.pwms[i],
+ PWM_POLARITY_INVERSED);
clk_disable_unprepare(pwm->clk);
return 0;
--
2.1.4
^ permalink raw reply related
* [PATCH v4 08/24] leds: pwm: use pwm_get/set_default_xxx() helpers where appropriate
From: Boris Brezillon @ 2015-11-16 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1447664207-24370-1-git-send-email-boris.brezillon@free-electrons.com>
pwm_set/get_default_xxx() helpers have been introduced to differentiate
the default PWM states (those retrieved through DT, PWM lookup table or
statically assigned by the driver) and the current ones.
Make use of those helpers where appropriate.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
---
drivers/leds/leds-pwm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 1d07e3e..2c564d1 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -125,7 +125,7 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
if (led_data->can_sleep)
INIT_WORK(&led_data->work, led_pwm_work);
- led_data->period = pwm_get_period(led_data->pwm);
+ led_data->period = pwm_get_default_period(led_data->pwm);
if (!led_data->period && (led->pwm_period_ns > 0))
led_data->period = led->pwm_period_ns;
--
2.1.4
^ permalink raw reply related
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