[PATCH 1/3] modetest: introduce get_prop_info() for getting property id and type
On 26 August 2015 at 07:21, Hyungwon Hwang wrote:
> Modetest gets the property name from user to set it. So the name must be
> converted to its id. Until now, this is done in the set_property(). But to
> support atomic modeset in modetest, this logic should be separated from the
> fuction, because atomic modeset and legacy modeset use different IOCTLs.
>
> Signed-off-by: Hyungwon Hwang
> ---
> tests/modetest/modetest.c | 31 +--
> 1 file changed, 21 insertions(+), 10 deletions(-)
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index 43bd06f..b7f6d32 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -866,12 +866,11 @@ struct property_arg {
> uint64_t value;
> };
>
> -static void set_property(struct device *dev, struct property_arg *p)
> +static int get_prop_info(struct resources *resources, struct property_arg *p,
> + char
> *obj_type)
Strictly speaking you don't need the struct device > struct resources
change here.
But if you prefer doing so, keep the const qualifier for obj_type.
> {
> drmModeObjectProperties *props = NULL;
> drmModePropertyRes **props_info = NULL;
> - const char *obj_type;
> - int ret;
> int i;
>
...
> +static void set_property(struct device *dev, struct property_arg *p)
> +{
> + int ret;
> + char *obj_type = NULL;
> +
Drop the initializer and constify.
-Emil
[PATCH 2/3] modetest: add atomic modeset support
Hi Hyungwon Hwang
On 26 August 2015 at 07:21, Hyungwon Hwang wrote:
> This patch adds support for atomic modeset. Using -a option, user can
> make modeset to use DRM_IOCTL_MODE_ATOMIC instead of legacy IOCTLs.
> Also, by using -w option, user can set the property as before.
>
> Signed-off-by: Hyungwon Hwang
> ---
> tests/modetest/modetest.c | 221
> +++---
> 1 file changed, 187 insertions(+), 34 deletions(-)
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index b7f6d32..753a559 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -1444,25 +1444,32 @@ static int parse_property(struct property_arg *p,
> const char *arg)
>
> static void usage(char *name)
> {
> - fprintf(stderr, "usage: %s [-cDdefMPpsCvw]\n", name);
> + fprintf(stderr, "usage: %s [-acDdefMPpsCvw]\n", name);
> + fprintf(stderr, "\tA: supported in atomic modeset\n");
> + fprintf(stderr, "\tL: supported in legacy modeset\n");
>
> - fprintf(stderr, "\n Query options:\n\n");
> + fprintf(stderr, "\n Query options: [AL]\n\n");
> fprintf(stderr, "\t-c\tlist connectors\n");
> fprintf(stderr, "\t-e\tlist encoders\n");
> fprintf(stderr, "\t-f\tlist framebuffers\n");
> fprintf(stderr, "\t-p\tlist CRTCs and planes (pipes)\n");
>
> - fprintf(stderr, "\n Test options:\n\n");
> + fprintf(stderr, "\n Common Test options: [AL]\n\n");
> + fprintf(stderr, "\t-w ::\tset property\n");
> +
> + fprintf(stderr, "\n Atomic Test options: [A]\n\n");
> + fprintf(stderr, "\t-a\tuse atomic modeset\n");
> +
> + fprintf(stderr, "\n Legacy test options: [L]\n\n");
> fprintf(stderr, "\t-P
> :x[++][*][@]\tset a plane\n");
> fprintf(stderr, "\t-s
> [,][@]:[-][@]\tset
> a mode\n");
> fprintf(stderr, "\t-C\ttest hw cursor\n");
> fprintf(stderr, "\t-v\ttest vsynced page flipping\n");
> - fprintf(stderr, "\t-w ::\tset property\n");
>
> fprintf(stderr, "\n Generic options:\n\n");
> - fprintf(stderr, "\t-d\tdrop master after mode set\n");
> - fprintf(stderr, "\t-M module\tuse the given driver\n");
> - fprintf(stderr, "\t-D device\tuse the given device\n");
> + fprintf(stderr, "\t-d\tdrop master after mode set [L]\n");
> + fprintf(stderr, "\t-M module\tuse the given driver [AL]\n");
> + fprintf(stderr, "\t-D device\tuse the given device [AL]\n");
>
Readability is greatly impaired with this approach. Can I suggest
splitting these into two sections - legacy and atomic.
> fprintf(stderr, "\n\tDefault is to dump all info.\n");
> exit(0);
> @@ -1495,7 +1502,132 @@ static int cursor_supported(void)
> return 1;
> }
>
> -static char optstr[] = "cdD:efM:P:ps:Cvw:";
> +static uint32_t is_obj_id_in_prop_args(struct property_arg *prop_args,
> + unsigned int prop_count, uint32_t obj_id)
Function name implies bool return value, as does the true/false below,
yet you define it as "uint32_t" ?
> +{
> + unsigned int i;
> +
> + for (i = 0; i < prop_count; i++)
> + if (obj_id == prop_args[i].obj_id)
> + return true;
> +
> + return false;
> +}
> +
> +static int get_value_in_prop_args(struct property_arg *prop_args,
> + unsigned int prop_count, uint32_t obj_id,
> + const char *name)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < prop_count; i++)
> + if (prop_args[i].obj_id == obj_id &&
> + !strcmp(prop_args[i].name, name))
Indentation seems off. Align prop_args... with !strcmp...
> + return (int)prop_args[i].value;
> +
> + return -1;
> +}
> +
> +static uint32_t get_atomic_plane_prop_id(struct resources *res, uint32_t
> obj_id,
> + const char *name)
> +{
> + drmModePropertyRes *props_info;
> + struct plane *plane;
> + unsigned int i, j;
> +
> + for (i = 0; i < res->plane_res->count_planes; i++) {
> + plane = &res->planes[i];
> + if (plane->plane->plane_id != obj_id)
> + continue;
> +
> + for (j = 0; j < plane->props->count_props; j++) {
> + props_info = plane->props_info[j];
> + if (!strcmp(props_info->name, name))
> + return props_info->prop_id;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int allocate_fb(struct device *dev, drmModeAtomicReqPtr req, struct
> resources *res,
> + uint32_t width, uint32_t height, uint32_t
> pixel_format,
> + int pattern, struct bo **bo, uint32_t *fb_id)
> +{
> + uint32_t handles[4] = {0}, pitches[4] = {0}, offsets[4] = {0};
> + int ret;
> +
> +
[PATCH 2/3] modetest: add atomic modeset support
On 2 September 2015 at 01:11, Emil Velikov wrote:
> Hi Hyungwon Hwang
>
> On 26 August 2015 at 07:21, Hyungwon Hwang wrote:
>> This patch adds support for atomic modeset. Using -a option, user can
>> make modeset to use DRM_IOCTL_MODE_ATOMIC instead of legacy IOCTLs.
>> Also, by using -w option, user can set the property as before.
>>
>> Signed-off-by: Hyungwon Hwang
>> ---
>> tests/modetest/modetest.c | 221
>> +++---
>> 1 file changed, 187 insertions(+), 34 deletions(-)
>>
>> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
>> index b7f6d32..753a559 100644
>> --- a/tests/modetest/modetest.c
>> +++ b/tests/modetest/modetest.c
>> @@ -1444,25 +1444,32 @@ static int parse_property(struct property_arg *p,
>> const char *arg)
>>
>> static void usage(char *name)
>> {
>> - fprintf(stderr, "usage: %s [-cDdefMPpsCvw]\n", name);
>> + fprintf(stderr, "usage: %s [-acDdefMPpsCvw]\n", name);
>> + fprintf(stderr, "\tA: supported in atomic modeset\n");
>> + fprintf(stderr, "\tL: supported in legacy modeset\n");
>>
>> - fprintf(stderr, "\n Query options:\n\n");
>> + fprintf(stderr, "\n Query options: [AL]\n\n");
>> fprintf(stderr, "\t-c\tlist connectors\n");
>> fprintf(stderr, "\t-e\tlist encoders\n");
>> fprintf(stderr, "\t-f\tlist framebuffers\n");
>> fprintf(stderr, "\t-p\tlist CRTCs and planes (pipes)\n");
>>
>> - fprintf(stderr, "\n Test options:\n\n");
>> + fprintf(stderr, "\n Common Test options: [AL]\n\n");
>> + fprintf(stderr, "\t-w ::\tset property\n");
>> +
>> + fprintf(stderr, "\n Atomic Test options: [A]\n\n");
>> + fprintf(stderr, "\t-a\tuse atomic modeset\n");
>> +
>> + fprintf(stderr, "\n Legacy test options: [L]\n\n");
>> fprintf(stderr, "\t-P
>> :x[++][*][@]\tset a plane\n");
>> fprintf(stderr, "\t-s
>> [,][@]:[-][@]\tset
>> a mode\n");
>> fprintf(stderr, "\t-C\ttest hw cursor\n");
>> fprintf(stderr, "\t-v\ttest vsynced page flipping\n");
>> - fprintf(stderr, "\t-w ::\tset property\n");
>>
>> fprintf(stderr, "\n Generic options:\n\n");
>> - fprintf(stderr, "\t-d\tdrop master after mode set\n");
>> - fprintf(stderr, "\t-M module\tuse the given driver\n");
>> - fprintf(stderr, "\t-D device\tuse the given device\n");
>> + fprintf(stderr, "\t-d\tdrop master after mode set [L]\n");
>> + fprintf(stderr, "\t-M module\tuse the given driver [AL]\n");
>> + fprintf(stderr, "\t-D device\tuse the given device [AL]\n");
>>
> Readability is greatly impaired with this approach. Can I suggest
> splitting these into two sections - legacy and atomic.
>
A bit tired and I've misread the above. Please ignore this comment.
-Emil
[PATCH 3/3] modetest: add atomic page flip support
On 26 August 2015 at 07:21, Hyungwon Hwang wrote:
> This patch adds support for atomic page flip. User can specify -V option
> with the plane id for testing atomic page flipping.
> ---
> tests/modetest/modetest.c | 153
> --
> 1 file changed, 149 insertions(+), 4 deletions(-)
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index 753a559..9bffa98 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -719,6 +719,10 @@ struct pipe_arg {
> struct timeval start;
>
> int swap_count;
> +
> + /* for atomic modeset */
> + uint32_t plane_id;
> + uint32_t fb_obj_id;
> };
>
> struct plane_arg {
> @@ -1444,7 +1448,7 @@ static int parse_property(struct property_arg *p, const
> char *arg)
>
> static void usage(char *name)
> {
> - fprintf(stderr, "usage: %s [-acDdefMPpsCvw]\n", name);
> + fprintf(stderr, "usage: %s [-acDdefMPpsCvVw]\n", name);
> fprintf(stderr, "\tA: supported in atomic modeset\n");
> fprintf(stderr, "\tL: supported in legacy modeset\n");
>
> @@ -1459,6 +1463,7 @@ static void usage(char *name)
>
> fprintf(stderr, "\n Atomic Test options: [A]\n\n");
> fprintf(stderr, "\t-a\tuse atomic modeset\n");
> + fprintf(stderr, "\t-V \ttest vsynced page
> flipping\n");
>
> fprintf(stderr, "\n Legacy test options: [L]\n\n");
> fprintf(stderr, "\t-P
> :x[++][*][@]\tset a plane\n");
> @@ -1627,7 +1632,138 @@ static void atomic_modeset(struct device *dev,
> drmModeAtomicReqPtr req,
> drmModeAtomicCommit(dev->fd, req, flags, NULL);
> }
>
> -static char optstr[] = "acdD:efM:P:ps:Cvw:";
> +static void
> +atomic_page_flip_handler(int fd, unsigned int frame,
> + unsigned int sec, unsigned int usec, void *data)
> +{
> + static drmModeAtomicReqPtr req = NULL;
> + unsigned int new_fb_id;
> + struct timeval end;
> + struct pipe_arg *pipe;
> + double t;
> + uint32_t flags = 0;
> +
> + pipe = (struct pipe_arg *)(unsigned long)data;
> +
> + if (pipe->current_fb_id == pipe->fb_id[0])
> + new_fb_id = pipe->fb_id[1];
> + else
> + new_fb_id = pipe->fb_id[0];
> +
> + pipe->current_fb_id = new_fb_id;
> + pipe->swap_count++;
> +
> + req = drmModeAtomicAlloc();
> +
> + drmModeAtomicAddProperty(req, pipe->plane_id, pipe->fb_obj_id,
> new_fb_id);
> +
We'll crash badly if req is NULL here. I guess we can smoke test the
API, but that is no excuse for the missing null check.
> + flags = DRM_MODE_PAGE_FLIP_EVENT;
> + drmModeAtomicCommit(fd, req, flags, pipe);
> +
> + if (pipe->swap_count == 60) {
> + gettimeofday(&end, NULL);
> + t = end.tv_sec + end.tv_usec * 1e-6 -
> + (pipe->start.tv_sec + pipe->start.tv_usec * 1e-6);
> + fprintf(stderr, "freq: %.02fHz\n", pipe->swap_count / t);
> + pipe->swap_count = 0;
> + pipe->start = end;
> + }
> +
> + drmModeAtomicFree(req);
> +}
> +
> +static int atomic_test_page_flip(struct device *dev, drmModeAtomicReqPtr req,
> + struct resources *res, struct property_arg *prop_args,
> + unsigned int prop_count,unsigned int plane_id)
> +{
> + struct bo *other_bo;
> + unsigned int other_fb_id;
> + struct pipe_arg *pipe = NULL;
> + drmEventContext evctx;
> + uint32_t flags = 0, fb_obj_id = 0, pixel_format;
> + uint64_t width, height;
> + int ret;
> +
> + if (!is_obj_id_in_prop_args(prop_args, prop_count, plane_id))
> + return -1;
> +
> + fb_obj_id = get_atomic_plane_prop_id(res, plane_id, "FB_ID");
> + if (!fb_obj_id)
> + return -1;
> +
> + width = get_value_in_prop_args(prop_args, prop_count, plane_id,
> + "SRC_W");
> + height = get_value_in_prop_args(prop_args, prop_count, plane_id,
> + "SRC_H");
Here and in the previous patch you assume that always succeeds.
Perhaps one should check it otherwise all sort of crazy stuff will
happen in allocate_fb() ?
> + pixel_format = DRM_FORMAT_XRGB;
> +
For the future we might consider making this user configurable,
although as is it looks like a good default.
> + ret = allocate_fb(dev, req, res, width, height, pixel_format,
> + PATTERN_TILES, &other_bo, &other_fb_id);
> + if (ret < 0)
> + return ret;
> +
> + ret = drmModeAtomicAddProperty(req, plane_id, fb_obj_id,
> + other_fb_id);
> + if (ret < 0)
Why do you return 'success' here ?
> + goto err;
> +
> + if (!fb_obj_id) {
Here (and in previous patch) we're missing RmFB()
Leaking other_bo.
> + fprintf(stderr, "page flipping requires at least one plane
> setting.\n");
[PATCH 3/5] drm/i2c: adv7511: Refactor encoder slave functions
On 08/04/2015 05:54 PM, Rob Clark wrote: > On Tue, Aug 4, 2015 at 1:16 AM, Andrzej Hajda wrote: >> On 08/03/2015 04:04 PM, Rob Clark wrote: >>> On Mon, Aug 3, 2015 at 8:03 AM, Andrzej Hajda >>> wrote: Hi, On 07/31/2015 04:48 PM, Rob Clark wrote: > On Fri, Jul 31, 2015 at 8:58 AM, Boris Brezillon > wrote: >> Hi Rob, >> >> On Fri, 31 Jul 2015 08:13:59 -0400 >> Rob Clark wrote: >> (...) >> Another problem I've seen with some drm bridge drivers is that they >> directly create their own connector, which, as Archit stated, is wrong >> if you decide to chain this bridge with another bridge. The other > I agree with Archit on this. He took this approach w/ msm support for > external bridges, and it seems sensible that the last bridge > constructs the connector. (Plus presumably that is where hpd, ddc > probing, etc, is happing) With this approach many bridges should construct connector conditionally, depending if there is something behind them in pipeline (the same is true for encoders and even crtcs). It works, but for me there is lot of unnecessary code and all those conditional paths make things less friendly for development. Wouldn't be better to move creation of the connector to the main drm driver, it would require probably adding some opses/fields to drm_bridges but the drivers would be simpler, I guess. >>> six of one, half dozen of the other.. you'd still need to implement >>> the hpd and ddc probe bits, and that sort of thing *somewhere*. >>> Whether it is directly by implementing drm_connector in the bridge, or >>> indirectly via some extra drm_bridge op's called by a shim connector >>> in the main drm driver, doesn't really seem to change things.. >> >> The difference is that instead of duplicating connector related code in every >> driver you will call one helper from the main drm driver/core. > > Which isn't more than a few lines of code.. I mean, looking at a > couple connectors, the bulk of the code is hpd and ddc related. That > doesn't magically go away. There isn't that many lines of > boilerplate, so meh. Could we get to a consensus for this? Is it okay for bridge and i2c_encoder to co-exist for now? Thanks, Archit > > BR, > -R > >> Regards >> Andrzej >> >>> >>> BR, >>> -R >>> Regards Andrzej >> reason why the bridge should not create the connector by its own is >> that in some case the encoder supports different types of connectors (a >> TDMS encoder can be used to output HDMI or DVI), and thus, selecting >> the connector type should be left to the part responsible for creating >> the display pipelines. > did you mean "should" instead of "should not"? Otherwise I don't > think I understand.. > > BR, > -R > >> This being said, I'm definitely not an expert in this area, so don't >> hesitate to show me where I'm wrong. >> >> Best Regards, >> >> Boris >> >> -- >> Boris Brezillon, Free Electrons >> Embedded Linux and Kernel engineering >> http://free-electrons.com >> -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH] drm/nouveau: remove unused function
coverity.com reported that memset was using a buffer of size 0, on
checking the code it turned out that the function was not being used. So
remove it.
Signed-off-by: Sudip Mukherjee
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/pmu.h | 2 --
drivers/gpu/drm/nouveau/nvkm/subdev/bios/pmu.c | 13 -
2 files changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/pmu.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/pmu.h
index d606875..3a643df 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/pmu.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/pmu.h
@@ -4,8 +4,6 @@ struct nvbios_pmuT {
};
u32 nvbios_pmuTe(struct nvkm_bios *, u8 *ver, u8 *hdr, u8 *cnt, u8 *len);
-u32 nvbios_pmuTp(struct nvkm_bios *, u8 *ver, u8 *hdr, u8 *cnt, u8 *len,
-struct nvbios_pmuT *);
struct nvbios_pmuE {
u8 type;
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/pmu.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/pmu.c
index 441ec45..c268e5a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/pmu.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/pmu.c
@@ -62,19 +62,6 @@ nvbios_pmuTe(struct nvkm_bios *bios, u8 *ver, u8 *hdr, u8
*cnt, u8 *len)
}
u32
-nvbios_pmuTp(struct nvkm_bios *bios, u8 *ver, u8 *hdr, u8 *cnt, u8 *len,
-struct nvbios_pmuT *info)
-{
- u32 data = nvbios_pmuTe(bios, ver, hdr, cnt, len);
- memset(info, 0x00, sizeof(*info));
- switch (!!data * *ver) {
- default:
- break;
- }
- return data;
-}
-
-u32
nvbios_pmuEe(struct nvkm_bios *bios, int idx, u8 *ver, u8 *hdr)
{
u8 cnt, len;
--
1.9.1
[Bug 76559] screen corruption after going from VT to X
https://bugs.freedesktop.org/show_bug.cgi?id=76559 Fabio Pedretti changed: What|Removed |Added Attachment #96296|0 |1 is obsolete|| CC||fabio.ped at libero.it --- Comment #4 from Fabio Pedretti --- Created attachment 118045 --> https://bugs.freedesktop.org/attachment.cgi?id=118045&action=edit dmesg with 3.19.0-26-generic Any news on this issue? It is still reproducible with Ubuntu 15.04 kernel: Linux fabio-mac 3.19.0-26-generic #28-Ubuntu SMP Tue Aug 11 14:16:45 UTC 2015 i686 i686 i686 GNU/Linux Attached updated dmesg. Let me know if something other is needed. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150902/ca40a592/attachment-0001.html>
[Bug 91841] Juniper 5770 entering Hibernate crashes the system (instant reboot)
https://bugs.freedesktop.org/show_bug.cgi?id=91841 Heiko Lechner changed: What|Removed |Added Component|DRM/Radeon |Driver/Radeon Version|unspecified |7.5 (2009.10) Assignee|dri-devel at lists.freedesktop |xorg-driver-ati at lists.x.org |.org| Product|DRI |xorg QA Contact||xorg-team at lists.x.org -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150902/3c0054b5/attachment.html>
[PATCH 1/2] drm/atomic: Make prepare_fb/cleanup_fb only take state, v3.
This removes the need to separately track fb changes i915.
That will be done as a separate commit, however.
Changes since v1:
- Add dri-devel to cc.
- Fix a check in intel's prepare and cleanup fb to take rotation
into account.
Changes since v2:
- Split out i915 changes to a separate commit.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 4 +++-
drivers/gpu/drm/drm_atomic_helper.c | 21 ++---
drivers/gpu/drm/drm_plane_helper.c | 6 +++---
drivers/gpu/drm/i915/intel_display.c| 9 -
drivers/gpu/drm/i915/intel_drv.h| 2 --
drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 10 --
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 9 -
drivers/gpu/drm/omapdrm/omap_plane.c| 10 ++
drivers/gpu/drm/tegra/dc.c | 2 --
include/drm/drm_plane_helper.h | 2 --
10 files changed, 38 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index be9fa8220499..36fda86b3518 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -712,11 +712,13 @@ static int atmel_hlcdc_plane_atomic_check(struct
drm_plane *p,
}
static int atmel_hlcdc_plane_prepare_fb(struct drm_plane *p,
- struct drm_framebuffer *fb,
const struct drm_plane_state *new_state)
{
struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
+ if (!new_state->fb)
+ return 0;
+
return atmel_hlcdc_layer_update_start(&plane->layer);
}
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index a2629ee133ba..9b0c47690ae8 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -,17 +,14 @@ int drm_atomic_helper_prepare_planes(struct drm_device
*dev,
const struct drm_plane_helper_funcs *funcs;
struct drm_plane *plane = state->planes[i];
struct drm_plane_state *plane_state = state->plane_states[i];
- struct drm_framebuffer *fb;
if (!plane)
continue;
funcs = plane->helper_private;
- fb = plane_state->fb;
-
- if (fb && funcs->prepare_fb) {
- ret = funcs->prepare_fb(plane, fb, plane_state);
+ if (funcs->prepare_fb) {
+ ret = funcs->prepare_fb(plane, plane_state);
if (ret)
goto fail;
}
@@ -1134,17 +1131,14 @@ fail:
const struct drm_plane_helper_funcs *funcs;
struct drm_plane *plane = state->planes[i];
struct drm_plane_state *plane_state = state->plane_states[i];
- struct drm_framebuffer *fb;
if (!plane)
continue;
funcs = plane->helper_private;
- fb = state->plane_states[i]->fb;
-
- if (fb && funcs->cleanup_fb)
- funcs->cleanup_fb(plane, fb, plane_state);
+ if (funcs->cleanup_fb)
+ funcs->cleanup_fb(plane, plane_state);
}
@@ -1300,14 +1294,11 @@ void drm_atomic_helper_cleanup_planes(struct drm_device
*dev,
for_each_plane_in_state(old_state, plane, plane_state, i) {
const struct drm_plane_helper_funcs *funcs;
- struct drm_framebuffer *old_fb;
funcs = plane->helper_private;
- old_fb = plane_state->fb;
-
- if (old_fb && funcs->cleanup_fb)
- funcs->cleanup_fb(plane, old_fb, plane_state);
+ if (funcs->cleanup_fb)
+ funcs->cleanup_fb(plane, plane_state);
}
}
EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/drivers/gpu/drm/drm_plane_helper.c
index 5e5a07af02c8..d384ebcf0aaf 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -426,7 +426,7 @@ int drm_plane_helper_commit(struct drm_plane *plane,
if (plane_funcs->prepare_fb && plane_state->fb &&
plane_state->fb != old_fb) {
- ret = plane_funcs->prepare_fb(plane, plane_state->fb,
+ ret = plane_funcs->prepare_fb(plane,
plane_state);
if (ret)
goto out;
@@ -479,8 +479,8 @@ int drm_plane_helper_commit(struct drm_plane *plane,
ret = 0;
}
- if (plane_funcs->cleanup_fb && old_fb)
- plane_funcs->cleanup_fb(plane, old_fb, plane_state);
+ if (pla
[PATCH 2/2] drm/i915: Make plane fb tracking work correctly.
atomic->disabled_planes is a hack that had to exist because
prepare_fb was only called when a new fb was set. This messed
up fb tracking in some circumstances like aborts from
interruptible waits. As a result interruptible waiting in
prepare_plane_fb was forbidden, but other errors could still
cause frontbuffer tracking to be messed up.
Now that prepare_fb is always called, this hack is no longer
required and prepare_fb may fail without consequences.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 47 ++--
drivers/gpu/drm/i915/intel_drv.h | 1 -
2 files changed, 18 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index edcf8746440e..6ebc7661ec8c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4718,17 +4718,6 @@ static void intel_pre_plane_update(struct intel_crtc
*crtc)
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
- struct drm_plane *p;
-
- /* Track fb's for any planes being disabled */
- drm_for_each_plane_mask(p, dev, atomic->disabled_planes) {
- struct intel_plane *plane = to_intel_plane(p);
-
- mutex_lock(&dev->struct_mutex);
- i915_gem_track_fb(intel_fb_obj(plane->base.fb), NULL,
- plane->frontbuffer_bit);
- mutex_unlock(&dev->struct_mutex);
- }
if (atomic->wait_for_flips)
intel_crtc_wait_for_pending_flips(&crtc->base);
@@ -11511,14 +11500,6 @@ int intel_plane_atomic_calc_changes(struct
drm_crtc_state *crtc_state,
return ret;
}
- /*
-* Disabling a plane is always okay; we just need to update
-* fb tracking in a special way since cleanup_fb() won't
-* get called by the plane helpers.
-*/
- if (old_plane_state->base.fb && !fb)
- intel_crtc->atomic.disabled_planes |= 1 << i;
-
was_visible = old_plane_state->visible;
visible = to_intel_plane_state(plane_state)->visible;
@@ -13272,15 +13253,17 @@ intel_prepare_plane_fb(struct drm_plane *plane,
struct drm_framebuffer *fb = new_state->fb;
struct intel_plane *intel_plane = to_intel_plane(plane);
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
- struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
+ struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->state->fb);
int ret = 0;
- if (!obj)
+ if (!obj && !old_obj)
return 0;
mutex_lock(&dev->struct_mutex);
- if (plane->type == DRM_PLANE_TYPE_CURSOR &&
+ if (!obj) {
+ ret = 0;
+ } else if (plane->type == DRM_PLANE_TYPE_CURSOR &&
INTEL_INFO(dev)->cursor_needs_physical) {
int align = IS_I830(dev) ? 16 * 1024 : 256;
ret = i915_gem_object_attach_phys(obj, align);
@@ -13310,17 +13293,23 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
const struct drm_plane_state *old_state)
{
struct drm_device *dev = plane->dev;
- struct drm_i915_gem_object *obj = intel_fb_obj(old_state->fb);
+ struct intel_plane *intel_plane = to_intel_plane(plane);
+ struct drm_i915_gem_object *old_obj = intel_fb_obj(old_state->fb);
+ struct drm_i915_gem_object *obj = intel_fb_obj(plane->fb);
- if (!obj)
+ if (!obj && !old_obj)
return;
- if (plane->type != DRM_PLANE_TYPE_CURSOR ||
- !INTEL_INFO(dev)->cursor_needs_physical) {
- mutex_lock(&dev->struct_mutex);
+ mutex_lock(&dev->struct_mutex);
+ if (old_obj && (plane->type != DRM_PLANE_TYPE_CURSOR ||
+ !INTEL_INFO(dev)->cursor_needs_physical))
intel_unpin_fb_obj(old_state->fb, old_state);
- mutex_unlock(&dev->struct_mutex);
- }
+
+ /* prepare_fb aborted? */
+ if ((old_obj && (old_obj->frontbuffer_bits &
intel_plane->frontbuffer_bit)) ||
+ (obj && !(obj->frontbuffer_bits & intel_plane->frontbuffer_bit)))
+ i915_gem_track_fb(old_obj, obj, intel_plane->frontbuffer_bit);
+ mutex_unlock(&dev->struct_mutex);
}
int
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 104a7f8b650d..176f0a15e41b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -505,7 +505,6 @@ struct intel_crtc_atomic_commit {
bool disable_cxsr;
bool pre_disable_primary;
bool update_wm_pre, update_wm_post;
- unsigned disabled_planes;
/* Sleepable operations to perform after commit */
unsigned fb_bits;
--
2.1.0
[Bug 91790] TONGA hang in amdgpu_ring_lock
https://bugs.freedesktop.org/show_bug.cgi?id=91790 --- Comment #9 from Mathias Tillman --- (In reply to Andy Furniss from comment #8) > (In reply to Mathias Tillman from comment #7) > > Andy: Could you try compiling the latest kernel from drm-next-4.3-wip? I've > > been running it all day without a single lock up, before it used to lock up > > several times a day. Just wanted someone to confirm if it is in fact > > working, or if it's just me. > > I can imaging that it's far better for desktop locks - I moved onto it when > it got updated. > > Initially testing with Unigine Valley I thought it was going to be good - I > got further than ever before (about 4x through all the scenes having not got > through once previously), but it did lock. That's a shame. I'll try and see if I can find out what has caused the lockups to stop for me, maybe that could help in finding out what's still causing them for you. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150902/45e0303b/attachment.html>
[Intel-gfx] [PATCH] drm/atomic: Make sure lock is held in trylock contexts.
On Thu, Aug 27, 2015 at 01:58:09PM +0200, Maarten Lankhorst wrote:
> This will make sure we get a lockdep spat in all cases
> even if the context is a complete garbage pointer.
>
> Signed-off-by: Maarten Lankhorst
Applied to drm-misc, thanks.
-Daniel
> ---
> diff --git a/drivers/gpu/drm/drm_modeset_lock.c
> b/drivers/gpu/drm/drm_modeset_lock.c
> index 9abee87c1501..7c9ca2381d78 100644
> --- a/drivers/gpu/drm/drm_modeset_lock.c
> +++ b/drivers/gpu/drm/drm_modeset_lock.c
> @@ -305,6 +305,8 @@ static inline int modeset_lock(struct drm_modeset_lock
> *lock,
> WARN_ON(ctx->contended);
>
> if (ctx->trylock_only) {
> + lockdep_assert_held(&ctx->ww_ctx);
> +
> if (!ww_mutex_trylock(&lock->mutex))
> return -EBUSY;
> else
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 6/9] drm/exynos: update exynos_drm_framebuffer_init() for multiple buffers
On 2015ë
09ì 02ì¼ 05:35, Gustavo Padovan wrote:
> 2015-09-01 Joonyoung Shim :
>
>> This modifies exynos_drm_framebuffer_init() to be possible to support
>> multiple buffers. Then it can be used by exynos_user_fb_create().
>>
>> Signed-off-by: Joonyoung Shim
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fb.c| 36
>> +--
>> drivers/gpu/drm/exynos/exynos_drm_fb.h| 5 -
>> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 +--
>> 3 files changed, 25 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> index 5cee148..8e5d3eb 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> @@ -23,7 +23,6 @@
>> #include "exynos_drm_drv.h"
>> #include "exynos_drm_fb.h"
>> #include "exynos_drm_fbdev.h"
>> -#include "exynos_drm_gem.h"
>> #include "exynos_drm_iommu.h"
>> #include "exynos_drm_crtc.h"
>>
>> @@ -134,36 +133,41 @@ unsigned int exynos_drm_fb_get_buf_cnt(struct
>> drm_framebuffer *fb)
>> struct drm_framebuffer *
>> exynos_drm_framebuffer_init(struct drm_device *dev,
>> struct drm_mode_fb_cmd2 *mode_cmd,
>> -struct drm_gem_object *obj)
>> +struct exynos_drm_gem_obj **gem_obj,
>> +int count)
>> {
>> struct exynos_drm_fb *exynos_fb;
>> -struct exynos_drm_gem_obj *exynos_gem_obj;
>> +int i;
>> int ret;
>>
>> -exynos_gem_obj = to_exynos_gem_obj(obj);
>> -
>> -ret = check_fb_gem_memory_type(dev, exynos_gem_obj);
>> -if (ret < 0)
>> -return ERR_PTR(ret);
>> -
>> exynos_fb = kzalloc(sizeof(*exynos_fb), GFP_KERNEL);
>> if (!exynos_fb)
>> return ERR_PTR(-ENOMEM);
>>
>> -drm_helper_mode_fill_fb_struct(&exynos_fb->fb, mode_cmd);
>> -exynos_fb->exynos_gem_obj[0] = exynos_gem_obj;
>> +exynos_fb->buf_cnt = count;
>> +DRM_DEBUG_KMS("buf_cnt = %d\n", exynos_fb->buf_cnt);
>>
>> -/* buffer count to framebuffer always is 1 at booting time. */
>> -exynos_fb->buf_cnt = 1;
>> +for (i = 0; i < count; i++) {
>> +ret = check_fb_gem_memory_type(dev, gem_obj[i]);
>> +if (ret < 0)
>> +goto err;
>> +
>> +exynos_fb->exynos_gem_obj[i] = gem_obj[i];
>> +}
>> +
>> +drm_helper_mode_fill_fb_struct(&exynos_fb->fb, mode_cmd);
>>
>> ret = drm_framebuffer_init(dev, &exynos_fb->fb, &exynos_drm_fb_funcs);
>> -if (ret) {
>> -kfree(exynos_fb);
>> +if (ret < 0) {
>> DRM_ERROR("failed to initialize framebuffer\n");
>> -return ERR_PTR(ret);
>> +goto err;
>> }
>>
>> return &exynos_fb->fb;
>> +
>> +err:
>> +kfree(exynos_fb);
>> +return ERR_PTR(ret);
>> }
>>
>> static struct drm_framebuffer *
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.h
>> b/drivers/gpu/drm/exynos/exynos_drm_fb.h
>> index 897d2cf..8900f6b 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.h
>> @@ -14,10 +14,13 @@
>> #ifndef _EXYNOS_DRM_FB_H_
>> #define _EXYNOS_DRM_FB_H
>>
>> +#include "exynos_drm_gem.h"
>> +
>> struct drm_framebuffer *
>> exynos_drm_framebuffer_init(struct drm_device *dev,
>> struct drm_mode_fb_cmd2 *mode_cmd,
>> -struct drm_gem_object *obj);
>> +struct exynos_drm_gem_obj **gem_obj,
>> +int count);
>>
>> /* get gem object of a drm framebuffer */
>> struct exynos_drm_gem_obj *exynos_drm_fb_gem_obj(struct drm_framebuffer *fb,
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> index 133cf5f..a221f75 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> @@ -21,7 +21,6 @@
>> #include "exynos_drm_drv.h"
>> #include "exynos_drm_fb.h"
>> #include "exynos_drm_fbdev.h"
>> -#include "exynos_drm_gem.h"
>> #include "exynos_drm_iommu.h"
>>
>> #define MAX_CONNECTOR 4
>> @@ -160,7 +159,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
>> *helper,
>>
>> exynos_fbdev->obj = obj;
>>
>> -helper->fb = exynos_drm_framebuffer_init(dev, &mode_cmd, &obj->base);
>> +helper->fb = exynos_drm_framebuffer_init(dev, &mode_cmd, &obj, 1);
>
> Do you have any use for this for multiple buffers? I don't see any patch
> in this series for multiple buffers. I think we should wait for a user
> of multiple buffers to apply this patch.
Exynos4412 SoC has a video processor which can handle YCbCr - NV12 and
NV21 - image, and the image is transferred to Digital TV through HDMI
controller. NV12 and NV21 have 2 plane buffers and the video processor
is controlled by Exynos drm driver. So reasonable and looks good to me.
Thanks,
Inki Dae
>
> Gustavo
> __
[PATCH 01/20] drm: Constify drm_encoder_slave_funcs
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/drm_encoder_slave.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_encoder.h | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c | 6 +++---
drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 8
include/drm/drm_encoder_slave.h | 2 +-
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder_slave.c
b/drivers/gpu/drm/drm_encoder_slave.c
index d18b88b..e862907 100644
--- a/drivers/gpu/drm/drm_encoder_slave.c
+++ b/drivers/gpu/drm/drm_encoder_slave.c
@@ -124,7 +124,7 @@ EXPORT_SYMBOL(drm_i2c_encoder_destroy);
* Wrapper fxns which can be plugged in to drm_encoder_helper_funcs:
*/
-static inline struct drm_encoder_slave_funcs *
+static inline const struct drm_encoder_slave_funcs *
get_slave_funcs(struct drm_encoder *enc)
{
return to_encoder_slave(enc)->slave_funcs;
diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h
b/drivers/gpu/drm/nouveau/nouveau_encoder.h
index b37da95..07527db 100644
--- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
+++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
@@ -80,7 +80,7 @@ static inline struct drm_encoder *to_drm_encoder(struct
nouveau_encoder *enc)
return &enc->base.base;
}
-static inline struct drm_encoder_slave_funcs *
+static inline const struct drm_encoder_slave_funcs *
get_slave_funcs(struct drm_encoder *enc)
{
return to_encoder_slave(enc)->slave_funcs;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c
b/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c
index 96f2eb4..a37b6e2 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c
@@ -28,7 +28,7 @@ static int rcar_du_hdmi_connector_get_modes(struct
drm_connector *connector)
{
struct rcar_du_connector *con = to_rcar_connector(connector);
struct drm_encoder *encoder = rcar_encoder_to_drm_encoder(con->encoder);
- struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder);
+ const struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder);
if (sfuncs->get_modes == NULL)
return 0;
@@ -41,7 +41,7 @@ static int rcar_du_hdmi_connector_mode_valid(struct
drm_connector *connector,
{
struct rcar_du_connector *con = to_rcar_connector(connector);
struct drm_encoder *encoder = rcar_encoder_to_drm_encoder(con->encoder);
- struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder);
+ const struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder);
if (sfuncs->mode_valid == NULL)
return MODE_OK;
@@ -66,7 +66,7 @@ rcar_du_hdmi_connector_detect(struct drm_connector
*connector, bool force)
{
struct rcar_du_connector *con = to_rcar_connector(connector);
struct drm_encoder *encoder = rcar_encoder_to_drm_encoder(con->encoder);
- struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder);
+ const struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder);
if (sfuncs->detect == NULL)
return connector_status_unknown;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
b/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
index 81da841..e41bbb6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
@@ -35,7 +35,7 @@ struct rcar_du_hdmienc {
static void rcar_du_hdmienc_disable(struct drm_encoder *encoder)
{
struct rcar_du_hdmienc *hdmienc = to_rcar_hdmienc(encoder);
- struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder);
+ const struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder);
if (sfuncs->dpms)
sfuncs->dpms(encoder, DRM_MODE_DPMS_OFF);
@@ -50,7 +50,7 @@ static void rcar_du_hdmienc_disable(struct drm_encoder
*encoder)
static void rcar_du_hdmienc_enable(struct drm_encoder *encoder)
{
struct rcar_du_hdmienc *hdmienc = to_rcar_hdmienc(encoder);
- struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder);
+ const struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder);
if (hdmienc->renc->lvds)
rcar_du_lvdsenc_enable(hdmienc->renc->lvds, encoder->crtc,
@@ -67,7 +67,7 @@ static int rcar_du_hdmienc_atomic_check(struct drm_encoder
*encoder,
struct drm_connector_state *conn_state)
{
struct rcar_du_hdmienc *hdmienc = to_rcar_hdmienc(encoder);
- struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder);
+ const struct drm_encoder_slave_funcs *sfuncs = to_slave_funcs(encoder);
struct drm_display_mode *adjusted_mode = &crtc_state->adjusted_mode;
const struct drm_display_mode *mode = &crtc_state->mode;
@@ -89,7 +89,7 @@ static void rcar_du_hdmienc_mode_set(struct drm_encoder
*encoder,
struct drm_display_mode *adjusted_mode)
{
struct
[PATCH 02/20] drm/armada: Constify function pointer structs
From: Ville Syrjälä
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/armada/armada.ko:
-.rodata 1040
+.rodata 1100
-.data1156
+.data1096
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/armada/armada_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index 01ffe9b..8a9c5d3 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1003,7 +1003,7 @@ armada_drm_crtc_set_property(struct drm_crtc *crtc,
return 0;
}
-static struct drm_crtc_funcs armada_crtc_funcs = {
+static const struct drm_crtc_funcs armada_crtc_funcs = {
.cursor_set = armada_drm_crtc_cursor_set,
.cursor_move= armada_drm_crtc_cursor_move,
.destroy= armada_drm_crtc_destroy,
--
2.4.6
[PATCH 03/20] drm/atmel-hlcdc: Constify function pointer structs
From: Ville Syrjälä
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/atmel-hlcdc/atmel-hlcdc-dc.ko:
-.text 12488
+.text 12480
-.rodata 1696
+.rodata 1760
-.data 776
+.data 712
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index 067e4c1..250f69e 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -146,7 +146,7 @@ atmel_hlcdc_rgb_encoder_mode_set(struct drm_encoder
*encoder,
cfg);
}
-static struct drm_encoder_helper_funcs atmel_hlcdc_panel_encoder_helper_funcs
= {
+static const struct drm_encoder_helper_funcs
atmel_hlcdc_panel_encoder_helper_funcs = {
.mode_fixup = atmel_hlcdc_panel_encoder_mode_fixup,
.mode_set = atmel_hlcdc_rgb_encoder_mode_set,
.disable = atmel_hlcdc_panel_encoder_disable,
@@ -192,7 +192,7 @@ atmel_hlcdc_rgb_best_encoder(struct drm_connector
*connector)
return &rgb->encoder;
}
-static struct drm_connector_helper_funcs
atmel_hlcdc_panel_connector_helper_funcs = {
+static const struct drm_connector_helper_funcs
atmel_hlcdc_panel_connector_helper_funcs = {
.get_modes = atmel_hlcdc_panel_get_modes,
.mode_valid = atmel_hlcdc_rgb_mode_valid,
.best_encoder = atmel_hlcdc_rgb_best_encoder,
--
2.4.6
[PATCH 04/20] drm/bochs: Constify function pointer structs
From: Ville Syrjälä
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/bochs/bochs-drm.ko:
-.text7608
+.text7600
-.rodata 648
+.rodata 716
-.data 612
+.data 544
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/bochs/bochs_kms.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 26bcd03..b25c3ef 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -245,13 +245,13 @@ static enum drm_connector_status
bochs_connector_detect(struct drm_connector
return connector_status_connected;
}
-struct drm_connector_helper_funcs bochs_connector_connector_helper_funcs = {
+static const struct drm_connector_helper_funcs
bochs_connector_connector_helper_funcs = {
.get_modes = bochs_connector_get_modes,
.mode_valid = bochs_connector_mode_valid,
.best_encoder = bochs_connector_best_encoder,
};
-struct drm_connector_funcs bochs_connector_connector_funcs = {
+static const struct drm_connector_funcs bochs_connector_connector_funcs = {
.dpms = drm_helper_connector_dpms,
.detect = bochs_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -283,7 +283,7 @@ int bochs_kms_init(struct bochs_device *bochs)
bochs->dev->mode_config.preferred_depth = 24;
bochs->dev->mode_config.prefer_shadow = 0;
- bochs->dev->mode_config.funcs = (void *)&bochs_mode_funcs;
+ bochs->dev->mode_config.funcs = &bochs_mode_funcs;
bochs_crtc_init(bochs->dev);
bochs_encoder_init(bochs->dev);
--
2.4.6
[PATCH 05/20] drm/bridge/dw_hdmi: Constify function pointer structs
From: Ville Syrjälä
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/bridge/dw_hdmi.ko:
-.rodata 120
+.rodata 216
-.data 96
+.data 0
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/bridge/dw_hdmi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 0083d4e..121bc08 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -1488,20 +1488,20 @@ static void dw_hdmi_connector_destroy(struct
drm_connector *connector)
drm_connector_cleanup(connector);
}
-static struct drm_connector_funcs dw_hdmi_connector_funcs = {
+static const struct drm_connector_funcs dw_hdmi_connector_funcs = {
.dpms = drm_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = dw_hdmi_connector_detect,
.destroy = dw_hdmi_connector_destroy,
};
-static struct drm_connector_helper_funcs dw_hdmi_connector_helper_funcs = {
+static const struct drm_connector_helper_funcs dw_hdmi_connector_helper_funcs
= {
.get_modes = dw_hdmi_connector_get_modes,
.mode_valid = dw_hdmi_connector_mode_valid,
.best_encoder = dw_hdmi_connector_best_encoder,
};
-static struct drm_bridge_funcs dw_hdmi_bridge_funcs = {
+static const struct drm_bridge_funcs dw_hdmi_bridge_funcs = {
.enable = dw_hdmi_bridge_enable,
.disable = dw_hdmi_bridge_disable,
.pre_enable = dw_hdmi_bridge_nop,
--
2.4.6
[PATCH 06/20] drm/bridge/nxp-ptn3460: Constify function pointer structs
From: Ville Syrjälä
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/bridge/nxp-ptn3460.ko:
-.rodata 440
+.rodata 536
-.data208
+.data112
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/bridge/nxp-ptn3460.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index 1b1bf23..b1908da 100644
--- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
+++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
@@ -242,7 +242,7 @@ static struct drm_encoder *ptn3460_best_encoder(struct
drm_connector *connector)
return ptn_bridge->bridge.encoder;
}
-static struct drm_connector_helper_funcs ptn3460_connector_helper_funcs = {
+static const struct drm_connector_helper_funcs ptn3460_connector_helper_funcs
= {
.get_modes = ptn3460_get_modes,
.best_encoder = ptn3460_best_encoder,
};
@@ -258,7 +258,7 @@ static void ptn3460_connector_destroy(struct drm_connector
*connector)
drm_connector_cleanup(connector);
}
-static struct drm_connector_funcs ptn3460_connector_funcs = {
+static const struct drm_connector_funcs ptn3460_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ptn3460_detect,
@@ -299,7 +299,7 @@ static int ptn3460_bridge_attach(struct drm_bridge *bridge)
return ret;
}
-static struct drm_bridge_funcs ptn3460_bridge_funcs = {
+static const struct drm_bridge_funcs ptn3460_bridge_funcs = {
.pre_enable = ptn3460_pre_enable,
.enable = ptn3460_enable,
.disable = ptn3460_disable,
--
2.4.6
[PATCH 07/20] drm/i2c/ch7006: Constify function pointer structs
From: Ville Syrjälä
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/i2c/ch7006.ko:
-.text5752
+.text5760
-.rodata 6608
+.rodata 6656
-.data 216
+.data 168
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/i2c/ch7006_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c
index d9a72c9..90db5f4 100644
--- a/drivers/gpu/drm/i2c/ch7006_drv.c
+++ b/drivers/gpu/drm/i2c/ch7006_drv.c
@@ -371,7 +371,7 @@ static int ch7006_encoder_set_property(struct drm_encoder
*encoder,
return 0;
}
-static struct drm_encoder_slave_funcs ch7006_encoder_funcs = {
+static const struct drm_encoder_slave_funcs ch7006_encoder_funcs = {
.set_config = ch7006_encoder_set_config,
.destroy = ch7006_encoder_destroy,
.dpms = ch7006_encoder_dpms,
--
2.4.6
[PATCH 08/20] drm/cirrus: Constify function pointer structs
From: Ville Syrjälä
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/cirrus/cirrus.ko:
-.text 10104
+.text 10092
-.rodata 528
+.rodata 596
-.data 608
+.data 540
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/cirrus/cirrus_mode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index 61385f2..e675160 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -533,12 +533,12 @@ static void cirrus_connector_destroy(struct drm_connector
*connector)
kfree(connector);
}
-struct drm_connector_helper_funcs cirrus_vga_connector_helper_funcs = {
+static const struct drm_connector_helper_funcs
cirrus_vga_connector_helper_funcs = {
.get_modes = cirrus_vga_get_modes,
.best_encoder = cirrus_connector_best_encoder,
};
-struct drm_connector_funcs cirrus_vga_connector_funcs = {
+static const struct drm_connector_funcs cirrus_vga_connector_funcs = {
.dpms = drm_helper_connector_dpms,
.detect = cirrus_vga_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
--
2.4.6
[PATCH 09/20] drm/exynos: Constify function pointer structs
From: Ville Syrjälä
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/exynos/exynosdrm.ko:
-.text 125792
+.text 125788
-.rodata 10972
+.rodata 11748
-.data 6720
+.data 5944
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 8
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 ++--
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 8
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8
drivers/gpu/drm/exynos/exynos_drm_fb.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 8
drivers/gpu/drm/exynos/exynos_hdmi.c | 8
8 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index d66ade0..c11b363 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -953,7 +953,7 @@ static void exynos_dp_connector_destroy(struct
drm_connector *connector)
drm_connector_cleanup(connector);
}
-static struct drm_connector_funcs exynos_dp_connector_funcs = {
+static const struct drm_connector_funcs exynos_dp_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = exynos_dp_detect,
@@ -998,7 +998,7 @@ static struct drm_encoder *exynos_dp_best_encoder(
return &dp->encoder;
}
-static struct drm_connector_helper_funcs exynos_dp_connector_helper_funcs = {
+static const struct drm_connector_helper_funcs
exynos_dp_connector_helper_funcs = {
.get_modes = exynos_dp_get_modes,
.best_encoder = exynos_dp_best_encoder,
};
@@ -1123,14 +1123,14 @@ static void exynos_dp_disable(struct drm_encoder
*encoder)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
}
-static struct drm_encoder_helper_funcs exynos_dp_encoder_helper_funcs = {
+static const struct drm_encoder_helper_funcs exynos_dp_encoder_helper_funcs = {
.mode_fixup = exynos_dp_mode_fixup,
.mode_set = exynos_dp_mode_set,
.enable = exynos_dp_enable,
.disable = exynos_dp_disable,
};
-static struct drm_encoder_funcs exynos_dp_encoder_funcs = {
+static const struct drm_encoder_funcs exynos_dp_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 0872aa2f..13f9c08 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -96,7 +96,7 @@ static void exynos_crtc_atomic_flush(struct drm_crtc *crtc,
}
}
-static struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
+static const struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
.enable = exynos_drm_crtc_enable,
.disable= exynos_drm_crtc_disable,
.mode_fixup = exynos_drm_crtc_mode_fixup,
@@ -116,7 +116,7 @@ static void exynos_drm_crtc_destroy(struct drm_crtc *crtc)
kfree(exynos_crtc);
}
-static struct drm_crtc_funcs exynos_crtc_funcs = {
+static const struct drm_crtc_funcs exynos_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
.destroy= exynos_drm_crtc_destroy,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index c748b87..45c2634 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -57,7 +57,7 @@ static void exynos_dpi_connector_destroy(struct drm_connector
*connector)
drm_connector_cleanup(connector);
}
-static struct drm_connector_funcs exynos_dpi_connector_funcs = {
+static const struct drm_connector_funcs exynos_dpi_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.detect = exynos_dpi_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -100,7 +100,7 @@ exynos_dpi_best_encoder(struct drm_connector *connector)
return &ctx->encoder;
}
-static struct drm_connector_helper_funcs exynos_dpi_connector_helper_funcs = {
+static const struct drm_connector_helper_funcs
exynos_dpi_connector_helper_funcs = {
.get_modes = exynos_dpi_get_modes,
.best_encoder = exynos_dpi_best_encoder,
};
@@ -161,14 +161,14 @@ static void exynos_dpi_disable(struct drm_encoder
*encoder)
}
}
-static struct drm_encoder_helper_funcs exynos_dpi_encoder_helper_funcs = {
+static const struct drm_encoder_helper_funcs exynos_dpi_encoder_helper_funcs =
{
.mode_fixup = exynos_dpi_mode_fixup,
.mode_set = exynos_dpi_mode_set,
.enable = exynos_dpi_enable,
.disable = exynos_dpi_disable,
};
-static struct drm_encoder_funcs exynos_dpi_encoder_funcs = {
+static co
[PATCH 10/20] drm/i2c/adv7511: Constify function pointer structs
From: Ville Syrjälä
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/i2c/adv7511.ko:
-.rodata 1368
+.rodata 1416
-.data164
+.data116
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/i2c/adv7511.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
index 00416f2..533d1e3 100644
--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511.c
@@ -752,7 +752,7 @@ static void adv7511_encoder_mode_set(struct drm_encoder
*encoder,
adv7511->f_tmds = mode->clock;
}
-static struct drm_encoder_slave_funcs adv7511_encoder_funcs = {
+static const struct drm_encoder_slave_funcs adv7511_encoder_funcs = {
.dpms = adv7511_encoder_dpms,
.mode_valid = adv7511_encoder_mode_valid,
.mode_set = adv7511_encoder_mode_set,
--
2.4.6
[PATCH 11/20] drm/i2c/sil164: Constify function pointer structs
From: Ville Syrjälä
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/i2c/sil164.ko:
-.text 1660
+.text 1656
-.rodata 56
+.rodata 104
-.data212
+.data164
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/i2c/sil164_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/sil164_drv.c b/drivers/gpu/drm/i2c/sil164_drv.c
index 002ce78..c400428 100644
--- a/drivers/gpu/drm/i2c/sil164_drv.c
+++ b/drivers/gpu/drm/i2c/sil164_drv.c
@@ -341,7 +341,7 @@ sil164_encoder_destroy(struct drm_encoder *encoder)
drm_i2c_encoder_destroy(encoder);
}
-static struct drm_encoder_slave_funcs sil164_encoder_funcs = {
+static const struct drm_encoder_slave_funcs sil164_encoder_funcs = {
.set_config = sil164_encoder_set_config,
.destroy = sil164_encoder_destroy,
.dpms = sil164_encoder_dpms,
--
2.4.6
[PATCH 12/20] drm/i2c/tda998x: Constify function pointer structs
From: Ville Syrjälä
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/i2c/tda998x.ko:
-.rodata 668
+.rodata 716
-.data212
+.data164
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/i2c/tda998x_drv.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 424228b..5de26ea 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1213,7 +1213,7 @@ tda998x_encoder_slave_create_resources(struct drm_encoder
*encoder,
return 0;
}
-static struct drm_encoder_slave_funcs tda998x_encoder_slave_funcs = {
+static const struct drm_encoder_slave_funcs tda998x_encoder_slave_funcs = {
.set_config = tda998x_encoder_slave_set_config,
.destroy = tda998x_encoder_slave_destroy,
.dpms = tda998x_encoder_slave_dpms,
@@ -1467,8 +1467,7 @@ tda998x_connector_best_encoder(struct drm_connector
*connector)
return &priv->encoder;
}
-static
-const struct drm_connector_helper_funcs tda998x_connector_helper_funcs = {
+static const struct drm_connector_helper_funcs tda998x_connector_helper_funcs
= {
.get_modes = tda998x_connector_get_modes,
.mode_valid = tda998x_connector_mode_valid,
.best_encoder = tda998x_connector_best_encoder,
--
2.4.6
[PATCH 13/20] drm/imx: Constify function pointer structs
From: Ville Syrjälä
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/imx/imxdrm.ko:
-.rodata 624
+.rodata 652
-.data372
+.data344
drivers/gpu/drm/imx/imx-ipuv3-crtc.ko:
-.rodata 224
+.rodata 280
-.data184
+.data128
drivers/gpu/drm/imx/imx-ldb.ko:
-.rodata 660
+.rodata 784
-.data240
+.data116
drivers/gpu/drm/imx/imx-tve.ko:
-.rodata 400
+.rodata 524
-.data416
+.data292
drivers/gpu/drm/imx/parallel-display.ko:
-.rodata 400
+.rodata 524
-.data216
+.data 92
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/imx/dw_hdmi-imx.c | 4 ++--
drivers/gpu/drm/imx/imx-drm-core.c | 2 +-
drivers/gpu/drm/imx/imx-ldb.c | 8
drivers/gpu/drm/imx/imx-tve.c | 8
drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +-
drivers/gpu/drm/imx/parallel-display.c | 8
6 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index 644edf6..9dbf410 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -131,7 +131,7 @@ static void dw_hdmi_imx_encoder_prepare(struct drm_encoder
*encoder)
imx_drm_set_bus_format(encoder, MEDIA_BUS_FMT_RGB888_1X24);
}
-static struct drm_encoder_helper_funcs dw_hdmi_imx_encoder_helper_funcs = {
+static const struct drm_encoder_helper_funcs dw_hdmi_imx_encoder_helper_funcs
= {
.mode_fixup = dw_hdmi_imx_encoder_mode_fixup,
.mode_set = dw_hdmi_imx_encoder_mode_set,
.prepare= dw_hdmi_imx_encoder_prepare,
@@ -139,7 +139,7 @@ static struct drm_encoder_helper_funcs
dw_hdmi_imx_encoder_helper_funcs = {
.disable= dw_hdmi_imx_encoder_disable,
};
-static struct drm_encoder_funcs dw_hdmi_imx_encoder_funcs = {
+static const struct drm_encoder_funcs dw_hdmi_imx_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index 74f505b..e970839 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -222,7 +222,7 @@ static void imx_drm_output_poll_changed(struct drm_device
*drm)
#endif
}
-static struct drm_mode_config_funcs imx_drm_mode_config_funcs = {
+static const struct drm_mode_config_funcs imx_drm_mode_config_funcs = {
.fb_create = drm_fb_cma_create,
.output_poll_changed = imx_drm_output_poll_changed,
};
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index abacc8f..0e3f33c 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -358,23 +358,23 @@ static void imx_ldb_encoder_disable(struct drm_encoder
*encoder)
drm_panel_unprepare(imx_ldb_ch->panel);
}
-static struct drm_connector_funcs imx_ldb_connector_funcs = {
+static const struct drm_connector_funcs imx_ldb_connector_funcs = {
.dpms = drm_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = imx_ldb_connector_detect,
.destroy = imx_drm_connector_destroy,
};
-static struct drm_connector_helper_funcs imx_ldb_connector_helper_funcs = {
+static const struct drm_connector_helper_funcs imx_ldb_connector_helper_funcs
= {
.get_modes = imx_ldb_connector_get_modes,
.best_encoder = imx_ldb_connector_best_encoder,
};
-static struct drm_encoder_funcs imx_ldb_encoder_funcs = {
+static const struct drm_encoder_funcs imx_ldb_encoder_funcs = {
.destroy = imx_drm_encoder_destroy,
};
-static struct drm_encoder_helper_funcs imx_ldb_encoder_helper_funcs = {
+static const struct drm_encoder_helper_funcs imx_ldb_encoder_helper_funcs = {
.dpms = imx_ldb_encoder_dpms,
.mode_fixup = imx_ldb_encoder_mode_fixup,
.prepare = imx_ldb_encoder_prepare,
diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index e671ad3..4cdbb77 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -360,24 +360,24 @@ static void imx_tve_encoder_disable(struct drm_encoder
*encoder)
tve_disable(tve);
}
-static struct drm_connector_funcs imx_tve_connector_funcs = {
+static const struct drm_connector_funcs imx_tve_connector_funcs = {
.dpms = drm_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = imx_tve_connector_detect,
.destroy = imx_drm_connector_destroy,
};
-static struct drm_connector_helper_funcs imx_tve_connector_helper_funcs = {
+static const struc
[PATCH 14/20] drm/mgag200: Constify function pointer structs
From: Ville Syrjälä
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/mgag200/mgag200.ko:
-.text 29244
+.text 29232
-.rodata 600
+.rodata 668
-.data 688
+.data 620
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index c99d3fe..a3be44f 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1684,13 +1684,13 @@ static void mga_connector_destroy(struct drm_connector
*connector)
kfree(connector);
}
-struct drm_connector_helper_funcs mga_vga_connector_helper_funcs = {
+static const struct drm_connector_helper_funcs mga_vga_connector_helper_funcs
= {
.get_modes = mga_vga_get_modes,
.mode_valid = mga_vga_mode_valid,
.best_encoder = mga_connector_best_encoder,
};
-struct drm_connector_funcs mga_vga_connector_funcs = {
+static const struct drm_connector_funcs mga_vga_connector_funcs = {
.dpms = drm_helper_connector_dpms,
.detect = mga_vga_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
--
2.4.6
[PATCH 15/20] drm/nouveau: Constify function pointer structs
From: Ville Syrjälä
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/nouveau/nouveau.ko:
-.rodata 105688
+.rodata 105792
-.data125724
+.data125620
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
index b734195..73a0ae6 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
@@ -769,7 +769,7 @@ static void nv17_tv_destroy(struct drm_encoder *encoder)
kfree(tv_enc);
}
-static struct drm_encoder_helper_funcs nv17_tv_helper_funcs = {
+static const struct drm_encoder_helper_funcs nv17_tv_helper_funcs = {
.dpms = nv17_tv_dpms,
.save = nv17_tv_save,
.restore = nv17_tv_restore,
@@ -780,14 +780,14 @@ static struct drm_encoder_helper_funcs
nv17_tv_helper_funcs = {
.detect = nv17_tv_detect,
};
-static struct drm_encoder_slave_funcs nv17_tv_slave_funcs = {
+static const struct drm_encoder_slave_funcs nv17_tv_slave_funcs = {
.get_modes = nv17_tv_get_modes,
.mode_valid = nv17_tv_mode_valid,
.create_resources = nv17_tv_create_resources,
.set_property = nv17_tv_set_property,
};
-static struct drm_encoder_funcs nv17_tv_funcs = {
+static const struct drm_encoder_funcs nv17_tv_funcs = {
.destroy = nv17_tv_destroy,
};
--
2.4.6
[PATCH 16/20] drm/rockchip: Constify function pointer structs
From: Ville Syrjälä
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.ko:
-.rodata 772
+.rodata 828
-.data148
+.data 92
drivers/gpu/drm/rockchip/rockchipdrm.ko:
-.rodata 748
+.rodata 760
-.data448
+.data436
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 4 ++--
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 80d6fc8..ef2c239 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -173,7 +173,7 @@ dw_hdmi_rockchip_mode_valid(struct drm_connector *connector,
return (valid) ? MODE_OK : MODE_BAD;
}
-static struct drm_encoder_funcs dw_hdmi_rockchip_encoder_funcs = {
+static const struct drm_encoder_funcs dw_hdmi_rockchip_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
@@ -218,7 +218,7 @@ static void dw_hdmi_rockchip_encoder_prepare(struct
drm_encoder *encoder)
ROCKCHIP_OUT_MODE_);
}
-static struct drm_encoder_helper_funcs dw_hdmi_rockchip_encoder_helper_funcs =
{
+static const struct drm_encoder_helper_funcs
dw_hdmi_rockchip_encoder_helper_funcs = {
.mode_fixup = dw_hdmi_rockchip_encoder_mode_fixup,
.mode_set = dw_hdmi_rockchip_encoder_mode_set,
.prepare= dw_hdmi_rockchip_encoder_prepare,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 002645b..316e444 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -66,7 +66,7 @@ static int rockchip_drm_fb_create_handle(struct
drm_framebuffer *fb,
rockchip_fb->obj[0], handle);
}
-static struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
+static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
.destroy= rockchip_drm_fb_destroy,
.create_handle = rockchip_drm_fb_create_handle,
};
--
2.4.6
[PATCH 18/20] drm/tegra: Constify function pointer structs
From: Ville Syrjälä
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/tegra/tegra-drm.ko:
-.rodata 13672
+.rodata 13684
-.data1108
+.data1096
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/tegra/fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 07c844b..388ae88 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -86,7 +86,7 @@ static int tegra_fb_create_handle(struct drm_framebuffer
*framebuffer,
return drm_gem_handle_create(file, &fb->planes[0]->gem, handle);
}
-static struct drm_framebuffer_funcs tegra_fb_funcs = {
+static const struct drm_framebuffer_funcs tegra_fb_funcs = {
.destroy = tegra_fb_destroy,
.create_handle = tegra_fb_create_handle,
};
--
2.4.6
[PATCH 19/20] drm/udl: Constify function pointer structs
From: Ville Syrjälä
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/udl/udl.ko:
-.text 11336
+.text 11332
-.rodata 560
+.rodata 684
-.data 696
+.data 572
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/udl/udl_connector.c | 4 ++--
drivers/gpu/drm/udl/udl_modeset.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_connector.c
b/drivers/gpu/drm/udl/udl_connector.c
index 0110d95..4709b54 100644
--- a/drivers/gpu/drm/udl/udl_connector.c
+++ b/drivers/gpu/drm/udl/udl_connector.c
@@ -122,13 +122,13 @@ static void udl_connector_destroy(struct drm_connector
*connector)
kfree(connector);
}
-static struct drm_connector_helper_funcs udl_connector_helper_funcs = {
+static const struct drm_connector_helper_funcs udl_connector_helper_funcs = {
.get_modes = udl_get_modes,
.mode_valid = udl_mode_valid,
.best_encoder = udl_best_single_encoder,
};
-static struct drm_connector_funcs udl_connector_funcs = {
+static const struct drm_connector_funcs udl_connector_funcs = {
.dpms = drm_helper_connector_dpms,
.detect = udl_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index 677190a6..160ef2a 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -400,7 +400,7 @@ static void udl_crtc_commit(struct drm_crtc *crtc)
udl_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
}
-static struct drm_crtc_helper_funcs udl_helper_funcs = {
+static const struct drm_crtc_helper_funcs udl_helper_funcs = {
.dpms = udl_crtc_dpms,
.mode_fixup = udl_crtc_mode_fixup,
.mode_set = udl_crtc_mode_set,
--
2.4.6
[PATCH 20/20] drm/vmwgfx: Constify function pointer structs
From: Ville Syrjälä
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/vmwgfx/vmwgfx.ko:
-.text 132244
+.text 132240
-.rodata 18296
+.rodata 18680
-.data 5096
+.data 4712
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 6 +++---
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 61fb7f3..b572ef7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -470,7 +470,7 @@ int vmw_kms_readback(struct vmw_private *dev_priv,
}
-static struct drm_framebuffer_funcs vmw_framebuffer_surface_funcs = {
+static const struct drm_framebuffer_funcs vmw_framebuffer_surface_funcs = {
.destroy = vmw_framebuffer_surface_destroy,
.dirty = vmw_framebuffer_surface_dirty,
};
@@ -647,7 +647,7 @@ static int vmw_framebuffer_dmabuf_dirty(struct
drm_framebuffer *framebuffer,
return ret;
}
-static struct drm_framebuffer_funcs vmw_framebuffer_dmabuf_funcs = {
+static const struct drm_framebuffer_funcs vmw_framebuffer_dmabuf_funcs = {
.destroy = vmw_framebuffer_dmabuf_destroy,
.dirty = vmw_framebuffer_dmabuf_dirty,
};
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index bb63e4d..62b2572 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -294,7 +294,7 @@ static int vmw_ldu_crtc_set_config(struct drm_mode_set *set)
return vmw_ldu_commit_list(dev_priv);
}
-static struct drm_crtc_funcs vmw_legacy_crtc_funcs = {
+static const struct drm_crtc_funcs vmw_legacy_crtc_funcs = {
.save = vmw_du_crtc_save,
.restore = vmw_du_crtc_restore,
.cursor_set = vmw_du_crtc_cursor_set,
@@ -314,7 +314,7 @@ static void vmw_ldu_encoder_destroy(struct drm_encoder
*encoder)
vmw_ldu_destroy(vmw_encoder_to_ldu(encoder));
}
-static struct drm_encoder_funcs vmw_legacy_encoder_funcs = {
+static const struct drm_encoder_funcs vmw_legacy_encoder_funcs = {
.destroy = vmw_ldu_encoder_destroy,
};
@@ -327,7 +327,7 @@ static void vmw_ldu_connector_destroy(struct drm_connector
*connector)
vmw_ldu_destroy(vmw_connector_to_ldu(connector));
}
-static struct drm_connector_funcs vmw_legacy_connector_funcs = {
+static const struct drm_connector_funcs vmw_legacy_connector_funcs = {
.dpms = vmw_du_connector_dpms,
.save = vmw_du_connector_save,
.restore = vmw_du_connector_restore,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index b96d1ab..2dd20c34 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -530,7 +530,7 @@ out_no_fence:
return ret;
}
-static struct drm_crtc_funcs vmw_screen_object_crtc_funcs = {
+static const struct drm_crtc_funcs vmw_screen_object_crtc_funcs = {
.save = vmw_du_crtc_save,
.restore = vmw_du_crtc_restore,
.cursor_set = vmw_du_crtc_cursor_set,
@@ -550,7 +550,7 @@ static void vmw_sou_encoder_destroy(struct drm_encoder
*encoder)
vmw_sou_destroy(vmw_encoder_to_sou(encoder));
}
-static struct drm_encoder_funcs vmw_screen_object_encoder_funcs = {
+static const struct drm_encoder_funcs vmw_screen_object_encoder_funcs = {
.destroy = vmw_sou_encoder_destroy,
};
@@ -563,7 +563,7 @@ static void vmw_sou_connector_destroy(struct drm_connector
*connector)
vmw_sou_destroy(vmw_connector_to_sou(connector));
}
-static struct drm_connector_funcs vmw_sou_connector_funcs = {
+static const struct drm_connector_funcs vmw_sou_connector_funcs = {
.dpms = vmw_du_connector_dpms,
.save = vmw_du_connector_save,
.restore = vmw_du_connector_restore,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index c22e2df..61d9686 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -1038,7 +1038,7 @@ out_finish:
/*
* Screen Target CRTC dispatch table
*/
-static struct drm_crtc_funcs vmw_stdu_crtc_funcs = {
+static const struct drm_crtc_funcs vmw_stdu_crtc_funcs = {
.save = vmw_du_crtc_save,
.restore = vmw_du_crtc_restore,
.cursor_set = vmw_du_crtc_cursor_set,
@@ -1070,7 +1070,7 @@ static void vmw_stdu_encoder_destroy(struct drm_encoder
*encoder)
vmw_stdu_destroy(vmw_encoder_to_stdu(encoder));
}
-static struct drm_encoder_funcs vmw_stdu_encoder_funcs = {
+static const struct drm_encoder_funcs vmw_stdu_encoder_funcs = {
.destroy = vmw_stdu_encoder_destroy,
};
@@ -1097,7 +1097,7 @@ static void vmw_stdu_conne
[PATCH 17/20] drm/sti: Constify function pointer structs
From: Ville Syrjälä
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/sti/sticompositor.ko:
-.text 12216
+.text 12212
-.rodata 1284
+.rodata 1400
-.data 488
+.data 372
drivers/gpu/drm/sti/sti_drv.ko:
-.rodata 516
+.rodata 544
-.data368
+.data340
drivers/gpu/drm/sti/stidvo.ko:
-.text 3356
+.text 3348
-.rodata 188
+.rodata 256
-.data572
+.data504
drivers/gpu/drm/sti/sti_hda.ko:
-.text 3008
+.text 3004
-.rodata 2820
+.rodata 2888
-.data684
+.data616
drivers/gpu/drm/sti/stihdmi.ko:
-.text6988
+.text6980
-.rodata 1340
+.rodata 1408
-.data 176
+.data 108
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/sti/sti_crtc.c | 4 ++--
drivers/gpu/drm/sti/sti_drv.c | 2 +-
drivers/gpu/drm/sti/sti_dvo.c | 4 ++--
drivers/gpu/drm/sti/sti_hda.c | 4 ++--
drivers/gpu/drm/sti/sti_hdmi.c | 4 ++--
5 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
index 018ffc9..a86a2d4 100644
--- a/drivers/gpu/drm/sti/sti_crtc.c
+++ b/drivers/gpu/drm/sti/sti_crtc.c
@@ -226,7 +226,7 @@ static void sti_crtc_atomic_flush(struct drm_crtc *crtc,
}
}
-static struct drm_crtc_helper_funcs sti_crtc_helper_funcs = {
+static const struct drm_crtc_helper_funcs sti_crtc_helper_funcs = {
.enable = sti_crtc_enable,
.disable = sti_crtc_disabling,
.mode_fixup = sti_crtc_mode_fixup,
@@ -338,7 +338,7 @@ void sti_crtc_disable_vblank(struct drm_device *drm_dev,
int crtc)
}
EXPORT_SYMBOL(sti_crtc_disable_vblank);
-static struct drm_crtc_funcs sti_crtc_funcs = {
+static const struct drm_crtc_funcs sti_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
.destroy = sti_crtc_destroy,
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 6f4af6a..85fc971 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -107,7 +107,7 @@ static int sti_atomic_commit(struct drm_device *drm,
return 0;
}
-static struct drm_mode_config_funcs sti_mode_config_funcs = {
+static const struct drm_mode_config_funcs sti_mode_config_funcs = {
.fb_create = drm_fb_cma_create,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = sti_atomic_commit,
diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index d141d64..c8b5078 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -329,7 +329,7 @@ struct drm_encoder *sti_dvo_best_encoder(struct
drm_connector *connector)
return dvo_connector->encoder;
}
-static struct drm_connector_helper_funcs sti_dvo_connector_helper_funcs = {
+static const struct drm_connector_helper_funcs sti_dvo_connector_helper_funcs
= {
.get_modes = sti_dvo_connector_get_modes,
.mode_valid = sti_dvo_connector_mode_valid,
.best_encoder = sti_dvo_best_encoder,
@@ -364,7 +364,7 @@ static void sti_dvo_connector_destroy(struct drm_connector
*connector)
kfree(dvo_connector);
}
-static struct drm_connector_funcs sti_dvo_connector_funcs = {
+static const struct drm_connector_funcs sti_dvo_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = sti_dvo_connector_detect,
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 598cd78..68a5118 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -589,7 +589,7 @@ struct drm_encoder *sti_hda_best_encoder(struct
drm_connector *connector)
return hda_connector->encoder;
}
-static struct drm_connector_helper_funcs sti_hda_connector_helper_funcs = {
+static const struct drm_connector_helper_funcs sti_hda_connector_helper_funcs
= {
.get_modes = sti_hda_connector_get_modes,
.mode_valid = sti_hda_connector_mode_valid,
.best_encoder = sti_hda_best_encoder,
@@ -611,7 +611,7 @@ static void sti_hda_connector_destroy(struct drm_connector
*connector)
kfree(hda_connector);
}
-static struct drm_connector_funcs sti_hda_connector_funcs = {
+static const struct drm_connector_funcs sti_hda_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
[PULL] drm-intel-next-fixes
Hi Dave - i915 display fixes headed for v4.3. Mostly SKL, but some regression fixes too. BR, Jani. The following changes since commit 26951caf55d73ceb1967b0bf12f6d0b96853508e: drm/i915/skl: enable DDI-E hotplug (2015-08-26 10:24:25 +0300) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-fixes-2015-09-02 for you to fetch changes up to 6fa2d197936ba0b8936e813d0adecefac160062b: i915: Set ddi_pll_sel in DP MST path (2015-09-01 12:42:27 +0300) Ander Conselvan de Oliveira (1): i915: Set ddi_pll_sel in DP MST path Gary Wang (1): drm/i915: set CDCLK if DPLL0 enabled during resuming from S3 Imre Deak (1): drm/i915: apply the PCI_D0/D3 hibernation workaround everywhere on pre GEN6 Lukas Wunner (1): drm/i915: Preserve SSC earlier Rodrigo Vivi (2): drm/i915/skl: Enable DDI-E drm/i915: eDP can be present on DDI-E Ville Syrjälä (2): drm/i915: Check DP link status on long hpd too drm/i915: Don't use link_bw for PLL setup Xiong Zhang (2): drm/i915: Enable HDMI on DDI-E drm/i915/skl: Adding DDI_E power well domain drivers/gpu/drm/i915/i915_debugfs.c | 2 + drivers/gpu/drm/i915/i915_drv.c | 15 +--- drivers/gpu/drm/i915/i915_drv.h | 6 +++ drivers/gpu/drm/i915/intel_bios.c | 39 +-- drivers/gpu/drm/i915/intel_bios.h | 7 +--- drivers/gpu/drm/i915/intel_ddi.c| 11 ++ drivers/gpu/drm/i915/intel_display.c| 54 +-- drivers/gpu/drm/i915/intel_dp.c | 66 - drivers/gpu/drm/i915/intel_dp_mst.c | 5 +++ drivers/gpu/drm/i915/intel_drv.h| 1 + drivers/gpu/drm/i915/intel_hdmi.c | 21 +++ drivers/gpu/drm/i915/intel_runtime_pm.c | 2 + 12 files changed, 147 insertions(+), 82 deletions(-) -- Jani Nikula, Intel Open Source Technology Center
[PATCH 09/20] drm/exynos: Constify function pointer structs
Hi Ville, 2015-09-02 ville.syrjala at linux.intel.com : > From: Ville Syrjälä > > Moves a bunch of junk to .rodata from .data. > > drivers/gpu/drm/exynos/exynosdrm.ko: > -.text 125792 > +.text 125788 > -.rodata 10972 > +.rodata 11748 > -.data 6720 > +.data 5944 > > Signed-off-by: Ville Syrjälä > Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/exynos/exynos_dp_core.c | 8 > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 ++-- > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 8 > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 > drivers/gpu/drm/exynos/exynos_drm_fb.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 8 > drivers/gpu/drm/exynos/exynos_hdmi.c | 8 > 8 files changed, 24 insertions(+), 24 deletions(-) Reviewed-by: Gustavo Padovan Gustavo
[PATCH v2 2/3] drm/dp: Adjust i2c-over-aux retry count based on message size and i2c bus speed
On Tue, 01 Sep 2015, Daniel Vetter wrote:
> On Tue, Sep 01, 2015 at 05:11:45PM +0200, Daniel Vetter wrote:
>> On Tue, Sep 01, 2015 at 02:13:01PM +0300, Ville Syrjälä wrote:
>> > On Tue, Sep 01, 2015 at 11:14:43AM +0200, Daniel Vetter wrote:
>> > > On Wed, Aug 26, 2015 at 10:55:06PM +0300, ville.syrjala at
>> > > linux.intel.com wrote:
>> > > > From: Ville Syrjälä
>> > > >
>> > > > Calculate the number of retries we should do for each i2c-over-aux
>> > > > message based on the time it takes to perform the i2c transfer vs. the
>> > > > aux transfer. We assume the shortest possible length for the aux
>> > > > transfer, and the longest possible (exluding clock stretching) for the
>> > > > i2c transfer.
>> > > >
>> > > > The DP spec has some examples on how to calculate this, but we don't
>> > > > calculate things quite the same way. The spec doesn't account for the
>> > > > retry interval (assumes immediate retry on defer), and doesn't assume
>> > > > the best/worst case behaviour as we do.
>> > > >
>> > > > Note that currently we assume 10 kHz speed for the i2c bus. Some real
>> > > > world devices (eg. some Apple DP->VGA dongle) fails with less than 16
>> > > > retries. and that would correspond to something close to 15 kHz (with
>> > > > our method of calculating things) But let's just go for 10 kHz to be
>> > > > on the safe side. Ideally we should query/set the i2c bus speed via
>> > > > DPCD but for now this should at leaast remove the regression from the
>> > > > 1->16 byte trasnfer size change. And of course if the sink completes
>> > > > the transfer quicker this shouldn't slow things down since we don't
>> > > > change the interval between retries.
>> > > >
>> > > > I did a few experiments with a DP->DVI dongle I have that allows you
>> > > > to change the i2c bus speed. Here are the results of me changing the
>> > > > actual bus speed and the assumed bus speed and seeing when we start
>> > > > to fail the operation:
>> > > >
>> > > > actual i2c khz assumed i2c khz max retries
>> > > > 1 1 ok -> 2 fail 211 ok -> 106 fail
>> > > > 5 8 ok -> 9 fail 27 ok -> 24 fail
>> > > > 10 17 ok -> 18 fail13 ok -> 12 fail
>> > > > 100 210 ok -> 211 fail 2 ok -> 1 fail
>> > > >
>> > > > So based on that we have a fairly decent safety margin baked into
>> > > > the formula to calculate the max number of retries.
>> > > >
>> > > > Fixes a regression with some DP dongles from:
>> > > > commit 1d002fa720738bcd0bddb9178e9ea0773288e1dd
>> > > > Author: Simon Farnsworth
>> > > > Date: Tue Feb 10 18:38:08 2015 +
>> > > >
>> > > > drm/dp: Use large transactions for I2C over AUX
>> > > >
>> > > > v2: Use best case for AUX and worst case for i2c (Simon Farnsworth)
>> > > > Add a define our AUX retry interval and account for it
>> > > >
>> > > > Cc: Simon Farnsworth
>> > > > Cc: moosotc at gmail.com
>> > > > Tested-by: moosotc at gmail.com
>> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91451
>> > > > Signed-off-by: Ville Syrjälä
>> > > > ---
>> > > > drivers/gpu/drm/drm_dp_helper.c | 81
>> > > > -
>> > > > 1 file changed, 79 insertions(+), 2 deletions(-)
>> > > >
>> > > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
>> > > > b/drivers/gpu/drm/drm_dp_helper.c
>> > > > index 7069e54..23b9fcc 100644
>> > > > --- a/drivers/gpu/drm/drm_dp_helper.c
>> > > > +++ b/drivers/gpu/drm/drm_dp_helper.c
>> > > > @@ -424,6 +424,78 @@ static u32 drm_dp_i2c_functionality(struct
>> > > > i2c_adapter *adapter)
>> > > > I2C_FUNC_10BIT_ADDR;
>> > > > }
>> > > >
>> > > > +#define AUX_PRECHARGE_LEN 10 /* 10 to 16 */
>> > > > +#define AUX_SYNC_LEN (16 + 4) /* preamble + AUX_SYNC_END */
>> > > > +#define AUX_STOP_LEN 4
>> > > > +#define AUX_CMD_LEN 4
>> > > > +#define AUX_ADDRESS_LEN 20
>> > > > +#define AUX_REPLY_PAD_LEN 4
>> > > > +#define AUX_LENGTH_LEN 8
>> > > > +
>> > > > +/*
>> > > > + * Calculate the length of the AUX request/reply. Gives the "best"
>> > > > + * case estimate, ie. successful while as short as possible.
>> > > > + */
>> > > > +static int drm_dp_aux_req_len(const struct drm_dp_aux_msg *msg)
>> > > > +{
>> > > > + int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
>> > > > + AUX_CMD_LEN + AUX_ADDRESS_LEN + AUX_LENGTH_LEN;
>> > > > +
>> > > > + if ((msg->request & DP_AUX_I2C_READ) == 0)
>> > > > + len += msg->size * 8;
>> > > > +
>> > > > + return len;
>> > > > +}
>> > > > +
>> > > > +static int drm_dp_aux_reply_len(const struct drm_dp_aux_msg *msg)
>> > > > +{
>> > > > + int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
>> > > > + AUX_CMD_LEN + AUX_REPLY_PAD_LEN;
>> > > > +
>> > > > + /*
>> > > > + * For read we expect what was asked. For writes there will
>> > > > + * be 0 or 1 data bytes. Ass
[Bug 76559] screen corruption after going from VT to X
https://bugs.freedesktop.org/show_bug.cgi?id=76559 --- Comment #5 from Alex Deucher --- this seems suspect: [ 61.916143] [ cut here ] [ 61.916157] WARNING: CPU: 0 PID: 31 at /build/linux-eVPZfP/linux-3.19.0/arch/x86/kernel/check.c:140 check_for_bios_corruption+0x8d/0xd0() [ 61.916161] Memory corruption detected in low memory Maybe some Mac firmware issue? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150902/6122ea87/attachment-0001.html>
[Bug 91841] Juniper 5770 entering Hibernate crashes the system (instant reboot)
https://bugs.freedesktop.org/show_bug.cgi?id=91841 Alex Deucher changed: What|Removed |Added Component|Driver/Radeon |DRM/Radeon Version|7.5 (2009.10) |unspecified Assignee|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org Product|xorg|DRI QA Contact|xorg-team at lists.x.org | -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150902/99432af9/attachment.html>
[Bug 91503] [r600g] regression: SB-related NI/Turks crash on 'gsraytrace'
https://bugs.freedesktop.org/show_bug.cgi?id=91503 Dieter Nützel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Dieter Nützel --- FIXED by one of this: 36f1999a87258603b6720d55e6020d5d24c215c9 a830225adbb77073272961df409885cca6b861ee a830225adbb77073272961df409885cca6b861ee -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150902/b8e2897a/attachment.html>
[PATCH v4 08/16] drm: rockchip/dp: add rockchip platform dp driver
Hi Heiko,
å¨ 09/02/2015 05:00 AM, Heiko Stuebner åé:
> Hi Yakir,
>
> Am Dienstag, 1. September 2015, 14:01:28 schrieb Yakir Yang:
>> Rockchip have three clocks for dp controller, we leave pclk_edp
>> to analogix_dp driver control, and keep the sclk_edp_24m and
>> sclk_edp in platform driver.
>>
>> Signed-off-by: Yakir Yang
>> ---
>> Changes in v4:
>> - Remove some deprecated DT properties in rockchip dp document.
>>
>> Changes in v3:
>> - Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip
>>dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp
>>core driver which name to "dp", and leave "pclk_edp" to rockchip dp
>> platform driver which name to "pclk".
>> - Take Heiko suggest, add devicetree binding document.
>> - Take Heiko suggest, remove "rockchip,panel" DT property, take use of
>> remote point to get panel node.
>> - Add the new function point analogix_dp_platdata.get_modes init.
>>
>> Changes in v2:
>> - Take Heiko suggest, get panel node with remote-endpoint method,
>>and create devicetree binding for driver.
>> - Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
>>leave those clock to rockchip dp phy driver.
>>
>> .../bindings/video/analogix_dp-rockchip.txt| 74
>> drivers/gpu/drm/rockchip/Kconfig | 9 +
>> drivers/gpu/drm/rockchip/Makefile | 1 +
>> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 389
>> + 4 files changed, 473 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt create
>> mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>
>> diff --git
>> a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
>> b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt new file
>> mode 100644
>> index 000..502483e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
>> @@ -0,0 +1,74 @@
>> +Rockchip RK3288 specific extensions to the Analogix Display Port
>> +
>> +
>> +Required properties:
>> +- compatible: "rockchip,rk3288-edp";
>> +
>> +- reg: physical base address of the controller and length
>> +
>> +- clocks: from common clock binding: handle to dp clock.
>> + of memory mapped region.
>> +
>> +- clock-names: from common clock binding:
>> + Required elements: "dp" "pclk"
>> +
>> +- resets: Must contain an entry for each entry in reset-names.
>> + See ../reset/reset.txt for details.
>> +
>> +- reset-names: Must include the name "dp"
>> +
>> +- rockchip,grf: this soc should set GRF regs, so need get grf here.
>> +
>> +- ports: contain a port node with endpoint definitions as defined in
>> + Documentation/devicetree/bindings/media/video-interfaces.txt.
>> +
>> +
>> +For the below properties, please refer to Analogix DP binding document:
>> + * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
>> +- phys (required)
>> +- phy-names (required)
>> +- hpd-gpios (optional)
>> +---
>> +
>> +Example:
>> +dp-controller: dp at ff97 {
>> +compatible = "rockchip,rk3288-dp";
>> +reg = <0xff97 0x4000>;
>> +interrupts = ;
>> +clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>;
>> +clock-names = "dp", "pclk";
>> +phys = <&dp_phy>;
>> +phy-names = "dp";
>> +
>> +rockchip,grf = <&grf>;
>> +resets = <&cru 111>;
>> +reset-names = "dp";
>> +
>> +status = "disabled";
>> +
>> +ports {
> #address-cells = <1>;
> #size-cells = <0>;
Done,
>> +edp_in: port {
> edp_in: port at 0
> reg = <0>;
Done,
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +edp_in_vopb: endpoint at 0 {
>> +reg = <0>;
>> +remote-endpoint = <&vopb_out_edp>;
>> +};
>> +edp_in_vopl: endpoint at 1 {
>> +reg = <1>;
>> +remote-endpoint = <&vopl_out_edp>;
>> +};
>> +};
>> +
>> +edp_out: port at 1 {
>> +reg = <1>;
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +edp_out_panel: endpoint {
>> +reg = <0>;
>> +remote-endpoint = <&panel_in_edp>
>> +};
>> +};
>> +};
>> +};
>> +
>> diff --git a/drivers/gpu/drm/rockchip/Kconfig
>> b/drivers/gpu/drm/rockchip/Kconfig index 35215f6
[PATCH v4 10/16] phy: Add driver for rockchip Display Port PHY
Hi Heiko,
å¨ 09/02/2015 12:51 AM, Heiko Stuebner åé:
> Am Dienstag, 1. September 2015, 14:04:15 schrieb Yakir Yang:
>> This phy driver would control the Rockchip DisplayPort module
>> phy clock and phy power, it is relate to analogix_dp-rockchip
>> dp driver. If you want DP works rightly on rockchip platform,
>> then you should select both of them.
>>
>> Signed-off-by: Yakir Yang
>> ---
>> Changes in v4:
>> - Take Kishon suggest, add commit message, and remove the redundant
>>rockchip_dp_phy_init() function, move those code to probe() method.
>>And remove driver .owner number.
>>
>> Changes in v3:
>> - Take Heiko suggest, add rockchip dp phy driver,
>>collect the phy clocks and power control.
>>
>> Changes in v2: None
>>
>> .../devicetree/bindings/phy/rockchip-dp-phy.txt| 26
>> drivers/phy/Kconfig| 7 +
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-rockchip-dp.c | 166
>> + 4 files changed, 200 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt create mode
>> 100644 drivers/phy/phy-rockchip-dp.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
>> b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt new file mode
>> 100644
>> index 000..5de1088
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
>> @@ -0,0 +1,26 @@
>> +Rockchip Soc Seroes Display Port PHY
>> +
>> +
>> +Required properties:
>> +- compatible : should be one of the following supported values:
>> + - "rockchip.rk3288-dp-phy"
>> +
>> +- reg : a list of registers used by phy driver
> nodes do not necessarily need to have a regs property. You can do all
> operations via the grf syscon already.
Oh, yes, the dp phy power register is belong to GRF filed, thanks.
>
>> +- clocks: from common clock binding: handle to dp clock.
>> +of memory mapped region.
>> +- clock-names: from common clock binding:
>> +Required elements: "sclk_dp" "sclk_dp_24m"
>> +
>> +- rockchip,grf: this soc should set GRF regs, so need get grf here.
>> +- #phy-cells : from the generic PHY bindings, must be 0;
>> +
>> +Example:
>> +
>> +edp_phy: phy at ff770274 {
> edp_phy: edp-phy {
Done,
>
>
>> +compatilble = "rockchip,rk3288-dp-phy";
>> +reg = <0xff770274 4>;
> no regs property
Done
>> +rockchip,grf = <&grf>;
>> +clocks = <&cru SCLK_EDP_24M>;
>> +clock-names = "24m";
>> +#phy-cells = <0>;
>> +}
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 47da573..8f2bc4f 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -310,6 +310,13 @@ config PHY_ROCKCHIP_USB
>> help
>>Enable this to support the Rockchip USB 2.0 PHY.
>>
>> +config PHY_ROCKCHIP_DP
>> +tristate "Rockchip Display Port PHY Driver"
>> +depends on ARCH_ROCKCHIP && OF
>> +select GENERIC_PHY
>> +help
>> + Enable this to support the Rockchip Display Port PHY.
>> +
>> config PHY_ST_SPEAR1310_MIPHY
>> tristate "ST SPEAR1310-MIPHY driver"
>> select GENERIC_PHY
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index a5b18c1..e281f35 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -34,6 +34,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2) +=
>> phy-s5pv210-usb2.o obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
>> obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
>> obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
>> +obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
>> obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
>> obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
>> obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
>> diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
>> new file mode 100644
>> index 000..e9a726e
>> --- /dev/null
>> +++ b/drivers/phy/phy-rockchip-dp.c
>> @@ -0,0 +1,166 @@
>> +/*
>> + * Rockchip DP PHY driver
>> + *
>> + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
>> + * Author: Yakir Yang
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define GRF_SOC_CON12 0x0274
>> +#define GRF_EDP_REF_CLK_SEL_INTER BIT(4)
>> +
>> +#define DP_PHY_SIDDQ_WRITE_EN BIT(21)
>> +#define DP_PHY_SIDDQ_ON 0
>> +#define DP_PHY_SIDDQ_OFFBIT(5)
>> +
>> +struct rockchip_dp_phy {
>> +struct device *dev;
>> +struct regmap *grf;
>>
[PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir
Heiko,
å¨ 09/02/2015 04:46 AM, Heiko Stuebner åé:
> Am Dienstag, 1. September 2015, 13:49:58 schrieb Yakir Yang:
>> Split the dp core driver from exynos directory to bridge
>> directory, and rename the core driver to analogix_dp_*,
>> leave the platform code to analogix_dp-exynos.
>>
>> Signed-off-by: Yakir Yang
> [...]
>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c similarity index 50%
>> rename from drivers/gpu/drm/exynos/exynos_dp_core.c
>> rename to drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> index bed0252..7d62f22 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> [...]
>
>> connector->polled = DRM_CONNECTOR_POLL_HPD;
>>
>> ret = drm_connector_init(dp->drm_dev, connector,
>> - &exynos_dp_connector_funcs,
>> + &analogix_dp_connector_funcs,
>> DRM_MODE_CONNECTOR_eDP);
>> if (ret) {
>> DRM_ERROR("Failed to initialize connector with drm\n");
>> return ret;
>> }
>>
>> -drm_connector_helper_add(connector, &exynos_dp_connector_helper_funcs);
>> +drm_connector_helper_add(connector,
>> + &analogix_dp_connector_helper_funcs);
>> drm_connector_register(connector);
> this should only run on exynos, as we're doing all our connector registration
> in the core driver after all components are bound, so I guess something like
> the following is needed:
>
> if (dp->plat_data && dp->plat_data->dev_type == EXYNOS_DP)
> drm_connector_register(connector);
>
Oh, good catch, thanks
>
>> drm_mode_connector_attach_encoder(connector, encoder);
>>
> [...]
>
>> @@ -1301,7 +1239,10 @@ static int exynos_dp_bind(struct device *dev, struct
>> device *master, void *data) if (IS_ERR(dp->reg_base))
>> return PTR_ERR(dp->reg_base);
>>
>> -dp->hpd_gpio = of_get_named_gpio(dev->of_node, "samsung,hpd-gpio", 0);
>> +dp->hpd_gpio = of_get_named_gpio(dev->of_node, "hpd-gpios", 0);
>> +if (gpio_is_valid(dp->hpd_gpio))
> this should be !gpio_is_valid ... i.e. only check the old property if the new
> one is _not_ valid
Oh, much appreciate ;)
- Yakir
>
>> +dp->hpd_gpio = of_get_named_gpio(dev->of_node,
>> + "samsung,hpd-gpio", 0);
>>
>> if (gpio_is_valid(dp->hpd_gpio)) {
>> /*
>
>
>
[PATCH v4 10/16] phy: Add driver for rockchip Display Port PHY
Hi Heiko,
å¨ 09/02/2015 04:58 AM, Heiko Stuebner åé:
> Hi Yakir,
>
> small nit more below
>
> Am Dienstag, 1. September 2015, 18:51:16 schrieb Heiko Stuebner:
>> Am Dienstag, 1. September 2015, 14:04:15 schrieb Yakir Yang:
>>> +- clocks: from common clock binding: handle to dp clock.
>>> + of memory mapped region.
>>> +- clock-names: from common clock binding:
>>> + Required elements: "sclk_dp" "sclk_dp_24m"
>>> +
>>> +- rockchip,grf: this soc should set GRF regs, so need get grf here.
>>> +- #phy-cells : from the generic PHY bindings, must be 0;
>>> +
>>> +Example:
>>> +
>>> +edp_phy: phy at ff770274 {
>> edp_phy: edp-phy {
>>
>>> + compatilble = "rockchip,rk3288-dp-phy";
> typo: compatible
Aha, thanks.
- Yakir
>
>
>
[PATCH v4 0/16] Add Analogix Core Display Port Driver
Hi Heiko, å¨ 09/02/2015 05:47 AM, Heiko Stuebner åé: > Hi Yakir, > > Am Dienstag, 1. September 2015, 13:46:11 schrieb Yakir Yang: >> The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller >> share the same IP, so a lot of parts can be re-used. I split the common >> code into bridge directory, then rk3288 and exynos only need to keep >> some platform code. Cause I can't find the exact IP name of exynos dp >> controller, so I decide to name dp core driver with "analogix" which I >> find in rk3288 eDP TRM ;) >> >> Beyond that, there are three light registers setting differents bewteen >> exynos and rk3288. >> 1. RK3288 have five special pll resigters which not indicata in exynos >> dp controller. >> 2. The address of DP_PHY_PD(dp phy power manager register) are different >> between rk3288 and exynos. >> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug >> register). >> >> I have verified this series on two kinds of rockchip platform board, one >> is rk3288 sdk board which connect with a 2K display port monitor, the other >> is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2", >> both of them works rightlly. > it looks like during the rebase something did go wrong and I found some issues > I mentioned in the replies to individual patches. > > I did prepare a branch based on mainline [0] with both the old and the new edp > driver - rk3288_veyron_defconfig build both drivers into the image. > > While the old driver still works, I wasn't able to make the new one work yet > ... the drm core does find the connector, but not that anything is connected > to it. I'll try to dig deeper tomorrow, but maybe you'll see anything > interesting before then. Many thanks for your comment and debug, I would rebase on your "edp-with-veyron" branch and fix the broken, make sure v6 would work rightly at least in your side and my side. - Yakir > > Heiko > > [0] https://github.com/mmind/linux-rockchip/tree/tmp/edp-with-veyron > > > >
[Intel-gfx] [PATCH 4/5] Documentation: drm: Convert KMS Properties HTML table to CALS
On Tue, 2015-09-01 at 14:56 -0300, Danilo Cesar Lemes de Paula wrote: > On 08/25/2015 01:10 PM, Graham Whaley wrote: > > On Tue, 2015-08-25 at 16:29 +0200, Daniel Vetter wrote: > > > On Tue, Aug 25, 2015 at 10:26:44AM +0100, Graham Whaley wrote: > > > > The KMS Properties table is in HTML format, which is not > > > > supported > > > > for building pdfdocs, resulting in the following types of > > > > errors: > > > > > > > > jade:/Documentation/DocBook/drm.xml:34413:15:E: there is no > > > > attribute > > > > "border" > > > > jade:/Documentation/DocBook/drm.xml:34413:31:E: there is no > > > > attribute > > > > "cellpadding" > > > > jade:/Documentation/DocBook/drm.xml:34413:47:E: there is no > > > > attribute > > > > "cellspacing" > > > > jade:/Documentation/DocBook/drm.xml:34414:7:E: document type > > > > does > > > > not > > > > allow element "tbody" here > > > > > > > > Convert the table over to a CALS format table > > > > > > Hm, long-term plan was to move this table into DOC: comments in > > > the > > > source-code using markdown, which we now have (at least in > > > drm-intel-nightly and also planned to be merged into 4.4). Since > > > this > > > is > > > both a lot of churn I'd like to get there in just 1 step ... > > > -Daniel > > First - I've just noted an erroneous debug comment (or two) left in > > this patch as well, so looks like I will have to re-issue the > > series > > anyway. > > > > OK. I guess this comes down to a matter of timing... > > From Danilos patch of: f6d6913 (drm/doc: Convert to markdown) > > we can see markdown does not natively support tables, and we'd have > > to > > make this a fixed width layout like the one in that patch I > > suspect. > > Danilo - any advice on how you did that other table conversion? I > > just > > did a pandoc docbook->markdown_github and it looks some way there - > > but > > of course seems to have not honored the multi-column items, of > > which > > there are a few. It's probably not too bad to fix up by hand - I'll > > see > > if I can get that to work... > > Hi Graham, > > To be honest I didn't have to do any conversion as that table was > already in the header file. I just added 4 spaces so it would be > transformed into fixed width. > > However, there's tool you can use to help you: http://pandoc.org/try/ > I did a lot of translation there. If your table doesn't have any > spancells, you can put the HTML code there and get the Markdown for > free. > > Danilo Thanks, I got to have a look at this yesterday. I did a text render from the html using 'links' that worked surprisingly well, but the table has many spancells (both vertical and horizontal), and some other issues arose. I'll do an email later with some details of what I've found, but right now I'm not hopeful that it will be practical to move that large KMS Properties table to markdown. More later. Graham
[PATCH] virtio-gpu: fix compilation warnings
Update snprintf format in virtgpu_fence.c and virtgpu_debugfs.c to fix the
following compilation warnings:
C [M] drivers/gpu/drm/virtio/virtgpu_fence.o
drivers/gpu/drm/virtio/virtgpu_fence.c: In function
âvirtio_timeline_value_strâ :
drivers/gpu/drm/virtio/virtgpu_fence.c:64:2: warning: format â%luâ expects
argument of type âlong unsigned intâ, but argument 4 has type âlong long
intâ [-Wformat=]
snprintf(str, size, "%lu", atomic64_read(&fence->drv->last_seq));
^
CC [M] drivers/gpu/drm/virtio/virtgpu_debugfs.o
drivers/gpu/drm/virtio/virtgpu_debugfs.c: In function
âvirtio_gpu_debugfs_irq_infoâ:
drivers/gpu/drm/virtio/virtgpu_debugfs.c:39:6: warning: format â%ldâ
expects argument of type âlong intâ, but argument 3 has type âlong long
intâ [-Wformat=]
vgdev->fence_drv.sync_seq);
^
Signed-off-by: Mike Rapoport
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_fence.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_debugfs.c
b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
index db8b491..d87b27c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_debugfs.c
+++ b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
@@ -34,7 +34,7 @@ virtio_gpu_debugfs_irq_info(struct seq_file *m, void *data)
struct drm_info_node *node = (struct drm_info_node *) m->private;
struct virtio_gpu_device *vgdev = node->minor->dev->dev_private;
- seq_printf(m, "fence %ld %lld\n",
+ seq_printf(m, "fence %lld %lld\n",
atomic64_read(&vgdev->fence_drv.last_seq),
vgdev->fence_drv.sync_seq);
return 0;
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index 1da6326..98dd385 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fence.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
@@ -61,7 +61,7 @@ static void virtio_timeline_value_str(struct fence *f, char
*str, int size)
{
struct virtio_gpu_fence *fence = to_virtio_fence(f);
- snprintf(str, size, "%lu", atomic64_read(&fence->drv->last_seq));
+ snprintf(str, size, "%llu", atomic64_read(&fence->drv->last_seq));
}
static const struct fence_ops virtio_fence_ops = {
--
1.8.3.1
[PATCH v4 09/16] drm: rockchip: add bpc and color mode setting
Thierry,
å¨ 2015/9/2 16:34, Thierry Reding åé:
> On Wed, Sep 02, 2015 at 10:06:36AM +0800, Yakir Yang wrote:
>> å¨ 09/02/2015 05:00 AM, Heiko Stuebner åé:
>>> Am Dienstag, 1. September 2015, 14:01:48 schrieb Yakir Yang:
> [...]
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index 34b78e7..5d7f9b6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -811,14 +811,41 @@ static const struct drm_plane_funcs vop_plane_funcs =
{
int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc,
int connector_type,
-int out_mode)
+int bpc, int color)
{
struct vop *vop = to_vop(crtc);
-
vop->connector_type = connector_type;
vop->connector_out_mode = out_mode;
>>> this line should probably go away, as the source var "out_mode" does not
>>> exist
>>> in the function params any more, making the compilation break, and is set
>>> below anyway.
>> Sorry for the failed, there are must be a problem when I backport those code
>> to chrome-3.14 to verify.
>>
>> Thanks a lot, I would update next version soon.
> *sigh*
>
> I get the feeling that you're going about upstreaming the wrong way. If
> you post patches to upstream mailing lists and you expect people to
> apply those patches, then your target is the upstream kernel. So you
> should be basing all of your work on top of a recent release candidate
> directly from Linus or some recent version of linux-next.
Yeah, do feel I am in the wrong way now. I used to write my patch on
linux-next branch, then backport some head file to productor kernel,
so I can check compiled failed. After that, I backport the dp driver code
to normal productor kernel, start to debug the function.
So I used to ensure no compiled failed on upstrean kernel, actually it's
also hard to ensure, cause I just backport head file. Not even debug the
function on upstream kernel.
> Your current approach is already making people waste time trying to
> build the patches and fail because you've been testing on something
> other than mainline or linux-next.
>
> At the very least your code must compile when applied against a recent
> upstream tree. I would also expect you to make sure the code works at
> runtime, though, contrary to build testing, not everybody will be able
> to verify that you've actually done so. It is ultimately your platform
> maintainer's (i.e. Heiko's) responsibility to ensure that because they
> will get to deal with user complaints if people can't run an upstream
> kernel on the devices.
Oh, first time to know this rule. So I should work on Heiko's github
kernel branch at the first time to start send upstream.
> I realize that the upstream kernel isn't what's going to end up in
> products later on, but that doesn't change the fact that you're
> submitting code for inclusion in the mainline tree. If you need to
> backport code to some ChromeOS tree, then that should be done after
> you've verified that things build and run upstream. Doing so makes life
> a lot easier for your upstream maintainers, and that in turn makes it
> more likely to get your code merged.
Feel free now, I would correct those in bellow version. Thanks
for your remind (or maybe complain :-D ).
- Yakir
> Thierry
[PATCH v4 10/16] phy: Add driver for rockchip Display Port PHY
On Tue, Sep 1, 2015 at 1:04 AM, Yakir Yang wrote:
> This phy driver would control the Rockchip DisplayPort module
> phy clock and phy power, it is relate to analogix_dp-rockchip
> dp driver. If you want DP works rightly on rockchip platform,
> then you should select both of them.
>
> Signed-off-by: Yakir Yang
> ---
> Changes in v4:
> - Take Kishon suggest, add commit message, and remove the redundant
> rockchip_dp_phy_init() function, move those code to probe() method.
> And remove driver .owner number.
>
> Changes in v3:
> - Take Heiko suggest, add rockchip dp phy driver,
> collect the phy clocks and power control.
>
> Changes in v2: None
>
> .../devicetree/bindings/phy/rockchip-dp-phy.txt| 26
It is preferred that you split binding doc's from driver changes.
> drivers/phy/Kconfig| 7 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-rockchip-dp.c | 166
> +
> 4 files changed, 200 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> create mode 100644 drivers/phy/phy-rockchip-dp.c
>
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> new file mode 100644
> index 000..5de1088
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> @@ -0,0 +1,26 @@
> +Rockchip Soc Seroes Display Port PHY
> +
> +
> +Required properties:
> +- compatible : should be one of the following supported values:
> +- "rockchip.rk3288-dp-phy"
> +
> +- reg : a list of registers used by phy driver
Please state the size of the list and order of what each entry if more than one.
> +- clocks: from common clock binding: handle to dp clock.
> + of memory mapped region.
> +- clock-names: from common clock binding:
> + Required elements: "sclk_dp" "sclk_dp_24m"
> +
> +- rockchip,grf: this soc should set GRF regs, so need get grf here.
I have no idea what GRF means.
> +- #phy-cells : from the generic PHY bindings, must be 0;
> +
> +Example:
> +
> +edp_phy: phy at ff770274 {
> + compatilble = "rockchip,rk3288-dp-phy";
> + reg = <0xff770274 4>;
> + rockchip,grf = <&grf>;
> + clocks = <&cru SCLK_EDP_24M>;
> + clock-names = "24m";
> + #phy-cells = <0>;
> +}
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 47da573..8f2bc4f 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -310,6 +310,13 @@ config PHY_ROCKCHIP_USB
> help
> Enable this to support the Rockchip USB 2.0 PHY.
>
> +config PHY_ROCKCHIP_DP
> + tristate "Rockchip Display Port PHY Driver"
> + depends on ARCH_ROCKCHIP && OF
> + select GENERIC_PHY
> + help
> + Enable this to support the Rockchip Display Port PHY.
> +
> config PHY_ST_SPEAR1310_MIPHY
> tristate "ST SPEAR1310-MIPHY driver"
> select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index a5b18c1..e281f35 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -34,6 +34,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+=
> phy-s5pv210-usb2.o
> obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
> obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
> obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
> +obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
> obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
> obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
> obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
> diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
> new file mode 100644
> index 000..e9a726e
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-dp.c
> @@ -0,0 +1,166 @@
> +/*
> + * Rockchip DP PHY driver
> + *
> + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
> + * Author: Yakir Yang
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define GRF_SOC_CON12 0x0274
> +#define GRF_EDP_REF_CLK_SEL_INTER BIT(4)
> +
> +#define DP_PHY_SIDDQ_WRITE_EN BIT(21)
> +#define DP_PHY_SIDDQ_ON 0
> +#define DP_PHY_SIDDQ_OFFBIT(5)
> +
> +struct rockchip_dp_phy {
> + struct device *dev;
> + struct regmap *grf;
> + void __iomem *regs;
> + struct clk *phy_24m;
> +};
> +
> +static int rockchip_dp_phy_clk_enable(struct rockchip_dp_phy *dp)
> +{
> + int ret = 0;
> +
> + ret = clk_set_rate(dp->phy_24m,
[PATCH v4 09/16] drm: rockchip: add bpc and color mode setting
Hi Heiko,
å¨ 09/02/2015 05:00 AM, Heiko Stuebner åé:
> Hi Yakir,
>
> Am Dienstag, 1. September 2015, 14:01:48 schrieb Yakir Yang:
>> From: Mark Yao
>>
>> Add bpc and color mode setting in rockchip_drm_vop driver, so
>> connector could try to use the edid drm_display_info to config
>> vop output mode.
>>
>> Signed-off-by: Mark Yao
>> Signed-off-by: Yakir Yang
>> ---
>> Changes in v4: None
>> Changes in v3: None
>> Changes in v2: None
>>
>> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 46
>> +++-- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |
>> 2 +-
>> drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 +-
>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 33 --
>> 4 files changed, 68 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c index cebff9e..efea045
>> 100644
>> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>> @@ -11,11 +11,6 @@
>>* Free Software Foundation; either version 2 of the License, or (at your
>>* option) any later version.
>>*/
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>>
>> #include
>> #include
>> @@ -27,6 +22,13 @@
>> #include
>> #include
>>
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> #include
>>
>> #include "rockchip_drm_drv.h"
>> @@ -125,20 +127,44 @@ static void rockchip_dp_drm_encoder_mode_set(struct
>> drm_encoder *encoder, /* do nothing */
>> }
>>
>> +static drm_connector *rockchip_dp_get_connector(struct rockchip_dp_device
> missing a "struct" -> static struct drm_connector
What the hell mistake I make in v5 :-(
Thanks a lot, I would fix this as soon as possible
>
>> *dp) +{
>> +struct drm_connector *connector;
>> +struct drm_device *drm_dev = dp->drm_dev;
>> +
>> +drm_for_each_connector(connector, drm_dev) {
>> +if (connector->encoder != &dp->encoder)
>> +return connector;
>> +}
>> +
>> +return NULL;
>> +}
>> +
>> static void rockchip_dp_drm_encoder_prepare(struct drm_encoder *encoder)
>> {
>> struct rockchip_dp_device *dp = encoder_to_dp(encoder);
>> +struct drm_connector *connector;
>> +int ret = 0;
>> u32 val;
>> -int ret;
>>
>> -ret = rockchip_drm_crtc_mode_config(encoder->crtc,
>> -DRM_MODE_CONNECTOR_eDP,
>> -ROCKCHIP_OUT_MODE_);
>> -if (ret < 0) {
>> +connector = rockchip_dp_get_connector(dp);
>> +if (!connector) {
>> +DRM_ERROR("Failed to get connector by encoder[%p]\n", encoder);
>> +return;
>> +}
>> +
>> +if (connector->display_info.color_formats | DRM_COLOR_FORMAT_RGB444)
>> +ret = rockchip_drm_crtc_mode_config(
>> +encoder->crtc, DRM_MODE_CONNECTOR_eDP,
>> +connector->display_info.bpc, DRM_COLOR_FORMAT_RGB444);
>> +if (!ret) {
>> dev_err(dp->dev, "Could not set crtc mode config: %d.\n", ret);
>> return;
>> }
>>
>> +connector->display_info.bpc = ret;
>> +connector->display_info.color_formats = DRM_COLOR_FORMAT_RGB444;
>> +
>> ret = rockchip_drm_encoder_get_mux_id(dp->dev->of_node, encoder);
>> if (ret < 0)
>> return;
>> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c index 80d6fc8..428a3c1 100644
>> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> @@ -215,7 +215,7 @@ static void dw_hdmi_rockchip_encoder_commit(struct
>> drm_encoder *encoder) static void dw_hdmi_rockchip_encoder_prepare(struct
>> drm_encoder *encoder) {
>> rockchip_drm_crtc_mode_config(encoder->crtc, DRM_MODE_CONNECTOR_HDMIA,
>> - ROCKCHIP_OUT_MODE_);
>> + 10, DRM_COLOR_FORMAT_RGB444);
>> }
>>
>> static struct drm_encoder_helper_funcs
>> dw_hdmi_rockchip_encoder_helper_funcs = { diff --git
>> a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
>> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h index dc4e5f0..ef1d7fb 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
>> @@ -59,7 +59,7 @@ void rockchip_unregister_crtc_funcs(struct drm_device
>> *dev, int pipe); int rockchip_drm_encoder_get_mux_id(struct device_node
>> *node,
>> struct drm_encoder *encoder);
>> int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, int
>> connector_type, - int out_mode);
>> + int bpc, int color);
>> int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
>> struct device *dev);
>> void ro
[PATCH v4 09/16] drm: rockchip: add bpc and color mode setting
On Wed, Sep 02, 2015 at 10:06:36AM +0800, Yakir Yang wrote:
> å¨ 09/02/2015 05:00 AM, Heiko Stuebner åé:
> >Am Dienstag, 1. September 2015, 14:01:48 schrieb Yakir Yang:
[...]
> >>diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> >>b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index 34b78e7..5d7f9b6 100644
> >>--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> >>+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> >>@@ -811,14 +811,41 @@ static const struct drm_plane_funcs vop_plane_funcs =
> >>{
> >>
> >> int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc,
> >> int connector_type,
> >>- int out_mode)
> >>+ int bpc, int color)
> >> {
> >>struct vop *vop = to_vop(crtc);
> >>-
> >>vop->connector_type = connector_type;
> >>vop->connector_out_mode = out_mode;
> >this line should probably go away, as the source var "out_mode" does not
> >exist
> >in the function params any more, making the compilation break, and is set
> >below anyway.
>
> Sorry for the failed, there are must be a problem when I backport those code
> to chrome-3.14 to verify.
>
> Thanks a lot, I would update next version soon.
*sigh*
I get the feeling that you're going about upstreaming the wrong way. If
you post patches to upstream mailing lists and you expect people to
apply those patches, then your target is the upstream kernel. So you
should be basing all of your work on top of a recent release candidate
directly from Linus or some recent version of linux-next.
Your current approach is already making people waste time trying to
build the patches and fail because you've been testing on something
other than mainline or linux-next.
At the very least your code must compile when applied against a recent
upstream tree. I would also expect you to make sure the code works at
runtime, though, contrary to build testing, not everybody will be able
to verify that you've actually done so. It is ultimately your platform
maintainer's (i.e. Heiko's) responsibility to ensure that because they
will get to deal with user complaints if people can't run an upstream
kernel on the devices.
I realize that the upstream kernel isn't what's going to end up in
products later on, but that doesn't change the fact that you're
submitting code for inclusion in the mainline tree. If you need to
backport code to some ChromeOS tree, then that should be done after
you've verified that things build and run upstream. Doing so makes life
a lot easier for your upstream maintainers, and that in turn makes it
more likely to get your code merged.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150902/7dc4ae84/attachment.sig>
[Bug 76559] screen corruption after going from VT to X
https://bugs.freedesktop.org/show_bug.cgi?id=76559 Fabio Pedretti changed: What|Removed |Added Attachment #118045|0 |1 is obsolete|| --- Comment #6 from Fabio Pedretti --- Created attachment 118051 --> https://bugs.freedesktop.org/attachment.cgi?id=118051&action=edit dmesg with 3.19.0-26-generic > Maybe some Mac firmware issue? Possibly, but I think that may not be related, as that doesnât always happen and maybe be a different issue. I attach a different dmesg where the crash doesn't happen, but the corruption problem is still present. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150902/0d875b9c/attachment.html>
[RFC] Docs: drm: Move KMS properties table out to source files
On Wed, 02 Sep 2015, Graham Whaley wrote: > Documentation/DocBook/drm.tmpl | 925 > + > drivers/gpu/drm/drm_crtc.c | 16 + > 2 files changed, 17 insertions(+), 924 deletions(-) I like this already. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
[PATCH] scripts/kernel-doc: Improve Markdown results
On Tue, 1 Sep 2015 14:57:33 -0300 Danilo Cesar Lemes de Paula wrote: > Did you find time to check this patch? As you mentioned that you applied > the Markdown support for the linux-next tree, this patch might be needed > (maybe "wanted" is a better word). Not quite what I said...I said I'd apply it right after the merge window so it can sit in linux-next through the full cycle. It's a bit early to be pushing 4.4 stuff into linux-next now... Beyond that, I wasn't sure where things stand with fixes... Can you send me a new patch set with this fix (and any others that might exist) integrated in? Thanks, jon
[GIT PULL] exynos-drm-next
Hi Dave, This is a last pull request, which includes two g2d patches I missed, and more cleanup series of Exynos drm driver. The cleanup series makes Exynos drm driver more simple, and removes unnecessary codes, and considers multiple plane format of framebuffer. I hope this not to be late. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 879a37d00f1882b1e56a66e626af4194d592d257: Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next (2015-08-31 10:25:45 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git exynos-drm-next for you to fetch changes up to c3058579a2882bb4bb6bf1ab0fe65f5ed070e530: drm/exynos: remove buf_cnt from struct exynos_drm_fb (2015-09-02 23:10:34 +0900) Joonyoung Shim (9): drm/exynos: remove exynos_drm_fb_set_buf_cnt() drm/exynos: s/exynos_gem_obj/obj in exynos_drm_fbdev.c drm/exynos: cleanup exynos_drm_fbdev_update() drm/exynos: update fb_info via only one function drm/exynos: cleanup to get gem object for fb drm/exynos: update exynos_drm_framebuffer_init() for multiple buffers drm/exynos: cleanup exynos_user_fb_create() drm/exynos: remove exynos_drm_fb_get_buf_cnt() drm/exynos: remove buf_cnt from struct exynos_drm_fb Tobias Jakobi (2): drm/exynos: fix size check in g2d_check_buf_desc_is_valid() drm/exynos: remove superfluous checks in g2d_check_reg_offset() drivers/gpu/drm/exynos/exynos_drm_fb.c| 115 + drivers/gpu/drm/exynos/exynos_drm_fb.h| 12 +-- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 78 --- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 59 ++- drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +- 5 files changed, 110 insertions(+), 156 deletions(-)
[PATCH 1/2] drm/atomic: Make prepare_fb/cleanup_fb only take state, v3.
On 2 September 2015 at 09:42, Maarten Lankhorst wrote: > This removes the need to separately track fb changes i915. > That will be done as a separate commit, however. > > Changes since v1: > - Add dri-devel to cc. > - Fix a check in intel's prepare and cleanup fb to take rotation > into account. > Changes since v2: > - Split out i915 changes to a separate commit. > > Cc: dri-devel at lists.freedesktop.org > Signed-off-by: Maarten Lankhorst I'd probably prefer to see the change to call them unconditionally (regardless of fb != NULL) in a separate patch, but with or without: Reviewed-by: Daniel Stone Cheers, Daniel
[PATCH 1/2] drm/atomic: Make prepare_fb/cleanup_fb only take state, v3.
On Wed, Sep 02, 2015 at 03:36:33PM +0100, Daniel Stone wrote: > On 2 September 2015 at 09:42, Maarten Lankhorst > wrote: > > This removes the need to separately track fb changes i915. > > That will be done as a separate commit, however. > > > > Changes since v1: > > - Add dri-devel to cc. > > - Fix a check in intel's prepare and cleanup fb to take rotation > > into account. > > Changes since v2: > > - Split out i915 changes to a separate commit. > > > > Cc: dri-devel at lists.freedesktop.org > > Signed-off-by: Maarten Lankhorst > > I'd probably prefer to see the change to call them unconditionally > (regardless of fb != NULL) in a separate patch, but with or without: > Reviewed-by: Daniel Stone Applied to drm-misc, thanks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[RFC] Docs: drm: Move KMS properties table out to source files
On Wed, Sep 02, 2015 at 05:14:35PM +0300, Jani Nikula wrote: > On Wed, 02 Sep 2015, Graham Whaley wrote: > > Documentation/DocBook/drm.tmpl | 925 > > + > > drivers/gpu/drm/drm_crtc.c | 16 + > > 2 files changed, 17 insertions(+), 924 deletions(-) > > I like this already. Well the patch removes the entire table but only adds the entry for rotation property. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[RFC] Docs: drm: Move KMS properties table out to source files
On Wed, Sep 02, 2015 at 02:50:52PM +0100, Graham Whaley wrote:
> (RFC/test - not for merging)
> The below is a test of moving the large HTML KMS properties table out
> to markdown style in the appropriate files.
> In the test we only use the first few rows of the existing KMS table
> an example.
> We use a fixed width table as the other styles of table supported by
> pandoc markdown do not support multi-column cells.
>
> The test shows a couple of issues:
> 1) double quote characters are being expanded in the fixed width table
> which then breaks the table alignment and leaves html style tags
> in the text
>
> 2) Cramming the seven columns into the apprx 80ish column width makes
> some entries fairly impractical - one word per row. For reference,
> pdfdocs rendering clips the fixed text tables at around 80 characters.
>
> If we can:
> a) Resolve (1) above
> and
> b) Agree that we are OK with comment fields extending beyond the 80th
> column significantly
>
> then maybe we can continue looking at moving the KMS properties table out
> of drm.tmpl and into markdown format fragments in the source files.
> If not, then maybe we go back to considering the conversion of the KMS
> table to docbook CALS format.
Another option would be to split up the table into sub-tables - the first
1-2 rows are really just headings for sub-tables imo. If we split them up
we have tables without spans and that could use the markdown table layout
instead of fixed-width text.
But then we'd need to do that part-by-part ...
-Daniel
> ---
> Documentation/DocBook/drm.tmpl | 925
> +
> drivers/gpu/drm/drm_crtc.c | 16 +
> 2 files changed, 17 insertions(+), 924 deletions(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 66bc646..ecfd084 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2573,930 +2573,7 @@ void intel_crt_init(struct drm_device *dev)
> The following table gives description of drm properties exposed by
> various
> modules/drivers.
>
> -
> -
> -
> - Owner Module/Drivers
> - Group
> - Property Name
> - Type
> - Property Values
> - Object attached
> - Description/Restrictions
> -
> -
> - DRM
> - Generic
> - ârotationâ
> - BITMASK
> - { 0, "rotate-0" },
> - { 1, "rotate-90" },
> - { 2, "rotate-180" },
> - { 3, "rotate-270" },
> - { 4, "reflect-x" },
> - { 5, "reflect-y" }
> - CRTC, Plane
> - rotate-(degrees) rotates the image by the specified
> amount in degrees
> - in counter clockwise direction. reflect-x and reflect-y reflects the
> - image along the specified axis prior to rotation
> -
> -
> - Connector
> - âEDIDâ
> - BLOB | IMMUTABLE
> - 0
> - Connector
> - Contains id of edid blob ptr object.
> -
> -
> - âDPMSâ
> - ENUM
> - { âOnâ, âStandbyâ, âSuspendâ, âOffâ
> }
> - Connector
> - Contains DPMS operation mode value.
> -
> -
> - âPATHâ
> - BLOB | IMMUTABLE
> - 0
> - Connector
> - Contains topology path to a connector.
> -
> -
> - âTILEâ
> - BLOB | IMMUTABLE
> - 0
> - Connector
> - Contains tiling information for a connector.
> -
> -
> - âCRTC_IDâ
> - OBJECT
> - DRM_MODE_OBJECT_CRTC
> - Connector
> - CRTC that connector is attached to (atomic)
> -
> -
> - Plane
> - âtypeâ
> - ENUM | IMMUTABLE
> - { "Overlay", "Primary", "Cursor" }
> - Plane
> - Plane type
> -
> -
> - âSRC_Xâ
> - RANGE
> - Min=0, Max=UINT_MAX
> - Plane
> - Scanout source x coordinate in 16.16 fixed point
> (atomic)
> -
> -
> - âSRC_Yâ
> - RANGE
> - Min=0, Max=UINT_MAX
> - Plane
> - Scanout source y coordinate in 16.16 fixed point
> (atomic)
> -
> -
> - âSRC_Wâ
> - RANGE
> - Min=0, Max=UINT_MAX
> - Plane
> - Scanout source width in 16.16 fixed point
> (atomic)
> -
> -
> - âSRC_Hâ
> - RANGE
> - Min=0, Max=UINT_MAX
> - Plane
> - Scanout source height in 16.16 fixed point
> (atomic)
> -
> -
> - âCRTC_Xâ
> - SIGNED_RANGE
> - Min=INT_MIN, Max=INT_MAX
> - Plane
> - Scanout CRTC (destination) x coordinate (atomic)
> -
> -
> - âCRTC_Yâ
> - SIGNED_RANGE
> - Min=INT_MIN, Max=INT_MAX
> - Plane
> - Scanout CRTC (destination) y coordinate (atomic)
> -
> -
> - âCRTC_Wâ
> - RANGE
> - Min=0, Max=UINT_MAX
> - Plane
> - Scanout CRTC (destination) width (atomic)
> -
> -
> - âCRTC_Hâ
> - RANGE
> - Min=0, Max=UINT_MAX
> - Plane
> - Scanout CRTC (destination) height (atomic)
> -
> -
> - âFB_IDâ
[RFC] Docs: drm: Move KMS properties table out to source files
(RFC/test - not for merging)
The below is a test of moving the large HTML KMS properties table out
to markdown style in the appropriate files.
In the test we only use the first few rows of the existing KMS table
an example.
We use a fixed width table as the other styles of table supported by
pandoc markdown do not support multi-column cells.
The test shows a couple of issues:
1) double quote characters are being expanded in the fixed width table
which then breaks the table alignment and leaves html style tags
in the text
2) Cramming the seven columns into the apprx 80ish column width makes
some entries fairly impractical - one word per row. For reference,
pdfdocs rendering clips the fixed text tables at around 80 characters.
If we can:
a) Resolve (1) above
and
b) Agree that we are OK with comment fields extending beyond the 80th
column significantly
then maybe we can continue looking at moving the KMS properties table out
of drm.tmpl and into markdown format fragments in the source files.
If not, then maybe we go back to considering the conversion of the KMS
table to docbook CALS format.
---
Documentation/DocBook/drm.tmpl | 925 +
drivers/gpu/drm/drm_crtc.c | 16 +
2 files changed, 17 insertions(+), 924 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 66bc646..ecfd084 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2573,930 +2573,7 @@ void intel_crt_init(struct drm_device *dev)
The following table gives description of drm properties exposed by
various
modules/drivers.
-
-
-
- Owner Module/Drivers
- Group
- Property Name
- Type
- Property Values
- Object attached
- Description/Restrictions
-
-
- DRM
- Generic
- ârotationâ
- BITMASK
- { 0, "rotate-0" },
- { 1, "rotate-90" },
- { 2, "rotate-180" },
- { 3, "rotate-270" },
- { 4, "reflect-x" },
- { 5, "reflect-y" }
- CRTC, Plane
- rotate-(degrees) rotates the image by the specified
amount in degrees
- in counter clockwise direction. reflect-x and reflect-y reflects the
- image along the specified axis prior to rotation
-
-
- Connector
- âEDIDâ
- BLOB | IMMUTABLE
- 0
- Connector
- Contains id of edid blob ptr object.
-
-
- âDPMSâ
- ENUM
- { âOnâ, âStandbyâ, âSuspendâ, âOffâ
}
- Connector
- Contains DPMS operation mode value.
-
-
- âPATHâ
- BLOB | IMMUTABLE
- 0
- Connector
- Contains topology path to a connector.
-
-
- âTILEâ
- BLOB | IMMUTABLE
- 0
- Connector
- Contains tiling information for a connector.
-
-
- âCRTC_IDâ
- OBJECT
- DRM_MODE_OBJECT_CRTC
- Connector
- CRTC that connector is attached to (atomic)
-
-
- Plane
- âtypeâ
- ENUM | IMMUTABLE
- { "Overlay", "Primary", "Cursor" }
- Plane
- Plane type
-
-
- âSRC_Xâ
- RANGE
- Min=0, Max=UINT_MAX
- Plane
- Scanout source x coordinate in 16.16 fixed point
(atomic)
-
-
- âSRC_Yâ
- RANGE
- Min=0, Max=UINT_MAX
- Plane
- Scanout source y coordinate in 16.16 fixed point
(atomic)
-
-
- âSRC_Wâ
- RANGE
- Min=0, Max=UINT_MAX
- Plane
- Scanout source width in 16.16 fixed point
(atomic)
-
-
- âSRC_Hâ
- RANGE
- Min=0, Max=UINT_MAX
- Plane
- Scanout source height in 16.16 fixed point
(atomic)
-
-
- âCRTC_Xâ
- SIGNED_RANGE
- Min=INT_MIN, Max=INT_MAX
- Plane
- Scanout CRTC (destination) x coordinate (atomic)
-
-
- âCRTC_Yâ
- SIGNED_RANGE
- Min=INT_MIN, Max=INT_MAX
- Plane
- Scanout CRTC (destination) y coordinate (atomic)
-
-
- âCRTC_Wâ
- RANGE
- Min=0, Max=UINT_MAX
- Plane
- Scanout CRTC (destination) width (atomic)
-
-
- âCRTC_Hâ
- RANGE
- Min=0, Max=UINT_MAX
- Plane
- Scanout CRTC (destination) height (atomic)
-
-
- âFB_IDâ
- OBJECT
- DRM_MODE_OBJECT_FB
- Plane
- Scanout framebuffer (atomic)
-
-
- âCRTC_IDâ
- OBJECT
- DRM_MODE_OBJECT_CRTC
- Plane
- CRTC that plane is attached to (atomic)
-
-
- DVI-I
- âsubconnectorâ
- ENUM
- { âUnknownâ, âDVI-Dâ, âDVI-Aâ }
- Connector
- TBD
-
-
- âselect subconnectorâ
- ENUM
-
[PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir
[Dropping the CC list] Hi Yakir Yang, On 1 September 2015 at 06:49, Yakir Yang wrote: > Split the dp core driver from exynos directory to bridge > directory, and rename the core driver to analogix_dp_*, > leave the platform code to analogix_dp-exynos. > > Signed-off-by: Yakir Yang > --- > Changes in v4: > - Take Rob suggest, update "analogix,hpd-gpios" to "hpd-gpios" DT propery. > - Take Jingoo suggest, rename "analogix_dp-exynos.c" file name to > "exynos_dp.c" > - Take Archit suggest, create a separate folder for analogix code in bridge/ > "Take X suggest", is grammatically incorrect. You should use "suggestion(s)" or alternatively use the following approach. - Create a separate folder for analogix code in bridge/ (Archit) Cheers, Emil P.S. Why do you resend the whole series (some 10+ patches) when only a few patches have been changed ? Are all the patches changed whist missing that information (vX: rebase on top of A)
[Intel-gfx] [PATCH 4/5] Documentation: drm: Convert KMS Properties HTML table to CALS
On Tue, 2015-09-01 at 14:56 -0300, Danilo Cesar Lemes de Paula wrote: > On 08/25/2015 01:10 PM, Graham Whaley wrote: > > On Tue, 2015-08-25 at 16:29 +0200, Daniel Vetter wrote: > > > On Tue, Aug 25, 2015 at 10:26:44AM +0100, Graham Whaley wrote: > > > > The KMS Properties table is in HTML format, which is not > > > > supported > > > > for building pdfdocs, resulting in the following types of > > > > errors: > > > > > > > > jade:/Documentation/DocBook/drm.xml:34413:15:E: there is no > > > > attribute > > > > "border" > > > > jade:/Documentation/DocBook/drm.xml:34413:31:E: there is no > > > > attribute > > > > "cellpadding" > > > > jade:/Documentation/DocBook/drm.xml:34413:47:E: there is no > > > > attribute > > > > "cellspacing" > > > > jade:/Documentation/DocBook/drm.xml:34414:7:E: document type > > > > does > > > > not > > > > allow element "tbody" here > > > > > > > > Convert the table over to a CALS format table > > > > > > Hm, long-term plan was to move this table into DOC: comments in > > > the > > > source-code using markdown, which we now have (at least in > > > drm-intel-nightly and also planned to be merged into 4.4). Since > > > this > > > is > > > both a lot of churn I'd like to get there in just 1 step ... > > > -Daniel > > First - I've just noted an erroneous debug comment (or two) left in > > this patch as well, so looks like I will have to re-issue the > > series > > anyway. > > > > OK. I guess this comes down to a matter of timing... > > From Danilos patch of: f6d6913 (drm/doc: Convert to markdown) > > we can see markdown does not natively support tables, and we'd have > > to > > make this a fixed width layout like the one in that patch I > > suspect. > > Danilo - any advice on how you did that other table conversion? I > > just > > did a pandoc docbook->markdown_github and it looks some way there - > > but > > of course seems to have not honored the multi-column items, of > > which > > there are a few. It's probably not too bad to fix up by hand - I'll > > see > > if I can get that to work... > > Hi Graham, > > To be honest I didn't have to do any conversion as that table was > already in the header file. I just added 4 spaces so it would be > transformed into fixed width. > > However, there's tool you can use to help you: http://pandoc.org/try/ > I did a lot of translation there. If your table doesn't have any > spancells, you can put the HTML code there and get the Markdown for > free. > > Danilo Hi, following this email should be an [RFC] patch with the subject: [RFC] Docs: drm: Move KMS properties table out to source files This is not a fix - it is an example to show that maybe this table does not migrate well to markdown. Danilo, if you have any thoughts about the 'quote expansion' detailed in the patch I'd be interested. Daniel, we should probably consider if moving this table to markdown will work out given the width of the table and the restrictions of having to use fixed width for multi-row markdown table representation. Graham
[Bug 100071] Crash on several PRIME radeon usage
https://bugzilla.kernel.org/show_bug.cgi?id=100071 higuita changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |OBSOLETE --- Comment #1 from higuita --- The problem disappeared with recent kernel or mesa updates, so closing -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 83319] [r600g] GPU lockup in gsraytrace (Mesa-demo-8.2.0) - RV730
https://bugs.freedesktop.org/show_bug.cgi?id=83319 Heiko changed: What|Removed |Added CC||lil_tux at web.de --- Comment #9 from Heiko --- Created attachment 118054 --> https://bugs.freedesktop.org/attachment.cgi?id=118054&action=edit kmsg: gsraytrace lockup on HD6850 Just noticed the problem today on my HD6850. Unfortunately, it doesn't come back to life all the time. That is either complete lockup (and reboot) or at least Xorg being hung in process state D and gsraytrace in state Z. Attached log produced, when hitting the latter one (though sysrq still worked and terminal after sysrq-r worked well). The lock contains some of the sysrq-show-xyz triggers, which are of help maybe (the blocked cat is from catting one of the radeon sysfs entries). Xorg log only shows event overflows. GPU hang seems to be 100% reproducable with gsraytrace for me. Software components being: media-libs/mesa- (git-4de86e1) sys-devel/llvm-3.6.2 sys-kernel/vanilla-sources-4.2.0 x11-libs/libdrm-2.4.64 options radeon audio=1 tv=0 dpm=1 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150902/43c65f16/attachment.html>
[PATCH 10/98] via_drm.h: hide struct via_file_private in userspace
On Wed, Jun 03, 2015 at 05:50:22PM +0100, Emil Velikov wrote:
> Hi Mikko,
>
> On 30 May 2015 at 16:38, Mikko Rapeli wrote:
> > Fixes compiler error since list_head is not exported to userspace headers.
> >
> > Signed-off-by: Mikko Rapeli
> > ---
> > include/uapi/drm/via_drm.h | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/include/uapi/drm/via_drm.h b/include/uapi/drm/via_drm.h
> > index 791531e..34ce658 100644
> > --- a/include/uapi/drm/via_drm.h
> > +++ b/include/uapi/drm/via_drm.h
> > @@ -272,8 +272,10 @@ typedef struct drm_via_dmablit {
> > drm_via_blitsync_t sync;
> > } drm_via_dmablit_t;
> >
> > +#ifdef __KERNEL__
> > struct via_file_private {
> > struct list_head obj_list;
> > };
> > +#endif
> >
> We might want to follow the example of other drivers (i915) and move
> it to drivers/gpu/drm/via_drv.h, There are two users of this struct
> (via_drv.c and via_mm.c), and each one explicitly includes the header.
> How does that sound ?
>
> Same suggestion goes for the equivalent sis patch.
Thanks, moved both of the file_private definitions to the driver headers.
-Mikko
[PATCH 10/14] exynos/fimg2d: remove default case from g2d_get_blend_op()
Hello Inki, Inki Dae wrote: > On 2015ë 09ì 01ì¼ 03:53, Emil Velikov wrote: >> On 31 August 2015 at 14:25, Inki Dae wrote: >>> On 2015ë 08ì 24ì¼ 23:14, Tobias Jakobi wrote: We now validate the blending mode via g2d_validate_mode() prior to feeding it to g2d_get_blend_op(). Signed-off-by: Tobias Jakobi --- exynos/exynos_fimg2d.c | 5 - 1 file changed, 5 deletions(-) diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c index 4274a94..d708e91 100644 --- a/exynos/exynos_fimg2d.c +++ b/exynos/exynos_fimg2d.c @@ -91,11 +91,6 @@ static unsigned int g2d_get_blend_op(enum e_g2d_op op) SET_BF(val, G2D_COEFF_MODE_SRC_ALPHA, 0, 0, 0, G2D_COEFF_MODE_SRC_ALPHA, 1, 0, 0); break; - default: - fprintf(stderr, "Not support operation(%d).\n", op); - SET_BF(val, G2D_COEFF_MODE_ONE, 0, 0, 0, G2D_COEFF_MODE_ZERO, - 0, 0, 0); - break; >>> >>> With this, how about changing above switch and case statement to if >>> statement? >>> >> Out of curiosity: why is if/else statement preferred - won't it make >> things longer/harder to read (there are 11 cases here) ? > > Just looks strange to me switch and case statement has no default > statement. This is just my opinion and trivial. I would like to keep the switch statement here. As Emil has pointed out the big advantage of switch is that the compiler can warn us if we're not dealing with a value of an enum. I think that's definitely a feature which we want here. I would suggest instead this: I add a short comment to the switch making clear why we don't have a default case here and that a user of g2d_get_blend_op() should first validate any data passed to it. With best wishes, Tobias > > Thanks, > Inki Dae > >> >> Cheers, >> Emil >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" >> in >> the body of a message to majordomo at vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >
[pull] radeon and amdgpu drm-next-4.3
Hi Dave, More fixes for radeon and amdgpu for 4.3: - Send full DP aux address fixes for radeon and amdgpu - Fix an HDMI display regression for pre-DCE5 parts - UVD suspend fixes for amdgpu - Add an rs480 suspend quirk - Fix bo reserve handling in amdgpu GEM_OP ioctl - GPU scheduler fixes - SDMA optimizations - MEC fix for Fiji The following changes since commit 92cffd56b21c825579f3b37bc7803e4c37073076: drm/nouveau/dispnv04: fix build on powerpc (2015-08-28 20:33:58 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.3 for you to fetch changes up to bddf8026386927985ef6d0d11c3ba78f70b76bad: drm/amdgpu: set MEC doorbell range for Fiji (2015-09-02 12:35:52 -0400) Alex Deucher (3): drm/radeon: fix HDMI quantization_range for pre-DCE5 asics drm/radeon/native: Send out the full AUX address drm/amdgpu/atom: Send out the full AUX address Christian König (6): drm/amdgpu: let the scheduler work more with jobs v2 drm/amdgpu: add scheduler dependency callback v2 drm/amdgpu: stop trying to suspend UVD sessions v2 drm/amdgpu: partially revert "modify amdgpu_fence_wait_any() to amdgpu_fence_wait_multiple()" v2 drm/amdgpu: fix amdgpu_bo_unreserve order in GEM_OP IOCTL v2 drm/amdgpu: use PT for VM sync on unmap Chunming Zhou (3): drm/amdgpu: use IB for fill_buffer instead of direct command drm/amdgpu: re-work sync_resv drm/amdgpu: make wait_event uninterruptible in push_job Jammy Zhou (7): drm/amdgpu: add count field for the SDMA NOP packet v2 drm/amdgpu: add burst_nop flag for sdma drm/amdgpu: add AMDGPU_MAX_SDMA_INSTANCES drm/amdgpu: add amdgpu_get_sdma_instance helper function drm/amdgpu: add insert_nop ring func and default implementation drm/amdgpu: implement burst NOP for SDMA drm/amdgpu: set MEC doorbell range for Fiji Jeffery Miller (1): Add radeon suspend/resume quirk for HP Compaq dc5750. Ville Syrjälä (1): drm/radeon/atom: Send out the full AUX address drivers/gpu/drm/amd/amdgpu/amdgpu.h| 41 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 44 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 24 +- drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c | 7 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 46 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c| 42 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 19 ++--- drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 3 +- drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 47 --- drivers/gpu/drm/amd/amdgpu/cikd.h | 1 + drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 2 + drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 5 +- drivers/gpu/drm/amd/amdgpu/iceland_sdma_pkt_open.h | 5 ++ drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 47 --- drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 46 --- drivers/gpu/drm/amd/amdgpu/tonga_sdma_pkt_open.h | 5 ++ drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c | 1 + drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c | 1 + drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 1 + drivers/gpu/drm/amd/amdgpu/vce_v2_0.c | 1 + drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 1 + drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 90 +++--- drivers/gpu/drm/amd/scheduler/gpu_scheduler.h | 3 + drivers/gpu/drm/radeon/atombios_dp.c | 5 +- drivers/gpu/drm/radeon/radeon_audio.c | 16 ++-- drivers/gpu/drm/radeon/radeon_combios.c| 8 ++ drivers/gpu/drm/radeon/radeon_dp_auxch.c | 4 +- 29 files changed, 360 insertions(+), 164 deletions(-)
[Bug 91790] TONGA hang in amdgpu_ring_lock
https://bugs.freedesktop.org/show_bug.cgi?id=91790 --- Comment #10 from Alex Deucher --- Created attachment 118056 --> https://bugs.freedesktop.org/attachment.cgi?id=118056&action=edit possible fix I think this patch should fix it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150902/0cb03ea3/attachment.html>
[PATCH libdrm] amdgpu: use EINVAL instead of EBADMSG in amdgpu_bo_cpu_unmap()
On Tue, Sep 1, 2015 at 9:07 AM, Christian König
wrote:
> On 01.09.2015 13:37, Jonathan Gray wrote:
>>
>> EBADMSG is a streams errno. OpenBSD does not implement streams and does
>> include the streams errnos, this commit fixes the build on OpenBSD.
>>
>> None of the callers of this function check the return value for -EBADMSG.
>>
>> Signed-off-by: Jonathan Gray
>
>
> Probably not intentional to use this error code here.
>
> Patch is Reviewed-by: Christian König
Pushed!
Alex
>
> Regards,
> Christian.
>
>> ---
>> amdgpu/amdgpu_bo.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
>> index 220422d..348da00 100644
>> --- a/amdgpu/amdgpu_bo.c
>> +++ b/amdgpu/amdgpu_bo.c
>> @@ -482,7 +482,7 @@ int amdgpu_bo_cpu_unmap(amdgpu_bo_handle bo)
>> if (bo->cpu_map_count == 0) {
>> /* not mapped */
>> pthread_mutex_unlock(&bo->cpu_access_mutex);
>> - return -EBADMSG;
>> + return -EINVAL;
>> }
>> bo->cpu_map_count--;
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 91790] TONGA hang in amdgpu_ring_lock
https://bugs.freedesktop.org/show_bug.cgi?id=91790 --- Comment #11 from Mathias Tillman --- (In reply to Alex Deucher from comment #10) > Created attachment 118056 [details] [review] > possible fix > > I think this patch should fix it. No luck here I'm afraid - I'm having a hard time reproducing it during normal desktop usage (with or without the patch), but it did lockup while running Unigine Valley. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150902/f001a74f/attachment.html>
[PATCH v3 2/2] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
On Wed, Sep 02, 2015 at 03:07:49PM -0700, Doug Anderson wrote:
> Hi,
>
> On Sun, Aug 30, 2015 at 2:34 PM, Vladimir Zapolskiy
> wrote:
> > +static struct i2c_adapter *dw_hdmi_i2c_adapter(struct dw_hdmi *hdmi)
> > +{
> > + struct i2c_adapter *adap;
> > + struct dw_hdmi_i2c *i2c;
> > + int ret;
> > +
> > + i2c = devm_kzalloc(hdmi->dev, sizeof(*i2c), GFP_KERNEL);
> > + if (!i2c)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + mutex_init(&i2c->lock);
> > + init_completion(&i2c->cmp);
> > +
> > + adap = &i2c->adap;
> > + adap->class = I2C_CLASS_DDC;
> > + adap->owner = THIS_MODULE;
> > + adap->dev.parent = hdmi->dev;
>
> I think you may want to add "adap->dev.of_node = hdmi->dev->of_node;"
> here. That will allow device trees to specify the i2c bus by using an
> alias.
Never copy the of_node from one device to another. That allows the
bus matching to unintentionally match the of_node against the wrong
driver.
Also, is it appropriate to hook non-DDC devices to a DDC bus? I suspect
that's asking for trouble.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
[Bug 95911] Recursive error in radeon device driver module after resume from hibernation
https://bugzilla.kernel.org/show_bug.cgi?id=95911
--- Comment #23 from gitne at excite.co.jp ---
(In reply to Alex Deucher from comment #20)
> Does this help?
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 5751446..1b4ac44 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -435,14 +435,14 @@ static int radeon_pmops_freeze(struct device *dev)
> {
> struct pci_dev *pdev = to_pci_dev(dev);
> struct drm_device *drm_dev = pci_get_drvdata(pdev);
> - return radeon_suspend_kms(drm_dev, false, true);
> + return radeon_suspend_kms(drm_dev, true, true);
> }
>
> static int radeon_pmops_thaw(struct device *dev)
> {
> struct pci_dev *pdev = to_pci_dev(dev);
> struct drm_device *drm_dev = pci_get_drvdata(pdev);
> - return radeon_resume_kms(drm_dev, false, true);
> + return radeon_resume_kms(drm_dev, true, true);
> }
>
> static int radeon_pmops_runtime_suspend(struct device *dev)
Thank you for digging into this. Again, I do not have the capacity to build a
Linux kernel. Could you do this for me? Then, I could also test it on my older
machine, which could potentially greatly improve support for many other
machines at the same time.
So far, radeon.msi=0 works for me as a workaround. I do not know how much of a
performance penalty this incurs but things seem to work smoothly. To quantify
any penalty, some exact measurements are required. However, since radeon.msi=1
does not work smoothly, it is going to be difficult to assess any quantifiable
results (and be able to compare them to radeon.msi=0) in this case. Can you
give me a hint as to what benchmarks I could/should run?
--
You are receiving this mail because:
You are watching the assignee of the bug.
[PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
On Tue, Sep 1, 2015 at 1:14 AM, Yakir Yang wrote:
> Some edp screen do not have hpd signal, so we can't just return
> failed when hpd plug in detect failed.
This is a property of the panel (or connector perhaps), so this
property should be located there. At least, it is a common issue and
not specific to this chip. We could have an HDMI connector and failed
to hook up HPD for example. A connector node is also where hpd-gpios
should be located instead (and are already defined by
../bindings/video/hdmi-connector.txt). Perhaps we need a eDP connector
binding, too.
Are there any eDP panels which don't have EDID and need panel details in DT?
Rob
> This is an hardware property, so we need add a devicetree property
> "analogix,need-force-hpd" to indicate this sutiation.
>
> Signed-off-by: Yakir Yang
> ---
> Changes in v4: None
> Changes in v3:
> - Add "analogix,need-force-hpd" to indicate whether driver need foce
> hpd when hpd detect failed.
>
> Changes in v2: None
>
> .../devicetree/bindings/drm/bridge/analogix_dp.txt | 4 ++-
> .../bindings/video/analogix_dp-rockchip.txt| 1 +
> .../devicetree/bindings/video/exynos_dp.txt| 1 +
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 36
> +++---
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 ++
> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 9 ++
> 6 files changed, 47 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
> b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
> index f54dc3e..c310367 100644
> --- a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
> +++ b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
> @@ -22,6 +22,9 @@ Required properties for dp-controller:
> from general PHY binding: Should be "dp".
>
> Optional properties for dp-controller:
> + -analogix,need-force-hpd:
> + Indicate driver need force hpd when hpd detect failed, this
> + is used for some eDP screen which don't have hpd signal.
> -hpd-gpios:
> Hotplug detect GPIO.
> Indicates which GPIO should be used for hotplug detection
> @@ -31,7 +34,6 @@ Optional properties for dp-controller:
> * Documentation/devicetree/bindings/video/exynos_dp.txt
> *
> Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
>
> -
> [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>
> ---
>
> diff --git a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
> b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
> index 502483e..8b9ed7d 100644
> --- a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
> +++ b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
> @@ -28,6 +28,7 @@ For the below properties, please refer to Analogix DP
> binding document:
> - phys (required)
> - phy-names (required)
> - hpd-gpios (optional)
> +- analogix,need-force-hpd (optional)
>
> ---
>
> Example:
> diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
> b/Documentation/devicetree/bindings/video/exynos_dp.txt
> index ea03b3a..4f06e80 100644
> --- a/Documentation/devicetree/bindings/video/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
> @@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP
> binding document:
> -phys (required)
> -phy-names (required)
> -hpd-gpios (optional)
> + -analogix,need-force-hpd (optional)
> -video interfaces (optional)
>
> Deprecated properties for DisplayPort:
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index f7227ec..e6b328a 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -63,15 +63,38 @@ static int analogix_dp_detect_hpd(struct
> analogix_dp_device *dp)
> {
> int timeout_loop = 0;
>
> - while (analogix_dp_get_plug_in_status(dp) != 0) {
> + while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
> + if (analogix_dp_get_plug_in_status(dp) == 0)
> + return 0;
> +
> timeout_loop++;
> - if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
> - dev_err(dp->dev, "failed to get hpd plug status\n");
> - return -ETIMEDOUT;
> - }
> usleep_range(10, 11);
> }
>
> + /*
> +* Some edp screen do not have hpd signal, so we can't just
> +* return failed when hpd plug in detect failed, DT property
> +* "need-force-hpd" would indicate whether driver need this.
>
[PATCH v3 2/2] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
Hi,
On Sun, Aug 30, 2015 at 2:34 PM, Vladimir Zapolskiy
wrote:
> +static struct i2c_adapter *dw_hdmi_i2c_adapter(struct dw_hdmi *hdmi)
> +{
> + struct i2c_adapter *adap;
> + struct dw_hdmi_i2c *i2c;
> + int ret;
> +
> + i2c = devm_kzalloc(hdmi->dev, sizeof(*i2c), GFP_KERNEL);
> + if (!i2c)
> + return ERR_PTR(-ENOMEM);
> +
> + mutex_init(&i2c->lock);
> + init_completion(&i2c->cmp);
> +
> + adap = &i2c->adap;
> + adap->class = I2C_CLASS_DDC;
> + adap->owner = THIS_MODULE;
> + adap->dev.parent = hdmi->dev;
I think you may want to add "adap->dev.of_node = hdmi->dev->of_node;"
here. That will allow device trees to specify the i2c bus by using an
alias.
See
[PATCH v3 2/2] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
Russell, On Wed, Sep 2, 2015 at 3:50 PM, Russell King - ARM Linux wrote: >> I think you may want to add "adap->dev.of_node = hdmi->dev->of_node;" >> here. That will allow device trees to specify the i2c bus by using an >> alias. > > Never copy the of_node from one device to another. That allows the > bus matching to unintentionally match the of_node against the wrong > driver. So does that mean we need to create a sub-node for the i2c bus if we want something like this? > Also, is it appropriate to hook non-DDC devices to a DDC bus? I suspect > that's asking for trouble. I doubt it's appropriate. Why do you ask? -Doug
[PATCH v3 2/2] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
Russell, On Wed, Sep 2, 2015 at 3:50 PM, Russell King - ARM Linux wrote: > Never copy the of_node from one device to another. That allows the > bus matching to unintentionally match the of_node against the wrong > driver. Can you be more specific about what problems you'd expect. It seems like a terribly common practice to do this, but maybe I'm misunderstanding: On today's next, I do a simple: git grep 'dev.of_node = ' ...and I find lots of hits: drivers/i2c/busses/i2c-at91.c: dev->adapter.dev.of_node = pdev->dev.of_node; drivers/i2c/busses/i2c-axxia.c: idev->adapter.dev.of_node = pdev->dev.of_node; drivers/i2c/busses/i2c-bcm-iproc.c: adap->dev.of_node = pdev->dev.of_node; drivers/i2c/busses/i2c-bcm-kona.c: adap->dev.of_node = pdev->dev.of_node; drivers/i2c/busses/i2c-bcm2835.c: adap->dev.of_node = pdev->dev.of_node; drivers/i2c/busses/i2c-brcmstb.c: adap->dev.of_node = pdev->dev.of_node; ... So unless I'm mistaken, the code I'm suggesting is a common practice. Perhaps there is a latent bug that's waiting to bite us. If so then that bug should be reported and fixed. ...but without seeing some concrete problem (or some reason that the code I'm suggesting is different than everyone else's code) it seems best to take it and to later fix it (along with all the other code) if/when we find some problem. Objections? -Doug
[PATCH v3 2/2] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
Russell,
On Wed, Sep 2, 2015 at 4:04 PM, Russell King - ARM Linux
wrote:
>> > Also, is it appropriate to hook non-DDC devices to a DDC bus? I suspect
>> > that's asking for trouble.
>>
>> I doubt it's appropriate. Why do you ask?
>
> To find out why you want to "specify the I2C bus".
>
> Surely if we're talking about the DDC bus, we either want to use a
> separate I2C bus (in which case the HDMI DT description needs to
> specify which I2C bus to use) or we want to use the HDMI-internal
> I2C bus, which being part of the HDMI driver, the HDMI driver will
> know how to find it itself - there should be no need to put an
> explicit ddc-i2c-bus self-reference there in that case.
Overall it comes down to bus numbering. Possibly that's a stupid
reason, but it is my reason nevertheless.
Specifically it significantly helps my brain process kernel log
messages if the i2c bus that's referred to "bus 5" in my SoC's user
manual shows up consistently as "i2c5" in kernel log messages. It's
helpful it it shows up as "i2c5" even if "i2c0" - "i2c4" aren't
enabled.
That's all totally possible by using this type of syntax, like in rk3288.dtsi:
aliases {
i2c0 = &i2c0;
i2c1 = &i2c1;
i2c2 = &i2c2;
i2c3 = &i2c3;
i2c4 = &i2c4;
i2c5 = &i2c5;
Similarly, I'd like "bus 0" to show up as i2c0, which will happen as
you can see in the above.
The problem is that if another bus registers itself before the SoC's
i2c0 registers itself and that bus doesn't give a number to itself
then the i2c subsystem will chose "I2C 0". ...and then when the main
SoC i2c bus registers itself it will fail because i2c0 is already
taken.
By having a of_node for the hdmi i2c bus, we can assign a number to it like:
i2c15 = &hdmi;
This is all described in the two links I referenced in my original reply.
A possible other option is to have the i2c subsystem try to start
numbering at a larger base for all automatically numbered busses
(those that didn't specify a number). Then it's more likely (though
still not guaranteed) to conflict with another bus...
-Doug
[PATCH v4 01/16] drm: exynos/dp: fix code style
On Thu, 2015-09-03 at 13:33 +0800, Yakir Yang wrote:
[]
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
[]
> @@ -155,24 +156,22 @@ static int exynos_dp_read_edid(struct
> exynos_dp_device *dp)
> }
> exynos_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
> -&test_vector);
> + &test_vector);
> if (test_vector & DP_TEST_LINK_EDID_READ) {
> -exynos_dp_write_byte_to_dpcd(dp,
> -DP_TEST_EDID_CHECKSUM,
> +exynos_dp_write_byte_to_dpcd(
> +dp, DP_TEST_EDID_CHECKSUM,
> edid[EDID_BLOCK_LENGTH + EDID_CHECKSUM]);
> -exynos_dp_write_byte_to_dpcd(dp,
> -DP_TEST_RESPONSE,
> +exynos_dp_write_byte_to_dpcd(
> +dp, DP_TEST_RESPONSE,
> DP_TEST_EDID_CHECKSUM_WRITE);
> >>> To me, missing argument after opening parenthesis, looks worse. I would
> >>> prefer:
> >>>
> >>> exynos_dp_write_byte_to_dpcd(dp,
> >>>
> >>> Why you moved the 'dp' argument to new line?
> >> Hmm... Just like style tool indicate, no more warning after
> >> that change.
> >>
> >> For now, I would like to follow the original style, just improved
> >> some obvious style problem. :-)
> > What was the checkpatch warning that said 'dp' has to move to new line?
> > I tried this and I don't see it.
>
> checkpatch haven't remind me that put dp to new line would fix
> this warning, this just come from my experiments. And I works,
> no more warnings from checkpatch, so I toke this style.
Checkpatch isn't a great arbiter of style.
It's just a brainless tool.
Always use your instead of anything brainless.
If it were code I was writing, I'd ignore 80 columns warnings
where appropriate.
These are long function names and long macro defines, so it's
inappropriate to use 80 columns as a guiding style.
I'd write:
exynos_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
&test_vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
exynos_dp_write_byte_to_dpcd(dp, DP_TEST_EDID_CHECKSUM,
edid[EDID_BLOCK_LENGTH +
EDID_CHECKSUM]);
exynos_dp_write_byte_to_dpcd(dp, DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
}
