[Bug 77009] 24P playback video signal loss with latest DRI patches
https://bugs.freedesktop.org/show_bug.cgi?id=77009 --- Comment #11 from Garrett --- Created attachment 96963 --> https://bugs.freedesktop.org/attachment.cgi?id=96963&action=edit patch that breaks by 23.98 playback file removed -> built then ok. -- 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/20140405/ba485cd1/attachment.html>
[Bug 77009] 24P playback video signal loss with latest DRI patches
https://bugs.freedesktop.org/show_bug.cgi?id=77009 --- Comment #10 from Garrett --- Created attachment 96962 --> https://bugs.freedesktop.org/attachment.cgi?id=96962&action=edit xrandr 1920x1080x23.98 working 76564 removed OK. I finally got the patch removed and rebuilt (thanks to Peter's tips). Xrandr 23.98 now works as expected. No blank screen: [ 99.956862] [drm:radeon_compute_pll_avivo], 14818, pll dividers - fb: 32.6 ref: 2, post 11 With the patch "linux-996-drm-radeon-rework-finding-display-PLL-numbers.patch" it failed. I will upload this patch, that I removed from the source folder. I tried the 3 line patch x2, when it was present but I am not sure it took (built to fast to see on the screen). So I will add the 3 changes to non-working patch and rebuild, next. and dmesg it for pll vals. -- 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/20140405/a264766e/attachment.html>
[Bug 75234] UVD initialization fails while dGPU is powered on by DRI_PRIME
https://bugs.freedesktop.org/show_bug.cgi?id=75234 --- Comment #6 from Hohahiu --- The bug is still present in Kernel 3.14.0. -- 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/20140405/a38c849e/attachment.html>
[Bug 77002] problems with kernel 3.14
https://bugs.freedesktop.org/show_bug.cgi?id=77002 --- Comment #9 from bgunteriv at gmail.com --- does the information i gave you help? or do you need further explanation? -- 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/20140405/b108b333/attachment.html>
[PATCH] drm/omap: fix plane rotation
Plane rotation with omapdrm is currently broken.
It seems omap_plane_mode_set() expects width and height in screen
coordinates, so pass it like that.
Cc: Rob Clark
Signed-off-by: Grazvydas Ignotas
---
drivers/gpu/drm/omapdrm/omap_plane.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 370580c..5611f15 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -253,6 +253,14 @@ static int omap_plane_update(struct drm_plane *plane,
drm_framebuffer_reference(fb);
+ /* omap_plane_mode_set() takes adjusted src */
+ switch (omap_plane->win.rotation & 0xf) {
+ case BIT(DRM_ROTATE_90):
+ case BIT(DRM_ROTATE_270):
+ swap(src_w, src_h);
+ break;
+ }
+
return omap_plane_mode_set(plane, crtc, fb,
crtc_x, crtc_y, crtc_w, crtc_h,
src_x, src_y, src_w, src_h,
--
1.7.9.5
[PATCH v2 1/7] drm/exynos: add super device support
On 05.04.2014 20:52, Russell King - ARM Linux wrote: > On Sat, Apr 05, 2014 at 08:31:15PM +0200, Tomasz Figa wrote: >> Maybe my words have been misinterpreted, but all I'm suggesting here is >> that there is no need to add any new data to DT to solve the same issue >> to the same extent as componentized subsystem framework, at least in >> Exynos case. > > Right, so we seem to have agreement that what exynos is currently doing > is fundamentally broken. > > So the next question is, how is it going to get fixed? > I believe this is a separate issue from what is being discussed in this thread, but anyway, I'd wait with this until Monday, so we could discuss this with Inki and Andrzej, who is the person responsible for Exynos DRM in my team. I was just passing by. ;) Best regards, Tomasz
[PATCH v2 1/7] drm/exynos: add super device support
On 05.04.2014 20:24, Russell King - ARM Linux wrote:
> On Sat, Apr 05, 2014 at 07:32:50PM +0200, Tomasz Figa wrote:
>> Not exactly. The approach we found does mostly the same as componentized
>> subsystem framework but without _any_ extra data in Device Tree. Just
>> based on the list of subsystem sub-drivers that is already available to
>> the master driver.
>
> The existing approach is fundamentally broken. Yes, your solution may
> work for the probing case, but have you tried unbinding any of your
> sub-drivers?
>
> From what I can see, that causes a kernel oops for one very simple reason -
> you destroy stuff while it's still in use. Let's look at an example:
>
> struct platform_driver ipp_driver = {
> .probe = ipp_probe,
> .remove = ipp_remove,
> .driver = {
> .name = "exynos-drm-ipp",
> .owner = THIS_MODULE,
> .pm = &ipp_pm_ops,
> },
> };
>
> static int ipp_remove(struct platform_device *pdev)
> {
> struct ipp_context *ctx = platform_get_drvdata(pdev);
>
> /* unregister sub driver */
> exynos_drm_subdrv_unregister(&ctx->subdrv);
>
> /* remove,destroy ipp idr */
> idr_destroy(&ctx->ipp_idr);
> idr_destroy(&ctx->prop_idr);
>
> mutex_destroy(&ctx->ipp_lock);
> mutex_destroy(&ctx->prop_lock);
>
> /* destroy command, event work queue */
> destroy_workqueue(ctx->cmd_workq);
> destroy_workqueue(ctx->event_workq);
>
> return 0;
> }
>
> int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv *subdrv)
> {
> if (!subdrv)
> return -EINVAL;
>
> list_del(&subdrv->list);
>
> return 0;
> }
>
> Oh dear, that destroys a whole pile of resources which could already
> be in use without telling anything that it's about to do that.
>
> I'm sure if I continue looking at the exynos stuff, it'll show similar
> crap all over the place.
>
> What you have now in mainline is not a solution. It's a crappy bodge.
>
Undoubtedly. Nobody here is trying to state the opposite.
Maybe my words have been misinterpreted, but all I'm suggesting here is
that there is no need to add any new data to DT to solve the same issue
to the same extent as componentized subsystem framework, at least in
Exynos case.
Best regards,
Tomasz
[PATCH v2 1/7] drm/exynos: add super device support
On Sat, Apr 05, 2014 at 08:31:15PM +0200, Tomasz Figa wrote: > Maybe my words have been misinterpreted, but all I'm suggesting here is > that there is no need to add any new data to DT to solve the same issue > to the same extent as componentized subsystem framework, at least in > Exynos case. Right, so we seem to have agreement that what exynos is currently doing is fundamentally broken. So the next question is, how is it going to get fixed? -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.
[PATCH v2 1/7] drm/exynos: add super device support
[adding more people and MLs on Cc for further discussion]
On 04.04.2014 17:44, Inki Dae wrote:
> 2014-04-04 22:55 GMT+09:00 Tomasz Figa :
>> Hi Inki,
>>
>>
>> On 01.04.2014 14:37, Inki Dae wrote:
>>>
>>> This patch adds super device support to bind sub drivers
>>> using device tree.
>>>
>>> For this, you should add a super device node to each machine dt files
>>> like belows,
>>>
>>> In case of using MIPI-DSI,
>>> display-subsystem {
>>> compatible = "samsung,exynos-display-subsystem";
>>> ports = <&fimd>, <&dsi>;
>>> };
>>>
>>> In case of using DisplayPort,
>>> display-subsystem {
>>> compatible = "samsung,exynos-display-subsystem";
>>> ports = <&fimd>, <&dp>;
>>> };
>>>
>>> In case of using Parallel panel,
>>> display-subsystem {
>>> compatible = "samsung,exynos-display-subsystem";
>>> ports = <&fimd>;
>>> };
>>>
>>> And if you don't add connector device node to ports property,
>>> default parallel panel driver, exynos_drm_dpi module, will be used.
>>>
>>> ports property can have the following device nodes,
>>> fimd, mixer, Image Enhancer, MIPI-DSI, eDP, LVDS Bridge, or HDMI
>>>
>>> With this patch, we can resolve the probing order issue without
>>> some global lists. So this patch also removes the unnecessary lists and
>>> stuff related to these lists.
>>
>>
>> I can see several problems with this approach:
>>
>> 1) It breaks compatibility with existing DT. After this patch it is no
>> longer possible to use old device trees and get a working DRM. However, in
>> my opinion, this requirement can be relaxed if we make sure that any users
>> are properly converted.
>>
>> 2) What happens if in Kconfig you disable a driver for a component that is
>
> I'm not sure what you meant but there wouldn't be no way that users
> *cannot disable* the driver for a component. The driver would be
> exynos_drm_drv, not separated module, and would always be built as
> long as users want to use *exynos drm driver*.
I think you don't understand what I mean. Let me show you an example:
You have a board with a DSI panel and also a HDMI output. So you have a
supernode pointing to FIMD, DSI and HDMI.
Now, an user finds that he doesn't need HDMI in his system, so he turns
off CONFIG_DRM_EXYNOS_HDMI. The supernode still points at hdmi node and
Exynos DRM core will register it as a component, but HDMI driver is not
available and will never probe, leading the whole Exynos DRM to never
initialize. Is this a desired behavior?
>
>> listed in supernode? If I'm reading the code correctly, Exynos DRM will not
>
> And the only case a component isn't added to the list is when users
> disabled sub driver.
See above.
The code creating the list of components to wait for
(exynos_drm_add_components()) doesn't seem to consider which sub-drivers
are actually enabled in kernel config.
>> register, which is completely wrong. Users should be able to select which
>> drivers should be compiled into their kernels.
>
> So users are be able to select drivers they want to use, and will be
> compiled correctly. So no, the only thing users can disable is each
> sub driver, not core module.
>
>>
>> 3) Such approach leads to complete integration of all Exynos DRM drivers,
>> without possibility of loading some sub-drivers as modules. I know that
>> current driver design doesn't support it either, but if this series is
>
> No, current drm driver *must also be built* as one integrated single
> drm driver without super device approach.
As I wrote, I know that current design before this patch isn't modular
either, but this is not my concern here. See below.
> So the super device approach
> *has no any effect on existing design*, and what the super device
> approch tries to do is to resolve the probe order issue to sub drivers
> *without some codes specific to Exynos drm*.
My concern is that the supernode design is actually carving such broken
non-modular design in stone. Remember that we are currently heading
towards a fully multi-platform kernel where it is critical for such
subsystems to be modular, because the same zImage is going to be running
on completely different machines.
>
>> claimed to improve things, it should really do so.
>>
>> 4) Exactly the same can be achieved without changing the DT bindings at all.
>> In fact even without adding any new single property or node to DT. We
>> discussed this with Andrzej and Marek today and came to a solution in which
>> just by adding a little bit of code to Exynos DRM subdrivers, you could
>> guarantee correct registration of Exynos DRM platform and also get rid of
>> #ifdeffery in exynos_drm_drv.c. Andrzej will send an RFC after the weekend.
>
> I'm not sure but I had implemented below prototype codes for that, see
> the below link,
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-bridge-te
[PATCH v2 1/7] drm/exynos: add super device support
On Sat, Apr 05, 2014 at 07:32:50PM +0200, Tomasz Figa wrote:
> Not exactly. The approach we found does mostly the same as componentized
> subsystem framework but without _any_ extra data in Device Tree. Just
> based on the list of subsystem sub-drivers that is already available to
> the master driver.
The existing approach is fundamentally broken. Yes, your solution may
work for the probing case, but have you tried unbinding any of your
sub-drivers?
>From what I can see, that causes a kernel oops for one very simple reason -
you destroy stuff while it's still in use. Let's look at an example:
struct platform_driver ipp_driver = {
.probe = ipp_probe,
.remove = ipp_remove,
.driver = {
.name = "exynos-drm-ipp",
.owner = THIS_MODULE,
.pm = &ipp_pm_ops,
},
};
static int ipp_remove(struct platform_device *pdev)
{
struct ipp_context *ctx = platform_get_drvdata(pdev);
/* unregister sub driver */
exynos_drm_subdrv_unregister(&ctx->subdrv);
/* remove,destroy ipp idr */
idr_destroy(&ctx->ipp_idr);
idr_destroy(&ctx->prop_idr);
mutex_destroy(&ctx->ipp_lock);
mutex_destroy(&ctx->prop_lock);
/* destroy command, event work queue */
destroy_workqueue(ctx->cmd_workq);
destroy_workqueue(ctx->event_workq);
return 0;
}
int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv *subdrv)
{
if (!subdrv)
return -EINVAL;
list_del(&subdrv->list);
return 0;
}
Oh dear, that destroys a whole pile of resources which could already
be in use without telling anything that it's about to do that.
I'm sure if I continue looking at the exynos stuff, it'll show similar
crap all over the place.
What you have now in mainline is not a solution. It's a crappy bodge.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
[PATCH] drm/i2c/tda998x: Fix signed overflow issue
This is C standard hair-splitting, but afaict
- sum will be promoted to signed int in computation since
uint8_t fits
- signed overflow is undefined.
No we need to add up an awful lot of bytes to actually make it
overflow. But I guess the real risk is gcc spotting this and going
bananas. Fix this by simply using unsigned in to force all computations
to use the well-defined unsigned behaviour.
Spotted by coverity.
v2: Simplify the entire computation as suggested by Jean.
Cc: Russell King
Cc: Rob Clark
Cc: Jean-Francois Moine
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i2c/tda998x_drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 48af5cac1902..240c331405b9 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -568,11 +568,11 @@ static irqreturn_t tda998x_irq_thread(int irq, void *data)
static uint8_t tda998x_cksum(uint8_t *buf, size_t bytes)
{
- uint8_t sum = 0;
+ int sum = 0;
while (bytes--)
- sum += *buf++;
- return (255 - sum) + 1;
+ sum -= *buf++;
+ return sum;
}
#define HB(x) (x)
--
1.8.5.2
[PATCH] drm/ast: Remove unecessary NULL check in gem_free
The ->gem_free_object never gets called with a NULL pointer, the check
is redundant. Also checking after the upcast allows compilers to elide
it anyway.
Spotted by coverity.
v2: Fix patch subject.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/ast/ast_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 38941a656312..01bf9e730acf 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -418,8 +418,6 @@ void ast_gem_free_object(struct drm_gem_object *obj)
{
struct ast_bo *ast_bo = gem_to_ast_bo(obj);
- if (!ast_bo)
- return;
ast_bo_unref(&ast_bo);
}
--
1.8.5.2
[PATCH 1/4] drm/radeon/dp: handle zero sized i2c over aux transactions
On Sat, Apr 05, 2014 at 11:25:01AM +0200, Christian K?nig wrote: > Am 04.04.2014 21:58, schrieb Alex Deucher: > >Needed for proper i2c over aux handling for certain > >monitors and configurations (e.g., dp bridges or > >adapters). > > > >Signed-off-by: Alex Deucher > > My planning was that yesterdays pull request is the last one with > new features. I can't judge how invasive this series is, so should I > add it to my 3.15 branch and send Dave another pull request or > should we wait for 3.16? At least the two patches for the dp aux helper code should go into 3.15 since they fix a behavioral regression in i915, too. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/omap: fix plane rotation
On Sat, Apr 5, 2014 at 2:33 PM, Grazvydas Ignotas wrote:
> Plane rotation with omapdrm is currently broken.
> It seems omap_plane_mode_set() expects width and height in screen
> coordinates, so pass it like that.
>
> Cc: Rob Clark
> Signed-off-by: Grazvydas Ignotas
> ---
> drivers/gpu/drm/omapdrm/omap_plane.c |8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
> b/drivers/gpu/drm/omapdrm/omap_plane.c
> index 370580c..5611f15 100644
> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> @@ -253,6 +253,14 @@ static int omap_plane_update(struct drm_plane *plane,
>
> drm_framebuffer_reference(fb);
>
> + /* omap_plane_mode_set() takes adjusted src */
> + switch (omap_plane->win.rotation & 0xf) {
> + case BIT(DRM_ROTATE_90):
> + case BIT(DRM_ROTATE_270):
> + swap(src_w, src_h);
> + break;
> + }
> +
hmm, I think that the better thing would be to do this in
omap_framebuffer_update_scanout(). In fact we do already swap
src_w/src_h there. Only we don't swap the width/height parameters we
pass down to omapdss. Not quite sure if something changed in omapdss
with regards to rotation_type, but keeping it with the rest of the
rotation related maths in _update_scanout() seems cleaner.
BR,
-R
> return omap_plane_mode_set(plane, crtc, fb,
> crtc_x, crtc_y, crtc_w, crtc_h,
> src_x, src_y, src_w, src_h,
> --
> 1.7.9.5
>
[PATCH] acpi: allow non-optimus setups to load vbios from acpi
Hi, same for me. The screen does not freeze anymore and the boot succeeds. But now I have this kernel message during boot (for the second card): [ 24.382045] pci_pm_runtime_suspend(): nouveau_pmops_runtime_suspend+0x0/0xe0 [nouveau] returns -22 Do you want to have the complete dmesg log? I think this is a new bug. Your patch works for the previous one, so you can close it. Yours, Claas On 27.03.2014 11:54, Patrick Clara wrote: > I have tested this patch. I can confirm that now nouveau loads > correctly without errors. > Thank you > > 2014-03-27 0:37 GMT+01:00 Ilia Mirkin : >> There appear to be a crop of new hardware where the vbios is not >> available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. >> The data read from PCIROM almost invariably contains invalid >> instructions (still has the x86 opcodes), which makes this a low-risk >> way to try to obtain a valid vbios image. >> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475 >> Signed-off-by: Ilia Mirkin >> Cc: # v2.6.35+ >> --- >> >> Not sure if the stable CC is warranted... it's technically not a >> regression. But it's a simple change that enables hardware to work. >> >> Patrick/Claas -- please test this out (if you're applying this to a linux >> tree, you'll have to do it manually, but it should be fairly obvious where >> this should apply). >> >> drm/nouveau_acpi.c | 3 --- >> 1 file changed, 3 deletions(-) >> >> diff --git a/drm/nouveau_acpi.c b/drm/nouveau_acpi.c >> index 83face3..2792069 100644 >> --- a/drm/nouveau_acpi.c >> +++ b/drm/nouveau_acpi.c >> @@ -389,9 +389,6 @@ bool nouveau_acpi_rom_supported(struct pci_dev *pdev) >> acpi_status status; >> acpi_handle dhandle, rom_handle; >> >> - if (!nouveau_dsm_priv.dsm_detected && >> !nouveau_dsm_priv.optimus_detected) >> - return false; >> - >> dhandle = ACPI_HANDLE(&pdev->dev); >> if (!dhandle) >> return false; >> -- >> 1.8.3.2 >>
[PATCH 12/13] drm/i2c/tda998x: Fix signed overflow issue
On Sat Apr 5 02:45:01 PDT 2014,
Daniel Vetter wrote:
> This is C standard hair-splitting, but afaict
> - sum will be promoted to signed int in computation since
> uint8_t fits
> - signed overflow is undefined.
[snip]
> drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 48af5cac1902..ae2754760d77 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -568,7 +568,7 @@ static irqreturn_t tda998x_irq_thread(int irq, void *data)
>
> static uint8_t tda998x_cksum(uint8_t *buf, size_t bytes)
> {
> - uint8_t sum = 0;
> + unsigned sum = 0;
>
> while (bytes--)
> sum += *buf++;
This function may be simplified by:
--- tda998x_drv.c~
+++ tda998x_drv.c
@@ -568,11 +568,11 @@
static uint8_t tda998x_cksum(uint8_t *buf, size_t bytes)
{
- uint8_t sum = 0;
+ int sum = 0;
while (bytes--)
- sum += *buf++;
- return (255 - sum) + 1;
+ sum -= *buf++;
+ return sum;
}
#define HB(x) (x)
and the same may be done in hdmi.c:
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 9e758a8..b6c9030 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -31,14 +31,14 @@
static void hdmi_infoframe_checksum(void *buffer, size_t size)
{
u8 *ptr = buffer;
- u8 csum = 0;
+ int csum = 0;
size_t i;
/* compute checksum */
for (i = 0; i < size; i++)
- csum += ptr[i];
+ csum -= ptr[i];
- ptr[3] = 256 - csum;
+ ptr[3] = csum;
}
/**
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
[PATCH] acpi: allow non-optimus setups to load vbios from acpi
On Sat, Apr 5, 2014 at 7:53 AM, Claas Lorenz wrote: > Hi, same for me. The screen does not freeze anymore and the boot Great! And that's without the nouveau.config=NvBios= stuff that you added as a workaround, right? > succeeds. But now I have this kernel message during boot (for the second > card): > > [ 24.382045] pci_pm_runtime_suspend(): > nouveau_pmops_runtime_suspend+0x0/0xe0 [nouveau] returns -22 > > Do you want to have the complete dmesg log? I think this is a new bug. New to you, perhaps :) Try http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=adbbdbac04f093c0abf946b1e93e4e5291808491. Or you can try forcing runpm=1 and seeing what happens. Ideally it'll be able to suspend your second GPU, but... who knows. That logic is really designed around optimus. > Your patch works for the previous one, so you can close it. > > Yours, > Claas > > > On 27.03.2014 11:54, Patrick Clara wrote: >> I have tested this patch. I can confirm that now nouveau loads >> correctly without errors. >> Thank you >> >> 2014-03-27 0:37 GMT+01:00 Ilia Mirkin : >>> There appear to be a crop of new hardware where the vbios is not >>> available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. >>> The data read from PCIROM almost invariably contains invalid >>> instructions (still has the x86 opcodes), which makes this a low-risk >>> way to try to obtain a valid vbios image. >>> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475 >>> Signed-off-by: Ilia Mirkin >>> Cc: # v2.6.35+ >>> --- >>> >>> Not sure if the stable CC is warranted... it's technically not a >>> regression. But it's a simple change that enables hardware to work. >>> >>> Patrick/Claas -- please test this out (if you're applying this to a linux >>> tree, you'll have to do it manually, but it should be fairly obvious where >>> this should apply). >>> >>> drm/nouveau_acpi.c | 3 --- >>> 1 file changed, 3 deletions(-) >>> >>> diff --git a/drm/nouveau_acpi.c b/drm/nouveau_acpi.c >>> index 83face3..2792069 100644 >>> --- a/drm/nouveau_acpi.c >>> +++ b/drm/nouveau_acpi.c >>> @@ -389,9 +389,6 @@ bool nouveau_acpi_rom_supported(struct pci_dev *pdev) >>> acpi_status status; >>> acpi_handle dhandle, rom_handle; >>> >>> - if (!nouveau_dsm_priv.dsm_detected && >>> !nouveau_dsm_priv.optimus_detected) >>> - return false; >>> - >>> dhandle = ACPI_HANDLE(&pdev->dev); >>> if (!dhandle) >>> return false; >>> -- >>> 1.8.3.2 >>> >
screen goes blank when loading gma500_gfx (atom D2500)
Hello again It's been about 2 months since I sent the original debugging output. Today I tried out 3.14 kernel. And this one behaves quite similarly, screen goes blank right when loading gma500_gfx module. Here's the dmesg from a freshly booted system after doing modprobe drm debug=6 modprobe gma500_gfx with a monitor connected to VGA port (before loading gma500_gfx, it displays the regular text console): [ 39.863330] Linux agpgart interface v0.103 [ 39.900511] [drm] Initialized drm 1.1.0 20060810 [ 45.012300] [drm:psb_intel_opregion_setup], Public ACPI methods supported [ 45.012308] [drm:psb_intel_opregion_setup], ASLE supported [ 45.012345] gma500 :00:02.0: irq 50 for MSI/MSI-X [ 45.012371] [drm:psb_intel_init_bios], Using VBT from OpRegion: $VBT CEDARVIEW d [ 45.012384] [drm:drm_mode_debug_printmodeline], Modeline 0:"1920x1080" 0 144000 1920 2016 2080 2176 1080 1088 1092 1100 0x8 0xa [ 45.012389] [drm:parse_sdvo_device_mapping], No SDVO device info is found in VBT [ 45.012397] [drm:parse_edp], EDP timing in vbt t1_t3 2000 t8 10 t9 2000 t10 500 t11_t12 5000 [ 45.012401] [drm:parse_edp], VBT reports EDP: Lane_count 1, Lane_rate 6, Bpp 24 [ 45.012405] [drm:parse_edp], VBT reports EDP: VSwing 0, Preemph 0 [ 45.012478] gma500 :00:02.0: GPU: power management timed out. [ 45.026195] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 45.026891] acpi device:29: registered as cooling_device2 [ 45.027104] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input11 [ 45.027681] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 45.027726] [drm] No driver support for vblank timestamp query. [ 45.078928] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter intel drm LVDSDDC_C [ 45.079839] [drm:cdv_intel_dp_i2c_init], i2c_init DPDDC-B [ 45.080383] [drm:cdv_intel_dp_aux_ch], dp_aux_ch timeout status 0x51440064 [ 45.080388] [drm:cdv_intel_dp_i2c_aux_ch], aux_ch failed -110 [ 45.080896] [drm:cdv_intel_dp_aux_ch], dp_aux_ch timeout status 0x51440064 [ 45.080899] [drm:cdv_intel_dp_i2c_aux_ch], aux_ch failed -110 [ 45.081754] [drm:cdv_intel_dp_i2c_init], i2c_init DPDDC-C [ 45.082062] [drm:cdv_intel_dp_i2c_aux_ch], aux_i2c nack [ 45.082272] [drm:cdv_intel_dp_i2c_aux_ch], aux_i2c nack [ 45.122742] [drm:cdv_intel_single_pipe_active], pipe enabled 0 [ 45.142780] gma500 :00:02.0: trying to get vblank count for disabled pipe 1 [ 45.142826] gma500 :00:02.0: trying to get vblank count for disabled pipe 1 [ 45.183207] [drm:cdv_intel_single_pipe_active], pipe enabled 0 [ 45.203249] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:7:VGA-1] [ 45.332286] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:7:VGA-1] probed modes : [ 45.332297] [drm:drm_mode_debug_printmodeline], Modeline 23:"1280x1024" 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x48 0x5 [ 45.332304] [drm:drm_mode_debug_printmodeline], Modeline 33:"1280x1024" 75 135000 1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5 [ 45.332311] [drm:drm_mode_debug_printmodeline], Modeline 26:"1280x1024" 72 132840 1280 1368 1504 1728 1024 1025 1028 1067 0x0 0x6 [ 45.332318] [drm:drm_mode_debug_printmodeline], Modeline 25:"1152x864" 75 108000 1152 1216 1344 1600 864 865 868 900 0x40 0x5 [ 45.332325] [drm:drm_mode_debug_printmodeline], Modeline 34:"1024x768" 75 78800 1024 1040 1136 1312 768 769 772 800 0x40 0x5 [ 45.332332] [drm:drm_mode_debug_printmodeline], Modeline 35:"1024x768" 70 75000 1024 1048 1184 1328 768 771 777 806 0x40 0xa [ 45.332338] [drm:drm_mode_debug_printmodeline], Modeline 36:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa [ 45.332345] [drm:drm_mode_debug_printmodeline], Modeline 37:"832x624" 75 57284 832 864 928 1152 624 625 628 667 0x40 0xa [ 45.332352] [drm:drm_mode_debug_printmodeline], Modeline 38:"800x600" 75 49500 800 816 896 1056 600 601 604 625 0x40 0x5 [ 45.332359] [drm:drm_mode_debug_printmodeline], Modeline 39:"800x600" 72 5 800 856 976 1040 600 637 643 666 0x40 0x5 [ 45.332365] [drm:drm_mode_debug_printmodeline], Modeline 27:"800x600" 60 4 800 840 968 1056 600 601 605 628 0x40 0x5 [ 45.332372] [drm:drm_mode_debug_printmodeline], Modeline 28:"640x480" 75 31500 640 656 720 840 480 481 484 500 0x40 0xa [ 45.332379] [drm:drm_mode_debug_printmodeline], Modeline 29:"640x480" 73 31500 640 664 704 832 480 489 491 520 0x40 0xa [ 45.332385] [drm:drm_mode_debug_printmodeline], Modeline 30:"640x480" 67 30240 640 704 768 864 480 483 486 525 0x40 0xa [ 45.332392] [drm:drm_mode_debug_printmodeline], Modeline 31:"640x480" 60 25200 640 656 752 800 480 490 492 525 0x40 0xa [ 45.332398] [drm:drm_mode_debug_printmodeline], Modeline 32:"720x400" 70 28320 720 738 846 900 400 412 414 449 0x40 0x6 [ 45.332405] [drm:drm_mode_debug_printmodeline], Modeline 24:"640x350" 70 25170 640 656 752 800 350 387 389 449 0x40 0x9
[PATCH 13/13] drm: Fix error handling in drm_master_create
We need to check whether drm_ht_create succeed and clean up
if not.
Spotted by coverity.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_stub.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index dc2c6095d850..a7f22822371c 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -131,7 +131,10 @@ struct drm_master *drm_master_create(struct drm_minor
*minor)
kref_init(&master->refcount);
spin_lock_init(&master->lock.spinlock);
init_waitqueue_head(&master->lock.lock_queue);
- drm_ht_create(&master->magiclist, DRM_MAGIC_HASH_ORDER);
+ if (drm_ht_create(&master->magiclist, DRM_MAGIC_HASH_ORDER)) {
+ kfree(master);
+ return NULL;
+ }
INIT_LIST_HEAD(&master->magicfree);
master->minor = minor;
--
1.8.5.2
[PATCH 12/13] drm/i2c/tda998x: Fix signed overflow issue
This is C standard hair-splitting, but afaict
- sum will be promoted to signed int in computation since
uint8_t fits
- signed overflow is undefined.
No we need to add up an awful lot of bytes to actually make it
overflow. But I guess the real risk is gcc spotting this and going
bananas. Fix this by simply using unsigned in to force all computations
to use the well-defined unsigned behaviour.
Spotted by coverity.
Cc: Russell King
Cc: Rob Clark
Cc: Jean-Francois Moine
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 48af5cac1902..ae2754760d77 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -568,7 +568,7 @@ static irqreturn_t tda998x_irq_thread(int irq, void *data)
static uint8_t tda998x_cksum(uint8_t *buf, size_t bytes)
{
- uint8_t sum = 0;
+ unsigned sum = 0;
while (bytes--)
sum += *buf++;
--
1.8.5.2
[PATCH 11/13] drm/bochs: Remove unecessary NULL check in gem_free
The ->gem_free_object never gets called with a NULL pointer, the check
is redundant. Also checking after the upcast allows compilers to elide
it anyway.
Noticed while chasing coverity reports, somehow this one here was not
flagged.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs_mm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 4a239e931aff..b9a695d92792 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -441,8 +441,6 @@ void bochs_gem_free_object(struct drm_gem_object *obj)
{
struct bochs_bo *bochs_bo = gem_to_bochs_bo(obj);
- if (!bochs_bo)
- return;
bochs_bo_unref(&bochs_bo);
}
--
1.8.5.2
[PATCH 10/13] drm/bochs: Remove unnecessary NULL check in bo_unref
ttm_bo_unref unconditionally calls kref_put on it's argument, so the thing can't be NULL without already causing Oopses. Spotted by coverity. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/bochs/bochs_mm.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c index f488be55d650..4a239e931aff 100644 --- a/drivers/gpu/drm/bochs/bochs_mm.c +++ b/drivers/gpu/drm/bochs/bochs_mm.c @@ -434,9 +434,7 @@ static void bochs_bo_unref(struct bochs_bo **bo) tbo = &((*bo)->bo); ttm_bo_unref(&tbo); - if (tbo == NULL) - *bo = NULL; - + *bo = NULL; } void bochs_gem_free_object(struct drm_gem_object *obj) -- 1.8.5.2
[PATCH 09/13] drm/udl: Initialize ret in udl_driver_load
We need to set it to -ENODEV when we don't recognize the device.
Otherwise we return/print stack garbage.
Spotted by coverity.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/udl/udl_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index f5ae57406f34..e1038a945f40 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -294,6 +294,7 @@ int udl_driver_load(struct drm_device *dev, unsigned long
flags)
dev->dev_private = udl;
if (!udl_parse_vendor_descriptor(dev, dev->usbdev)) {
+ ret = -ENODEV;
DRM_ERROR("firmware not recognized. Assume incompatible
device\n");
goto err;
}
--
1.8.5.2
[PATCH 08/13] drm/ast: Remove dead code from cbr_scan2
The outer if already checks for data != 0, so it can't really be
0. Hence remove it.
Now I don't have specs or anything for this beast, so I have no
idea whether this was actually intended or whether the logic
should be different. At least the code still seems to be doing
something useful.
Spotted by coverity.
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/ast/ast_post.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index 977cfb35837a..6263116054b6 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -572,8 +572,6 @@ static u32 cbr_scan2(struct ast_private *ast)
for (loop = 0; loop < CBR_PASSNUM2; loop++) {
if ((data = cbr_test2(ast)) != 0) {
data2 &= data;
- if (!data)
- return 0;
break;
}
}
--
1.8.5.2
[PATCH 07/13] drm/via: Remove unecessary NULL check
The context_dtor callback is only called once we've successfully loaded
the driver, which means dev->dev_private is set up. The check is hence
pointless.
Also dev->dev_private is deref already above, so compilers are free
to elide it anyway.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/via/via_mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/via/via_mm.c b/drivers/gpu/drm/via/via_mm.c
index 927889105483..d70b1e1544bf 100644
--- a/drivers/gpu/drm/via/via_mm.c
+++ b/drivers/gpu/drm/via/via_mm.c
@@ -79,7 +79,7 @@ int via_final_context(struct drm_device *dev, int context)
/* Linux specific until context tracking code gets ported to BSD */
/* Last context, perform cleanup */
- if (list_is_singular(&dev->ctxlist) && dev->dev_private) {
+ if (list_is_singular(&dev->ctxlist)) {
DRM_DEBUG("Last Context\n");
drm_irq_uninstall(dev);
via_cleanup_futex(dev_priv);
--
1.8.5.2
[PATCH 06/13] drm/mgag200: Remove unecessary NULL check in gem_free
The ->gem_free_object never gets called with a NULL pointer, the check
is redundant. Also checking after the upcast allows compilers to elide
it anyway.
Spotted by coverity.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/ast/ast_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 38941a656312..01bf9e730acf 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -418,8 +418,6 @@ void ast_gem_free_object(struct drm_gem_object *obj)
{
struct ast_bo *ast_bo = gem_to_ast_bo(obj);
- if (!ast_bo)
- return;
ast_bo_unref(&ast_bo);
}
--
1.8.5.2
[PATCH 05/13] drm/ast: Remove unnecessary NULL check in bo_unref
ttm_bo_unref unconditionally calls kref_put on it's argument, so the
thing can't be NULL without already causing Oopses.
Spotted by coverity.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/ast/ast_main.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 50535fd5a88d..38941a656312 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -411,10 +411,9 @@ static void ast_bo_unref(struct ast_bo **bo)
tbo = &((*bo)->bo);
ttm_bo_unref(&tbo);
- if (tbo == NULL)
- *bo = NULL;
-
+ *bo = NULL;
}
+
void ast_gem_free_object(struct drm_gem_object *obj)
{
struct ast_bo *ast_bo = gem_to_ast_bo(obj);
--
1.8.5.2
[PATCH 04/13] drm/cirrus: Remove unecessary NULL check in gem_free
The ->gem_free_object never gets called with a NULL pointer, the check
is redundant. Also checking after the upcast allows compilers to elide
it anyway.
Spotted by coverity.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/cirrus/cirrus_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c
b/drivers/gpu/drm/cirrus/cirrus_main.c
index b119f66fed92..99c1983f99d2 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -271,8 +271,6 @@ void cirrus_gem_free_object(struct drm_gem_object *obj)
{
struct cirrus_bo *cirrus_bo = gem_to_cirrus_bo(obj);
- if (!cirrus_bo)
- return;
cirrus_bo_unref(&cirrus_bo);
}
--
1.8.5.2
[PATCH 03/13] drm/cirrus: Remove unnecessary NULL check in bo_unref
ttm_bo_unref unconditionally calls kref_put on it's argument, so the thing can't be NULL without already causing Oopses. Spotted by coverity. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/cirrus/cirrus_main.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c b/drivers/gpu/drm/cirrus/cirrus_main.c index 4b0170cf53fd..b119f66fed92 100644 --- a/drivers/gpu/drm/cirrus/cirrus_main.c +++ b/drivers/gpu/drm/cirrus/cirrus_main.c @@ -264,9 +264,7 @@ static void cirrus_bo_unref(struct cirrus_bo **bo) tbo = &((*bo)->bo); ttm_bo_unref(&tbo); - if (tbo == NULL) - *bo = NULL; - + *bo = NULL; } void cirrus_gem_free_object(struct drm_gem_object *obj) -- 1.8.5.2
[PATCH 02/13] drm/mgag200: Remove unecessary NULL check in gem_free
The ->gem_free_object never gets called with a NULL pointer, the check
is redundant. Also checking after the upcast allows compilers to elide
it anyway.
Spotted by coverity.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/mgag200/mgag200_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 0722d18992f4..f6b283b8375e 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -329,8 +329,6 @@ void mgag200_gem_free_object(struct drm_gem_object *obj)
{
struct mgag200_bo *mgag200_bo = gem_to_mga_bo(obj);
- if (!mgag200_bo)
- return;
mgag200_bo_unref(&mgag200_bo);
}
--
1.8.5.2
[PATCH 01/13] drm/mgag200: Remove unnecessary NULL check in bo_unref
ttm_bo_unref unconditionally calls kref_put on it's argument, so the thing can't be NULL without already causing Oopses. Spotted by coverity. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/mgag200/mgag200_main.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c b/drivers/gpu/drm/mgag200/mgag200_main.c index 26868e5c55b0..0722d18992f4 100644 --- a/drivers/gpu/drm/mgag200/mgag200_main.c +++ b/drivers/gpu/drm/mgag200/mgag200_main.c @@ -322,9 +322,7 @@ static void mgag200_bo_unref(struct mgag200_bo **bo) tbo = &((*bo)->bo); ttm_bo_unref(&tbo); - if (tbo == NULL) - *bo = NULL; - + *bo = NULL; } void mgag200_gem_free_object(struct drm_gem_object *obj) -- 1.8.5.2
[PATCH 00/13] coverity
Hi all, Rainy w/e here and I got a bit bored, so looked at coverity again. I've closed all outstanding issues in drivers/gpu now either as false positives or fixed in this series expect for vmwgfx/ttm stuff (not enough clue) and one insane savage init issue (no desire to wake dragons today). Cheers, Daniel Daniel Vetter (13): drm/mgag200: Remove unnecessary NULL check in bo_unref drm/mgag200: Remove unecessary NULL check in gem_free drm/cirrus: Remove unnecessary NULL check in bo_unref drm/cirrus: Remove unecessary NULL check in gem_free drm/ast: Remove unnecessary NULL check in bo_unref drm/mgag200: Remove unecessary NULL check in gem_free drm/via: Remove unecessary NULL check drm/ast: Remove dead code from cbr_scan2 drm/udl: Initialize ret in udl_driver_load drm/bochs: Remove unnecessary NULL check in bo_unref drm/bochs: Remove unecessary NULL check in gem_free drm/i2c/tda998x: Fix signed overflow issue drm: Fix error handling in drm_master_create drivers/gpu/drm/ast/ast_main.c | 7 ++- drivers/gpu/drm/ast/ast_post.c | 2 -- drivers/gpu/drm/bochs/bochs_mm.c | 6 +- drivers/gpu/drm/cirrus/cirrus_main.c | 6 +- drivers/gpu/drm/drm_stub.c | 5 - drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- drivers/gpu/drm/mgag200/mgag200_main.c | 6 +- drivers/gpu/drm/udl/udl_main.c | 1 + drivers/gpu/drm/via/via_mm.c | 2 +- 9 files changed, 12 insertions(+), 25 deletions(-) -- 1.8.5.2
[PATCH 00/13] coverity
Hi all, Rainy w/e here and I got a bit bored, so looked at coverity again. I've closed all outstanding issues in drivers/gpu now either as false positives or fixed in this series expect for vmwgfx/ttm stuff (not enough clue) and one insane savage init issue (no desire to wake dragons today). Cheers, Daniel Daniel Vetter (13): drm/mgag200: Remove unnecessary NULL check in bo_unref drm/mgag200: Remove unecessary NULL check in gem_free drm/cirrus: Remove unnecessary NULL check in bo_unref drm/cirrus: Remove unecessary NULL check in gem_free drm/ast: Remove unnecessary NULL check in bo_unref drm/mgag200: Remove unecessary NULL check in gem_free drm/via: Remove unecessary NULL check drm/ast: Remove dead code from cbr_scan2 drm/udl: Initialize ret in udl_driver_load drm/bochs: Remove unnecessary NULL check in bo_unref drm/bochs: Remove unecessary NULL check in gem_free drm/i2c/tda998x: Fix signed overflow issue drm: Fix error handling in drm_master_create drivers/gpu/drm/ast/ast_main.c | 7 ++- drivers/gpu/drm/ast/ast_post.c | 2 -- drivers/gpu/drm/bochs/bochs_mm.c | 6 +- drivers/gpu/drm/cirrus/cirrus_main.c | 6 +- drivers/gpu/drm/drm_stub.c | 5 - drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- drivers/gpu/drm/mgag200/mgag200_main.c | 6 +- drivers/gpu/drm/udl/udl_main.c | 1 + drivers/gpu/drm/via/via_mm.c | 2 +- 9 files changed, 12 insertions(+), 25 deletions(-) -- 1.8.5.2
[PATCH 1/4] drm/radeon/dp: handle zero sized i2c over aux transactions
Am 04.04.2014 21:58, schrieb Alex Deucher:
> Needed for proper i2c over aux handling for certain
> monitors and configurations (e.g., dp bridges or
> adapters).
>
> Signed-off-by: Alex Deucher
My planning was that yesterdays pull request is the last one with new
features. I can't judge how invasive this series is, so should I add it
to my 3.15 branch and send Dave another pull request or should we wait
for 3.16?
Christian.
> ---
> drivers/gpu/drm/radeon/atombios_dp.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
> b/drivers/gpu/drm/radeon/atombios_dp.c
> index 8b0ab17..e914008 100644
> --- a/drivers/gpu/drm/radeon/atombios_dp.c
> +++ b/drivers/gpu/drm/radeon/atombios_dp.c
> @@ -143,6 +143,7 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan
> *chan,
> }
>
> #define HEADER_SIZE 4
> +#define BARE_ADDRESS_SIZE 3
>
> static ssize_t
> radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
> @@ -160,13 +161,16 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct
> drm_dp_aux_msg *msg)
> tx_buf[0] = msg->address & 0xff;
> tx_buf[1] = msg->address >> 8;
> tx_buf[2] = msg->request << 4;
> - tx_buf[3] = msg->size - 1;
> + tx_buf[3] = msg->size ? (msg->size - 1) : 0;
>
> switch (msg->request & ~DP_AUX_I2C_MOT) {
> case DP_AUX_NATIVE_WRITE:
> case DP_AUX_I2C_WRITE:
> tx_size = HEADER_SIZE + msg->size;
> - tx_buf[3] |= tx_size << 4;
> + if (msg->size == 0)
> + tx_buf[3] |= BARE_ADDRESS_SIZE << 4;
> + else
> + tx_buf[3] |= tx_size << 4;
> memcpy(tx_buf + HEADER_SIZE, msg->buffer, msg->size);
> ret = radeon_process_aux_ch(chan,
> tx_buf, tx_size, NULL, 0, delay,
> &ack);
> @@ -177,7 +181,10 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct
> drm_dp_aux_msg *msg)
> case DP_AUX_NATIVE_READ:
> case DP_AUX_I2C_READ:
> tx_size = HEADER_SIZE;
> - tx_buf[3] |= tx_size << 4;
> + if (msg->size == 0)
> + tx_buf[3] |= BARE_ADDRESS_SIZE << 4;
> + else
> + tx_buf[3] |= tx_size << 4;
> ret = radeon_process_aux_ch(chan,
> tx_buf, tx_size, msg->buffer,
> msg->size, delay, &ack);
> break;
> @@ -186,7 +193,7 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct
> drm_dp_aux_msg *msg)
> break;
> }
>
> - if (ret > 0)
> + if (ret >= 0)
> msg->reply = ack >> 4;
>
> return ret;
[PATCH 0/8] various exynos cleanups
On Fri, Mar 14, 2014 at 9:34 AM, Daniel Kurtz wrote: > On Wed, Mar 5, 2014 at 1:15 PM, Inki Dae wrote: >> Hi, >> >> Thanks you for cleanups. >> >> 2014-03-05 14:01 GMT+09:00 Daniel Kurtz : >>> Just some clean up patches, mostly for libdrm_exynos. >>> >>> Daniel Kurtz (8): >>> eyxnos: install exynos tests if HAVE_INSTALL_TESTS >>> exynos: fix two warnings >>> exynos_fimg2d: fix cast from pointer to integer of different size >>> exynos: remove unusable "run" target >>> exynos_fimg2d_test: fix drmModeRmFB >>> drmOpenByName: remove redundant drmAvailable check >>> exynos: prime: use drmPrime*() helpers >>> exynos: removed unused fd field >>> >> >> 1 through 5, and 7 through 8, >> >> Acked-by: Inki Dae > > Inki, > Thanks for the reviews. > > Can someone with commit access push the 7 ACK'ed patches. > Also, can someone please review patch number 6? Gentle ping... Can someone with commit access push the 7 ACK'ed patches. Also, can someone please review patch number 6? > >> >> >> Thanks, >> Inki Dae >> >>> exynos/exynos_drm.c | 52 >>> +-- >>> exynos/exynos_drmif.h | 2 -- >>> exynos/exynos_fimg2d.c| 4 +-- >>> tests/exynos/Makefile.am | 7 -- >>> tests/exynos/exynos_fimg2d_test.c | 2 +- >>> xf86drm.c | 13 -- >>> 6 files changed, 20 insertions(+), 60 deletions(-) >>> >>> -- >>> 1.9.0.rc1.175.g0b1dcb5 >>> >>> ___ >>> dri-devel mailing list >>> dri-devel at lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/7] drm/exynos: add super device support
2014-04-04 22:55 GMT+09:00 Tomasz Figa :
> Hi Inki,
>
>
> On 01.04.2014 14:37, Inki Dae wrote:
>>
>> This patch adds super device support to bind sub drivers
>> using device tree.
>>
>> For this, you should add a super device node to each machine dt files
>> like belows,
>>
>> In case of using MIPI-DSI,
>> display-subsystem {
>> compatible = "samsung,exynos-display-subsystem";
>> ports = <&fimd>, <&dsi>;
>> };
>>
>> In case of using DisplayPort,
>> display-subsystem {
>> compatible = "samsung,exynos-display-subsystem";
>> ports = <&fimd>, <&dp>;
>> };
>>
>> In case of using Parallel panel,
>> display-subsystem {
>> compatible = "samsung,exynos-display-subsystem";
>> ports = <&fimd>;
>> };
>>
>> And if you don't add connector device node to ports property,
>> default parallel panel driver, exynos_drm_dpi module, will be used.
>>
>> ports property can have the following device nodes,
>> fimd, mixer, Image Enhancer, MIPI-DSI, eDP, LVDS Bridge, or HDMI
>>
>> With this patch, we can resolve the probing order issue without
>> some global lists. So this patch also removes the unnecessary lists and
>> stuff related to these lists.
>
>
> I can see several problems with this approach:
>
> 1) It breaks compatibility with existing DT. After this patch it is no
> longer possible to use old device trees and get a working DRM. However, in
> my opinion, this requirement can be relaxed if we make sure that any users
> are properly converted.
>
> 2) What happens if in Kconfig you disable a driver for a component that is
I'm not sure what you meant but there wouldn't be no way that users
*cannot disable* the driver for a component. The driver would be
exynos_drm_drv, not separated module, and would always be built as
long as users want to use *exynos drm driver*.
> listed in supernode? If I'm reading the code correctly, Exynos DRM will not
And the only case a component isn't added to the list is when users
disabled sub driver.
> register, which is completely wrong. Users should be able to select which
> drivers should be compiled into their kernels.
So users are be able to select drivers they want to use, and will be
compiled correctly. So no, the only thing users can disable is each
sub driver, not core module.
>
> 3) Such approach leads to complete integration of all Exynos DRM drivers,
> without possibility of loading some sub-drivers as modules. I know that
> current driver design doesn't support it either, but if this series is
No, current drm driver *must also be built* as one integrated single
drm driver without super device approach. So the super device approach
*has no any effect on existing design*, and what the super device
approch tries to do is to resolve the probe order issue to sub drivers
*without some codes specific to Exynos drm*.
> claimed to improve things, it should really do so.
>
> 4) Exactly the same can be achieved without changing the DT bindings at all.
> In fact even without adding any new single property or node to DT. We
> discussed this with Andrzej and Marek today and came to a solution in which
> just by adding a little bit of code to Exynos DRM subdrivers, you could
> guarantee correct registration of Exynos DRM platform and also get rid of
> #ifdeffery in exynos_drm_drv.c. Andrzej will send an RFC after the weekend.
I'm not sure but I had implemented below prototype codes for that, see
the below link,
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-bridge-test&id=2860ad02d736e300034ddeabce3da92614922b4e
I guess what you said would be similler approach.
And I still think the use of the component framework would be the best
solution and *Linux generic way* for resolving the probe order issue
without any specific codes. So I'm not advocating the compoent
framework but I tend not to want to use specific codes.
>
> 5) This series seems to break DPI display support with runtime PM enabled.
> Universal C210 just hangs on second FIMD probe, after first one fails with
> probe deferral. This needs more investigation, though.
For -next, I never expect that pm operations would be operated
perfactly. They are really not for product. Just adding new feature
and drivers to -next, and then fixing them while in RC. And RC process
would also be for it. Actually, I see pm interfaces of exynos_drm_dsi
driver leads to break a single driver model because pm operations
should be done at top level of exynos drm, and some codes Sean didn't
fix. So such things are in my fix-todo-list. I tend to accept new
features and drivers for -next as long as they have no big problem,
And that is my style I maintain.
Thanks,
Inki Dae
>
> Best regards,
> Tomasz
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-deve
