[Bug 70675] steam error dialogs are garbled
https://bugs.freedesktop.org/show_bug.cgi?id=70675 --- Comment #4 from Alex Deucher --- I think the patch is fine. I think 64 is too small for 2D tiling on some asics depending on the number of memory channels they have. It shouldn't hurt anything. -- 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/20131023/e2a9f741/attachment-0001.html>
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
2013/10/23 Sean Paul : > On Wed, Oct 23, 2013 at 1:42 AM, Inki Dae wrote: >> 2013/10/23 Sean Paul : >>> On Wed, Oct 23, 2013 at 12:48 AM, Inki Dae wrote: 2013/10/23 St?phane Marchesin : > > > > On Tue, Oct 22, 2013 at 9:15 PM, Inki Dae wrote: >> >> 2013/10/23 St?phane Marchesin : >> > >> > >> > >> > On Tue, Oct 22, 2013 at 8:38 PM, Inki Dae >> > wrote: >> >> >> >> 2013/10/23 St?phane Marchesin : >> >> > >> >> > >> >> > >> >> > On Tue, Oct 22, 2013 at 7:28 PM, Inki Dae >> >> > wrote: >> >> >> >> >> >> 2013/10/22 Sean Paul : >> >> >> > On Tue, Oct 22, 2013 at 1:30 AM, Inki Dae > >> >> > samsung.com> >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> >> >>> -Original Message- >> >> >> >>> From: Sean Paul [mailto:seanpaul at chromium.org] >> >> >> >>> Sent: Tuesday, October 22, 2013 6:18 AM >> >> >> >>> To: Inki Dae >> >> >> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin >> >> >> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split >> >> >> >>> manager/display/subdrv >> >> >> >>> >> >> >> >>> On Mon, Oct 21, 2013 at 10:46 AM, Sean Paul >> >> >> >>> >> >> >> >>> wrote: >> >> >> >>> > On Thu, Oct 17, 2013 at 10:31 PM, Inki Dae >> >> >> >>> > >> >> >> >>> > wrote: >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >>> -Original Message- >> >> >> >>> >>> From: Sean Paul [mailto:seanpaul at chromium.org] >> >> >> >>> >>> Sent: Thursday, October 17, 2013 11:37 PM >> >> >> >>> >>> To: Inki Dae >> >> >> >>> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin >> >> >> >>> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split >> >> >> >>> >>> manager/display/subdrv >> >> >> >>> >>> >> >> >> >>> >>> On Thu, Oct 17, 2013 at 4:21 AM, Inki Dae >> >> >> >>> >>> >> >> >> >> wrote: >> >> >> >>> >>> > >> >> >> >>> >>> > >> >> >> >>> >>> >> -Original Message- >> >> >> >>> >>> >> From: Sean Paul [mailto:seanpaul at chromium.org] >> >> >> >>> >>> >> Sent: Thursday, October 17, 2013 4:27 AM >> >> >> >>> >>> >> To: dri-devel at lists.freedesktop.org; inki.dae at >> >> >> >>> >>> >> samsung.com >> >> >> >>> >>> >> Cc: airlied at linux.ie; tomasz.figa at gmail.com; >> >> >> >>> >>> >> marcheu at chromium.org; >> >> >> >>> Sean >> >> >> >>> >>> >> Paul >> >> >> >>> >>> >> Subject: [PATCH v2 12/26] drm/exynos: Split >> >> >> >>> >>> >> manager/display/subdrv >> >> >> >>> >>> >> >> >> >> >>> >>> >> This patch splits display and manager from subdrv. The >> >> >> >>> >>> >> result >> >> >> >>> >>> >> is >> >> >> >>> that >> >> >> >>> >>> >> crtc functions can directly call into manager callbacks >> >> >> >>> >>> >> and >> >> >> >>> >>> >> encoder >> >> >> >>> >>> >> functions can directly call into display callbacks. This >> >> >> >>> >>> >> will >> >> >> >>> >>> >> allow >> >> >> >>> >>> >> us to remove the exynos_drm_hdmi shim and support >> >> >> >>> >>> >> mixer/hdmi >> >> >> >>> >>> >> & >> >> >> >>> fimd/dp >> >> >> >>> >>> >> with common code. >> >> >> >>> >>> >> >> >> >> >>> >>> >> Signed-off-by: Sean Paul >> >> >> >>> >>> >> --- >> >> >> >>> >>> >> >> >> >> >>> >>> >> Changes in v2: >> >> >> >>> >>> >> - Pass display into display_ops instead of context >> >> >> >>> >>> > >> >> >> >>> >>> > Sorry but it seems like more reasonable to pass device >> >> >> >>> >>> > object >> >> >> >>> >>> > into >> >> >> >>> >>> > display_ops and manager_ops. >> >> >> >>> >>> > >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> So you've changed your mind from when you said the >> >> >> >>> >>> following? >> >> >> >>> >>> >> >> >> >>> >>> >>> manager->ops->xxx(manager, ...); >> >> >> >>> >>> >>> display->ops->xxx(display, ...); >> >> >> >>> >>> >>> >> >> >> >>> >>> >>> Agree. >> >> >> >>> >>> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> True. Before that, My comment was to pass device object into >> >> >> >>> display_ops and >> >> >> >>> >> manager_ops, and then you said the good solution is to pass >> >> >> >>> >> manager >> >> >> >>> >> and >> >> >> >>> >> display to each driver. At that time, I thought no matter >> >> >> >>> >> how >> >> >> >>> >> the >> >> >> >>> callback >> >> >> >>> >> is called if the framework doesn't call callbacks of each >> >> >> >>> >> driver >> >> >> >>> >> with >> >> >> >>> ctx. >> >> >> >>> >> So I agreed. >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >>> It would have been nice if you had changed your mind >> >> >> >>> >>> *before* I >> >> >> >>> >>> reworked everything. At any rate, I think it's still the >> >> >> >>> >>> right >> >> >> >>> >>> thing >>
[Bug 70654] [DPM] Mobility 4570: power_dpm_force_performance_level is reset to auto when UVD is used
https://bugs.freedesktop.org/show_bug.cgi?id=70654 --- Comment #2 from Alex Deucher --- Created attachment 88057 --> https://bugs.freedesktop.org/attachment.cgi?id=88057&action=edit possible fix This patch should fix the 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/20131023/b61e2aaa/attachment.html>
[PATCH] drm/radeon: fix definition of WAIT_REG_MEM_OPERATION for CIK
On Tue, Oct 22, 2013 at 3:09 PM, Marek Ol??k wrote: > From: Marek Ol??k > > Signed-off-by: Marek Ol??k Applied. thanks! Alex > --- > drivers/gpu/drm/radeon/cikd.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/radeon/cikd.h b/drivers/gpu/drm/radeon/cikd.h > index 203d2a0..cad6e8a 100644 > --- a/drivers/gpu/drm/radeon/cikd.h > +++ b/drivers/gpu/drm/radeon/cikd.h > @@ -1626,7 +1626,7 @@ > /* 0 - reg > * 1 - mem > */ > -#defineWAIT_REG_MEM_OPERATION(x) ((x) << 6) > +#defineWAIT_REG_MEM_OPERATION(x) ((x) << 5) > /* 0 - wait_reg_mem > * 1 - wr_wait_wr_reg > */ > -- > 1.8.1.2 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70804] radeonsi_compute.c:254:11: error: 'struct pipe_context' has no member named 'set_compute_sampler_views'
https://bugs.freedesktop.org/show_bug.cgi?id=70804 Brian Paul changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Brian Paul --- Fixed w/ commit ef98e2ee618f9452a3d16b8fb884d0318f7896fc -- 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/20131023/7a84cc37/attachment.html>
[Bug 70804] radeonsi_compute.c:254:11: error: 'struct pipe_context' has no member named 'set_compute_sampler_views'
https://bugs.freedesktop.org/show_bug.cgi?id=70804 --- Comment #2 from Vinson Lee --- attachment 88049 fixes the build. Tested-by: Vinson Lee -- 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/20131023/ce04886a/attachment.html>
[Bug 69341] [radeonsi] KDE 4.11 is EXTREMELY slow with Raster QT backend
https://bugs.freedesktop.org/show_bug.cgi?id=69341 --- Comment #18 from darkbasic --- I just tried plain Kubuntu 13.10: same issue, desktop is unusable :( -- 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/20131023/53c4579e/attachment.html>
[Patch v2][ 03/37] drm: Add the lacking DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*
On Wed, Oct 23, 2013 at 04:48:51PM +0200, Denis Carikli wrote: > Hi, > > On 10/18/2013 09:46 AM, Ville Syrj?l? wrote: > >> +#define DRM_MODE_FLAG_PDATEN (1<<22) > >> +#define DRM_MODE_FLAG_NDATEN (1<<23) > >> +#define DRM_MODE_FLAG_PPIXDATEDGE (1<<24) > >> +#define DRM_MODE_FLAG_NPIXDATEDGE (1<<25) > > > > Do we really need to make this stuff visible to userspace? > > And there's no documentation to explain any of it. > > DRM_MODE_FLAG_PDATEN and DRM_MODE_FLAG_NDATEN were meant to represent > the data enable polarity. > > DRM_MODE_FLAG_PPIXDATEDGE and DRM_MODE_FLAG_NPIXDATEDGE were meant to > represent the clock polarity. > > What would you recommend to represent theses polarities? I don't really care that much how you represent them. Just wondering if userspace has any business dictating those, and it not, then they shouldn't be DRM_MODE flags. -- Ville Syrj?l? Intel OTC
[Bug 70804] radeonsi_compute.c:254:11: error: 'struct pipe_context' has no member named 'set_compute_sampler_views'
https://bugs.freedesktop.org/show_bug.cgi?id=70804 --- Comment #1 from Brian Paul --- Created attachment 88049 --> https://bugs.freedesktop.org/attachment.cgi?id=88049&action=edit fix breakage Can you test this patch, Vinson? -- 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/20131023/62183533/attachment.html>
[Bug 70698] xorg+glamor crash in libllvm on kabini
https://bugs.freedesktop.org/show_bug.cgi?id=70698 Alexander Sabourenkov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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/20131023/ce211af8/attachment.html>
[Bug 70698] xorg+glamor crash in libllvm on kabini
https://bugs.freedesktop.org/show_bug.cgi?id=70698 --- Comment #3 from Alexander Sabourenkov --- (In reply to comment #2) > A fix for this was recently pushed to the Mesa git repository. Can you > fetch the latest version and re-test. Today's git head works fine. I guess 9da4021626dd48a1cc25054d1d4009e098f4d97b did it, I should have retested with git head at once. Sorry for the noise. -- 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/20131023/e31ac2dc/attachment.html>
How to change radeon power state
On Sat, Oct 19, 2013 at 10:15 PM, Daniel Mota Leite wrote: > On Sat, 19 Oct 2013 21:09:31 -0400, Alex Deucher > wrote: >> On Sat, Oct 19, 2013 at 8:36 PM, Daniel Mota Leite >> wrote: >> > [ 12.359671] == power state 1 == >> > [ 12.359726] ui class: performance >> > [ 12.359824] internal class: ovrdrv > (...) >> > [ 12.360442] == power state 2 == >> > [ 12.360497] ui class: none >> > [ 12.360594] internal class: none > (...) >> > As you can see, the driver choose the performance profile, but >> > that one is limited to 400MHz, half of what this card can do. Of >> > course i want to be able jump the GPU to 800MHz. So is there any easy >> > way to choose the power state 2 instead of power state 1? >> We'll probably need to add a quirk for your card. Can you send me the >> output of lspci -vnn for the GPU? > > > Please note that the original card firmware had all powerstates > the same, i had used rbe (http://www.techpowerup.com/rbe/) to change then > to the current frequencies. In that app, the powerstate 1 is called > battery and the powerstate 2 is called performance. > > I can switch the two and reflash, but to me seems logic that one > can manually choose what powerstate to use if needed, just like the > powerlevels (excluding the middle powerlevel problem) You'll need to fix the power state to be flagged as performance. Alex > > Here is the output: > > 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee > ATI RV 630 XT AGP [Radeon HD 2600 XT AGP] [1002:9586] (prog-if 00 [VGA > controller]) > Subsystem: PC Partner Limited Device [174b:0028] > Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 > Memory at e000 (32-bit, prefetchable) [size=256M] > I/O ports at e000 [size=256] > Memory at fbf0 (32-bit, non-prefetchable) [size=64K] > Expansion ROM at fbe0 [disabled] [size=128K] > Capabilities: [50] Power Management version 3 > Capabilities: [58] AGP version 3.0 > Kernel driver in use: radeon > > Thanks in advance. > higuita > -- > Naturally the common people don't want war... but after all it is the > leaders of a country who determine the policy, and it is always a > simple matter to drag the people along, whether it is a democracy, or > a fascist dictatorship, or a parliament, or a communist dictatorship. > Voice or no voice, the people can always be brought to the bidding of > the leaders. That is easy. All you have to do is tell them they are > being attacked, and denounce the pacifists for lack of patriotism and > exposing the country to danger. It works the same in every country. >-- Hermann Goering, Nazi and war criminal, 1883-1946
[Bug 70804] New: radeonsi_compute.c:254:11: error: 'struct pipe_context' has no member named 'set_compute_sampler_views'
https://bugs.freedesktop.org/show_bug.cgi?id=70804 Priority: medium Bug ID: 70804 Keywords: regression CC: brianp at vmware.com Assignee: dri-devel at lists.freedesktop.org Summary: radeonsi_compute.c:254:11: error: 'struct pipe_context' has no member named 'set_compute_sampler_views' Severity: blocker Classification: Unclassified OS: Linux (All) Reporter: vlee at freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa mesa: a3ed98f7aa85636579a5696bf036ec13e5c9104a CC radeonsi_compute.lo radeonsi_compute.c: In function 'si_init_compute_functions': radeonsi_compute.c:254:11: error: 'struct pipe_context' has no member named 'set_compute_sampler_views' rctx->b.b.set_compute_sampler_views = si_set_cs_sampler_view; ^ -- 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/20131023/344bc7d9/attachment.html>
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
> I think we need to start considering a framework where subdrivers just add drm objects themselves, then the toplevel node is responsible for knowing that everything for the current configuration is loaded. >>> >>> It would be nice to specify the various pieces in dt, then have some >>> type of drm notifier to the toplevel node when everything has been >>> probed. Doing it in the dt would allow standalone drm_bridge/drm_panel >>> drivers to be transparent as far as the device's drm driver is >>> concerned. >>> >>> Sean >>> >>> I realise we may need to make changes to the core drm to allow this but we should probably start to create a strategy for fixing the API issues that this throws up. Note I'm not yet advocating for dynamic addition of nodes once the device is in use, or removing them. >> >> I do wonder if we had some sort of tag in the device tree for any nodes >> involved in the display, and the core drm layer would read that list, >> and when every driver registers tick things off, and when the last one >> joins we get a callback and init the drm layer, we'd of course have the >> basic drm layer setup prior to that so we can add the objects as the >> drivers load. It might make development a bit trickier as you'd need >> to make sure someone claimed ownership of all the bits for init to proceed. >> > > Yeah, that's basically what the strawman looked like in my head. > > Instead of a property in each node, I was thinking of having a > separate gfx pipe nodes that would have dt pointers to the various > pieces involved in that pipe. This would allow us to associate > standalone entities like bridges and panels with encoders in dt w/o > doing it in the drm code. I *think* this should be Ok with the dt guys > since it is still describing the hardware, but I think we'd have to > make sure it wasn't drm-specific. > I suppose the question is how much dynamic pipeline construction there is, even on things like radeon and i915 we have dynamic clock generator to crtc to encoder setups, so I worry about static lists per-pipe, so I still think just stating all these devices are needed for display and a list of valid interconnections between them, then we can have the generic code model drm crtc/encoders/connectors on that list, and construct the possible_crtcs /possible_clones etc at that stage. Dave.
[Patch v2][ 03/37] drm: Add the lacking DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*
Hi, On 10/18/2013 09:46 AM, Ville Syrj?l? wrote: >> +#define DRM_MODE_FLAG_PDATEN(1<<22) >> +#define DRM_MODE_FLAG_NDATEN(1<<23) >> +#define DRM_MODE_FLAG_PPIXDATEDGE (1<<24) >> +#define DRM_MODE_FLAG_NPIXDATEDGE (1<<25) > > Do we really need to make this stuff visible to userspace? > And there's no documentation to explain any of it. DRM_MODE_FLAG_PDATEN and DRM_MODE_FLAG_NDATEN were meant to represent the data enable polarity. DRM_MODE_FLAG_PPIXDATEDGE and DRM_MODE_FLAG_NPIXDATEDGE were meant to represent the clock polarity. What would you recommend to represent theses polarities? Denis.
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
On Wed, Oct 23, 2013 at 3:45 PM, Sean Paul wrote: > On Wed, Oct 23, 2013 at 10:29 AM, Dave Airlie wrote: >>> As I mentioned earlier, display_ops is needed to have no any >>> dependency of drm framework directly like below, >>> >>> DRM Framework >>>| >>> Exynos DRM Framework >>> / | \ >>> Real device drivers >>> >>> In particular, in case of ARM based DRM drivers with separated >>> devices, I still tend to think it's better design than that device >>> drivers implement the connector callbacks directly, but I will try to >>> consider what is the better way. >>> >> >> I think we need to start considering a framework where subdrivers just >> add drm objects themselves, then the toplevel node is responsible for >> knowing that everything for the current configuration is loaded. >> > > It would be nice to specify the various pieces in dt, then have some > type of drm notifier to the toplevel node when everything has been > probed. Doing it in the dt would allow standalone drm_bridge/drm_panel > drivers to be transparent as far as the device's drm driver is > concerned. > > Sean > > >> I realise we may need to make changes to the core drm to allow this >> but we should probably start to create a strategy for fixing the API >> issues that this throws up. >> >> Note I'm not yet advocating for dynamic addition of nodes once the >> device is in use, or removing them. >> I do wonder if we had some sort of tag in the device tree for any nodes involved in the display, and the core drm layer would read that list, and when every driver registers tick things off, and when the last one joins we get a callback and init the drm layer, we'd of course have the basic drm layer setup prior to that so we can add the objects as the drivers load. It might make development a bit trickier as you'd need to make sure someone claimed ownership of all the bits for init to proceed. Dave.
[PATCH] drm/radeon/dpm: fix incompatible casting on big endian
We use u16 for voltage values throughout the driver so switch
the table values to a u16 as well. Fixes an incompatible
cast error in ci_patch_clock_voltage_limits_with_vddc_leakage()
picked up by coverity.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index a400ac1..24f4960 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1272,8 +1272,8 @@ struct radeon_blacklist_clocks
struct radeon_clock_and_voltage_limits {
u32 sclk;
u32 mclk;
- u32 vddc;
- u32 vddci;
+ u16 vddc;
+ u16 vddci;
};
struct radeon_clock_array {
--
1.8.3.1
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
> As I mentioned earlier, display_ops is needed to have no any > dependency of drm framework directly like below, > > DRM Framework >| > Exynos DRM Framework > / | \ > Real device drivers > > In particular, in case of ARM based DRM drivers with separated > devices, I still tend to think it's better design than that device > drivers implement the connector callbacks directly, but I will try to > consider what is the better way. > I think we need to start considering a framework where subdrivers just add drm objects themselves, then the toplevel node is responsible for knowing that everything for the current configuration is loaded. I realise we may need to make changes to the core drm to allow this but we should probably start to create a strategy for fixing the API issues that this throws up. Note I'm not yet advocating for dynamic addition of nodes once the device is in use, or removing them. Dave.
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
2013/10/23 Sean Paul : > On Wed, Oct 23, 2013 at 12:48 AM, Inki Dae wrote: >> 2013/10/23 St?phane Marchesin : >>> >>> >>> >>> On Tue, Oct 22, 2013 at 9:15 PM, Inki Dae wrote: 2013/10/23 St?phane Marchesin : > > > > On Tue, Oct 22, 2013 at 8:38 PM, Inki Dae > wrote: >> >> 2013/10/23 St?phane Marchesin : >> > >> > >> > >> > On Tue, Oct 22, 2013 at 7:28 PM, Inki Dae >> > wrote: >> >> >> >> 2013/10/22 Sean Paul : >> >> > On Tue, Oct 22, 2013 at 1:30 AM, Inki Dae >> >> > wrote: >> >> >> >> >> >> >> >> >>> -Original Message- >> >> >>> From: Sean Paul [mailto:seanpaul at chromium.org] >> >> >>> Sent: Tuesday, October 22, 2013 6:18 AM >> >> >>> To: Inki Dae >> >> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin >> >> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split >> >> >>> manager/display/subdrv >> >> >>> >> >> >>> On Mon, Oct 21, 2013 at 10:46 AM, Sean Paul >> >> >>> >> >> >>> wrote: >> >> >>> > On Thu, Oct 17, 2013 at 10:31 PM, Inki Dae >> >> >>> > >> >> >>> > wrote: >> >> >>> >> >> >> >>> >> >> >> >>> >>> -Original Message- >> >> >>> >>> From: Sean Paul [mailto:seanpaul at chromium.org] >> >> >>> >>> Sent: Thursday, October 17, 2013 11:37 PM >> >> >>> >>> To: Inki Dae >> >> >>> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin >> >> >>> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split >> >> >>> >>> manager/display/subdrv >> >> >>> >>> >> >> >>> >>> On Thu, Oct 17, 2013 at 4:21 AM, Inki Dae >> >> >>> >>> >> >> >> wrote: >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> >> -Original Message- >> >> >>> >>> >> From: Sean Paul [mailto:seanpaul at chromium.org] >> >> >>> >>> >> Sent: Thursday, October 17, 2013 4:27 AM >> >> >>> >>> >> To: dri-devel at lists.freedesktop.org; inki.dae at >> >> >>> >>> >> samsung.com >> >> >>> >>> >> Cc: airlied at linux.ie; tomasz.figa at gmail.com; >> >> >>> >>> >> marcheu at chromium.org; >> >> >>> Sean >> >> >>> >>> >> Paul >> >> >>> >>> >> Subject: [PATCH v2 12/26] drm/exynos: Split >> >> >>> >>> >> manager/display/subdrv >> >> >>> >>> >> >> >> >>> >>> >> This patch splits display and manager from subdrv. The >> >> >>> >>> >> result >> >> >>> >>> >> is >> >> >>> that >> >> >>> >>> >> crtc functions can directly call into manager callbacks >> >> >>> >>> >> and >> >> >>> >>> >> encoder >> >> >>> >>> >> functions can directly call into display callbacks. This >> >> >>> >>> >> will >> >> >>> >>> >> allow >> >> >>> >>> >> us to remove the exynos_drm_hdmi shim and support >> >> >>> >>> >> mixer/hdmi >> >> >>> >>> >> & >> >> >>> fimd/dp >> >> >>> >>> >> with common code. >> >> >>> >>> >> >> >> >>> >>> >> Signed-off-by: Sean Paul >> >> >>> >>> >> --- >> >> >>> >>> >> >> >> >>> >>> >> Changes in v2: >> >> >>> >>> >> - Pass display into display_ops instead of context >> >> >>> >>> > >> >> >>> >>> > Sorry but it seems like more reasonable to pass device >> >> >>> >>> > object >> >> >>> >>> > into >> >> >>> >>> > display_ops and manager_ops. >> >> >>> >>> > >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> So you've changed your mind from when you said the >> >> >>> >>> following? >> >> >>> >>> >> >> >>> >>> >>> manager->ops->xxx(manager, ...); >> >> >>> >>> >>> display->ops->xxx(display, ...); >> >> >>> >>> >>> >> >> >>> >>> >>> Agree. >> >> >>> >>> >> >> >>> >> >> >> >>> >> >> >> >>> >> True. Before that, My comment was to pass device object into >> >> >>> display_ops and >> >> >>> >> manager_ops, and then you said the good solution is to pass >> >> >>> >> manager >> >> >>> >> and >> >> >>> >> display to each driver. At that time, I thought no matter how >> >> >>> >> the >> >> >>> callback >> >> >>> >> is called if the framework doesn't call callbacks of each >> >> >>> >> driver >> >> >>> >> with >> >> >>> ctx. >> >> >>> >> So I agreed. >> >> >>> >> >> >> >>> >> >> >> >>> >>> It would have been nice if you had changed your mind >> >> >>> >>> *before* I >> >> >>> >>> reworked everything. At any rate, I think it's still the >> >> >>> >>> right >> >> >>> >>> thing >> >> >>> >>> to do. >> >> >>> >> >> >> >>> >> Really sorry about that. And I will add new patch for it so >> >> >>> >> you >> >> >>> >> don't >> >> >>> need >> >> >>> >> to concern about that. >> >> >>> >> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> > I'm not sure but display_ops could be implemented in other >> >> >>> >>>
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
2013/10/22 Inki Dae : > 2013/10/17 Sean Paul : >> This patch splits display and manager from subdrv. The result is that >> crtc functions can directly call into manager callbacks and encoder >> functions can directly call into display callbacks. This will allow >> us to remove the exynos_drm_hdmi shim and support mixer/hdmi & fimd/dp >> with common code. >> >> Signed-off-by: Sean Paul >> --- >> >> Changes in v2: >> - Pass display into display_ops instead of context >> >> drivers/gpu/drm/exynos/exynos_drm_connector.c | 50 ++- >> drivers/gpu/drm/exynos/exynos_drm_core.c | 181 --- >> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 115 +-- >> drivers/gpu/drm/exynos/exynos_drm_crtc.h | 20 +- >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 29 +- >> drivers/gpu/drm/exynos/exynos_drm_drv.h | 106 +++--- >> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 258 ++- >> drivers/gpu/drm/exynos/exynos_drm_encoder.h | 18 +- >> drivers/gpu/drm/exynos/exynos_drm_fb.c| 4 +- >> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 161 + >> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 449 >> -- > > Build error. it seems that you missed vidi module. Can you consider > vidi module also? > Sean, ping~~~ > Thanks, > Inki Dae > >> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 2 + >> drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 +- >> 13 files changed, 466 insertions(+), 942 deletions(-) >> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_hdmi.c >>
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
2013/10/23 St?phane Marchesin : > > > > On Tue, Oct 22, 2013 at 9:15 PM, Inki Dae wrote: >> >> 2013/10/23 St?phane Marchesin : >> > >> > >> > >> > On Tue, Oct 22, 2013 at 8:38 PM, Inki Dae wrote: >> >> >> >> 2013/10/23 St?phane Marchesin : >> >> > >> >> > >> >> > >> >> > On Tue, Oct 22, 2013 at 7:28 PM, Inki Dae >> >> > wrote: >> >> >> >> >> >> 2013/10/22 Sean Paul : >> >> >> > On Tue, Oct 22, 2013 at 1:30 AM, Inki Dae >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> >> >>> -Original Message- >> >> >> >>> From: Sean Paul [mailto:seanpaul at chromium.org] >> >> >> >>> Sent: Tuesday, October 22, 2013 6:18 AM >> >> >> >>> To: Inki Dae >> >> >> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin >> >> >> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split >> >> >> >>> manager/display/subdrv >> >> >> >>> >> >> >> >>> On Mon, Oct 21, 2013 at 10:46 AM, Sean Paul >> >> >> >>> >> >> >> >>> wrote: >> >> >> >>> > On Thu, Oct 17, 2013 at 10:31 PM, Inki Dae >> >> >> >>> > >> >> >> >>> > wrote: >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >>> -Original Message- >> >> >> >>> >>> From: Sean Paul [mailto:seanpaul at chromium.org] >> >> >> >>> >>> Sent: Thursday, October 17, 2013 11:37 PM >> >> >> >>> >>> To: Inki Dae >> >> >> >>> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin >> >> >> >>> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split >> >> >> >>> >>> manager/display/subdrv >> >> >> >>> >>> >> >> >> >>> >>> On Thu, Oct 17, 2013 at 4:21 AM, Inki Dae >> >> >> >>> >>> >> >> >> >> wrote: >> >> >> >>> >>> > >> >> >> >>> >>> > >> >> >> >>> >>> >> -Original Message- >> >> >> >>> >>> >> From: Sean Paul [mailto:seanpaul at chromium.org] >> >> >> >>> >>> >> Sent: Thursday, October 17, 2013 4:27 AM >> >> >> >>> >>> >> To: dri-devel at lists.freedesktop.org; inki.dae at >> >> >> >>> >>> >> samsung.com >> >> >> >>> >>> >> Cc: airlied at linux.ie; tomasz.figa at gmail.com; >> >> >> >>> >>> >> marcheu at chromium.org; >> >> >> >>> Sean >> >> >> >>> >>> >> Paul >> >> >> >>> >>> >> Subject: [PATCH v2 12/26] drm/exynos: Split >> >> >> >>> >>> >> manager/display/subdrv >> >> >> >>> >>> >> >> >> >> >>> >>> >> This patch splits display and manager from subdrv. The >> >> >> >>> >>> >> result >> >> >> >>> >>> >> is >> >> >> >>> that >> >> >> >>> >>> >> crtc functions can directly call into manager callbacks >> >> >> >>> >>> >> and >> >> >> >>> >>> >> encoder >> >> >> >>> >>> >> functions can directly call into display callbacks. This >> >> >> >>> >>> >> will >> >> >> >>> >>> >> allow >> >> >> >>> >>> >> us to remove the exynos_drm_hdmi shim and support >> >> >> >>> >>> >> mixer/hdmi >> >> >> >>> >>> >> & >> >> >> >>> fimd/dp >> >> >> >>> >>> >> with common code. >> >> >> >>> >>> >> >> >> >> >>> >>> >> Signed-off-by: Sean Paul >> >> >> >>> >>> >> --- >> >> >> >>> >>> >> >> >> >> >>> >>> >> Changes in v2: >> >> >> >>> >>> >> - Pass display into display_ops instead of context >> >> >> >>> >>> > >> >> >> >>> >>> > Sorry but it seems like more reasonable to pass device >> >> >> >>> >>> > object >> >> >> >>> >>> > into >> >> >> >>> >>> > display_ops and manager_ops. >> >> >> >>> >>> > >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> So you've changed your mind from when you said the >> >> >> >>> >>> following? >> >> >> >>> >>> >> >> >> >>> >>> >>> manager->ops->xxx(manager, ...); >> >> >> >>> >>> >>> display->ops->xxx(display, ...); >> >> >> >>> >>> >>> >> >> >> >>> >>> >>> Agree. >> >> >> >>> >>> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> True. Before that, My comment was to pass device object into >> >> >> >>> display_ops and >> >> >> >>> >> manager_ops, and then you said the good solution is to pass >> >> >> >>> >> manager >> >> >> >>> >> and >> >> >> >>> >> display to each driver. At that time, I thought no matter how >> >> >> >>> >> the >> >> >> >>> callback >> >> >> >>> >> is called if the framework doesn't call callbacks of each >> >> >> >>> >> driver >> >> >> >>> >> with >> >> >> >>> ctx. >> >> >> >>> >> So I agreed. >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >>> It would have been nice if you had changed your mind >> >> >> >>> >>> *before* I >> >> >> >>> >>> reworked everything. At any rate, I think it's still the >> >> >> >>> >>> right >> >> >> >>> >>> thing >> >> >> >>> >>> to do. >> >> >> >>> >> >> >> >> >>> >> Really sorry about that. And I will add new patch for it so >> >> >> >>> >> you >> >> >> >>> >> don't >> >> >> >>> need >> >> >> >>> >> to concern about that. >> >> >> >>> >> >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> > I'm not sure but display_ops could be implemented in other >> >> >> >>> >>> > framework >> >> >> >>> >>> based >> >> >> >>> >>> > driver such as CDF based lcd panel driver. So if you pass >> >> >> >>> >>> > display - >> >> >> >>> it's >> >> >> >>> >>> > specific to exynos drm framework - into display_ops, the >> >> >> >>> >>> > other >> >> >> >>> framework >> >> >> >>> >>> > based driver should include specific exynos drm header.
[PATCH] drm/armada: Depend on ARM
The driver uses {readl,writel}_relaxed(), which are not available on all
platforms, so restrict the driver to ARM for now. Fixes a build failure
seen on x86_64 allmodconfig.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/armada/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/armada/Kconfig b/drivers/gpu/drm/armada/Kconfig
index 87e62dd..4b131e7 100644
--- a/drivers/gpu/drm/armada/Kconfig
+++ b/drivers/gpu/drm/armada/Kconfig
@@ -1,6 +1,6 @@
config DRM_ARMADA
tristate "DRM support for Marvell Armada SoCs"
- depends on DRM && HAVE_CLK
+ depends on DRM && ARM && HAVE_CLK
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
--
1.8.4
[Bug 59649] [r600][RV635] GPU lockup CP stall / GPU resets over and over - Kernel 3.7 to 3.12 inclusive
https://bugs.freedesktop.org/show_bug.cgi?id=59649 --- Comment #23 from Shawn Starr --- I'm going to disable tiling in the DDX w/ xorg config option and resume testing -- 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/20131023/4cde8778/attachment-0001.html>
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
2013/10/23 St?phane Marchesin : > > > > On Tue, Oct 22, 2013 at 8:38 PM, Inki Dae wrote: >> >> 2013/10/23 St?phane Marchesin : >> > >> > >> > >> > On Tue, Oct 22, 2013 at 7:28 PM, Inki Dae wrote: >> >> >> >> 2013/10/22 Sean Paul : >> >> > On Tue, Oct 22, 2013 at 1:30 AM, Inki Dae >> >> > wrote: >> >> >> >> >> >> >> >> >>> -Original Message- >> >> >>> From: Sean Paul [mailto:seanpaul at chromium.org] >> >> >>> Sent: Tuesday, October 22, 2013 6:18 AM >> >> >>> To: Inki Dae >> >> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin >> >> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split >> >> >>> manager/display/subdrv >> >> >>> >> >> >>> On Mon, Oct 21, 2013 at 10:46 AM, Sean Paul >> >> >>> wrote: >> >> >>> > On Thu, Oct 17, 2013 at 10:31 PM, Inki Dae >> >> >>> > wrote: >> >> >>> >> >> >> >>> >> >> >> >>> >>> -Original Message- >> >> >>> >>> From: Sean Paul [mailto:seanpaul at chromium.org] >> >> >>> >>> Sent: Thursday, October 17, 2013 11:37 PM >> >> >>> >>> To: Inki Dae >> >> >>> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin >> >> >>> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split >> >> >>> >>> manager/display/subdrv >> >> >>> >>> >> >> >>> >>> On Thu, Oct 17, 2013 at 4:21 AM, Inki Dae >> >> >>> >>> >> >> >> wrote: >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> >> -Original Message- >> >> >>> >>> >> From: Sean Paul [mailto:seanpaul at chromium.org] >> >> >>> >>> >> Sent: Thursday, October 17, 2013 4:27 AM >> >> >>> >>> >> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com >> >> >>> >>> >> Cc: airlied at linux.ie; tomasz.figa at gmail.com; >> >> >>> >>> >> marcheu at chromium.org; >> >> >>> Sean >> >> >>> >>> >> Paul >> >> >>> >>> >> Subject: [PATCH v2 12/26] drm/exynos: Split >> >> >>> >>> >> manager/display/subdrv >> >> >>> >>> >> >> >> >>> >>> >> This patch splits display and manager from subdrv. The >> >> >>> >>> >> result >> >> >>> >>> >> is >> >> >>> that >> >> >>> >>> >> crtc functions can directly call into manager callbacks and >> >> >>> >>> >> encoder >> >> >>> >>> >> functions can directly call into display callbacks. This >> >> >>> >>> >> will >> >> >>> >>> >> allow >> >> >>> >>> >> us to remove the exynos_drm_hdmi shim and support mixer/hdmi >> >> >>> >>> >> & >> >> >>> fimd/dp >> >> >>> >>> >> with common code. >> >> >>> >>> >> >> >> >>> >>> >> Signed-off-by: Sean Paul >> >> >>> >>> >> --- >> >> >>> >>> >> >> >> >>> >>> >> Changes in v2: >> >> >>> >>> >> - Pass display into display_ops instead of context >> >> >>> >>> > >> >> >>> >>> > Sorry but it seems like more reasonable to pass device object >> >> >>> >>> > into >> >> >>> >>> > display_ops and manager_ops. >> >> >>> >>> > >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> So you've changed your mind from when you said the following? >> >> >>> >>> >> >> >>> >>> >>> manager->ops->xxx(manager, ...); >> >> >>> >>> >>> display->ops->xxx(display, ...); >> >> >>> >>> >>> >> >> >>> >>> >>> Agree. >> >> >>> >>> >> >> >>> >> >> >> >>> >> >> >> >>> >> True. Before that, My comment was to pass device object into >> >> >>> display_ops and >> >> >>> >> manager_ops, and then you said the good solution is to pass >> >> >>> >> manager >> >> >>> >> and >> >> >>> >> display to each driver. At that time, I thought no matter how >> >> >>> >> the >> >> >>> callback >> >> >>> >> is called if the framework doesn't call callbacks of each driver >> >> >>> >> with >> >> >>> ctx. >> >> >>> >> So I agreed. >> >> >>> >> >> >> >>> >> >> >> >>> >>> It would have been nice if you had changed your mind *before* I >> >> >>> >>> reworked everything. At any rate, I think it's still the right >> >> >>> >>> thing >> >> >>> >>> to do. >> >> >>> >> >> >> >>> >> Really sorry about that. And I will add new patch for it so you >> >> >>> >> don't >> >> >>> need >> >> >>> >> to concern about that. >> >> >>> >> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> > I'm not sure but display_ops could be implemented in other >> >> >>> >>> > framework >> >> >>> >>> based >> >> >>> >>> > driver such as CDF based lcd panel driver. So if you pass >> >> >>> >>> > display - >> >> >>> it's >> >> >>> >>> > specific to exynos drm framework - into display_ops, the >> >> >>> >>> > other >> >> >>> framework >> >> >>> >>> > based driver should include specific exynos drm header. >> >> >>> >>> > >> >> >>> >>> >> >> >>> >>> AFAIK, CDF will not land in its current separate-from-drm form, >> >> >>> >>> we >> >> >>> >>> don't need to worry about this. Furthermore, these ops should >> >> >>> >>> just >> >> >>> >>> go >> >> >>> >>> away and become drm_crtc/drm_encoder/drm_connector funcs >> >> >>> >>> anyways. >> >> >>> >>> >> >> >>> >> >> >> >>> >> Can you assure the display_ops never implemented in other >> >> >>> >> framework >> >> >>> based >> >> >>> >> driver, not CDF? At any rate, I think all possibilities should >> >> >>> >> be >> >> >>> opened. >> >> >>> >> >> >> >>> > >> >> >>> > I don't think we should let an RFC framework make the
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
2013/10/23 St?phane Marchesin : > > > > On Tue, Oct 22, 2013 at 7:28 PM, Inki Dae wrote: >> >> 2013/10/22 Sean Paul : >> > On Tue, Oct 22, 2013 at 1:30 AM, Inki Dae wrote: >> >> >> >> >> >>> -Original Message- >> >>> From: Sean Paul [mailto:seanpaul at chromium.org] >> >>> Sent: Tuesday, October 22, 2013 6:18 AM >> >>> To: Inki Dae >> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin >> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split manager/display/subdrv >> >>> >> >>> On Mon, Oct 21, 2013 at 10:46 AM, Sean Paul >> >>> wrote: >> >>> > On Thu, Oct 17, 2013 at 10:31 PM, Inki Dae >> >>> > wrote: >> >>> >> >> >>> >> >> >>> >>> -Original Message- >> >>> >>> From: Sean Paul [mailto:seanpaul at chromium.org] >> >>> >>> Sent: Thursday, October 17, 2013 11:37 PM >> >>> >>> To: Inki Dae >> >>> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin >> >>> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split >> >>> >>> manager/display/subdrv >> >>> >>> >> >>> >>> On Thu, Oct 17, 2013 at 4:21 AM, Inki Dae >> >> wrote: >> >>> >>> > >> >>> >>> > >> >>> >>> >> -Original Message- >> >>> >>> >> From: Sean Paul [mailto:seanpaul at chromium.org] >> >>> >>> >> Sent: Thursday, October 17, 2013 4:27 AM >> >>> >>> >> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com >> >>> >>> >> Cc: airlied at linux.ie; tomasz.figa at gmail.com; >> >>> >>> >> marcheu at chromium.org; >> >>> Sean >> >>> >>> >> Paul >> >>> >>> >> Subject: [PATCH v2 12/26] drm/exynos: Split >> >>> >>> >> manager/display/subdrv >> >>> >>> >> >> >>> >>> >> This patch splits display and manager from subdrv. The result >> >>> >>> >> is >> >>> that >> >>> >>> >> crtc functions can directly call into manager callbacks and >> >>> >>> >> encoder >> >>> >>> >> functions can directly call into display callbacks. This will >> >>> >>> >> allow >> >>> >>> >> us to remove the exynos_drm_hdmi shim and support mixer/hdmi & >> >>> fimd/dp >> >>> >>> >> with common code. >> >>> >>> >> >> >>> >>> >> Signed-off-by: Sean Paul >> >>> >>> >> --- >> >>> >>> >> >> >>> >>> >> Changes in v2: >> >>> >>> >> - Pass display into display_ops instead of context >> >>> >>> > >> >>> >>> > Sorry but it seems like more reasonable to pass device object >> >>> >>> > into >> >>> >>> > display_ops and manager_ops. >> >>> >>> > >> >>> >>> >> >>> >>> >> >>> >>> So you've changed your mind from when you said the following? >> >>> >>> >> >>> >>> >>> manager->ops->xxx(manager, ...); >> >>> >>> >>> display->ops->xxx(display, ...); >> >>> >>> >>> >> >>> >>> >>> Agree. >> >>> >>> >> >>> >> >> >>> >> >> >>> >> True. Before that, My comment was to pass device object into >> >>> display_ops and >> >>> >> manager_ops, and then you said the good solution is to pass manager >> >>> >> and >> >>> >> display to each driver. At that time, I thought no matter how the >> >>> callback >> >>> >> is called if the framework doesn't call callbacks of each driver >> >>> >> with >> >>> ctx. >> >>> >> So I agreed. >> >>> >> >> >>> >> >> >>> >>> It would have been nice if you had changed your mind *before* I >> >>> >>> reworked everything. At any rate, I think it's still the right >> >>> >>> thing >> >>> >>> to do. >> >>> >> >> >>> >> Really sorry about that. And I will add new patch for it so you >> >>> >> don't >> >>> need >> >>> >> to concern about that. >> >>> >> >> >>> >>> >> >>> >>> >> >>> >>> > I'm not sure but display_ops could be implemented in other >> >>> >>> > framework >> >>> >>> based >> >>> >>> > driver such as CDF based lcd panel driver. So if you pass >> >>> >>> > display - >> >>> it's >> >>> >>> > specific to exynos drm framework - into display_ops, the other >> >>> framework >> >>> >>> > based driver should include specific exynos drm header. >> >>> >>> > >> >>> >>> >> >>> >>> AFAIK, CDF will not land in its current separate-from-drm form, we >> >>> >>> don't need to worry about this. Furthermore, these ops should just >> >>> >>> go >> >>> >>> away and become drm_crtc/drm_encoder/drm_connector funcs anyways. >> >>> >>> >> >>> >> >> >>> >> Can you assure the display_ops never implemented in other framework >> >>> based >> >>> >> driver, not CDF? At any rate, I think all possibilities should be >> >>> opened. >> >>> >> >> >>> > >> >>> > I don't think we should let an RFC framework make the code more >> >>> > complicated for unclear benefit. By removing manager/display >> >>> > entirely, >> >>> > we can get rid of a *lot* of other code that is basically just >> >>> > plumbing drm hooks (exynos_drm_connector is a good example). >> >>> > >> >>> >> >>> I hacked this up today to prove it out. Check out the top 5 commits in >> >>> >> >>> https://github.com/crseanpaul/exynos-drm-next/commits/linux-next-exynos- >> >>> staging. >> >>> It removes exynos_drm_connector in favor of just implementing >> >>> drm_connector directly. This same treatment should be done for >> >>> exynos_drm_encoder and exynos_drm_crtc, but I didn't get around to >> >>> doing
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie wrote:
>>
>
> I think we need to start considering a framework where subdrivers just
> add drm objects themselves, then the toplevel node is responsible for
> knowing that everything for the current configuration is loaded.
>
It would be nice to specify the various pieces in dt, then have some
type of drm notifier to the toplevel node when everything has been
probed. Doing it in the dt would allow standalone drm_bridge/drm_panel
drivers to be transparent as far as the device's drm driver is
concerned.
Sean
> I realise we may need to make changes to the core drm to allow this
> but we should probably start to create a strategy for fixing the API
> issues that this throws up.
>
> Note I'm not yet advocating for dynamic addition of nodes once the
> device is in use, or removing them.
>
>>>
>>> I do wonder if we had some sort of tag in the device tree for any nodes
>>> involved in the display, and the core drm layer would read that list,
>>> and when every driver registers tick things off, and when the last one
>>> joins we get a callback and init the drm layer, we'd of course have the
>>> basic drm layer setup prior to that so we can add the objects as the
>>> drivers load. It might make development a bit trickier as you'd need
>>> to make sure someone claimed ownership of all the bits for init to proceed.
>>>
>>
>> Yeah, that's basically what the strawman looked like in my head.
>>
>> Instead of a property in each node, I was thinking of having a
>> separate gfx pipe nodes that would have dt pointers to the various
>> pieces involved in that pipe. This would allow us to associate
>> standalone entities like bridges and panels with encoders in dt w/o
>> doing it in the drm code. I *think* this should be Ok with the dt guys
>> since it is still describing the hardware, but I think we'd have to
>> make sure it wasn't drm-specific.
>>
>
> I suppose the question is how much dynamic pipeline construction there is,
>
> even on things like radeon and i915 we have dynamic clock generator to
> crtc to encoder setups, so I worry about static lists per-pipe, so I still
> think just stating all these devices are needed for display and a list of
> valid
> interconnections between them, then we can have the generic code model
> drm crtc/encoders/connectors on that list, and construct the possible_crtcs
> /possible_clones etc at that stage.
>
I'm, without excuse, hopeless at devicetree, so there are probably
some violations, but something like:
display-pipelines {
required-elements = <&bridge-a &panel-a &encoder-x &encoder-y
&crtc-x &crtc-y>;
pipe1 {
bridge = <&bridge-a>;
encoder = <&encoder-x>;
crtc = <&crtc-y>;
};
pipe2 {
encoder = <&encoder-x>;
crtc = <&crtc-x>;
};
pipe3 {
panel = <&panel-a>;
encoder = <&encoder-y>;
crtc = <&crtc-y>;
};
};
I'm tempted to add connector to the pipe nodes as well, so it's
obvious which connector should be used in cases where multiple
entities in the pipe implement drm_connector. However, I'm not sure if
that would be NACKed by dt people.
I'm also not sure if there are too many combinations for i915 and
radeon to make this unreasonable. I suppose those devices could just
use required-elements and leave the pipe nodes out.
Sean
> Dave.
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
2013/10/22 Sean Paul : > On Tue, Oct 22, 2013 at 1:30 AM, Inki Dae wrote: >> >> >>> -Original Message- >>> From: Sean Paul [mailto:seanpaul at chromium.org] >>> Sent: Tuesday, October 22, 2013 6:18 AM >>> To: Inki Dae >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split manager/display/subdrv >>> >>> On Mon, Oct 21, 2013 at 10:46 AM, Sean Paul >>> wrote: >>> > On Thu, Oct 17, 2013 at 10:31 PM, Inki Dae >>> > wrote: >>> >> >>> >> >>> >>> -Original Message- >>> >>> From: Sean Paul [mailto:seanpaul at chromium.org] >>> >>> Sent: Thursday, October 17, 2013 11:37 PM >>> >>> To: Inki Dae >>> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin >>> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split manager/display/subdrv >>> >>> >>> >>> On Thu, Oct 17, 2013 at 4:21 AM, Inki Dae >> wrote: >>> >>> > >>> >>> > >>> >>> >> -Original Message- >>> >>> >> From: Sean Paul [mailto:seanpaul at chromium.org] >>> >>> >> Sent: Thursday, October 17, 2013 4:27 AM >>> >>> >> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com >>> >>> >> Cc: airlied at linux.ie; tomasz.figa at gmail.com; marcheu at >>> >>> >> chromium.org; >>> Sean >>> >>> >> Paul >>> >>> >> Subject: [PATCH v2 12/26] drm/exynos: Split manager/display/subdrv >>> >>> >> >>> >>> >> This patch splits display and manager from subdrv. The result is >>> that >>> >>> >> crtc functions can directly call into manager callbacks and encoder >>> >>> >> functions can directly call into display callbacks. This will allow >>> >>> >> us to remove the exynos_drm_hdmi shim and support mixer/hdmi & >>> fimd/dp >>> >>> >> with common code. >>> >>> >> >>> >>> >> Signed-off-by: Sean Paul >>> >>> >> --- >>> >>> >> >>> >>> >> Changes in v2: >>> >>> >> - Pass display into display_ops instead of context >>> >>> > >>> >>> > Sorry but it seems like more reasonable to pass device object into >>> >>> > display_ops and manager_ops. >>> >>> > >>> >>> >>> >>> >>> >>> So you've changed your mind from when you said the following? >>> >>> >>> >>> >>> manager->ops->xxx(manager, ...); >>> >>> >>> display->ops->xxx(display, ...); >>> >>> >>> >>> >>> >>> Agree. >>> >>> >>> >> >>> >> >>> >> True. Before that, My comment was to pass device object into >>> display_ops and >>> >> manager_ops, and then you said the good solution is to pass manager and >>> >> display to each driver. At that time, I thought no matter how the >>> callback >>> >> is called if the framework doesn't call callbacks of each driver with >>> ctx. >>> >> So I agreed. >>> >> >>> >> >>> >>> It would have been nice if you had changed your mind *before* I >>> >>> reworked everything. At any rate, I think it's still the right thing >>> >>> to do. >>> >> >>> >> Really sorry about that. And I will add new patch for it so you don't >>> need >>> >> to concern about that. >>> >> >>> >>> >>> >>> >>> >>> > I'm not sure but display_ops could be implemented in other framework >>> >>> based >>> >>> > driver such as CDF based lcd panel driver. So if you pass display - >>> it's >>> >>> > specific to exynos drm framework - into display_ops, the other >>> framework >>> >>> > based driver should include specific exynos drm header. >>> >>> > >>> >>> >>> >>> AFAIK, CDF will not land in its current separate-from-drm form, we >>> >>> don't need to worry about this. Furthermore, these ops should just go >>> >>> away and become drm_crtc/drm_encoder/drm_connector funcs anyways. >>> >>> >>> >> >>> >> Can you assure the display_ops never implemented in other framework >>> based >>> >> driver, not CDF? At any rate, I think all possibilities should be >>> opened. >>> >> >>> > >>> > I don't think we should let an RFC framework make the code more >>> > complicated for unclear benefit. By removing manager/display entirely, >>> > we can get rid of a *lot* of other code that is basically just >>> > plumbing drm hooks (exynos_drm_connector is a good example). >>> > >>> >>> I hacked this up today to prove it out. Check out the top 5 commits in >>> https://github.com/crseanpaul/exynos-drm-next/commits/linux-next-exynos- >>> staging. >>> It removes exynos_drm_connector in favor of just implementing >>> drm_connector directly. This same treatment should be done for >>> exynos_drm_encoder and exynos_drm_crtc, but I didn't get around to >>> doing this. >>> >>> As you can see, it cuts out a lot of code and removes an entire >>> abstraction layer. Much nicer :) >>> >> >> It seems that you implements connector in each device driver. Can't they be >> combined as common spot, exynos_connector, again to avoid codes from >> duplicated? :) > > There's nothing of substance being duplicated. Not true. xxx_create_connector is duplicated. > In fact, by getting rid > of the exynos_drm_connector layer, we deleted 150 lines. If you really > take a look at exynos_drm_connector, it's not doing anything useful. No, That is for each driver has no any dependency of drm fra
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
On Wed, Oct 23, 2013 at 11:27 AM, Sean Paul wrote: > On Wed, Oct 23, 2013 at 11:22 AM, Dave Airlie wrote: >> On Wed, Oct 23, 2013 at 3:45 PM, Sean Paul wrote: >>> On Wed, Oct 23, 2013 at 10:29 AM, Dave Airlie wrote: > As I mentioned earlier, display_ops is needed to have no any > dependency of drm framework directly like below, > > DRM Framework >| > Exynos DRM Framework > / | \ > Real device drivers > > In particular, in case of ARM based DRM drivers with separated > devices, I still tend to think it's better design than that device > drivers implement the connector callbacks directly, but I will try to > consider what is the better way. > I think we need to start considering a framework where subdrivers just add drm objects themselves, then the toplevel node is responsible for knowing that everything for the current configuration is loaded. >>> >>> It would be nice to specify the various pieces in dt, then have some >>> type of drm notifier to the toplevel node when everything has been >>> probed. Doing it in the dt would allow standalone drm_bridge/drm_panel >>> drivers to be transparent as far as the device's drm driver is >>> concerned. >>> >>> Sean >>> >>> I realise we may need to make changes to the core drm to allow this but we should probably start to create a strategy for fixing the API issues that this throws up. Note I'm not yet advocating for dynamic addition of nodes once the device is in use, or removing them. >> >> I do wonder if we had some sort of tag in the device tree for any nodes >> involved in the display, and the core drm layer would read that list, >> and when every driver registers tick things off, and when the last one >> joins we get a callback and init the drm layer, we'd of course have the >> basic drm layer setup prior to that so we can add the objects as the >> drivers load. It might make development a bit trickier as you'd need >> to make sure someone claimed ownership of all the bits for init to proceed. >> > > Yeah, that's basically what the strawman looked like in my head. > > Instead of a property in each node, I was thinking of having a > separate gfx pipe nodes that would have dt pointers to the various > pieces involved in that pipe. This would allow us to associate > standalone entities like bridges and panels with encoders in dt w/o > doing it in the drm code. I *think* this should be Ok with the dt guys > since it is still describing the hardware, but I think we'd have to > make sure it wasn't drm-specific. > tl;dr: What Rob said > Sean > >> Dave.
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
On Wed, Oct 23, 2013 at 11:22 AM, Dave Airlie wrote: > On Wed, Oct 23, 2013 at 3:45 PM, Sean Paul wrote: >> On Wed, Oct 23, 2013 at 10:29 AM, Dave Airlie wrote: As I mentioned earlier, display_ops is needed to have no any dependency of drm framework directly like below, DRM Framework | Exynos DRM Framework / | \ Real device drivers In particular, in case of ARM based DRM drivers with separated devices, I still tend to think it's better design than that device drivers implement the connector callbacks directly, but I will try to consider what is the better way. >>> >>> I think we need to start considering a framework where subdrivers just >>> add drm objects themselves, then the toplevel node is responsible for >>> knowing that everything for the current configuration is loaded. >>> >> >> It would be nice to specify the various pieces in dt, then have some >> type of drm notifier to the toplevel node when everything has been >> probed. Doing it in the dt would allow standalone drm_bridge/drm_panel >> drivers to be transparent as far as the device's drm driver is >> concerned. >> >> Sean >> >> >>> I realise we may need to make changes to the core drm to allow this >>> but we should probably start to create a strategy for fixing the API >>> issues that this throws up. >>> >>> Note I'm not yet advocating for dynamic addition of nodes once the >>> device is in use, or removing them. >>> > > I do wonder if we had some sort of tag in the device tree for any nodes > involved in the display, and the core drm layer would read that list, > and when every driver registers tick things off, and when the last one > joins we get a callback and init the drm layer, we'd of course have the > basic drm layer setup prior to that so we can add the objects as the > drivers load. It might make development a bit trickier as you'd need > to make sure someone claimed ownership of all the bits for init to proceed. > Yeah, that's basically what the strawman looked like in my head. Instead of a property in each node, I was thinking of having a separate gfx pipe nodes that would have dt pointers to the various pieces involved in that pipe. This would allow us to associate standalone entities like bridges and panels with encoders in dt w/o doing it in the drm code. I *think* this should be Ok with the dt guys since it is still describing the hardware, but I think we'd have to make sure it wasn't drm-specific. Sean > Dave.
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
On Wed, Oct 23, 2013 at 11:22 AM, Dave Airlie wrote: > On Wed, Oct 23, 2013 at 3:45 PM, Sean Paul wrote: >> On Wed, Oct 23, 2013 at 10:29 AM, Dave Airlie wrote: As I mentioned earlier, display_ops is needed to have no any dependency of drm framework directly like below, DRM Framework | Exynos DRM Framework / | \ Real device drivers In particular, in case of ARM based DRM drivers with separated devices, I still tend to think it's better design than that device drivers implement the connector callbacks directly, but I will try to consider what is the better way. >>> >>> I think we need to start considering a framework where subdrivers just >>> add drm objects themselves, then the toplevel node is responsible for >>> knowing that everything for the current configuration is loaded. >>> >> >> It would be nice to specify the various pieces in dt, then have some >> type of drm notifier to the toplevel node when everything has been >> probed. Doing it in the dt would allow standalone drm_bridge/drm_panel >> drivers to be transparent as far as the device's drm driver is >> concerned. >> >> Sean >> >> >>> I realise we may need to make changes to the core drm to allow this >>> but we should probably start to create a strategy for fixing the API >>> issues that this throws up. >>> >>> Note I'm not yet advocating for dynamic addition of nodes once the >>> device is in use, or removing them. >>> > > I do wonder if we had some sort of tag in the device tree for any nodes > involved in the display, and the core drm layer would read that list, > and when every driver registers tick things off, and when the last one > joins we get a callback and init the drm layer, we'd of course have the > basic drm layer setup prior to that so we can add the objects as the > drivers load. It might make development a bit trickier as you'd need > to make sure someone claimed ownership of all the bits for init to proceed. I think we do definitely need a way to group nodes so we know what needs to be assembled into a drm driver. I know folks seem to believe that DT should be software agnostic, but maybe we just need some grouper nodes that sit on the side and know how to map device DT nodes to software. (The real funny thing about needing that is.. well I've yet to see someone be able to hot-unplug a block on a piece of silicon.) BR, -R > Dave. > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
On Wed, Oct 23, 2013 at 9:18 AM, Inki Dae wrote: > Look at omapdrm, nouveau, and radeon drm drivers. btw, please don't look at omapdrm as a "good" example in this regard. The layering is really not a good idea and for a long time caused a lot of problems, which we essentially solved by bypassing parts of the layering. I still think omapdss and omapdrm should be flattened into a single drm driver, then net result would be a drop in # of lines of code. I wish there were folks like the Sean and St?phane who cared enough to do this for omapdrm ;-) Other drivers have some modularity to separate code that is significantly different across genarations (but what form that takes differs depending on what how the hw differs across generations). This isn't a bad thing. But you need to look at the end result. For example how I split out the phy code for the mdp4 code in msm (hdmi and dsi phy differ between otherwise similar 28nm and 45nm parts, but the rest of the display controller blocks are basically the same). BR, -R
[Patch v2][ 03/37] drm: Add the lacking DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*
On Thu, Oct 17, 2013 at 10:02 AM, Denis Carikli wrote: > Without that fix, drivers using the drm_display_mode_from_videomode > function will not be able to get certain information because > some DISPLAY_FLAGS_* have no corresponding DRM_MODE_FLAG_*. > > Cc: Greg Kroah-Hartman > Cc: driverdev-devel at linuxdriverproject.org > Cc: David Airlie > Cc: dri-devel at lists.freedesktop.org > Cc: linux-arm-kernel at lists.infradead.org > Cc: Fabio Estevam > Cc: Sascha Hauer > Cc: linux-arm-kernel at lists.infradead.org > Cc: Eric B?nard > Signed-off-by: Denis Carikli > --- > drivers/gpu/drm/drm_modes.c |9 + > include/uapi/drm/drm_mode.h |4 > 2 files changed, 13 insertions(+) > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > index b073315..353aaae 100644 > --- a/drivers/gpu/drm/drm_modes.c > +++ b/drivers/gpu/drm/drm_modes.c > @@ -537,6 +537,15 @@ int drm_display_mode_from_videomode(const struct > videomode *vm, > dmode->flags |= DRM_MODE_FLAG_DBLSCAN; > if (vm->flags & DISPLAY_FLAGS_DOUBLECLK) > dmode->flags |= DRM_MODE_FLAG_DBLCLK; > + if (vm->flags & DISPLAY_FLAGS_DE_LOW) > + dmode->flags |= DRM_MODE_FLAG_NDATEN; > + if (vm->flags & DISPLAY_FLAGS_DE_HIGH) > + dmode->flags |= DRM_MODE_FLAG_PDATEN; > + if (vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE) > + dmode->flags |= DRM_MODE_FLAG_PPIXDATEDGE; > + if (vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE) > + dmode->flags |= DRM_MODE_FLAG_NPIXDATEDGE; Is there any reason these aren't named after the original DISPLAY_FLAGS? DRM_MODE_FLAG_PIXDATA_POSEDGE is easier to get your head around if you know it is mapped from the DISPLAY_FLAGS_ version. PDATEN and PPIXDATEDGE don't exactly map to things like EDID field names either.. > +#define DRM_MODE_FLAG_PPIXDATEDGE (1<<24) > +#define DRM_MODE_FLAG_NPIXDATEDGE (1<<25) -- Matt Sealey
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
On Wed, Oct 23, 2013 at 10:29 AM, Dave Airlie wrote: >> As I mentioned earlier, display_ops is needed to have no any >> dependency of drm framework directly like below, >> >> DRM Framework >>| >> Exynos DRM Framework >> / | \ >> Real device drivers >> >> In particular, in case of ARM based DRM drivers with separated >> devices, I still tend to think it's better design than that device >> drivers implement the connector callbacks directly, but I will try to >> consider what is the better way. >> > > I think we need to start considering a framework where subdrivers just > add drm objects themselves, then the toplevel node is responsible for > knowing that everything for the current configuration is loaded. > It would be nice to specify the various pieces in dt, then have some type of drm notifier to the toplevel node when everything has been probed. Doing it in the dt would allow standalone drm_bridge/drm_panel drivers to be transparent as far as the device's drm driver is concerned. Sean > I realise we may need to make changes to the core drm to allow this > but we should probably start to create a strategy for fixing the API > issues that this throws up. > > Note I'm not yet advocating for dynamic addition of nodes once the > device is in use, or removing them. > > Dave.
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
On Wed, Oct 23, 2013 at 1:42 AM, Inki Dae wrote: > 2013/10/23 Sean Paul : >> On Wed, Oct 23, 2013 at 12:48 AM, Inki Dae wrote: >>> 2013/10/23 St?phane Marchesin : On Tue, Oct 22, 2013 at 9:15 PM, Inki Dae wrote: > > 2013/10/23 St?phane Marchesin : > > > > > > > > On Tue, Oct 22, 2013 at 8:38 PM, Inki Dae > > wrote: > >> > >> 2013/10/23 St?phane Marchesin : > >> > > >> > > >> > > >> > On Tue, Oct 22, 2013 at 7:28 PM, Inki Dae > >> > wrote: > >> >> > >> >> 2013/10/22 Sean Paul : > >> >> > On Tue, Oct 22, 2013 at 1:30 AM, Inki Dae >> >> > samsung.com> > >> >> > wrote: > >> >> >> > >> >> >> > >> >> >>> -Original Message- > >> >> >>> From: Sean Paul [mailto:seanpaul at chromium.org] > >> >> >>> Sent: Tuesday, October 22, 2013 6:18 AM > >> >> >>> To: Inki Dae > >> >> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin > >> >> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split > >> >> >>> manager/display/subdrv > >> >> >>> > >> >> >>> On Mon, Oct 21, 2013 at 10:46 AM, Sean Paul > >> >> >>> > >> >> >>> wrote: > >> >> >>> > On Thu, Oct 17, 2013 at 10:31 PM, Inki Dae > >> >> >>> > > >> >> >>> > wrote: > >> >> >>> >> > >> >> >>> >> > >> >> >>> >>> -Original Message- > >> >> >>> >>> From: Sean Paul [mailto:seanpaul at chromium.org] > >> >> >>> >>> Sent: Thursday, October 17, 2013 11:37 PM > >> >> >>> >>> To: Inki Dae > >> >> >>> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin > >> >> >>> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split > >> >> >>> >>> manager/display/subdrv > >> >> >>> >>> > >> >> >>> >>> On Thu, Oct 17, 2013 at 4:21 AM, Inki Dae > >> >> >>> >>> > >> >> >> wrote: > >> >> >>> >>> > > >> >> >>> >>> > > >> >> >>> >>> >> -Original Message- > >> >> >>> >>> >> From: Sean Paul [mailto:seanpaul at chromium.org] > >> >> >>> >>> >> Sent: Thursday, October 17, 2013 4:27 AM > >> >> >>> >>> >> To: dri-devel at lists.freedesktop.org; inki.dae at > >> >> >>> >>> >> samsung.com > >> >> >>> >>> >> Cc: airlied at linux.ie; tomasz.figa at gmail.com; > >> >> >>> >>> >> marcheu at chromium.org; > >> >> >>> Sean > >> >> >>> >>> >> Paul > >> >> >>> >>> >> Subject: [PATCH v2 12/26] drm/exynos: Split > >> >> >>> >>> >> manager/display/subdrv > >> >> >>> >>> >> > >> >> >>> >>> >> This patch splits display and manager from subdrv. The > >> >> >>> >>> >> result > >> >> >>> >>> >> is > >> >> >>> that > >> >> >>> >>> >> crtc functions can directly call into manager callbacks > >> >> >>> >>> >> and > >> >> >>> >>> >> encoder > >> >> >>> >>> >> functions can directly call into display callbacks. This > >> >> >>> >>> >> will > >> >> >>> >>> >> allow > >> >> >>> >>> >> us to remove the exynos_drm_hdmi shim and support > >> >> >>> >>> >> mixer/hdmi > >> >> >>> >>> >> & > >> >> >>> fimd/dp > >> >> >>> >>> >> with common code. > >> >> >>> >>> >> > >> >> >>> >>> >> Signed-off-by: Sean Paul > >> >> >>> >>> >> --- > >> >> >>> >>> >> > >> >> >>> >>> >> Changes in v2: > >> >> >>> >>> >> - Pass display into display_ops instead of context > >> >> >>> >>> > > >> >> >>> >>> > Sorry but it seems like more reasonable to pass device > >> >> >>> >>> > object > >> >> >>> >>> > into > >> >> >>> >>> > display_ops and manager_ops. > >> >> >>> >>> > > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> So you've changed your mind from when you said the > >> >> >>> >>> following? > >> >> >>> >>> > >> >> >>> >>> >>> manager->ops->xxx(manager, ...); > >> >> >>> >>> >>> display->ops->xxx(display, ...); > >> >> >>> >>> >>> > >> >> >>> >>> >>> Agree. > >> >> >>> >>> > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> True. Before that, My comment was to pass device object into > >> >> >>> display_ops and > >> >> >>> >> manager_ops, and then you said the good solution is to pass > >> >> >>> >> manager > >> >> >>> >> and > >> >> >>> >> display to each driver. At that time, I thought no matter how > >> >> >>> >> the > >> >> >>> callback > >> >> >>> >> is called if the framework doesn't call callbacks of each > >> >> >>> >> driver > >> >> >>> >> with > >> >> >>> ctx. > >> >> >>> >> So I agreed. > >> >> >>> >> > >> >> >>> >> > >> >> >>> >>> It would have been nice if you had changed your mind > >> >> >>> >>> *before* I > >> >> >>> >>> reworked everything. At any rate, I think it's still the > >> >> >>> >>> right > >> >> >>> >>> thing > >> >> >>> >>> to do. > >> >> >>> >> > >> >> >>> >> Really sorry about that. And I will add new patch for it so > >> >> >>> >> you > >> >> >>> >> don't > >>
[Bug 70778] OpenGL always hangs
https://bugs.freedesktop.org/show_bug.cgi?id=70778 Michel D?nzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Michel D?nzer --- I don't think there's much point in worrying about OpenGL before we even try not to use shader blocks which didn't pass hardware validation. *** This bug has been marked as a duplicate of bug 60879 *** -- 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/20131023/cf2529e7/attachment-0001.html>
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #50 from Michel D?nzer --- *** Bug 70778 has been marked as a duplicate of this bug. *** -- 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/20131023/ed8fb01e/attachment-0001.html>
[Bug 52952] Ubuntu 10.04.4 LTS 32-bit and ATI Technologies Radeon Xpress 200 for Intel (RC410) ACPI S3 State Resume Failure
https://bugs.freedesktop.org/show_bug.cgi?id=52952 Daniel T. changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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/20131023/1a94ec4a/attachment.html>
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
On Wed, Oct 23, 2013 at 12:48 AM, Inki Dae wrote: > 2013/10/23 St?phane Marchesin : >> >> >> >> On Tue, Oct 22, 2013 at 9:15 PM, Inki Dae wrote: >>> >>> 2013/10/23 St?phane Marchesin : >>> > >>> > >>> > >>> > On Tue, Oct 22, 2013 at 8:38 PM, Inki Dae wrote: >>> >> >>> >> 2013/10/23 St?phane Marchesin : >>> >> > >>> >> > >>> >> > >>> >> > On Tue, Oct 22, 2013 at 7:28 PM, Inki Dae >>> >> > wrote: >>> >> >> >>> >> >> 2013/10/22 Sean Paul : >>> >> >> > On Tue, Oct 22, 2013 at 1:30 AM, Inki Dae >>> >> >> > wrote: >>> >> >> >> >>> >> >> >> >>> >> >> >>> -Original Message- >>> >> >> >>> From: Sean Paul [mailto:seanpaul at chromium.org] >>> >> >> >>> Sent: Tuesday, October 22, 2013 6:18 AM >>> >> >> >>> To: Inki Dae >>> >> >> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin >>> >> >> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split >>> >> >> >>> manager/display/subdrv >>> >> >> >>> >>> >> >> >>> On Mon, Oct 21, 2013 at 10:46 AM, Sean Paul >>> >> >> >>> >>> >> >> >>> wrote: >>> >> >> >>> > On Thu, Oct 17, 2013 at 10:31 PM, Inki Dae >>> >> >> >>> > >>> >> >> >>> > wrote: >>> >> >> >>> >> >>> >> >> >>> >> >>> >> >> >>> >>> -Original Message- >>> >> >> >>> >>> From: Sean Paul [mailto:seanpaul at chromium.org] >>> >> >> >>> >>> Sent: Thursday, October 17, 2013 11:37 PM >>> >> >> >>> >>> To: Inki Dae >>> >> >> >>> >>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin >>> >> >> >>> >>> Subject: Re: [PATCH v2 12/26] drm/exynos: Split >>> >> >> >>> >>> manager/display/subdrv >>> >> >> >>> >>> >>> >> >> >>> >>> On Thu, Oct 17, 2013 at 4:21 AM, Inki Dae >>> >> >> >>> >>> >>> >> >> >> wrote: >>> >> >> >>> >>> > >>> >> >> >>> >>> > >>> >> >> >>> >>> >> -Original Message- >>> >> >> >>> >>> >> From: Sean Paul [mailto:seanpaul at chromium.org] >>> >> >> >>> >>> >> Sent: Thursday, October 17, 2013 4:27 AM >>> >> >> >>> >>> >> To: dri-devel at lists.freedesktop.org; inki.dae at >>> >> >> >>> >>> >> samsung.com >>> >> >> >>> >>> >> Cc: airlied at linux.ie; tomasz.figa at gmail.com; >>> >> >> >>> >>> >> marcheu at chromium.org; >>> >> >> >>> Sean >>> >> >> >>> >>> >> Paul >>> >> >> >>> >>> >> Subject: [PATCH v2 12/26] drm/exynos: Split >>> >> >> >>> >>> >> manager/display/subdrv >>> >> >> >>> >>> >> >>> >> >> >>> >>> >> This patch splits display and manager from subdrv. The >>> >> >> >>> >>> >> result >>> >> >> >>> >>> >> is >>> >> >> >>> that >>> >> >> >>> >>> >> crtc functions can directly call into manager callbacks >>> >> >> >>> >>> >> and >>> >> >> >>> >>> >> encoder >>> >> >> >>> >>> >> functions can directly call into display callbacks. This >>> >> >> >>> >>> >> will >>> >> >> >>> >>> >> allow >>> >> >> >>> >>> >> us to remove the exynos_drm_hdmi shim and support >>> >> >> >>> >>> >> mixer/hdmi >>> >> >> >>> >>> >> & >>> >> >> >>> fimd/dp >>> >> >> >>> >>> >> with common code. >>> >> >> >>> >>> >> >>> >> >> >>> >>> >> Signed-off-by: Sean Paul >>> >> >> >>> >>> >> --- >>> >> >> >>> >>> >> >>> >> >> >>> >>> >> Changes in v2: >>> >> >> >>> >>> >> - Pass display into display_ops instead of context >>> >> >> >>> >>> > >>> >> >> >>> >>> > Sorry but it seems like more reasonable to pass device >>> >> >> >>> >>> > object >>> >> >> >>> >>> > into >>> >> >> >>> >>> > display_ops and manager_ops. >>> >> >> >>> >>> > >>> >> >> >>> >>> >>> >> >> >>> >>> >>> >> >> >>> >>> So you've changed your mind from when you said the >>> >> >> >>> >>> following? >>> >> >> >>> >>> >>> >> >> >>> >>> >>> manager->ops->xxx(manager, ...); >>> >> >> >>> >>> >>> display->ops->xxx(display, ...); >>> >> >> >>> >>> >>> >>> >> >> >>> >>> >>> Agree. >>> >> >> >>> >>> >>> >> >> >>> >> >>> >> >> >>> >> >>> >> >> >>> >> True. Before that, My comment was to pass device object into >>> >> >> >>> display_ops and >>> >> >> >>> >> manager_ops, and then you said the good solution is to pass >>> >> >> >>> >> manager >>> >> >> >>> >> and >>> >> >> >>> >> display to each driver. At that time, I thought no matter how >>> >> >> >>> >> the >>> >> >> >>> callback >>> >> >> >>> >> is called if the framework doesn't call callbacks of each >>> >> >> >>> >> driver >>> >> >> >>> >> with >>> >> >> >>> ctx. >>> >> >> >>> >> So I agreed. >>> >> >> >>> >> >>> >> >> >>> >> >>> >> >> >>> >>> It would have been nice if you had changed your mind >>> >> >> >>> >>> *before* I >>> >> >> >>> >>> reworked everything. At any rate, I think it's still the >>> >> >> >>> >>> right >>> >> >> >>> >>> thing >>> >> >> >>> >>> to do. >>> >> >> >>> >> >>> >> >> >>> >> Really sorry about that. And I will add new patch for it so >>> >> >> >>> >> you >>> >> >> >>> >> don't >>> >> >> >>> need >>> >> >> >>> >> to concern about that. >>> >> >> >>> >> >>> >> >> >>> >>> >>> >> >> >>> >>> >>> >> >> >>> >>> > I'm not sure but display_ops could be implemented in other >>> >> >> >>> >>> > framework >>> >> >> >>> >>> based >>> >> >> >>> >>> > driver such as CDF based lcd panel driver. So if you pass >>> >> >> >>> >>> > display - >>> >> >> >>> it's >>> >>
