date:20121224

https://bugs.freedesktop.org/show_bug.cgi?id=56405

--- Comment #53 from runetmember at gmail.com ---
Yesterday I installed 3.8rc1 and also can confirm - fix works for me too.
Thanks!

Michael, if you also doesn't have this problem anymore please close the ticket.

-- 
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/20121224/d4acf2e8/attachment.html>

DRM NOUVEAU: cannot boot with kernel >=3.7

2012-12-24 Thread baldu...@units.it

hello everybody,

apologies if I am missing any blatant point; my knowledge about
KMS/DRM etc. is very poor, so I am asking for help here (hoping to be
at the right place)

Starting with kernel-3.7 I am not able to boot any more in KMS: as
soon as the screen resolution changes in the very early stage of the
boot, the machine freezes and the only option I'm left with is to
press a physical reset button.

I am on an athlon64 dual core machine and using DRM/NOUVEAU with a
NVIDIA GeForce 6200 LE GPU

Here are some facts:

=> while kernel-3.7.x gives the problems mentioned above,
   kernel-3.6.{8-10} boots just fine (and X11 works nicely)
=> if it can be of any use: if I reboot from a running 3.6.x kernel
   into a 3.7.x, the obtained freezed console screen shows the (somewhat
   misplaced) lines which were printed during the shutdown phase of
   the reboot process (I can send a screen photo, if needed)
=> kernel-3.7.x boots just fine on another box (another athlon64 dual core with
   a GeForce 6150SE nForce 430 (rev a2) GPU); kernel is 32bit there,
   if it matters

I am attaching lspci output and my kernel config below.

I will warmly appreciate any hint and will be more than happy to send
in any other information which might be useful


thank you very much  in advance

ciao
gabriele

---8<---8<---8<---8<---8<
00:00.0 Host bridge: Advanced Micro Devices [AMD] nee ATI RS480 Host Bridge 
(rev 01)
Subsystem: ASRock Incorporation Device 5950
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v1) Root Port (Slot-), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, 
L1 <1us
ExtTag+ RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency 
L0 <64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ 
DLActive- BWMgmt- ABWMgmt-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- 
CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID , PMEStatus- PMEPending-
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address:   Data: 
Capabilities: [b0] Subsystem: ASRock Incorporation Device 5a34
Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+

00:05.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RS480 PCI Bridge 
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v1) Root Port (Slot-), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, 
L1 <1us
ExtTag+ RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
TransPend-
LnkCap: Port #2, Speed 2.5GT/s, Width x2, ASPM L0s L1, Latency 
L0 <64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ 
DLActive- BWMgmt- ABWMgmt-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- 
CRSVisible-
RootCap: CRSVisible

Re: [PATCHv4 5/8] drm: tegra: Remove redundant host1x

2012-12-24 Thread Stephen Warren

On 12/21/2012 11:50 PM, Terje Bergström wrote:
> On 21.12.2012 16:36, Thierry Reding wrote:
>> On Fri, Dec 21, 2012 at 01:39:21PM +0200, Terje Bergstrom wrote:
>>> +static struct platform_driver tegra_drm_platform_driver = {
>>> +   .driver = {
>>> +   .name = "tegradrm",
>>
>> This should be "tegra-drm" to match the module name.
> 
> We've actually created two problems.
> 
> First is that the device name should match driver name which should
> match module name. But host1x doesn't know the module name of tegradrm.

There's no hard requirement for the device/driver name to match the
module name. It's good thing to do, but nothing will blow up if it don't
(modules can use MODULE_ALIAS() to declare which drivers they expose).

But, what's the problem with host1x knowing the driver name; the host1x
driver and tegradrm driver are both part of the same code-base, so this
seems trivial to achieve.

> Second problem is that host1x driver creates tegradrm device even if
> tegradrm isn't loaded to system.

That's fine. If there's no driver, the device simply won't be probe()d.
That's just like a device node existing in device tree, but the driver
for it not being enabled in the kernel, or the relevant module not being
inserted.

> These mean that the device has to be created in tegra-drm module to have

I definitely disagree here.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58734] New: Dungeon Defenders fails to launch crash

https://bugs.freedesktop.org/show_bug.cgi?id=58734

  Priority: medium
Bug ID: 58734
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Dungeon Defenders fails to launch crash
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: kphilli...@gmail.com
   URL: https://bugzilla.icculus.org/show_bug.cgi?id=5823
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

The recently released version of Dungeon defenders for linux is poor at best.
Currently the game fails to launch due to missing extensions... For now, the
first extension missing is GL_EXT_bindable_uniform.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56405] Distorted graphics on Radeon HD 6620G

https://bugs.freedesktop.org/show_bug.cgi?id=56405

--- Comment #52 from Johannes Hirte  ---
Fix works for me.

-- 
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/20121224/389911c8/attachment.html>

[Bug 58724] [r600g] [bisected]: "rework flusing ...v7" commit by Jerome causes problems

https://bugs.freedesktop.org/show_bug.cgi?id=58724

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Alex Deucher  ---


*** This bug has been marked as a duplicate of bug 58655 ***

-- 
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/20121224/cd0ae29b/attachment.html>

[Bug 58655] Screen totally corrupted on CAYMAN, [drm : evergreen_vm_reg_valid] ERROR Invalid register 0x8040 in CS

https://bugs.freedesktop.org/show_bug.cgi?id=58655

Alex Deucher  changed:

   What|Removed |Added

 CC||dcherkassov at gmail.com

--- Comment #4 from Alex Deucher  ---
*** Bug 58724 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/20121224/007d9ae5/attachment.html>

[Bug 58724] [r600g] [bisected]: "rework flusing ...v7" commit by Jerome causes problems

https://bugs.freedesktop.org/show_bug.cgi?id=58724

--- Comment #1 from Dmitry Cherkassov  ---
Forgot to add:
* The device is Radeon HD 6970 (cayman)
* Kernel is 3.7.0-rc5 (tip of Alex's drm-fixes-3.7 branch)

-- 
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/20121224/7e42f57f/attachment.html>

[Bug 58724] New: [r600g] [bisected]: "rework flusing ...v7" commit by Jerome causes problems

https://bugs.freedesktop.org/show_bug.cgi?id=58724

  Priority: medium
Bug ID: 58724
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [r600g] [bisected]: "rework flusing ...v7" commit by
Jerome causes problems
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: dcherkassov at gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 72082
  --> https://bugs.freedesktop.org/attachment.cgi?id=72082&action=edit
summary of ./configure

Hi. I've found by git-bisect that this commit causes problems with glxgears and
other stuff:

24b1206ab2dcd506aaac3ef656aebc8bc20cd27a is the first bad commit
commit 24b1206ab2dcd506aaac3ef656aebc8bc20cd27a
Author: Jerome Glisse 
Date:   Thu Nov 1 16:09:40 2012 -0400

r600g: rework flusing and synchronization pattern v7


The glxgears picture is crippled with no animation.

that's mesa runtime error:
> radeon: The kernel rejected CS, see dmesg for more information.

That's what kernel driver says:
> [20056.450057] [drm:evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 
> in CS

System is 64-bit debian.

Build flags are:
PKG_CONFIG_PATH=/opt/lib/pkgconfig ./autogen.sh --enable-texture-float
--with-dri-drivers="" --prefix=/opt --with-gallium-drivers=r600 --enable-debug

llvm is 3.2 from tstellard's branch (HEAD:
15265bc80edeceb5bcfc4d0b85be751be9275a7d )

-- 
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/20121224/ed222fcc/attachment-0001.html>

[RFC v2 0/5] Common Display Framework

Hi Rob,

(CC'ing Hans Verkuil)

On Wednesday 19 December 2012 10:05:27 Rob Clark wrote:
> On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen wrote:
> > On 2012-12-19 17:26, Rob Clark wrote:
> >> And, there are also external HDMI encoders (for example connected over
> >> i2c) that can also be shared between boards.  So I think there will be
> >> a number of cases where CDF is appropriate for HDMI drivers.  Although
> >> trying to keep this all independent of DRM (as opposed to just something
> >> similar to what drivers/gpu/i2c is today) seems a bit overkill for me. 
> >> Being able to use the helpers in drm and avoiding an extra layer of
> >> translation seems like the better option to me.  So my vote would be
> >> drivers/gpu/cdf.
> > 
> > Well, we need to think about that. I would like to keep CDF independent
> > of DRM. I don't like tying different components/frameworks together if
> > there's no real need for that.
> > 
> > Also, something that Laurent mentioned in our face-to-face discussions:
> > Some IPs/chips can be used for other purposes than with DRM.
> > 
> > He had an example of a board, that (if I understood right) gets video
> > signal from somewhere outside the board, processes the signal with some
> > IPs/chips, and then outputs the signal. So there's no framebuffer, and
> > the image is not stored anywhere. I think the framework used in these
> > cases is always v4l2.
> > 
> > The IPs/chips in the above model may be the exact same IPs/chips that
> > are used with "normal" display. If the CDF was tied to DRM, using the
> > same drivers for normal and these streaming cases would probably not be
> > possible.
> 
> Well, maybe there is a way, but it really seems to be over-complicating
> things unnecessarily to keep CDF independent of DRM..  there will be a lot
> more traditional uses of CDF compared to one crazy use-case.  So I don't
> really fancy making it more difficult than in needs to be for everyone.

Most of the use cases will be in DRM, we agree on that. However, I don't think 
that the use case mentioned by Tomi is in any way crazy. TI has DaVinci chips 
that can process/capture/generate up to 18 (if my memory is correct) video 
streams, and those are extensively used in video conferencing solutions or set 
top boxes for instance. A couple of the output video streams are display-based 
and should be handled by DRM/KMS, but most of them are V4L2 streams. That's 
something we should discuss with Hans Verkuil, he might be able to provide us 
with more information.

> Probably the thing to do is take a step back and reconsider that one crazy
> use-case.  For example, KMS doesn't enforce that the buffer handled passed
> when you create a drm framebuffer object to scan out is a GEM buffer.  So on
> that one crazy platform, maybe it makes sense to have a DRM/KMS display
> driver that takes a handle to identify which video stream coming from the
> capture end of the pipeline.  Anyways, that is just an off-the-top-of-my-
> head idea, probably there are other options too.

-- 
Regards,

Laurent Pinchart

[RFC v2 0/5] Common Display Framework

Hi Rob,

On Wednesday 19 December 2012 09:26:40 Rob Clark wrote:
> On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula wrote:
> > On Tue, 18 Dec 2012, Laurent Pinchart wrote:
> >> On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
> >>> I can see the need for a framework for DSI panels and such (in fact Tomi
> >>> and I have talked about it like 2-3 years ago already!) but what is the
> >>> story for HDMI and DP? In particular, what's the relationship between
> >>> DRM and CDF here? Is there a world domination plan to switch the DRM
> >>> drivers to use this framework too? ;) Do you have some rough plans how
> >>> DRM and CDF should work together in general?
> >> 
> >> There's always a world domination plan, isn't there ? :-)
> >> 
> >> I certainly want CDF to be used by DRM (or more accurately KMS). That's
> >> what the C stands for, common refers to sharing panel and other display
> >> entity drivers between FBDEV, KMS and V4L2.
> >> 
> >> I currently have no plan to expose CDF internals to userspace through the
> >> KMS API. We might have to do so later if the hardware complexity grows
> >> in such a way that finer control than what KMS provides needs to be
> >> exposed to userspace, but I don't think we're there yet. The CDF API
> >> will thus only be used internally in the kernel by display controller
> >> drivers. The KMS core might get functions to handle common display
> >> entity operations, but the bulk of the work will be in the display
> >> controller drivers to start with. We will then see what can be
> >> abstracted in KMS helper functions.
> >> 
> >> Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the
> >> CDF API. That's just a thought for now, I haven't tried to implement
> >> them, but it would be nice to handle HDMI screens and DPI/DBI/DSI panels
> >> in a generic way.
> >> 
> >> Do you have thoughts to share on this topic ?
> > 
> > It just seems to me that, at least from a DRM/KMS perspective, adding
> > another layer (=CDF) for HDMI or DP (or legacy outputs) would be
> > overengineering it. They are pretty well standardized, and I don't see
> > there would be a need to write multiple display drivers for them. Each
> > display controller has one, and can easily handle any chip specific
> > requirements right there. It's my gut feeling that an additional
> > framework would just get in the way. Perhaps there could be more common
> > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers,
> > but that's another thing.
> > 
> > So is the HDMI/DP drivers using CDF a more interesting idea from a
> > non-DRM perspective? Or, put another way, is it more of an alternative
> > to using DRM? Please enlighten me if there's some real benefit here that
> > I fail to see!
> 
> fwiw, I think there are at least a couple cases where multiple SoC's
> have the same HDMI IP block.
> 
> And, there are also external HDMI encoders (for example connected over
> i2c) that can also be shared between boards.  So I think there will be
> a number of cases where CDF is appropriate for HDMI drivers.  Although
> trying to keep this all independent of DRM (as opposed to just
> something similar to what drivers/gpu/i2c is today) seems a bit
> overkill for me.  Being able to use the helpers in drm and avoiding an
> extra layer of translation seems like the better option to me.  So my
> vote would be drivers/gpu/cdf.

I don't think there will be any need for translation (except perhaps between 
the DRM mode structures and the common video mode structure that is being 
discussed). Add a drm_ prefix to the existing CDF functions and structures, 
and there you go :-)

The reason why I'd like to keep CDF separate from DRM (or at least not 
requiring a drm_device) is that HDMI/DP encoders can be used by pure V4L2 
drivers.

> > For DSI panels (or DSI-to-whatever bridges) it's of course another
> > story. You typically need a panel specific driver. And here I see the
> > main point of the whole CDF: decoupling display controllers and the
> > panel drivers, and sharing panel (and converter chip) specific drivers
> > across display controllers. Making it easy to write new drivers, as
> > there would be a model to follow. I'm definitely in favour of coming up
> > with some framework that would tackle that.

-- 
Regards,

Laurent Pinchart

[RFC v2 0/5] Common Display Framework

Hi Tomi,

On Wednesday 19 December 2012 17:07:50 Tomi Valkeinen wrote:
> On 2012-12-19 16:57, Jani Nikula wrote:
> > It just seems to me that, at least from a DRM/KMS perspective, adding
> > another layer (=CDF) for HDMI or DP (or legacy outputs) would be
> > overengineering it. They are pretty well standardized, and I don't see
> > there would be a need to write multiple display drivers for them. Each
> > display controller has one, and can easily handle any chip specific
> > requirements right there. It's my gut feeling that an additional
> > framework would just get in the way. Perhaps there could be more common
> > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers,
> > but that's another thing.
> > 
> > So is the HDMI/DP drivers using CDF a more interesting idea from a
> > non-DRM perspective? Or, put another way, is it more of an alternative
> > to using DRM? Please enlighten me if there's some real benefit here that
> > I fail to see!
> 
> The use of CDF is an option, not something that has to be done. A DRM
> driver developer may use it if it gives benefit for him for that
> particular driver.
> 
> I don't know much about desktop display hardware, but I guess that using
> CDF would not really give much there. In some cases it could, if the IPs
> used on the graphics card are something that are used elsewhere also
> (sounds quite unlikely, though). In that case there could be separate
> drivers for the IPs.
> 
> And note that CDF is not really about the dispc side, i.e. the part that
> creates the video stream from pixels in the memory. It's more about the
> components after that, and how to connect those components.
> 
> > For DSI panels (or DSI-to-whatever bridges) it's of course another
> > story. You typically need a panel specific driver. And here I see the
> > main point of the whole CDF: decoupling display controllers and the
> > panel drivers, and sharing panel (and converter chip) specific drivers
> > across display controllers. Making it easy to write new drivers, as
> > there would be a model to follow. I'm definitely in favour of coming up
> > with some framework that would tackle that.
> 
> Right. But if you implement drivers for DSI panels with CDF for, say,
> OMAP, I think it's simpler to use CDF also for HDMI/DP on OMAP.
> Otherwise it'll be a mishmash with two different models.

I second your point here, using CDF for encoders should be simpler, but it 
will not be enforced. A display controller driver developer who wants to 
control the on-SoC encoder without conforming to the CDF model will be totally 
free to do so and won't be blamed.

-- 
Regards,

Laurent Pinchart
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121224/31720f81/attachment.pgp>

[RFC v2 0/5] Common Display Framework

Hi Jani,

On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote:
> On Tue, 18 Dec 2012, Laurent Pinchart wrote:
> > On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
> >> I can see the need for a framework for DSI panels and such (in fact Tomi
> >> and I have talked about it like 2-3 years ago already!) but what is the
> >> story for HDMI and DP? In particular, what's the relationship between
> >> DRM and CDF here? Is there a world domination plan to switch the DRM
> >> drivers to use this framework too? ;) Do you have some rough plans how
> >> DRM and CDF should work together in general?
> > 
> > There's always a world domination plan, isn't there ? :-)
> > 
> > I certainly want CDF to be used by DRM (or more accurately KMS). That's
> > what the C stands for, common refers to sharing panel and other display
> > entity drivers between FBDEV, KMS and V4L2.
> > 
> > I currently have no plan to expose CDF internals to userspace through the
> > KMS API. We might have to do so later if the hardware complexity grows in
> > such a way that finer control than what KMS provides needs to be exposed
> > to userspace, but I don't think we're there yet. The CDF API will thus
> > only be used internally in the kernel by display controller drivers. The
> > KMS core might get functions to handle common display entity operations,
> > but the bulk of the work will be in the display controller drivers to
> > start with. We will then see what can be abstracted in KMS helper
> > functions.
> > 
> > Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the
> > CDF API. That's just a thought for now, I haven't tried to implement them,
> > but it would be nice to handle HDMI screens and DPI/DBI/DSI panels in a
> > generic way.
> > 
> > Do you have thoughts to share on this topic ?
> 
> It just seems to me that, at least from a DRM/KMS perspective, adding
> another layer (=CDF) for HDMI or DP (or legacy outputs) would be
> overengineering it. They are pretty well standardized, and I don't see there
> would be a need to write multiple display drivers for them. Each display
> controller has one, and can easily handle any chip specific requirements
> right there. It's my gut feeling that an additional framework would just get
> in the way. Perhaps there could be more common HDMI/DP helper style code in
> DRM to reduce overlap across KMS drivers, but that's another thing.
>
> So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM
> perspective? Or, put another way, is it more of an alternative to using DRM?
> Please enlighten me if there's some real benefit here that I fail to see!

As Rob pointed out, you can have external HDMI/DP encoders, and even internal 
HDMI/DP encoder IPs can be shared between SoCs and SoC vendors. CDF aims at 
sharing a single driver between SoCs and boards for a given HDMI/DP encoder.

CDF isn't an alternative to DRM/KMS. It should be seen as a framework that 
helps DRM/KMS drivers (as well as V4L2 drivers, and possibly FBDEV drivers, 
although those should be ported to DRM/KMS) sharing encoder and connector 
code.

> For DSI panels (or DSI-to-whatever bridges) it's of course another story.
> You typically need a panel specific driver. And here I see the main point of
> the whole CDF: decoupling display controllers and the panel drivers, and
> sharing panel (and converter chip) specific drivers across display
> controllers. Making it easy to write new drivers, as there would be a model
> to follow. I'm definitely in favour of coming up with some framework that
> would tackle that.

That's the main (and original) goal of CDF (originally called Generic Panel 
Framwork, and renamed to CDF to support encoder drivers as explained above). 
I'm glad to know that you're in favour of it :-)

-- 
Regards,

Laurent Pinchart

[RFC v2 0/5] Common Display Framework

Hi Sylwester,

On Tuesday 18 December 2012 11:59:35 Sylwester Nawrocki wrote:
> On 12/18/2012 07:21 AM, Rob Clark wrote:
> > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie  wrote:
> >> So this might be a bit off topic but this whole CDF triggered me
> >> looking at stuff I generally avoid:
> >> 
> >> The biggest problem I'm having currently with the whole ARM graphics
> >> and output world is the proliferation of platform drivers for every
> >> little thing. The whole ordering of operations with respect to things
> >> like suspend/resume or dynamic power management is going to be a real
> >> nightmare if there are dependencies between the drivers. How do you
> >> enforce ordering of s/r operations between all the various components?
> 
> There have been already some ideas proposed to resolve this at the PM
> subsystem level [1]. And this problem is of course not only specific to
> platform drivers. The idea of having monolithic drivers, just because we
> can't get the suspend/resume sequences right otherwise, doesn't really sound
> appealing. SoC IPs get reused on multiple different SoC series, no only by
> single manufacturer. Whole graphics/video subsystems are composed from
> smaller blocks in SoCs, with various number of distinct sub-blocks and same
> sub-blocks repeated different number of times in a specific SoC revision.
> Expressing an IP as a platform device seems justified to me, often these
> platform devices have enough differences to treat them as such. E.g. belong
> in different power domain/use different clocks. Except there is big issue
> with the power management... However probably more important is to be able
> to have driver for a specific IP in a separate module.
> 
> And this suspend/resume ordering issue is not only about the platform
> devices. E.g. camera subsystem can be composed of an image sensor sub-device
> driver, which is most often an I2C client driver, and of multiple SoC
> processing blocks. The image sensor can have dependencies on the SoC sub-
> blocks. So even if we created monolithic driver for the SoC part, there are
> still two pieces to get s/r ordering right - I2C client and SoC drivers. And
> please don't propose to merge the sensor sub-device driver too. There has
> been a lot of effort in V4L2 to separate those various functional blocks
> into sub-devices, so they can be freely reused, without reimplementing same
> functionality in each driver. BTW, there has been a nice talk about these
> topics at ELCE [2], particularly slide 22 is interesting.
> 
> I believe the solution for these issues really needs to be sought in the PM
> subsystem itself.

I tend to agree with you, or at least I believe we should research a proper 
solution in the PM framework. In the meantime, though, I think early 
suspend/late resume might provide an intermediate solution.

> > I tend to think that sub-devices are useful just to have a way to
> > probe hw which may or may not be there, since on ARM we often don't
> > have any alternative.. but beyond that, suspend/resume, and other
> > life-cycle aspects, they should really be treated as all one device.
> > Especially to avoid undefined suspend/resume ordering.
> 
> [1] https://lkml.org/lkml/2009/9/9/373
> [2]
> http://elinux.org/images/9/90/ELCE2012-Modular-Graphics-on-Embedded-ARM.pdf

-- 
Regards,

Laurent Pinchart

[RFC v2 0/5] Common Display Framework

Hi Marcus,

On Tuesday 18 December 2012 11:39:11 Marcus Lorentzon wrote:
> On 12/18/2012 06:04 AM, Dave Airlie wrote:
> >> Many developers showed interest in the first RFC, and I've had the
> >> opportunity to discuss it with most of them. I would like to thank (in
> >> no particular order) Tomi Valkeinen for all the time he spend helping me
> >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect
> >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to
> >> discuss this topic.
> > 
> > So this might be a bit off topic but this whole CDF triggered me
> > looking at stuff I generally avoid:
>
> I like the effort, right now it seems like x86 and arm display sub systems
> are quite different in terms of DRM driver (and HW) design. I think this is
> partly due to little information shared about these different architectures
> and ideas behind the choices made. I hope some discussion will light up both
> sides. And an early discussion will hopefully give you less pain when CDF
> drivers starts to get pushed your way.

On the topic of discussions, would anyone be interested in a 
BoF/brainstorming/whatever session during the FOSDEM ?

> > The biggest problem I'm having currently with the whole ARM graphics
> > and output world is the proliferation of platform drivers for every
> > little thing. The whole ordering of operations with respect to things
> > like suspend/resume or dynamic power management is going to be a real
> > nightmare if there are dependencies between the drivers. How do you
> > enforce ordering of s/r operations between all the various components?
> 
> Could you give an example? Personally I don't think it is that many. I
> might not have counted the plat devs in all arm drivers. But the STE one
> have one per HW IP block in the HW (1 DSS + 3 DSI encoder/formatters).
> Then of course there are all these panel devices. But I hope that when
> CDF is "finished" we will have DSI devices on the DSI bus and DBI
> devices on the DBI bus. I think most vendors have used platform devices
> for these since they normally can't be probed in a generic way. But as
> they are off SoC I feel this is not the best choice. And then many of
> the panels are I2C devices (control bus) and that I guess is similar to
> "x86" encoders/connectors?

Tomi Valkeinen proposed dropping the DSI and DBI busses in favor of the 
platform bus. Although I still believe that DSI and DBI busses would make 
sense, I agree that they don't provide much in terms of probing and power 
management. You can read the discussion at http://www.spinics.net/lists/linux-
fbdev/msg09250.html.

> Another part of the difference I feel is that in x86 a DRM device is
> most likely a PCI device, and as such has one huge driver for all IPs on
> that board. The closest thing we get to that in ARM is probably the DSS
> (collection of IPs on SoC, like 3D, 2D, display output, encoders). But
> it doesn't fell right to create a single driver for all these. And as
> you know often 3D is even from a separate vendor. All these lead up to a
> slight increase in the number of devices and drivers. Right way, I feel
> so, but you are welcome to show a better way.
> 
> > The other thing I'd like you guys to do is kill the idea of fbdev and
> > v4l drivers that are "shared" with the drm codebase, really just
> > implement fbdev and v4l on top of the drm layer, some people might
> > think this is some sort of maintainer thing, but really nothing else
> > makes sense, and having these shared display frameworks just to avoid
> > having using drm/kms drivers seems totally pointless. Fix the drm
> > fbdev emulation if an fbdev interface is needed. But creating a fourth
> > framework because our previous 3 frameworks didn't work out doesn't
> > seem like a situation I want to get behind too much.
> 
> I have no intention to use CDF outside KMS connector/encoder and I have
> not heard Laurent talk about this either.

I don't either. CDF will mostly target KMS connectors, and can also be used 
for KMS encoders. I have no plan to touch the CRTC.

> Personally I see CDF as "helpers" to create and reuse connector/encoder
> drivers between SoCs instead of each SoC do their own panel drivers (which
> would be about a hundred, times the number of supported SoCs). We probably
> need to discuss the connector/encoder mappings to CDF/panels.

That's a topic I was planning to discuss at some point. One of the issues is 
that the KMS model can only have 3 entities in the pipeline, while hardware 
pipelines (especially in the embedded world) could be made of 4 or more 
entities (such as CRTC -> DSI encoder -> DSI to HDMI converter -> HDMI 
connector). We might not have to expose all details to userspace, but we need 
mapping rules.

> But I think we need to flush out the higher level details like control bus
> vs. data bus vs. display entities. While I like the generic way of the
> display entities, I also like the pure bus/device/driver model with

[RFC v2 0/5] Common Display Framework

Hi Tomasz,

On Friday 21 December 2012 11:00:52 Tomasz Figa wrote:
> On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote:
> > On 17 December 2012 20:55, Laurent Pinchart wrote:
> > > Hi Vikas,
> > > 
> > > Sorry for the late reply. I now have more time to work on CDF, so
> > > delays should be much shorter.
> > > 
> > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote:
> > > > Hi Laurent,
> > > > 
> > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, what
> > > > I found is that, the exynos display controller is MIPI DSI based
> > > > controller.
> > > > 
> > > > But if I look at CDF patches, it has only support for MIPI DBI based
> > > > Display controller.
> > > > 
> > > > So my question is, do we have any generic framework for MIPI DSI
> > > > based display controller? basically I wanted to know, how to go about
> > > > porting CDF for such kind of display controller.
> > > 
> > > MIPI DSI support is not available yet. The only reason for that is
> > > that I don't have any MIPI DSI hardware to write and test the code
> > > with :-)
> > > 
> > > The common display framework should definitely support MIPI DSI. I
> > > think the existing MIPI DBI code could be used as a base, so the
> > > implementation shouldn't be too high.
> > > 
> > > Yeah, i was also thinking in similar lines, below is my though for
> > > MIPI DSI support in CDF.
> > 
> > o   MIPI DSI support as part of CDF framework will expose
> > ?  mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c
> > file )
> > ?  mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from
> > platform specific init driver call )
> > ?bus ops will be
> > o   read data
> > o   write data
> > o   write command
> > ?  MIPI DSI will be registered as bus_register()
> > 
> > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will
> > initialize the MIPI DSI HW IP.
> > 
> > This probe will also parse the DT file for MIPI DSI based panel, add
> > the panel device (device_add() ) to kernel and register the display
> > entity with its control and  video ops with CDF.
> > 
> > I can give this a try.
> 
> I am currently in progress of reworking Exynos MIPI DSIM code and s6e8ax0
> LCD driver to use the v2 RFC of Common Display Framework. I have most of
> the work done, I have just to solve several remaining problems.

Do you already have code that you can publish ? I'm particularly interested 
(and I think Tomi Valkeinen would be as well) in looking at the DSI operations 
you expose to DSI sinks (panels, transceivers, ...).

-- 
Regards,

Laurent Pinchart

[RFC v2 0/5] Common Display Framework

Hi Inki,

On Tuesday 18 December 2012 18:38:31 Inki Dae wrote:
> 2012/12/18 Daniel Vetter 
> > On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark  wrote:
> > >> The other thing I'd like you guys to do is kill the idea of fbdev and
> > >> v4l drivers that are "shared" with the drm codebase, really just
> > >> implement fbdev and v4l on top of the drm layer, some people might
> > >> think this is some sort of maintainer thing, but really nothing else
> > >> makes sense, and having these shared display frameworks just to avoid
> > >> having using drm/kms drivers seems totally pointless. Fix the drm
> > >> fbdev emulation if an fbdev interface is needed. But creating a fourth
> > >> framework because our previous 3 frameworks didn't work out doesn't
> > >> seem like a situation I want to get behind too much.
> > > 
> > > yeah, let's not have multiple frameworks to do the same thing.. For
> > > fbdev, it is pretty clear that it is a dead end.  For v4l2
> > > (subdev+mcf), it is perhaps bit more flexible when it comes to random
> > > arbitrary hw pipelines than kms.  But to take advantage of that, your
> > > userspace isn't going to be portable anyways, so you might as well use
> > > driver specific properties/ioctls.  But I tend to think that is more
> > > useful for cameras.  And from userspace perspective, kms planes are
> > > less painful to use for output than v4l2, so lets stick to drm/kms for
> > > output (and not try to add camera/capture support to kms).. k, thx
> > 
> > Yeah, I guess having a v4l device also exported by the same driver
> > that exports the drm interface might make sense in some cases. But in
> > many cases I think the video part is just an independent IP block and
> > shuffling data around with dma-buf is all we really need. So yeah, I
> > guess sharing display resources between v4l and drm kms driver should
> > be a last resort option, since coordination (especially if it's
> > supposed to be somewhat dynamic) will be extremely hairy.
> 
> I think the one reason that the CDF was appeared is to avoid duplicating
> codes. For example, we should duplicate mipi-dsi or dbi drivers into drm to
> avoid ordering issue. And for this, those should be re-implemented in based
> on drm framework so that those could be treated as all one device.
> Actually, in case of Exynos, some guys tried to duplicate eDP driver into
> exynos drm framework in same issue. So I think the best way is to avoid
> duplicating codes and resolve ordering issue such as s/r operations between
> all the various components.
> 
> And the below is my opinion,
> 
>   ++
> Display Controller  CDF - |MIPI-DSI/DBI---LCD Panel|
>   ++
> 
> 1. to access MIPI-DSI/DBI and LCD Panel drivers.
> - Display Controller is controlled by linux framebuffer or drm kms
> based specific drivers like now. And each driver calls some interfaces of
> CDF.
> 
> 2. to control the power of these devices.
> - drm kms based specific driver calls dpms operation and next the dpms
> operation calls fb blank operation of linux framebuffer.
>   But for this, we need some interfaces that it can connect between drm
> and linux framebuffer framework and you can refer to the below link.
> 
> http://lists.freedesktop.org/archives/dri-devel/2011-July/013242.html

(Just FYI, I plan to clean up the backlight framework when I'll be done with 
CDF, to remove the FBDEV dependency)

> - linux framebuffer based driver calls fb blank operation.
> 
> fb blank(fb)-pm runtime(fb)---fb_blank--mipi and lcd
> dpms(drm kms)pm runtime(drm kms)--fb_blank--mipi and lcd
> 
> 3. suspend/resume
> - pm suspend/resume are implemented only in linux framebuffer or drm
> kms based specific drivers.
> - MIPI-DSI/DBI and LCD Panel drivers are controlled only by fb blank
> interfaces.
> 
> s/r(fb)pm runtime(fb)fb blank---mipi and lcd
> s/r(drm kms)---dpms(drm kms)---pm runtime(drm kms)---fb_blank---mipi and lcd
> 
> 
> We could resolve ordering issue to suspend/resume simply duplicating
> relevant drivers but couldn't avoid duplicating codes. So I think we could
> avoid the ordering issue using fb blank interface of linux framebuffer and
> also duplicating codes.

As I mentioned before, we have multiple ordering issues related to suspend and 
resume. Panels and display controllers will likely want to enforce a S/R order 
on the video bus, and control busses will also require a specific S/R order. 
My plan is to use early suspend/late resume in the display controller driver 
to control the video busses, and let the PM core handle control bus ordering 
issues. This will of course need to be prototyped and tested.

-- 
Regards,

Laurent Pinchart

[RFC v2 0/5] Common Display Framework

Hi Daniel,

On Tuesday 18 December 2012 09:30:00 Daniel Vetter wrote:
> On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark  wrote:
> >> The other thing I'd like you guys to do is kill the idea of fbdev and
> >> v4l drivers that are "shared" with the drm codebase, really just
> >> implement fbdev and v4l on top of the drm layer, some people might
> >> think this is some sort of maintainer thing, but really nothing else
> >> makes sense, and having these shared display frameworks just to avoid
> >> having using drm/kms drivers seems totally pointless. Fix the drm
> >> fbdev emulation if an fbdev interface is needed. But creating a fourth
> >> framework because our previous 3 frameworks didn't work out doesn't
> >> seem like a situation I want to get behind too much.
> > 
> > yeah, let's not have multiple frameworks to do the same thing.. For
> > fbdev, it is pretty clear that it is a dead end.  For v4l2
> > (subdev+mcf), it is perhaps bit more flexible when it comes to random
> > arbitrary hw pipelines than kms.  But to take advantage of that, your
> > userspace isn't going to be portable anyways, so you might as well use
> > driver specific properties/ioctls.  But I tend to think that is more
> > useful for cameras.  And from userspace perspective, kms planes are
> > less painful to use for output than v4l2, so lets stick to drm/kms for
> > output (and not try to add camera/capture support to kms).. k, thx
> 
> Yeah, I guess having a v4l device also exported by the same driver that
> exports the drm interface might make sense in some cases. But in many cases
> I think the video part is just an independent IP block and shuffling data
> around with dma-buf is all we really need. So yeah, I guess sharing display
> resources between v4l and drm kms driver should be a last resort option,
> since coordination (especially if it's supposed to be somewhat dynamic) will
> be extremely hairy.

I totally agree. As explained in my replies to Dave and Rob, I don't want to 
share devices between the different subsystems at runtime, but I'd like to 
avoid writing two drivers for a single device that can be used for display and 
graphics on one board, and video output on another board (HDMI transmitters 
are a good example).

-- 
Regards,

Laurent Pinchart

[RFC v2 0/5] Common Display Framework

Hi Rob,

On Tuesday 18 December 2012 00:21:32 Rob Clark wrote:
> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie  wrote:
> >> Many developers showed interest in the first RFC, and I've had the
> >> opportunity to discuss it with most of them. I would like to thank (in
> >> no particular order) Tomi Valkeinen for all the time he spend helping me
> >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect
> >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to
> >> discuss this topic.
> > 
> > So this might be a bit off topic but this whole CDF triggered me
> > looking at stuff I generally avoid:
> > 
> > The biggest problem I'm having currently with the whole ARM graphics
> > and output world is the proliferation of platform drivers for every
> > little thing. The whole ordering of operations with respect to things
> > like suspend/resume or dynamic power management is going to be a real
> > nightmare if there are dependencies between the drivers. How do you
> > enforce ordering of s/r operations between all the various components?
> 
> I tend to think that sub-devices are useful just to have a way to probe hw
> which may or may not be there, since on ARM we often don't have any
> alternative.. but beyond that, suspend/resume, and other life-cycle aspects,
> they should really be treated as all one device. Especially to avoid
> undefined suspend/resume ordering.

I tend to agree, except that I try to reuse the existing PM infrastructure 
when possible to avoid reinventing the wheel. So far handling suspend/resume 
ordering related to data busses in early suspend/late resume operations and 
allowing the Linux PM core to handle control busses using the Linux device 
tree worked pretty well.

> CDF or some sort of mechanism to share panel drivers between drivers is
> useful.  Keeping it within drm, is probably a good idea, if nothing else to
> simplify re-use of helper fxns (like avi-infoframe stuff, for example) and
> avoid dealing with merging changes across multiple trees. Treating them more
> like shared libraries and less like sub-devices which can be dynamically
> loaded/unloaded (ie. they should be not built as separate modules or
> suspend/resumed or probed/removed independently of the master driver) is a
> really good idea to avoid uncovering nasty synchronization issues later
> (remove vs modeset or pageflip) or surprising userspace in bad ways.

We've tried that in V4L2 years ago and realized that the approach led to a 
dead-end, especially when OF/DT got involved. With DT-based device probing, 
I2C camera sensors started getting probed asynchronously to the main camera 
device, as they are children of the I2C bus master. We will have similar 
issues with I2C HDMI transmitters or panels, so we should be prepared for it.

On PC hardware the I2C devices are connected to an I2C master provided by the 
GPU, but on embedded devices they are usually connected to an independent I2C 
master. We thus can't have a single self-contained driver that controls 
everything internally, and need to interface with the rest of the SoC drivers.

I agree that probing/removing devices independently of the master driver can 
lead to bad surprises, which is why I want to establish clear rules in CDF 
regarding what can and can't be done with display entities. Reference counting 
will be one way to make sure that devices don't disappear all of a sudden.

> > The other thing I'd like you guys to do is kill the idea of fbdev and
> > v4l drivers that are "shared" with the drm codebase, really just
> > implement fbdev and v4l on top of the drm layer, some people might
> > think this is some sort of maintainer thing, but really nothing else
> > makes sense, and having these shared display frameworks just to avoid
> > having using drm/kms drivers seems totally pointless. Fix the drm
> > fbdev emulation if an fbdev interface is needed. But creating a fourth
> > framework because our previous 3 frameworks didn't work out doesn't
> > seem like a situation I want to get behind too much.
> 
> yeah, let's not have multiple frameworks to do the same thing.. For fbdev,
> it is pretty clear that it is a dead end.  For v4l2 (subdev+mcf), it is
> perhaps bit more flexible when it comes to random arbitrary hw pipelines
> than kms.  But to take advantage of that, your userspace isn't going to be
> portable anyways, so you might as well use driver specific
> properties/ioctls.  But I tend to think that is more useful for cameras. 
> And from userspace perspective, kms planes are less painful to use for
> output than v4l2, so lets stick to drm/kms for output (and not try to add
> camera/capture support to kms)..

Agreed. I've started to advocate the deprecation of FBDEV during LPC. The 
positive response has motivated me to continue doing so :-) For V4L2 the 
situation is a little bit different, I think V4L2 shouldn't be used for 
graphics and display hardware, but it still has use cases on the video output

[RFC v2 0/5] Common Display Framework

Hi Dave,

On Tuesday 18 December 2012 15:04:02 Dave Airlie wrote:
> > Many developers showed interest in the first RFC, and I've had the
> > opportunity to discuss it with most of them. I would like to thank (in no
> > particular order) Tomi Valkeinen for all the time he spend helping me to
> > draft v2, Marcus Lorentzon for his useful input during Linaro Connect Q4
> > 2012, and Linaro for inviting me to Connect and providing a venue to
> > discuss this topic.
>
> So this might be a bit off topic but this whole CDF triggered me looking at
> stuff I generally avoid:
> 
> The biggest problem I'm having currently with the whole ARM graphics and
> output world is the proliferation of platform drivers for every little
> thing. The whole ordering of operations with respect to things like
> suspend/resume or dynamic power management is going to be a real nightmare
> if there are dependencies between the drivers.

We share the same concern, although my analysis of the problem is somewhat 
different. The power management ordering issues isn't only caused by the 
software architecture, but also comes from complex hardware requirements. The 
root cause, in my opinion, is the split control and data busses: as soon as a 
device sits on multiple busses and has power management ordering requirements 
related to those busses the Linux power management model breaks. Note that the 
problem isn't restricted to the display, we have run into the exact same 
issues years ago on the video capture side.

> How do you enforce ordering of s/r operations between all the various
> components?

The way we have handled this problem on the camera side is to use early 
suspend and late resume operations to handle the data (video) busses suspend 
and resume operations, and let the kernel handle the rest using the control 
bus based device tree model. The camera controller stops the video pipeline in 
its early suspend operation (and resumes it in the late resume operation) by 
calling operations provided by the entities (through function pointers of 
course, we don't want direct dependencies between the drivers). The control 
suspend/resume (such as sending a standby command through I2C to put the chip 
in low-power mode, or turning its power supply or clock off) is then handled 
by the PM core.

> The other thing I'd like you guys to do is kill the idea of fbdev and v4l
> drivers that are "shared" with the drm codebase, really just implement fbdev
> and v4l on top of the drm layer, some people might think this is some sort
> of maintainer thing, but really nothing else makes sense, and having these
> shared display frameworks just to avoid having using drm/kms drivers seems
> totally pointless. Fix the drm fbdev emulation if an fbdev interface is
> needed. But creating a fourth framework because our previous 3 frameworks
> didn't work out doesn't seem like a situation I want to get behind too much.

I think there's a misunderstanding here. I'm definitely not trying to create a 
framework to expose the FBDEV/KMS/V4L2 APIs through different drivers on top 
of the same hardware device. That's an idea I really dislike, and I fully 
agree that the FBDEV API should be provided on top of KMS using the DRM FBDEV 
emulation layer. V4L2 on top of KMS doesn't make too much sense to me, as V4L2 
isn't really a display and graphics API anyway.

My goal here is to share code for chips that are used by different "devices" 
(in the sense of an agregate device, such as a camera or a graphics card) 
supported by different subsystems. For instance, the same I2C-controlled HDMI 
transmitter can be used by a display device when connected to a display 
controller on an SoC, but can also be used by a video output device when 
connected to a video output (some complex TI SoCs have pass-through video 
pipelines with no associated frame buffer, making the V4L2 API better suited 
than DRM/KMS). As the first device would be supported by a DRM/KMS driver and 
the second device by a pure V4L2 driver, we need a common framework to share 
code between both.

If the same framework can be used to share panel drivers between DRM/KMS and 
pure FBDEV drivers (we have a bunch of those, not all of them will be ported 
to DRM/KMS, at least not in the very near future) that's also a bonus.

To summarize my point, CDF aims at creating a self-contained framework that 
can be used by FBDEV, DRM/KMS and V4L2 drivers to interface with various 
display-related devices. It does not provide any userspace API, and does not 
offer any way to share devices between the three subsystems at runtime. In a 
way you can think of CDF as a DRM panel framework, but without the drm_ 
prefix.

I hope this clarifies my goals. If not, or if there's still concerns and/or 
disagreements, let's discuss them.

-- 
Regards,

Laurent Pinchart

[PATCH 10/10] drm/exynos: Use devm_clk_get in exynos_drm_gsc.c

This eliminates the need for explicit clk_put and makes the
cleanup and exit path code simpler.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   13 -
 1 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index e21a0d9..0497e90 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1696,7 +1696,7 @@ static int __devinit gsc_probe(struct platform_device 
*pdev)
return -ENOMEM;

/* clock control */
-   ctx->gsc_clk = clk_get(dev, "gscl");
+   ctx->gsc_clk = devm_clk_get(dev, "gscl");
if (IS_ERR(ctx->gsc_clk)) {
dev_err(dev, "failed to get gsc clock.\n");
return PTR_ERR(ctx->gsc_clk);
@@ -1707,16 +1707,14 @@ static int __devinit gsc_probe(struct platform_device 
*pdev)
ctx->regs = devm_request_and_ioremap(dev, ctx->regs_res);
if (!ctx->regs) {
dev_err(dev, "failed to map registers.\n");
-   ret = -ENXIO;
-   goto err_clk;
+   return -ENXIO;
}

/* resource irq */
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
dev_err(dev, "failed to request irq resource.\n");
-   ret = -ENOENT;
-   goto err_clk;
+   return -ENOENT;
}

ctx->irq = res->start;
@@ -1724,7 +1722,7 @@ static int __devinit gsc_probe(struct platform_device 
*pdev)
IRQF_ONESHOT, "drm_gsc", ctx);
if (ret < 0) {
dev_err(dev, "failed to request irq.\n");
-   goto err_clk;
+   return ret;
}

/* context initailization */
@@ -1768,8 +1766,6 @@ err_ippdrv_register:
pm_runtime_disable(dev);
 err_get_irq:
free_irq(ctx->irq, ctx);
-err_clk:
-   clk_put(ctx->gsc_clk);
return ret;
 }

@@ -1787,7 +1783,6 @@ static int __devexit gsc_remove(struct platform_device 
*pdev)
pm_runtime_disable(dev);

free_irq(ctx->irq, ctx);
-   clk_put(ctx->gsc_clk);

return 0;
 }
-- 
1.7.4.1

[PATCH 09/10] drm/exynos: Remove redundant NULL check in exynos_drm_gsc.c

devm_request_and_ioremap API checks for NULL. Hence explicit
NULL check is not necessary. Saves some code.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 3b47a7d..e21a0d9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1704,12 +1704,6 @@ static int __devinit gsc_probe(struct platform_device 
*pdev)

/* resource memory */
ctx->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!ctx->regs_res) {
-   dev_err(dev, "failed to find registers.\n");
-   ret = -ENOENT;
-   goto err_clk;
-   }
-
ctx->regs = devm_request_and_ioremap(dev, ctx->regs_res);
if (!ctx->regs) {
dev_err(dev, "failed to map registers.\n");
-- 
1.7.4.1

[PATCH 08/10] drm/exynos: Remove explicit freeing using devm_* APIs in exynos_drm_gsc.c

devm_* APIs are device managed and get freed automatically when the
device detaches. Thus explicit freeing is not needed. This saves some
code.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   15 +++
 1 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 5639353..3b47a7d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1699,8 +1699,7 @@ static int __devinit gsc_probe(struct platform_device 
*pdev)
ctx->gsc_clk = clk_get(dev, "gscl");
if (IS_ERR(ctx->gsc_clk)) {
dev_err(dev, "failed to get gsc clock.\n");
-   ret = PTR_ERR(ctx->gsc_clk);
-   goto err_ctx;
+   return PTR_ERR(ctx->gsc_clk);
}

/* resource memory */
@@ -1723,7 +1722,7 @@ static int __devinit gsc_probe(struct platform_device 
*pdev)
if (!res) {
dev_err(dev, "failed to request irq resource.\n");
ret = -ENOENT;
-   goto err_get_regs;
+   goto err_clk;
}

ctx->irq = res->start;
@@ -1731,7 +1730,7 @@ static int __devinit gsc_probe(struct platform_device 
*pdev)
IRQF_ONESHOT, "drm_gsc", ctx);
if (ret < 0) {
dev_err(dev, "failed to request irq.\n");
-   goto err_get_regs;
+   goto err_clk;
}

/* context initailization */
@@ -1775,12 +1774,8 @@ err_ippdrv_register:
pm_runtime_disable(dev);
 err_get_irq:
free_irq(ctx->irq, ctx);
-err_get_regs:
-   devm_iounmap(dev, ctx->regs);
 err_clk:
clk_put(ctx->gsc_clk);
-err_ctx:
-   devm_kfree(dev, ctx);
return ret;
 }

@@ -1798,12 +1793,8 @@ static int __devexit gsc_remove(struct platform_device 
*pdev)
pm_runtime_disable(dev);

free_irq(ctx->irq, ctx);
-   devm_iounmap(dev, ctx->regs);
-
clk_put(ctx->gsc_clk);

-   devm_kfree(dev, ctx);
-
return 0;
 }

-- 
1.7.4.1

[PATCH 07/10] drm/exynos: Use devm_clk_get in exynos_drm_rotator.c

This eliminates the need for explicit clk_put and makes the
cleanup and exit path code simpler.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 4505163..484c6bd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -674,7 +674,7 @@ static int __devinit rotator_probe(struct platform_device 
*pdev)
return ret;
}

-   rot->clock = clk_get(dev, "rotator");
+   rot->clock = devm_clk_get(dev, "rotator");
if (IS_ERR_OR_NULL(rot->clock)) {
dev_err(dev, "failed to get clock\n");
ret = PTR_ERR(rot->clock);
@@ -712,7 +712,6 @@ static int __devinit rotator_probe(struct platform_device 
*pdev)
 err_ippdrv_register:
devm_kfree(dev, ippdrv->prop_list);
pm_runtime_disable(dev);
-   clk_put(rot->clock);
 err_clk_get:
free_irq(rot->irq, rot);
return ret;
@@ -728,7 +727,6 @@ static int __devexit rotator_remove(struct platform_device 
*pdev)
exynos_drm_ippdrv_unregister(ippdrv);

pm_runtime_disable(dev);
-   clk_put(rot->clock);

free_irq(rot->irq, rot);

-- 
1.7.4.1

[PATCH 06/10] drm/exynos: Remove redundant NULL check in exynos_drm_rotator.c

devm_request_and_ioremap API checks for NULL. Hence explicit
NULL check is not necessary. Saves some code.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |5 -
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 0f168449..4505163 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -655,11 +655,6 @@ static int __devinit rotator_probe(struct platform_device 
*pdev)
platform_get_device_id(pdev)->driver_data;

rot->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!rot->regs_res) {
-   dev_err(dev, "failed to find registers\n");
-   return -ENOENT;
-   }
-
rot->regs = devm_request_and_ioremap(dev, rot->regs_res);
if (!rot->regs) {
dev_err(dev, "failed to map register\n");
-- 
1.7.4.1

[PATCH 05/10] drm/exynos: Remove unnecessary devm_* freeing APIs in exynos_drm_rotator.c

devm_* APIs are device managed and get freed automatically when the
device detaches. Thus explicit freeing is not needed. This saves some
code.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   18 --
 1 files changed, 4 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 1c23660..0f168449 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -657,29 +657,26 @@ static int __devinit rotator_probe(struct platform_device 
*pdev)
rot->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!rot->regs_res) {
dev_err(dev, "failed to find registers\n");
-   ret = -ENOENT;
-   goto err_get_resource;
+   return -ENOENT;
}

rot->regs = devm_request_and_ioremap(dev, rot->regs_res);
if (!rot->regs) {
dev_err(dev, "failed to map register\n");
-   ret = -ENXIO;
-   goto err_get_resource;
+   return -ENXIO;
}

rot->irq = platform_get_irq(pdev, 0);
if (rot->irq < 0) {
dev_err(dev, "failed to get irq\n");
-   ret = rot->irq;
-   goto err_get_irq;
+   return rot->irq;
}

ret = request_threaded_irq(rot->irq, NULL, rotator_irq_handler,
IRQF_ONESHOT, "drm_rotator", rot);
if (ret < 0) {
dev_err(dev, "failed to request irq\n");
-   goto err_get_irq;
+   return ret;
}

rot->clock = clk_get(dev, "rotator");
@@ -723,10 +720,6 @@ err_ippdrv_register:
clk_put(rot->clock);
 err_clk_get:
free_irq(rot->irq, rot);
-err_get_irq:
-   devm_iounmap(dev, rot->regs);
-err_get_resource:
-   devm_kfree(dev, rot);
return ret;
 }

@@ -743,9 +736,6 @@ static int __devexit rotator_remove(struct platform_device 
*pdev)
clk_put(rot->clock);

free_irq(rot->irq, rot);
-   devm_iounmap(dev, rot->regs);
-
-   devm_kfree(dev, rot);

return 0;
 }
-- 
1.7.4.1

[PATCH 04/10] drm/exynos: Use devm_clk_get in exynos_drm_fimc.c

This eliminates the need for explicit clk_put and makes the
cleanup and exit path code simpler.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |   46 ++---
 1 files changed, 10 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 972aa70..c4006b8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1739,64 +1739,50 @@ static int __devinit fimc_probe(struct platform_device 
*pdev)
platform_get_device_id(pdev)->driver_data;

/* clock control */
-   ctx->sclk_fimc_clk = clk_get(dev, "sclk_fimc");
+   ctx->sclk_fimc_clk = devm_clk_get(dev, "sclk_fimc");
if (IS_ERR(ctx->sclk_fimc_clk)) {
dev_err(dev, "failed to get src fimc clock.\n");
return PTR_ERR(ctx->sclk_fimc_clk);
}
clk_enable(ctx->sclk_fimc_clk);

-   ctx->fimc_clk = clk_get(dev, "fimc");
+   ctx->fimc_clk = devm_clk_get(dev, "fimc");
if (IS_ERR(ctx->fimc_clk)) {
dev_err(dev, "failed to get fimc clock.\n");
clk_disable(ctx->sclk_fimc_clk);
-   clk_put(ctx->sclk_fimc_clk);
return PTR_ERR(ctx->fimc_clk);
}

-   ctx->wb_clk = clk_get(dev, "pxl_async0");
+   ctx->wb_clk = devm_clk_get(dev, "pxl_async0");
if (IS_ERR(ctx->wb_clk)) {
dev_err(dev, "failed to get writeback a clock.\n");
clk_disable(ctx->sclk_fimc_clk);
-   clk_put(ctx->sclk_fimc_clk);
-   clk_put(ctx->fimc_clk);
return PTR_ERR(ctx->wb_clk);
}

-   ctx->wb_b_clk = clk_get(dev, "pxl_async1");
+   ctx->wb_b_clk = devm_clk_get(dev, "pxl_async1");
if (IS_ERR(ctx->wb_b_clk)) {
dev_err(dev, "failed to get writeback b clock.\n");
clk_disable(ctx->sclk_fimc_clk);
-   clk_put(ctx->sclk_fimc_clk);
-   clk_put(ctx->fimc_clk);
-   clk_put(ctx->wb_clk);
return PTR_ERR(ctx->wb_b_clk);
}

-   parent_clk = clk_get(dev, ddata->parent_clk);
+   parent_clk = devm_clk_get(dev, ddata->parent_clk);

if (IS_ERR(parent_clk)) {
dev_err(dev, "failed to get parent clock.\n");
clk_disable(ctx->sclk_fimc_clk);
-   clk_put(ctx->sclk_fimc_clk);
-   clk_put(ctx->fimc_clk);
-   clk_put(ctx->wb_clk);
-   clk_put(ctx->wb_b_clk);
return PTR_ERR(parent_clk);
}

if (clk_set_parent(ctx->sclk_fimc_clk, parent_clk)) {
dev_err(dev, "failed to set parent.\n");
-   clk_put(parent_clk);
+   devm_clk_put(dev, parent_clk);
clk_disable(ctx->sclk_fimc_clk);
-   clk_put(ctx->sclk_fimc_clk);
-   clk_put(ctx->fimc_clk);
-   clk_put(ctx->wb_clk);
-   clk_put(ctx->wb_b_clk);
return -EINVAL;
}

-   clk_put(parent_clk);
+   devm_clk_put(dev, parent_clk);
clk_set_rate(ctx->sclk_fimc_clk, pdata->clk_rate);

/* resource memory */
@@ -1804,16 +1790,14 @@ static int __devinit fimc_probe(struct platform_device 
*pdev)
ctx->regs = devm_request_and_ioremap(dev, ctx->regs_res);
if (!ctx->regs) {
dev_err(dev, "failed to map registers.\n");
-   ret = -ENXIO;
-   goto err_clk;
+   return -ENXIO;
}

/* resource irq */
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
dev_err(dev, "failed to request irq resource.\n");
-   ret = -ENOENT;
-   goto err_clk;
+   return -ENOENT;
}

ctx->irq = res->start;
@@ -1821,7 +1805,7 @@ static int __devinit fimc_probe(struct platform_device 
*pdev)
IRQF_ONESHOT, "drm_fimc", ctx);
if (ret < 0) {
dev_err(dev, "failed to request irq.\n");
-   goto err_clk;
+   return ret;
}

/* context initailization */
@@ -1867,11 +1851,6 @@ err_ippdrv_register:
pm_runtime_disable(dev);
 err_get_irq:
free_irq(ctx->irq, ctx);
-err_clk:
-   clk_put(ctx->sclk_fimc_clk);
-   clk_put(ctx->fimc_clk);
-   clk_put(ctx->wb_clk);
-   clk_put(ctx->wb_b_clk);

return ret;
 }
@@ -1891,11 +1870,6 @@ static int __devexit fimc_remove(struct platform_device 
*pdev)

free_irq(ctx->irq, ctx);

-   clk_put(ctx->sclk_fimc_clk);
-   clk_put(ctx->fimc_clk);
-   clk_put(ctx->wb_clk);
-   clk_put(ctx->wb_b_clk);
-
return 0;
 }

-- 
1.7.4.1

[PATCH 03/10] drm/exynos: Remove redundant NULL check

devm_request_and_ioremap API checks for NULL. Hence explicit
NULL check is not necessary. Saves some code.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index ab75150..972aa70 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1801,12 +1801,6 @@ static int __devinit fimc_probe(struct platform_device 
*pdev)

/* resource memory */
ctx->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!ctx->regs_res) {
-   dev_err(dev, "failed to find registers.\n");
-   ret = -ENOENT;
-   goto err_clk;
-   }
-
ctx->regs = devm_request_and_ioremap(dev, ctx->regs_res);
if (!ctx->regs) {
dev_err(dev, "failed to map registers.\n");
-- 
1.7.4.1

[PATCH 02/10] drm/exynos: Remove explicit freeing using devm_* APIs in exynos_drm_fimc.c

devm_* APIs are device managed and get freed automatically when the
device detaches. Thus explicit freeing is not needed. This saves some
code.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |   30 +-
 1 files changed, 9 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 61ea242..ab75150 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1742,64 +1742,58 @@ static int __devinit fimc_probe(struct platform_device 
*pdev)
ctx->sclk_fimc_clk = clk_get(dev, "sclk_fimc");
if (IS_ERR(ctx->sclk_fimc_clk)) {
dev_err(dev, "failed to get src fimc clock.\n");
-   ret = PTR_ERR(ctx->sclk_fimc_clk);
-   goto err_ctx;
+   return PTR_ERR(ctx->sclk_fimc_clk);
}
clk_enable(ctx->sclk_fimc_clk);

ctx->fimc_clk = clk_get(dev, "fimc");
if (IS_ERR(ctx->fimc_clk)) {
dev_err(dev, "failed to get fimc clock.\n");
-   ret = PTR_ERR(ctx->fimc_clk);
clk_disable(ctx->sclk_fimc_clk);
clk_put(ctx->sclk_fimc_clk);
-   goto err_ctx;
+   return PTR_ERR(ctx->fimc_clk);
}

ctx->wb_clk = clk_get(dev, "pxl_async0");
if (IS_ERR(ctx->wb_clk)) {
dev_err(dev, "failed to get writeback a clock.\n");
-   ret = PTR_ERR(ctx->wb_clk);
clk_disable(ctx->sclk_fimc_clk);
clk_put(ctx->sclk_fimc_clk);
clk_put(ctx->fimc_clk);
-   goto err_ctx;
+   return PTR_ERR(ctx->wb_clk);
}

ctx->wb_b_clk = clk_get(dev, "pxl_async1");
if (IS_ERR(ctx->wb_b_clk)) {
dev_err(dev, "failed to get writeback b clock.\n");
-   ret = PTR_ERR(ctx->wb_b_clk);
clk_disable(ctx->sclk_fimc_clk);
clk_put(ctx->sclk_fimc_clk);
clk_put(ctx->fimc_clk);
clk_put(ctx->wb_clk);
-   goto err_ctx;
+   return PTR_ERR(ctx->wb_b_clk);
}

parent_clk = clk_get(dev, ddata->parent_clk);

if (IS_ERR(parent_clk)) {
dev_err(dev, "failed to get parent clock.\n");
-   ret = PTR_ERR(parent_clk);
clk_disable(ctx->sclk_fimc_clk);
clk_put(ctx->sclk_fimc_clk);
clk_put(ctx->fimc_clk);
clk_put(ctx->wb_clk);
clk_put(ctx->wb_b_clk);
-   goto err_ctx;
+   return PTR_ERR(parent_clk);
}

if (clk_set_parent(ctx->sclk_fimc_clk, parent_clk)) {
dev_err(dev, "failed to set parent.\n");
-   ret = -EINVAL;
clk_put(parent_clk);
clk_disable(ctx->sclk_fimc_clk);
clk_put(ctx->sclk_fimc_clk);
clk_put(ctx->fimc_clk);
clk_put(ctx->wb_clk);
clk_put(ctx->wb_b_clk);
-   goto err_ctx;
+   return -EINVAL;
}

clk_put(parent_clk);
@@ -1825,7 +1819,7 @@ static int __devinit fimc_probe(struct platform_device 
*pdev)
if (!res) {
dev_err(dev, "failed to request irq resource.\n");
ret = -ENOENT;
-   goto err_get_regs;
+   goto err_clk;
}

ctx->irq = res->start;
@@ -1833,7 +1827,7 @@ static int __devinit fimc_probe(struct platform_device 
*pdev)
IRQF_ONESHOT, "drm_fimc", ctx);
if (ret < 0) {
dev_err(dev, "failed to request irq.\n");
-   goto err_get_regs;
+   goto err_clk;
}

/* context initailization */
@@ -1879,15 +1873,12 @@ err_ippdrv_register:
pm_runtime_disable(dev);
 err_get_irq:
free_irq(ctx->irq, ctx);
-err_get_regs:
-   devm_iounmap(dev, ctx->regs);
 err_clk:
clk_put(ctx->sclk_fimc_clk);
clk_put(ctx->fimc_clk);
clk_put(ctx->wb_clk);
clk_put(ctx->wb_b_clk);
-err_ctx:
-   devm_kfree(dev, ctx);
+
return ret;
 }

@@ -1905,15 +1896,12 @@ static int __devexit fimc_remove(struct platform_device 
*pdev)
pm_runtime_disable(dev);

free_irq(ctx->irq, ctx);
-   devm_iounmap(dev, ctx->regs);

clk_put(ctx->sclk_fimc_clk);
clk_put(ctx->fimc_clk);
clk_put(ctx->wb_clk);
clk_put(ctx->wb_b_clk);

-   devm_kfree(dev, ctx);
-
return 0;
 }

-- 
1.7.4.1

[PATCH 01/10] drm/exynos: Use devm_kzalloc in exynos_drm_ipp.c

devm_kzalloc makes the code simpler by eliminating the need for
explicit freeing.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |9 ++---
 1 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 49eebe9..441b719 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -1895,7 +1895,7 @@ static int __devinit ipp_probe(struct platform_device 
*pdev)
struct exynos_drm_subdrv *subdrv;
int ret;

-   ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+   ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;

@@ -1916,8 +1916,7 @@ static int __devinit ipp_probe(struct platform_device 
*pdev)
ctx->event_workq = create_singlethread_workqueue("ipp_event");
if (!ctx->event_workq) {
dev_err(dev, "failed to create event workqueue\n");
-   ret = -EINVAL;
-   goto err_clear;
+   return -EINVAL;
}

/*
@@ -1958,8 +1957,6 @@ err_cmd_workq:
destroy_workqueue(ctx->cmd_workq);
 err_event_workq:
destroy_workqueue(ctx->event_workq);
-err_clear:
-   kfree(ctx);
return ret;
 }

@@ -1985,8 +1982,6 @@ static int __devexit ipp_remove(struct platform_device 
*pdev)
destroy_workqueue(ctx->cmd_workq);
destroy_workqueue(ctx->event_workq);

-   kfree(ctx);
-
return 0;
 }

-- 
1.7.4.1

[PATCH 00/10] drm/exynos: Cleanup and update IPP drivers

Compile tested against linux-next tree (20121224).

Sachin Kamat (10):
  drm/exynos: Use devm_kzalloc in exynos_drm_ipp.c
  drm/exynos: Remove explicit freeing using devm_* APIs in
exynos_drm_fimc.c
  drm/exynos: Remove redundant NULL check
  drm/exynos: Use devm_clk_get in exynos_drm_fimc.c
  drm/exynos: Remove unnecessary devm_* freeing APIs in
exynos_drm_rotator.c
  drm/exynos: Remove redundant NULL check in exynos_drm_rotator.c
  drm/exynos: Use devm_clk_get in exynos_drm_rotator.c
  drm/exynos: Remove explicit freeing using devm_* APIs in
exynos_drm_gsc.c
  drm/exynos: Remove redundant NULL check in exynos_drm_gsc.c
  drm/exynos: Use devm_clk_get in exynos_drm_gsc.c

 drivers/gpu/drm/exynos/exynos_drm_fimc.c|   78 ++-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   30 ++-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |9 +---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   25 ++---
 4 files changed, 28 insertions(+), 114 deletions(-)

-- 
1.7.4.1

[RFC v2 0/5] Common Display Framework

Hi Vikas,

On Tuesday 18 December 2012 08:31:30 Vikas Sajjan wrote:
> On 17 December 2012 20:55, Laurent Pinchart wrote:
> > Hi Vikas,
> > 
> > Sorry for the late reply. I now have more time to work on CDF, so delays
> > should be much shorter.
> > 
> > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote:
> > > Hi Laurent,
> > > 
> > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, what I
> > > found is that, the exynos display controller is MIPI DSI based
> > > controller.
> > > 
> > > But if I look at CDF patches, it has only support for MIPI DBI based
> > > Display controller.
> > > 
> > > So my question is, do we have any generic framework for MIPI DSI based
> > > display controller? basically I wanted to know, how to go about porting
> > > CDF for such kind of display controller.
> > 
> > MIPI DSI support is not available yet. The only reason for that is that I
> > don't have any MIPI DSI hardware to write and test the code with :-)
> > 
> > The common display framework should definitely support MIPI DSI. I think
> > the existing MIPI DBI code could be used as a base, so the implementation
> > shouldn't be too high.
> > 
> > Yeah, i was also thinking in similar lines, below is my though for MIPI
> > DSI support in CDF.
> 
> o MIPI DSI support as part of CDF framework will expose
>   ? mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c
> file)
>   ? mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from
> platform specific init driver call )
> ? bus ops will be
>   o read data
>   o write data
>   o write command
>  ? MIPI DSI will be registered as bus_register()
> 
> When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will
> initialize the MIPI DSI HW IP.
> 
> This probe will also parse the DT file for MIPI DSI based panel, add
> the panel device (device_add() ) to kernel and register the display
> entity with its control and  video ops with CDF.

After discussing the DBI/DSI busses with Tomi Valkeinen we concluded that 
creating a real bus for DBI and DSI, although possible, wasn't required. DSI 
operations should thus be provided through display entity video source 
operations. You can find a proposed implementation in Tomi's patch set.

> > I can give this a try. Does the existing Exynos 5250 driver support MIPI
> > DSI ? Is the device documentation publicly available ? Can you point me to
> > a MIPI DSI panel with public documentation (preferably with an existing
> > mainline driver if possible) ?
>
> yeah, existing Exynos 5250 driver support MIPI DSI ass well as eDP.
> 
>  i think device documentation is NOT available publicly.

-- 
Regards,

Laurent Pinchart

[Bug 44499] r280 and xbmc - choppy menu and video playback

https://bugs.freedesktop.org/show_bug.cgi?id=44499

--- Comment #16 from smoki  ---
Created attachment 72076
  --> https://bugs.freedesktop.org/attachment.cgi?id=72076&action=edit
corruption in gliv

-- 
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/20121224/559689d8/attachment.html>

[Bug 56405] Distorted graphics on Radeon HD 6620G

https://bugs.freedesktop.org/show_bug.cgi?id=56405

--- Comment #53 from runetmem...@gmail.com ---
Yesterday I installed 3.8rc1 and also can confirm - fix works for me too.
Thanks!

Michael, if you also doesn't have this problem anymore please close the ticket.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 44499] r280 and xbmc - choppy menu and video playback

https://bugs.freedesktop.org/show_bug.cgi?id=44499

--- Comment #15 from smoki  ---
Created attachment 72075
  --> https://bugs.freedesktop.org/attachment.cgi?id=72075&action=edit
corruption in STK


 Actually corruption can be easely seen in supertuxkart, non-fbo case usage.

 That is before this commit, don't know why people tries to hide a problem and
instead slowing down everything - that way no one can manage to see a problem
and maybe manage to try to fix it ;).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121224/954e0467/attachment.html>

[Bug 58660] Radeon HD 6950 completely broken with sapphire locked vbios

https://bugs.freedesktop.org/show_bug.cgi?id=58660

Alex Deucher  changed:

   What|Removed |Added

Summary|Radeon HD 6950 completely   |Radeon HD 6950 completely
   |broken with sapphire|broken with sapphire locked
   |unlocked vbios  |vbios

-- 
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/20121224/f4c11b4b/attachment.html>

Re: DRM NOUVEAU: cannot boot with kernel >=3.7

2012-12-24 Thread Marcin Slusarz

On Mon, Dec 24, 2012 at 09:26:17PM +0100, baldu...@units.it wrote:
> hello everybody,
> 
> apologies if I am missing any blatant point; my knowledge about
> KMS/DRM etc. is very poor, so I am asking for help here (hoping to be
> at the right place)
> 
> Starting with kernel-3.7 I am not able to boot any more in KMS: as
> soon as the screen resolution changes in the very early stage of the
> boot, the machine freezes and the only option I'm left with is to
> press a physical reset button.
> 
> I am on an athlon64 dual core machine and using DRM/NOUVEAU with a
> NVIDIA GeForce 6200 LE GPU
> 
> Here are some facts:
> 
> => while kernel-3.7.x gives the problems mentioned above,
>kernel-3.6.{8-10} boots just fine (and X11 works nicely)
> => if it can be of any use: if I reboot from a running 3.6.x kernel
>into a 3.7.x, the obtained freezed console screen shows the (somewhat
>misplaced) lines which were printed during the shutdown phase of
>the reboot process (I can send a screen photo, if needed)
> => kernel-3.7.x boots just fine on another box (another athlon64 dual core 
> with
>a GeForce 6150SE nForce 430 (rev a2) GPU); kernel is 32bit there,
>if it matters
> 
> I am attaching lspci output and my kernel config below.
> 
> I will warmly appreciate any hint and will be more than happy to send
> in any other information which might be useful

Thanks for reporting.

Please follow instructions from http://nouveau.freedesktop.org/wiki/Bugs and
open new bug report. You may need to compile nouveau as module to catch full
kernel log.

Marcin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 0/6] Common Display Framework-T

2012-12-24 Thread Vikas Sajjan

Hi Laurent,

On Wed, Dec 19, 2012 at 6:51 PM, Laurent Pinchart
 wrote:
> Hi Tomi,
>
> On Friday 14 December 2012 16:27:26 Tomi Valkeinen wrote:
>> Hi,
>>
>> I have been testing Common Display Framework on OMAP, and making changes
>> that I've discussed in the posts I've sent in reply to the CDF series from
>> Laurent. While my CDF code is rather hacky and not at all ready, I wanted
>> to post the code for comments and also as a reference code to my posts.
>>
>> So here is CDF-T (Tomi-edition =).
>
> We've discussed your approach extensively face-to-face today so I won't review
> the patches in detail, but I will instead summarize our discussion to make
> sure we understood each other (and let other developers jump in).
>
> For the purpose of this discussion the term "display controller driver" (or
> just "display controller") refer to both the low-level driver layer that
> communicates directly with the display controller hardware, and to the higher-
> level driver layer that implements and exposes the userspace API (FBDEV, KMS
> and/or V4L). Those layers can be implemented in multiple kernel modules (such
> as in the OMAP DSS case, with omapdss for the low-level layer and omapdrm,
> omapfb and omapvout for the API-level layer) or a single kernel module.
>
> Control model
> -
>
> The figure at http://www.ideasonboard.org/media/cdf/cdf-panel-control-
> model.png shows the CDF control model.
>
> The panel object depicted on the figure doesn't need to be a panel in the
> stricter sense but could be any chain of off-SoC (both on-board or off-board)
> display entities. It however helps thinking about it as a panel and doesn't
> hurt the model.
>
> The panel is controlled through abstract control requests. Those requests are
> used to retrieve panel information (such as the physical size, the supported
> video modes, EDID information, ...), set the panel configuration (such as the
> active video timings) or control the panel operation state (enabling/disabling
> the panel, controlling panel blanking and power management, ...). They are
> exposed by the panel using function pointers, and called by other kernel
> components in response to userspace requests (through the FBDEV, KMS or V4L2
> APIs) or in-kernel events (for instance hotplug notifications).
>
> In response to the control requests the panel driver will communicate with the
> panel through the panel control bus (I2C, SPI, DBI, DSI, GPIO, ..., not shown
> on the figure) and will control the video stream it receives on its input.
>
> The panel is connected at the hardware level to a video source (shown as a
> green hashed rectangle) that provides it with a video stream. The video stream
> flows from the video source to the panel and is directly controlled by its
> source, as shown by the green arrow from the display controller to the video
> stream. The video source exposes stream control operations as function
> pointers that are used by the panel to control the video stream, as shown by
> the green arrow from the panel to the video source.
>
> The figure at http://www.ideasonboard.org/media/cdf/cdf-panel-control-
> model-2.png shows the call flow across entities when the panel is a pipeline
> made of more than a single entity. In this case the SoC (on the left of the
> dashed line) outputs a video stream on a DSI bus connected to a DSI to LVDS
> transmitter. The output of the DSI to LVDS transmitter is connected to an LVDS
> panel (or, more accurately, an LVDS panel module made of an LVDS panel
> controller and a panel).
>
> The transmitter and panel module are seen by the display controller and
> userspace API implementations as a single entity that exposes control request
> operations and controls its input video stream. When a control request is
> performed (outermost green arrow) the DSI to LVDS transmitter will propagate
> it to the panel, possibly mangling the input parameters or the response. For
> panel operation state control requests the last entity in the pipeline will
> likely want to control the video stream it receives on its input. The video
> stream control calls will be propagated from right to left as shown by the red
> arrows.
>
> Every entity in the call stack can communicate with its hardware device
> through the corresponding control bus, and/or control the video stream it
> receives on its input.
>
> This model allows filtering out modes and timings supported by the panel but
> unsupported by the transmitter and mangling the modes and timings according to
> the transmitter limitations. It has no complexity drawback for simple devices,
> as the corresponding drivers can just forward the calls directly. Similar use
> cases could exist for other control operations than mode and information
> retrieval.
>
> Discovery
> -
>
> Before being able to issue control requests, panel devices need to be
> discovered and associated with the connected display controller(s).
>
> Panels and display controllers are cross-dependen

[Bug 56405] Distorted graphics on Radeon HD 6620G

https://bugs.freedesktop.org/show_bug.cgi?id=56405

--- Comment #52 from Johannes Hirte  ---
Fix works for me.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58655] Screen totally corrupted on CAYMAN, [drm : evergreen_vm_reg_valid] ERROR Invalid register 0x8040 in CS

https://bugs.freedesktop.org/show_bug.cgi?id=58655

Alex Deucher  changed:

   What|Removed |Added

 CC||dcherkas...@gmail.com

--- Comment #4 from Alex Deucher  ---
*** Bug 58724 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58724] [r600g] [bisected]: "rework flusing ...v7" commit by Jerome causes problems

https://bugs.freedesktop.org/show_bug.cgi?id=58724

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Alex Deucher  ---


*** This bug has been marked as a duplicate of bug 58655 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58724] [r600g] [bisected]: "rework flusing ...v7" commit by Jerome causes problems

https://bugs.freedesktop.org/show_bug.cgi?id=58724

--- Comment #1 from Dmitry Cherkassov  ---
Forgot to add:
* The device is Radeon HD 6970 (cayman)
* Kernel is 3.7.0-rc5 (tip of Alex's drm-fixes-3.7 branch)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58724] New: [r600g] [bisected]: "rework flusing ...v7" commit by Jerome causes problems

https://bugs.freedesktop.org/show_bug.cgi?id=58724

  Priority: medium
Bug ID: 58724
  Assignee: dri-devel@lists.freedesktop.org
   Summary: [r600g] [bisected]: "rework flusing ...v7" commit by
Jerome causes problems
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: dcherkas...@gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 72082
  --> https://bugs.freedesktop.org/attachment.cgi?id=72082&action=edit
summary of ./configure

Hi. I've found by git-bisect that this commit causes problems with glxgears and
other stuff:

24b1206ab2dcd506aaac3ef656aebc8bc20cd27a is the first bad commit
commit 24b1206ab2dcd506aaac3ef656aebc8bc20cd27a
Author: Jerome Glisse 
Date:   Thu Nov 1 16:09:40 2012 -0400

r600g: rework flusing and synchronization pattern v7


The glxgears picture is crippled with no animation.

that's mesa runtime error:
> radeon: The kernel rejected CS, see dmesg for more information.

That's what kernel driver says:
> [20056.450057] [drm:evergreen_vm_reg_valid] *ERROR* Invalid register 0x8040 
> in CS

System is 64-bit debian.

Build flags are:
PKG_CONFIG_PATH=/opt/lib/pkgconfig ./autogen.sh --enable-texture-float
--with-dri-drivers="" --prefix=/opt --with-gallium-drivers=r600 --enable-debug

llvm is 3.2 from tstellard's branch (HEAD:
15265bc80edeceb5bcfc4d0b85be751be9275a7d )

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

Hi Rob,

(CC'ing Hans Verkuil)

On Wednesday 19 December 2012 10:05:27 Rob Clark wrote:
> On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen wrote:
> > On 2012-12-19 17:26, Rob Clark wrote:
> >> And, there are also external HDMI encoders (for example connected over
> >> i2c) that can also be shared between boards.  So I think there will be
> >> a number of cases where CDF is appropriate for HDMI drivers.  Although
> >> trying to keep this all independent of DRM (as opposed to just something
> >> similar to what drivers/gpu/i2c is today) seems a bit overkill for me. 
> >> Being able to use the helpers in drm and avoiding an extra layer of
> >> translation seems like the better option to me.  So my vote would be
> >> drivers/gpu/cdf.
> > 
> > Well, we need to think about that. I would like to keep CDF independent
> > of DRM. I don't like tying different components/frameworks together if
> > there's no real need for that.
> > 
> > Also, something that Laurent mentioned in our face-to-face discussions:
> > Some IPs/chips can be used for other purposes than with DRM.
> > 
> > He had an example of a board, that (if I understood right) gets video
> > signal from somewhere outside the board, processes the signal with some
> > IPs/chips, and then outputs the signal. So there's no framebuffer, and
> > the image is not stored anywhere. I think the framework used in these
> > cases is always v4l2.
> > 
> > The IPs/chips in the above model may be the exact same IPs/chips that
> > are used with "normal" display. If the CDF was tied to DRM, using the
> > same drivers for normal and these streaming cases would probably not be
> > possible.
> 
> Well, maybe there is a way, but it really seems to be over-complicating
> things unnecessarily to keep CDF independent of DRM..  there will be a lot
> more traditional uses of CDF compared to one crazy use-case.  So I don't
> really fancy making it more difficult than in needs to be for everyone.

Most of the use cases will be in DRM, we agree on that. However, I don't think 
that the use case mentioned by Tomi is in any way crazy. TI has DaVinci chips 
that can process/capture/generate up to 18 (if my memory is correct) video 
streams, and those are extensively used in video conferencing solutions or set 
top boxes for instance. A couple of the output video streams are display-based 
and should be handled by DRM/KMS, but most of them are V4L2 streams. That's 
something we should discuss with Hans Verkuil, he might be able to provide us 
with more information.

> Probably the thing to do is take a step back and reconsider that one crazy
> use-case.  For example, KMS doesn't enforce that the buffer handled passed
> when you create a drm framebuffer object to scan out is a GEM buffer.  So on
> that one crazy platform, maybe it makes sense to have a DRM/KMS display
> driver that takes a handle to identify which video stream coming from the
> capture end of the pipeline.  Anyways, that is just an off-the-top-of-my-
> head idea, probably there are other options too.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

Hi Rob,

On Wednesday 19 December 2012 09:26:40 Rob Clark wrote:
> On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula wrote:
> > On Tue, 18 Dec 2012, Laurent Pinchart wrote:
> >> On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
> >>> I can see the need for a framework for DSI panels and such (in fact Tomi
> >>> and I have talked about it like 2-3 years ago already!) but what is the
> >>> story for HDMI and DP? In particular, what's the relationship between
> >>> DRM and CDF here? Is there a world domination plan to switch the DRM
> >>> drivers to use this framework too? ;) Do you have some rough plans how
> >>> DRM and CDF should work together in general?
> >> 
> >> There's always a world domination plan, isn't there ? :-)
> >> 
> >> I certainly want CDF to be used by DRM (or more accurately KMS). That's
> >> what the C stands for, common refers to sharing panel and other display
> >> entity drivers between FBDEV, KMS and V4L2.
> >> 
> >> I currently have no plan to expose CDF internals to userspace through the
> >> KMS API. We might have to do so later if the hardware complexity grows
> >> in such a way that finer control than what KMS provides needs to be
> >> exposed to userspace, but I don't think we're there yet. The CDF API
> >> will thus only be used internally in the kernel by display controller
> >> drivers. The KMS core might get functions to handle common display
> >> entity operations, but the bulk of the work will be in the display
> >> controller drivers to start with. We will then see what can be
> >> abstracted in KMS helper functions.
> >> 
> >> Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the
> >> CDF API. That's just a thought for now, I haven't tried to implement
> >> them, but it would be nice to handle HDMI screens and DPI/DBI/DSI panels
> >> in a generic way.
> >> 
> >> Do you have thoughts to share on this topic ?
> > 
> > It just seems to me that, at least from a DRM/KMS perspective, adding
> > another layer (=CDF) for HDMI or DP (or legacy outputs) would be
> > overengineering it. They are pretty well standardized, and I don't see
> > there would be a need to write multiple display drivers for them. Each
> > display controller has one, and can easily handle any chip specific
> > requirements right there. It's my gut feeling that an additional
> > framework would just get in the way. Perhaps there could be more common
> > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers,
> > but that's another thing.
> > 
> > So is the HDMI/DP drivers using CDF a more interesting idea from a
> > non-DRM perspective? Or, put another way, is it more of an alternative
> > to using DRM? Please enlighten me if there's some real benefit here that
> > I fail to see!
> 
> fwiw, I think there are at least a couple cases where multiple SoC's
> have the same HDMI IP block.
> 
> And, there are also external HDMI encoders (for example connected over
> i2c) that can also be shared between boards.  So I think there will be
> a number of cases where CDF is appropriate for HDMI drivers.  Although
> trying to keep this all independent of DRM (as opposed to just
> something similar to what drivers/gpu/i2c is today) seems a bit
> overkill for me.  Being able to use the helpers in drm and avoiding an
> extra layer of translation seems like the better option to me.  So my
> vote would be drivers/gpu/cdf.

I don't think there will be any need for translation (except perhaps between 
the DRM mode structures and the common video mode structure that is being 
discussed). Add a drm_ prefix to the existing CDF functions and structures, 
and there you go :-)

The reason why I'd like to keep CDF separate from DRM (or at least not 
requiring a drm_device) is that HDMI/DP encoders can be used by pure V4L2 
drivers.

> > For DSI panels (or DSI-to-whatever bridges) it's of course another
> > story. You typically need a panel specific driver. And here I see the
> > main point of the whole CDF: decoupling display controllers and the
> > panel drivers, and sharing panel (and converter chip) specific drivers
> > across display controllers. Making it easy to write new drivers, as
> > there would be a model to follow. I'm definitely in favour of coming up
> > with some framework that would tackle that.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

Hi Tomi,

On Wednesday 19 December 2012 17:07:50 Tomi Valkeinen wrote:
> On 2012-12-19 16:57, Jani Nikula wrote:
> > It just seems to me that, at least from a DRM/KMS perspective, adding
> > another layer (=CDF) for HDMI or DP (or legacy outputs) would be
> > overengineering it. They are pretty well standardized, and I don't see
> > there would be a need to write multiple display drivers for them. Each
> > display controller has one, and can easily handle any chip specific
> > requirements right there. It's my gut feeling that an additional
> > framework would just get in the way. Perhaps there could be more common
> > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers,
> > but that's another thing.
> > 
> > So is the HDMI/DP drivers using CDF a more interesting idea from a
> > non-DRM perspective? Or, put another way, is it more of an alternative
> > to using DRM? Please enlighten me if there's some real benefit here that
> > I fail to see!
> 
> The use of CDF is an option, not something that has to be done. A DRM
> driver developer may use it if it gives benefit for him for that
> particular driver.
> 
> I don't know much about desktop display hardware, but I guess that using
> CDF would not really give much there. In some cases it could, if the IPs
> used on the graphics card are something that are used elsewhere also
> (sounds quite unlikely, though). In that case there could be separate
> drivers for the IPs.
> 
> And note that CDF is not really about the dispc side, i.e. the part that
> creates the video stream from pixels in the memory. It's more about the
> components after that, and how to connect those components.
> 
> > For DSI panels (or DSI-to-whatever bridges) it's of course another
> > story. You typically need a panel specific driver. And here I see the
> > main point of the whole CDF: decoupling display controllers and the
> > panel drivers, and sharing panel (and converter chip) specific drivers
> > across display controllers. Making it easy to write new drivers, as
> > there would be a model to follow. I'm definitely in favour of coming up
> > with some framework that would tackle that.
> 
> Right. But if you implement drivers for DSI panels with CDF for, say,
> OMAP, I think it's simpler to use CDF also for HDMI/DP on OMAP.
> Otherwise it'll be a mishmash with two different models.

I second your point here, using CDF for encoders should be simpler, but it 
will not be enforced. A display controller driver developer who wants to 
control the on-SoC encoder without conforming to the CDF model will be totally 
free to do so and won't be blamed.

-- 
Regards,

Laurent Pinchart


signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

Hi Jani,

On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote:
> On Tue, 18 Dec 2012, Laurent Pinchart wrote:
> > On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
> >> I can see the need for a framework for DSI panels and such (in fact Tomi
> >> and I have talked about it like 2-3 years ago already!) but what is the
> >> story for HDMI and DP? In particular, what's the relationship between
> >> DRM and CDF here? Is there a world domination plan to switch the DRM
> >> drivers to use this framework too? ;) Do you have some rough plans how
> >> DRM and CDF should work together in general?
> > 
> > There's always a world domination plan, isn't there ? :-)
> > 
> > I certainly want CDF to be used by DRM (or more accurately KMS). That's
> > what the C stands for, common refers to sharing panel and other display
> > entity drivers between FBDEV, KMS and V4L2.
> > 
> > I currently have no plan to expose CDF internals to userspace through the
> > KMS API. We might have to do so later if the hardware complexity grows in
> > such a way that finer control than what KMS provides needs to be exposed
> > to userspace, but I don't think we're there yet. The CDF API will thus
> > only be used internally in the kernel by display controller drivers. The
> > KMS core might get functions to handle common display entity operations,
> > but the bulk of the work will be in the display controller drivers to
> > start with. We will then see what can be abstracted in KMS helper
> > functions.
> > 
> > Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the
> > CDF API. That's just a thought for now, I haven't tried to implement them,
> > but it would be nice to handle HDMI screens and DPI/DBI/DSI panels in a
> > generic way.
> > 
> > Do you have thoughts to share on this topic ?
> 
> It just seems to me that, at least from a DRM/KMS perspective, adding
> another layer (=CDF) for HDMI or DP (or legacy outputs) would be
> overengineering it. They are pretty well standardized, and I don't see there
> would be a need to write multiple display drivers for them. Each display
> controller has one, and can easily handle any chip specific requirements
> right there. It's my gut feeling that an additional framework would just get
> in the way. Perhaps there could be more common HDMI/DP helper style code in
> DRM to reduce overlap across KMS drivers, but that's another thing.
>
> So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM
> perspective? Or, put another way, is it more of an alternative to using DRM?
> Please enlighten me if there's some real benefit here that I fail to see!

As Rob pointed out, you can have external HDMI/DP encoders, and even internal 
HDMI/DP encoder IPs can be shared between SoCs and SoC vendors. CDF aims at 
sharing a single driver between SoCs and boards for a given HDMI/DP encoder.

CDF isn't an alternative to DRM/KMS. It should be seen as a framework that 
helps DRM/KMS drivers (as well as V4L2 drivers, and possibly FBDEV drivers, 
although those should be ported to DRM/KMS) sharing encoder and connector 
code.

> For DSI panels (or DSI-to-whatever bridges) it's of course another story.
> You typically need a panel specific driver. And here I see the main point of
> the whole CDF: decoupling display controllers and the panel drivers, and
> sharing panel (and converter chip) specific drivers across display
> controllers. Making it easy to write new drivers, as there would be a model
> to follow. I'm definitely in favour of coming up with some framework that
> would tackle that.

That's the main (and original) goal of CDF (originally called Generic Panel 
Framwork, and renamed to CDF to support encoder drivers as explained above). 
I'm glad to know that you're in favour of it :-)

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

Hi Sylwester,

On Tuesday 18 December 2012 11:59:35 Sylwester Nawrocki wrote:
> On 12/18/2012 07:21 AM, Rob Clark wrote:
> > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie  wrote:
> >> So this might be a bit off topic but this whole CDF triggered me
> >> looking at stuff I generally avoid:
> >> 
> >> The biggest problem I'm having currently with the whole ARM graphics
> >> and output world is the proliferation of platform drivers for every
> >> little thing. The whole ordering of operations with respect to things
> >> like suspend/resume or dynamic power management is going to be a real
> >> nightmare if there are dependencies between the drivers. How do you
> >> enforce ordering of s/r operations between all the various components?
> 
> There have been already some ideas proposed to resolve this at the PM
> subsystem level [1]. And this problem is of course not only specific to
> platform drivers. The idea of having monolithic drivers, just because we
> can't get the suspend/resume sequences right otherwise, doesn't really sound
> appealing. SoC IPs get reused on multiple different SoC series, no only by
> single manufacturer. Whole graphics/video subsystems are composed from
> smaller blocks in SoCs, with various number of distinct sub-blocks and same
> sub-blocks repeated different number of times in a specific SoC revision.
> Expressing an IP as a platform device seems justified to me, often these
> platform devices have enough differences to treat them as such. E.g. belong
> in different power domain/use different clocks. Except there is big issue
> with the power management... However probably more important is to be able
> to have driver for a specific IP in a separate module.
> 
> And this suspend/resume ordering issue is not only about the platform
> devices. E.g. camera subsystem can be composed of an image sensor sub-device
> driver, which is most often an I2C client driver, and of multiple SoC
> processing blocks. The image sensor can have dependencies on the SoC sub-
> blocks. So even if we created monolithic driver for the SoC part, there are
> still two pieces to get s/r ordering right - I2C client and SoC drivers. And
> please don't propose to merge the sensor sub-device driver too. There has
> been a lot of effort in V4L2 to separate those various functional blocks
> into sub-devices, so they can be freely reused, without reimplementing same
> functionality in each driver. BTW, there has been a nice talk about these
> topics at ELCE [2], particularly slide 22 is interesting.
> 
> I believe the solution for these issues really needs to be sought in the PM
> subsystem itself.

I tend to agree with you, or at least I believe we should research a proper 
solution in the PM framework. In the meantime, though, I think early 
suspend/late resume might provide an intermediate solution.

> > I tend to think that sub-devices are useful just to have a way to
> > probe hw which may or may not be there, since on ARM we often don't
> > have any alternative.. but beyond that, suspend/resume, and other
> > life-cycle aspects, they should really be treated as all one device.
> > Especially to avoid undefined suspend/resume ordering.
> 
> [1] https://lkml.org/lkml/2009/9/9/373
> [2]
> http://elinux.org/images/9/90/ELCE2012-Modular-Graphics-on-Embedded-ARM.pdf

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58696] Choppy video playback in VLC with R600g on Radeon HD 6620G

https://bugs.freedesktop.org/show_bug.cgi?id=58696

Andreas Boll  changed:

   What|Removed |Added

  Component|Drivers/DRI/R600|Drivers/Gallium/r600

-- 
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/20121224/d25e0690/attachment.html>

Re: [RFC v2 0/5] Common Display Framework

Hi Marcus,

On Tuesday 18 December 2012 11:39:11 Marcus Lorentzon wrote:
> On 12/18/2012 06:04 AM, Dave Airlie wrote:
> >> Many developers showed interest in the first RFC, and I've had the
> >> opportunity to discuss it with most of them. I would like to thank (in
> >> no particular order) Tomi Valkeinen for all the time he spend helping me
> >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect
> >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to
> >> discuss this topic.
> > 
> > So this might be a bit off topic but this whole CDF triggered me
> > looking at stuff I generally avoid:
>
> I like the effort, right now it seems like x86 and arm display sub systems
> are quite different in terms of DRM driver (and HW) design. I think this is
> partly due to little information shared about these different architectures
> and ideas behind the choices made. I hope some discussion will light up both
> sides. And an early discussion will hopefully give you less pain when CDF
> drivers starts to get pushed your way.

On the topic of discussions, would anyone be interested in a 
BoF/brainstorming/whatever session during the FOSDEM ?

> > The biggest problem I'm having currently with the whole ARM graphics
> > and output world is the proliferation of platform drivers for every
> > little thing. The whole ordering of operations with respect to things
> > like suspend/resume or dynamic power management is going to be a real
> > nightmare if there are dependencies between the drivers. How do you
> > enforce ordering of s/r operations between all the various components?
> 
> Could you give an example? Personally I don't think it is that many. I
> might not have counted the plat devs in all arm drivers. But the STE one
> have one per HW IP block in the HW (1 DSS + 3 DSI encoder/formatters).
> Then of course there are all these panel devices. But I hope that when
> CDF is "finished" we will have DSI devices on the DSI bus and DBI
> devices on the DBI bus. I think most vendors have used platform devices
> for these since they normally can't be probed in a generic way. But as
> they are off SoC I feel this is not the best choice. And then many of
> the panels are I2C devices (control bus) and that I guess is similar to
> "x86" encoders/connectors?

Tomi Valkeinen proposed dropping the DSI and DBI busses in favor of the 
platform bus. Although I still believe that DSI and DBI busses would make 
sense, I agree that they don't provide much in terms of probing and power 
management. You can read the discussion at http://www.spinics.net/lists/linux-
fbdev/msg09250.html.

> Another part of the difference I feel is that in x86 a DRM device is
> most likely a PCI device, and as such has one huge driver for all IPs on
> that board. The closest thing we get to that in ARM is probably the DSS
> (collection of IPs on SoC, like 3D, 2D, display output, encoders). But
> it doesn't fell right to create a single driver for all these. And as
> you know often 3D is even from a separate vendor. All these lead up to a
> slight increase in the number of devices and drivers. Right way, I feel
> so, but you are welcome to show a better way.
> 
> > The other thing I'd like you guys to do is kill the idea of fbdev and
> > v4l drivers that are "shared" with the drm codebase, really just
> > implement fbdev and v4l on top of the drm layer, some people might
> > think this is some sort of maintainer thing, but really nothing else
> > makes sense, and having these shared display frameworks just to avoid
> > having using drm/kms drivers seems totally pointless. Fix the drm
> > fbdev emulation if an fbdev interface is needed. But creating a fourth
> > framework because our previous 3 frameworks didn't work out doesn't
> > seem like a situation I want to get behind too much.
> 
> I have no intention to use CDF outside KMS connector/encoder and I have
> not heard Laurent talk about this either.

I don't either. CDF will mostly target KMS connectors, and can also be used 
for KMS encoders. I have no plan to touch the CRTC.

> Personally I see CDF as "helpers" to create and reuse connector/encoder
> drivers between SoCs instead of each SoC do their own panel drivers (which
> would be about a hundred, times the number of supported SoCs). We probably
> need to discuss the connector/encoder mappings to CDF/panels.

That's a topic I was planning to discuss at some point. One of the issues is 
that the KMS model can only have 3 entities in the pipeline, while hardware 
pipelines (especially in the embedded world) could be made of 4 or more 
entities (such as CRTC -> DSI encoder -> DSI to HDMI converter -> HDMI 
connector). We might not have to expose all details to userspace, but we need 
mapping rules.

> But I think we need to flush out the higher level details like control bus
> vs. data bus vs. display entities. While I like the generic way of the
> display entities, I also like the pure bus/device/driver model with

Re: [RFC v2 0/5] Common Display Framework

Hi Tomasz,

On Friday 21 December 2012 11:00:52 Tomasz Figa wrote:
> On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote:
> > On 17 December 2012 20:55, Laurent Pinchart wrote:
> > > Hi Vikas,
> > > 
> > > Sorry for the late reply. I now have more time to work on CDF, so
> > > delays should be much shorter.
> > > 
> > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote:
> > > > Hi Laurent,
> > > > 
> > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, what
> > > > I found is that, the exynos display controller is MIPI DSI based
> > > > controller.
> > > > 
> > > > But if I look at CDF patches, it has only support for MIPI DBI based
> > > > Display controller.
> > > > 
> > > > So my question is, do we have any generic framework for MIPI DSI
> > > > based display controller? basically I wanted to know, how to go about
> > > > porting CDF for such kind of display controller.
> > > 
> > > MIPI DSI support is not available yet. The only reason for that is
> > > that I don't have any MIPI DSI hardware to write and test the code
> > > with :-)
> > > 
> > > The common display framework should definitely support MIPI DSI. I
> > > think the existing MIPI DBI code could be used as a base, so the
> > > implementation shouldn't be too high.
> > > 
> > > Yeah, i was also thinking in similar lines, below is my though for
> > > MIPI DSI support in CDF.
> > 
> > o   MIPI DSI support as part of CDF framework will expose
> > §  mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c
> > file )
> > §  mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from
> > platform specific init driver call )
> > ·bus ops will be
> > o   read data
> > o   write data
> > o   write command
> > §  MIPI DSI will be registered as bus_register()
> > 
> > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will
> > initialize the MIPI DSI HW IP.
> > 
> > This probe will also parse the DT file for MIPI DSI based panel, add
> > the panel device (device_add() ) to kernel and register the display
> > entity with its control and  video ops with CDF.
> > 
> > I can give this a try.
> 
> I am currently in progress of reworking Exynos MIPI DSIM code and s6e8ax0
> LCD driver to use the v2 RFC of Common Display Framework. I have most of
> the work done, I have just to solve several remaining problems.

Do you already have code that you can publish ? I'm particularly interested 
(and I think Tomi Valkeinen would be as well) in looking at the DSI operations 
you expose to DSI sinks (panels, transceivers, ...).

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

Hi Inki,

On Tuesday 18 December 2012 18:38:31 Inki Dae wrote:
> 2012/12/18 Daniel Vetter 
> > On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark  wrote:
> > >> The other thing I'd like you guys to do is kill the idea of fbdev and
> > >> v4l drivers that are "shared" with the drm codebase, really just
> > >> implement fbdev and v4l on top of the drm layer, some people might
> > >> think this is some sort of maintainer thing, but really nothing else
> > >> makes sense, and having these shared display frameworks just to avoid
> > >> having using drm/kms drivers seems totally pointless. Fix the drm
> > >> fbdev emulation if an fbdev interface is needed. But creating a fourth
> > >> framework because our previous 3 frameworks didn't work out doesn't
> > >> seem like a situation I want to get behind too much.
> > > 
> > > yeah, let's not have multiple frameworks to do the same thing.. For
> > > fbdev, it is pretty clear that it is a dead end.  For v4l2
> > > (subdev+mcf), it is perhaps bit more flexible when it comes to random
> > > arbitrary hw pipelines than kms.  But to take advantage of that, your
> > > userspace isn't going to be portable anyways, so you might as well use
> > > driver specific properties/ioctls.  But I tend to think that is more
> > > useful for cameras.  And from userspace perspective, kms planes are
> > > less painful to use for output than v4l2, so lets stick to drm/kms for
> > > output (and not try to add camera/capture support to kms).. k, thx
> > 
> > Yeah, I guess having a v4l device also exported by the same driver
> > that exports the drm interface might make sense in some cases. But in
> > many cases I think the video part is just an independent IP block and
> > shuffling data around with dma-buf is all we really need. So yeah, I
> > guess sharing display resources between v4l and drm kms driver should
> > be a last resort option, since coordination (especially if it's
> > supposed to be somewhat dynamic) will be extremely hairy.
> 
> I think the one reason that the CDF was appeared is to avoid duplicating
> codes. For example, we should duplicate mipi-dsi or dbi drivers into drm to
> avoid ordering issue. And for this, those should be re-implemented in based
> on drm framework so that those could be treated as all one device.
> Actually, in case of Exynos, some guys tried to duplicate eDP driver into
> exynos drm framework in same issue. So I think the best way is to avoid
> duplicating codes and resolve ordering issue such as s/r operations between
> all the various components.
> 
> And the below is my opinion,
> 
>   ++
> Display Controller  CDF - |MIPI-DSI/DBI---LCD Panel|
>   ++
> 
> 1. to access MIPI-DSI/DBI and LCD Panel drivers.
> - Display Controller is controlled by linux framebuffer or drm kms
> based specific drivers like now. And each driver calls some interfaces of
> CDF.
> 
> 2. to control the power of these devices.
> - drm kms based specific driver calls dpms operation and next the dpms
> operation calls fb blank operation of linux framebuffer.
>   But for this, we need some interfaces that it can connect between drm
> and linux framebuffer framework and you can refer to the below link.
> 
> http://lists.freedesktop.org/archives/dri-devel/2011-July/013242.html

(Just FYI, I plan to clean up the backlight framework when I'll be done with 
CDF, to remove the FBDEV dependency)

> - linux framebuffer based driver calls fb blank operation.
> 
> fb blank(fb)-pm runtime(fb)---fb_blank--mipi and lcd
> dpms(drm kms)pm runtime(drm kms)--fb_blank--mipi and lcd
> 
> 3. suspend/resume
> - pm suspend/resume are implemented only in linux framebuffer or drm
> kms based specific drivers.
> - MIPI-DSI/DBI and LCD Panel drivers are controlled only by fb blank
> interfaces.
> 
> s/r(fb)pm runtime(fb)fb blank---mipi and lcd
> s/r(drm kms)---dpms(drm kms)---pm runtime(drm kms)---fb_blank---mipi and lcd
> 
> 
> We could resolve ordering issue to suspend/resume simply duplicating
> relevant drivers but couldn't avoid duplicating codes. So I think we could
> avoid the ordering issue using fb blank interface of linux framebuffer and
> also duplicating codes.

As I mentioned before, we have multiple ordering issues related to suspend and 
resume. Panels and display controllers will likely want to enforce a S/R order 
on the video bus, and control busses will also require a specific S/R order. 
My plan is to use early suspend/late resume in the display controller driver 
to control the video busses, and let the PM core handle control bus ordering 
issues. This will of course need to be prototyped and tested.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedeskt

[Bug 44499] r280 and xbmc - choppy menu and video playback

https://bugs.freedesktop.org/show_bug.cgi?id=44499

--- Comment #16 from smoki  ---
Created attachment 72076
  --> https://bugs.freedesktop.org/attachment.cgi?id=72076&action=edit
corruption in gliv

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

Hi Daniel,

On Tuesday 18 December 2012 09:30:00 Daniel Vetter wrote:
> On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark  wrote:
> >> The other thing I'd like you guys to do is kill the idea of fbdev and
> >> v4l drivers that are "shared" with the drm codebase, really just
> >> implement fbdev and v4l on top of the drm layer, some people might
> >> think this is some sort of maintainer thing, but really nothing else
> >> makes sense, and having these shared display frameworks just to avoid
> >> having using drm/kms drivers seems totally pointless. Fix the drm
> >> fbdev emulation if an fbdev interface is needed. But creating a fourth
> >> framework because our previous 3 frameworks didn't work out doesn't
> >> seem like a situation I want to get behind too much.
> > 
> > yeah, let's not have multiple frameworks to do the same thing.. For
> > fbdev, it is pretty clear that it is a dead end.  For v4l2
> > (subdev+mcf), it is perhaps bit more flexible when it comes to random
> > arbitrary hw pipelines than kms.  But to take advantage of that, your
> > userspace isn't going to be portable anyways, so you might as well use
> > driver specific properties/ioctls.  But I tend to think that is more
> > useful for cameras.  And from userspace perspective, kms planes are
> > less painful to use for output than v4l2, so lets stick to drm/kms for
> > output (and not try to add camera/capture support to kms).. k, thx
> 
> Yeah, I guess having a v4l device also exported by the same driver that
> exports the drm interface might make sense in some cases. But in many cases
> I think the video part is just an independent IP block and shuffling data
> around with dma-buf is all we really need. So yeah, I guess sharing display
> resources between v4l and drm kms driver should be a last resort option,
> since coordination (especially if it's supposed to be somewhat dynamic) will
> be extremely hairy.

I totally agree. As explained in my replies to Dave and Rob, I don't want to 
share devices between the different subsystems at runtime, but I'd like to 
avoid writing two drivers for a single device that can be used for display and 
graphics on one board, and video output on another board (HDMI transmitters 
are a good example).

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

Hi Rob,

On Tuesday 18 December 2012 00:21:32 Rob Clark wrote:
> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie  wrote:
> >> Many developers showed interest in the first RFC, and I've had the
> >> opportunity to discuss it with most of them. I would like to thank (in
> >> no particular order) Tomi Valkeinen for all the time he spend helping me
> >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect
> >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to
> >> discuss this topic.
> > 
> > So this might be a bit off topic but this whole CDF triggered me
> > looking at stuff I generally avoid:
> > 
> > The biggest problem I'm having currently with the whole ARM graphics
> > and output world is the proliferation of platform drivers for every
> > little thing. The whole ordering of operations with respect to things
> > like suspend/resume or dynamic power management is going to be a real
> > nightmare if there are dependencies between the drivers. How do you
> > enforce ordering of s/r operations between all the various components?
> 
> I tend to think that sub-devices are useful just to have a way to probe hw
> which may or may not be there, since on ARM we often don't have any
> alternative.. but beyond that, suspend/resume, and other life-cycle aspects,
> they should really be treated as all one device. Especially to avoid
> undefined suspend/resume ordering.

I tend to agree, except that I try to reuse the existing PM infrastructure 
when possible to avoid reinventing the wheel. So far handling suspend/resume 
ordering related to data busses in early suspend/late resume operations and 
allowing the Linux PM core to handle control busses using the Linux device 
tree worked pretty well.

> CDF or some sort of mechanism to share panel drivers between drivers is
> useful.  Keeping it within drm, is probably a good idea, if nothing else to
> simplify re-use of helper fxns (like avi-infoframe stuff, for example) and
> avoid dealing with merging changes across multiple trees. Treating them more
> like shared libraries and less like sub-devices which can be dynamically
> loaded/unloaded (ie. they should be not built as separate modules or
> suspend/resumed or probed/removed independently of the master driver) is a
> really good idea to avoid uncovering nasty synchronization issues later
> (remove vs modeset or pageflip) or surprising userspace in bad ways.

We've tried that in V4L2 years ago and realized that the approach led to a 
dead-end, especially when OF/DT got involved. With DT-based device probing, 
I2C camera sensors started getting probed asynchronously to the main camera 
device, as they are children of the I2C bus master. We will have similar 
issues with I2C HDMI transmitters or panels, so we should be prepared for it.

On PC hardware the I2C devices are connected to an I2C master provided by the 
GPU, but on embedded devices they are usually connected to an independent I2C 
master. We thus can't have a single self-contained driver that controls 
everything internally, and need to interface with the rest of the SoC drivers.

I agree that probing/removing devices independently of the master driver can 
lead to bad surprises, which is why I want to establish clear rules in CDF 
regarding what can and can't be done with display entities. Reference counting 
will be one way to make sure that devices don't disappear all of a sudden.

> > The other thing I'd like you guys to do is kill the idea of fbdev and
> > v4l drivers that are "shared" with the drm codebase, really just
> > implement fbdev and v4l on top of the drm layer, some people might
> > think this is some sort of maintainer thing, but really nothing else
> > makes sense, and having these shared display frameworks just to avoid
> > having using drm/kms drivers seems totally pointless. Fix the drm
> > fbdev emulation if an fbdev interface is needed. But creating a fourth
> > framework because our previous 3 frameworks didn't work out doesn't
> > seem like a situation I want to get behind too much.
> 
> yeah, let's not have multiple frameworks to do the same thing.. For fbdev,
> it is pretty clear that it is a dead end.  For v4l2 (subdev+mcf), it is
> perhaps bit more flexible when it comes to random arbitrary hw pipelines
> than kms.  But to take advantage of that, your userspace isn't going to be
> portable anyways, so you might as well use driver specific
> properties/ioctls.  But I tend to think that is more useful for cameras. 
> And from userspace perspective, kms planes are less painful to use for
> output than v4l2, so lets stick to drm/kms for output (and not try to add
> camera/capture support to kms)..

Agreed. I've started to advocate the deprecation of FBDEV during LPC. The 
positive response has motivated me to continue doing so :-) For V4L2 the 
situation is a little bit different, I think V4L2 shouldn't be used for 
graphics and display hardware, but it still has use cases on the video output

[Bug 44499] r280 and xbmc - choppy menu and video playback

https://bugs.freedesktop.org/show_bug.cgi?id=44499

--- Comment #15 from smoki  ---
Created attachment 72075
  --> https://bugs.freedesktop.org/attachment.cgi?id=72075&action=edit
corruption in STK


 Actually corruption can be easely seen in supertuxkart, non-fbo case usage.

 That is before this commit, don't know why people tries to hide a problem and
instead slowing down everything - that way no one can manage to see a problem
and maybe manage to try to fix it ;).

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

Hi Dave,

On Tuesday 18 December 2012 15:04:02 Dave Airlie wrote:
> > Many developers showed interest in the first RFC, and I've had the
> > opportunity to discuss it with most of them. I would like to thank (in no
> > particular order) Tomi Valkeinen for all the time he spend helping me to
> > draft v2, Marcus Lorentzon for his useful input during Linaro Connect Q4
> > 2012, and Linaro for inviting me to Connect and providing a venue to
> > discuss this topic.
>
> So this might be a bit off topic but this whole CDF triggered me looking at
> stuff I generally avoid:
> 
> The biggest problem I'm having currently with the whole ARM graphics and
> output world is the proliferation of platform drivers for every little
> thing. The whole ordering of operations with respect to things like
> suspend/resume or dynamic power management is going to be a real nightmare
> if there are dependencies between the drivers.

We share the same concern, although my analysis of the problem is somewhat 
different. The power management ordering issues isn't only caused by the 
software architecture, but also comes from complex hardware requirements. The 
root cause, in my opinion, is the split control and data busses: as soon as a 
device sits on multiple busses and has power management ordering requirements 
related to those busses the Linux power management model breaks. Note that the 
problem isn't restricted to the display, we have run into the exact same 
issues years ago on the video capture side.

> How do you enforce ordering of s/r operations between all the various
> components?

The way we have handled this problem on the camera side is to use early 
suspend and late resume operations to handle the data (video) busses suspend 
and resume operations, and let the kernel handle the rest using the control 
bus based device tree model. The camera controller stops the video pipeline in 
its early suspend operation (and resumes it in the late resume operation) by 
calling operations provided by the entities (through function pointers of 
course, we don't want direct dependencies between the drivers). The control 
suspend/resume (such as sending a standby command through I2C to put the chip 
in low-power mode, or turning its power supply or clock off) is then handled 
by the PM core.

> The other thing I'd like you guys to do is kill the idea of fbdev and v4l
> drivers that are "shared" with the drm codebase, really just implement fbdev
> and v4l on top of the drm layer, some people might think this is some sort
> of maintainer thing, but really nothing else makes sense, and having these
> shared display frameworks just to avoid having using drm/kms drivers seems
> totally pointless. Fix the drm fbdev emulation if an fbdev interface is
> needed. But creating a fourth framework because our previous 3 frameworks
> didn't work out doesn't seem like a situation I want to get behind too much.

I think there's a misunderstanding here. I'm definitely not trying to create a 
framework to expose the FBDEV/KMS/V4L2 APIs through different drivers on top 
of the same hardware device. That's an idea I really dislike, and I fully 
agree that the FBDEV API should be provided on top of KMS using the DRM FBDEV 
emulation layer. V4L2 on top of KMS doesn't make too much sense to me, as V4L2 
isn't really a display and graphics API anyway.

My goal here is to share code for chips that are used by different "devices" 
(in the sense of an agregate device, such as a camera or a graphics card) 
supported by different subsystems. For instance, the same I2C-controlled HDMI 
transmitter can be used by a display device when connected to a display 
controller on an SoC, but can also be used by a video output device when 
connected to a video output (some complex TI SoCs have pass-through video 
pipelines with no associated frame buffer, making the V4L2 API better suited 
than DRM/KMS). As the first device would be supported by a DRM/KMS driver and 
the second device by a pure V4L2 driver, we need a common framework to share 
code between both.

If the same framework can be used to share panel drivers between DRM/KMS and 
pure FBDEV drivers (we have a bunch of those, not all of them will be ported 
to DRM/KMS, at least not in the very near future) that's also a bonus.

To summarize my point, CDF aims at creating a self-contained framework that 
can be used by FBDEV, DRM/KMS and V4L2 drivers to interface with various 
display-related devices. It does not provide any userspace API, and does not 
offer any way to share devices between the three subsystems at runtime. In a 
way you can think of CDF as a DRM panel framework, but without the drm_ 
prefix.

I hope this clarifies my goals. If not, or if there's still concerns and/or 
disagreements, let's discuss them.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58660] Radeon HD 6950 completely broken with sapphire locked vbios

https://bugs.freedesktop.org/show_bug.cgi?id=58660

Alex Deucher  changed:

   What|Removed |Added

Summary|Radeon HD 6950 completely   |Radeon HD 6950 completely
   |broken with sapphire|broken with sapphire locked
   |unlocked vbios  |vbios

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 0/5] Common Display Framework

Hi Vikas,

On Tuesday 18 December 2012 08:31:30 Vikas Sajjan wrote:
> On 17 December 2012 20:55, Laurent Pinchart wrote:
> > Hi Vikas,
> > 
> > Sorry for the late reply. I now have more time to work on CDF, so delays
> > should be much shorter.
> > 
> > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote:
> > > Hi Laurent,
> > > 
> > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, what I
> > > found is that, the exynos display controller is MIPI DSI based
> > > controller.
> > > 
> > > But if I look at CDF patches, it has only support for MIPI DBI based
> > > Display controller.
> > > 
> > > So my question is, do we have any generic framework for MIPI DSI based
> > > display controller? basically I wanted to know, how to go about porting
> > > CDF for such kind of display controller.
> > 
> > MIPI DSI support is not available yet. The only reason for that is that I
> > don't have any MIPI DSI hardware to write and test the code with :-)
> > 
> > The common display framework should definitely support MIPI DSI. I think
> > the existing MIPI DBI code could be used as a base, so the implementation
> > shouldn't be too high.
> > 
> > Yeah, i was also thinking in similar lines, below is my though for MIPI
> > DSI support in CDF.
> 
> o MIPI DSI support as part of CDF framework will expose
>   § mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c
> file)
>   § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from
> platform specific init driver call )
> · bus ops will be
>   o read data
>   o write data
>   o write command
>  § MIPI DSI will be registered as bus_register()
> 
> When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will
> initialize the MIPI DSI HW IP.
> 
> This probe will also parse the DT file for MIPI DSI based panel, add
> the panel device (device_add() ) to kernel and register the display
> entity with its control and  video ops with CDF.

After discussing the DBI/DSI busses with Tomi Valkeinen we concluded that 
creating a real bus for DBI and DSI, although possible, wasn't required. DSI 
operations should thus be provided through display entity video source 
operations. You can find a proposed implementation in Tomi's patch set.

> > I can give this a try. Does the existing Exynos 5250 driver support MIPI
> > DSI ? Is the device documentation publicly available ? Can you point me to
> > a MIPI DSI panel with public documentation (preferably with an existing
> > mainline driver if possible) ?
>
> yeah, existing Exynos 5250 driver support MIPI DSI ass well as eDP.
> 
>  i think device documentation is NOT available publicly.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot

https://bugs.freedesktop.org/show_bug.cgi?id=58659

--- Comment #4 from Bryan Quigley  ---
Reverting patch 2d6cc729 does indeed fix the problem.

-- 
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/20121224/2c9c6870/attachment.html>

[Bug 57842] r200: Culling is broken when rendering to an FBO

https://bugs.freedesktop.org/show_bug.cgi?id=57842

--- Comment #12 from smoki  ---

 Yeah i tried your patch and it works, thanks Raphal. Someone could pushed it
in git if it's in good looking now ;).

-- 
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/20121224/ff20bd94/attachment.html>

[Bug 57842] r200: Culling is broken when rendering to an FBO

https://bugs.freedesktop.org/show_bug.cgi?id=57842

--- Comment #11 from Rafa? Mu?y?o  ---
Created attachment 72051
  --> https://bugs.freedesktop.org/attachment.cgi?id=72051&action=edit
attachment 72047 as patch for r200/radeon

@comment 9: your own attachment says it was not.
Anyway, attachment 72047 translated into a patch.

'cull_face = (mode == GL_CW) ? R200_FFACE_CULL_CW : R200_FFACE_CULL_CCW'
is bit of a mouthful, but atm. I've got not idea how to turn that into proper
obfuscation style of mesa sources.

-- 
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/20121224/56efba9d/attachment-0001.html>

[Bug 58696] New: Choppy video playback in VLC with R600g on Radeon HD 6620G

https://bugs.freedesktop.org/show_bug.cgi?id=58696

Priority: medium
Bug ID: 58696
Assignee: dri-devel at lists.freedesktop.org
Summary: Choppy video playback in VLC with R600g on Radeon HD
6620G
Severity: normal
Classification: Unclassified
OS: All
Reporter: runetmember at gmail.com
Hardware: Other
Status: NEW
Version: git
Component: Drivers/DRI/R600
Product: Mesa

Video playback of almost any typical 10Mbps 1080p BDRip is choppy (many dropped
frames) in VLC if R600g driver is used instead of fglrx on Radeon HD 6620G GPU.
Enabling/disabling composting doesn't make difference (so this issue is not
duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=47776 ).
Enabling/disabling "Suspend desktop effects for fullscreen windows" KWin
options doesn't make difference for fullscreen playback.
There is little difference between xv and OpenGL (GLX) output in VLC - xv
output a little faster but gives choppy playback too.

Issue is not reproducible:
1. in mplayer (SMPlayer is used) with R600g driver,
2. in Firefox (1080p VP8 playback) in Chrome (1080p H.264 playback) and in
Adobe Flash 11.5 plugin (1080p H.264 too) with R600g driver.
3. in VLC with fglrx driver (hardware decoder is not enabled).

Issue happen only in VLC&R600g combination.

VLC always uses indirect rendering instead of direct so I check mplayer
playback with disabled direct rendering and with enabled direct rendering but I
doesn't notice any difference. AFAIK mplayer and VLC drops frames very
differently so I check mplayer with disabled frame drop and with enabled frame
drop but (again) doesn't notice any difference. So I doesn't sure what exactly
is wrong in VLC&R600g combination but choppy video playback happen only in this
combination for sure. In my opinion issues most likely is relevant only for APU
hardware.

Video sample used for testing: http://www.multiupload.nl/56CCVTW42H (most
noticeable slowdown happen since 00:32).

Software:
Linux 3.8rc1
libdrm 2.4.40+git20121123.171666e4
Mesa 9.1~git20121222.a585b8f3
xserver-xorg-video-radeon 7.0.99+git20121207.793e1b0e
Xserver 1.13.0.902+git20121207
VLC 2.0.5 (default settings tested too - no difference)
mplayer 1.0~rc4.dfsg1+svn34540
Kubuntu 12.10 x86_64, Xorg Edgers PPA enabled.

Hardware:
A8-3500M with Radeon HD 6620G.

--
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/20121224/576bc6fe/attachment.html>

[Bug 57842] r200: Culling is broken when rendering to an FBO

https://bugs.freedesktop.org/show_bug.cgi?id=57842

smoki  changed:

   What|Removed |Added

  Attachment #72050|text/plain  |image/png
  mime type||

-- 
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/20121224/ab84e705/attachment.html>

[Bug 57842] r200: Culling is broken when rendering to an FBO

https://bugs.freedesktop.org/show_bug.cgi?id=57842

--- Comment #10 from smoki  ---
Created attachment 72050
  --> https://bugs.freedesktop.org/attachment.cgi?id=72050&action=edit
STK minimap icon


 He, he, i'am not programmer at all ;) but i managed to fix fogcoords, lighting
and culling on rv280 with tcl this year.

 Happy holidays :).

-- 
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/20121224/cad18970/attachment.html>

[PATCH 10/10] drm/exynos: Use devm_clk_get in exynos_drm_gsc.c

This eliminates the need for explicit clk_put and makes the
cleanup and exit path code simpler.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   13 -
 1 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index e21a0d9..0497e90 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1696,7 +1696,7 @@ static int __devinit gsc_probe(struct platform_device 
*pdev)
return -ENOMEM;
 
/* clock control */
-   ctx->gsc_clk = clk_get(dev, "gscl");
+   ctx->gsc_clk = devm_clk_get(dev, "gscl");
if (IS_ERR(ctx->gsc_clk)) {
dev_err(dev, "failed to get gsc clock.\n");
return PTR_ERR(ctx->gsc_clk);
@@ -1707,16 +1707,14 @@ static int __devinit gsc_probe(struct platform_device 
*pdev)
ctx->regs = devm_request_and_ioremap(dev, ctx->regs_res);
if (!ctx->regs) {
dev_err(dev, "failed to map registers.\n");
-   ret = -ENXIO;
-   goto err_clk;
+   return -ENXIO;
}
 
/* resource irq */
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
dev_err(dev, "failed to request irq resource.\n");
-   ret = -ENOENT;
-   goto err_clk;
+   return -ENOENT;
}
 
ctx->irq = res->start;
@@ -1724,7 +1722,7 @@ static int __devinit gsc_probe(struct platform_device 
*pdev)
IRQF_ONESHOT, "drm_gsc", ctx);
if (ret < 0) {
dev_err(dev, "failed to request irq.\n");
-   goto err_clk;
+   return ret;
}
 
/* context initailization */
@@ -1768,8 +1766,6 @@ err_ippdrv_register:
pm_runtime_disable(dev);
 err_get_irq:
free_irq(ctx->irq, ctx);
-err_clk:
-   clk_put(ctx->gsc_clk);
return ret;
 }
 
@@ -1787,7 +1783,6 @@ static int __devexit gsc_remove(struct platform_device 
*pdev)
pm_runtime_disable(dev);
 
free_irq(ctx->irq, ctx);
-   clk_put(ctx->gsc_clk);
 
return 0;
 }
-- 
1.7.4.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 09/10] drm/exynos: Remove redundant NULL check in exynos_drm_gsc.c

devm_request_and_ioremap API checks for NULL. Hence explicit
NULL check is not necessary. Saves some code.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 3b47a7d..e21a0d9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1704,12 +1704,6 @@ static int __devinit gsc_probe(struct platform_device 
*pdev)
 
/* resource memory */
ctx->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!ctx->regs_res) {
-   dev_err(dev, "failed to find registers.\n");
-   ret = -ENOENT;
-   goto err_clk;
-   }
-
ctx->regs = devm_request_and_ioremap(dev, ctx->regs_res);
if (!ctx->regs) {
dev_err(dev, "failed to map registers.\n");
-- 
1.7.4.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 08/10] drm/exynos: Remove explicit freeing using devm_* APIs in exynos_drm_gsc.c

devm_* APIs are device managed and get freed automatically when the
device detaches. Thus explicit freeing is not needed. This saves some
code.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   15 +++
 1 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 5639353..3b47a7d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1699,8 +1699,7 @@ static int __devinit gsc_probe(struct platform_device 
*pdev)
ctx->gsc_clk = clk_get(dev, "gscl");
if (IS_ERR(ctx->gsc_clk)) {
dev_err(dev, "failed to get gsc clock.\n");
-   ret = PTR_ERR(ctx->gsc_clk);
-   goto err_ctx;
+   return PTR_ERR(ctx->gsc_clk);
}
 
/* resource memory */
@@ -1723,7 +1722,7 @@ static int __devinit gsc_probe(struct platform_device 
*pdev)
if (!res) {
dev_err(dev, "failed to request irq resource.\n");
ret = -ENOENT;
-   goto err_get_regs;
+   goto err_clk;
}
 
ctx->irq = res->start;
@@ -1731,7 +1730,7 @@ static int __devinit gsc_probe(struct platform_device 
*pdev)
IRQF_ONESHOT, "drm_gsc", ctx);
if (ret < 0) {
dev_err(dev, "failed to request irq.\n");
-   goto err_get_regs;
+   goto err_clk;
}
 
/* context initailization */
@@ -1775,12 +1774,8 @@ err_ippdrv_register:
pm_runtime_disable(dev);
 err_get_irq:
free_irq(ctx->irq, ctx);
-err_get_regs:
-   devm_iounmap(dev, ctx->regs);
 err_clk:
clk_put(ctx->gsc_clk);
-err_ctx:
-   devm_kfree(dev, ctx);
return ret;
 }
 
@@ -1798,12 +1793,8 @@ static int __devexit gsc_remove(struct platform_device 
*pdev)
pm_runtime_disable(dev);
 
free_irq(ctx->irq, ctx);
-   devm_iounmap(dev, ctx->regs);
-
clk_put(ctx->gsc_clk);
 
-   devm_kfree(dev, ctx);
-
return 0;
 }
 
-- 
1.7.4.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 07/10] drm/exynos: Use devm_clk_get in exynos_drm_rotator.c

This eliminates the need for explicit clk_put and makes the
cleanup and exit path code simpler.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 4505163..484c6bd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -674,7 +674,7 @@ static int __devinit rotator_probe(struct platform_device 
*pdev)
return ret;
}
 
-   rot->clock = clk_get(dev, "rotator");
+   rot->clock = devm_clk_get(dev, "rotator");
if (IS_ERR_OR_NULL(rot->clock)) {
dev_err(dev, "failed to get clock\n");
ret = PTR_ERR(rot->clock);
@@ -712,7 +712,6 @@ static int __devinit rotator_probe(struct platform_device 
*pdev)
 err_ippdrv_register:
devm_kfree(dev, ippdrv->prop_list);
pm_runtime_disable(dev);
-   clk_put(rot->clock);
 err_clk_get:
free_irq(rot->irq, rot);
return ret;
@@ -728,7 +727,6 @@ static int __devexit rotator_remove(struct platform_device 
*pdev)
exynos_drm_ippdrv_unregister(ippdrv);
 
pm_runtime_disable(dev);
-   clk_put(rot->clock);
 
free_irq(rot->irq, rot);
 
-- 
1.7.4.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 06/10] drm/exynos: Remove redundant NULL check in exynos_drm_rotator.c

devm_request_and_ioremap API checks for NULL. Hence explicit
NULL check is not necessary. Saves some code.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |5 -
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 0f168449..4505163 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -655,11 +655,6 @@ static int __devinit rotator_probe(struct platform_device 
*pdev)
platform_get_device_id(pdev)->driver_data;
 
rot->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!rot->regs_res) {
-   dev_err(dev, "failed to find registers\n");
-   return -ENOENT;
-   }
-
rot->regs = devm_request_and_ioremap(dev, rot->regs_res);
if (!rot->regs) {
dev_err(dev, "failed to map register\n");
-- 
1.7.4.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 05/10] drm/exynos: Remove unnecessary devm_* freeing APIs in exynos_drm_rotator.c

devm_* APIs are device managed and get freed automatically when the
device detaches. Thus explicit freeing is not needed. This saves some
code.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   18 --
 1 files changed, 4 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 1c23660..0f168449 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -657,29 +657,26 @@ static int __devinit rotator_probe(struct platform_device 
*pdev)
rot->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!rot->regs_res) {
dev_err(dev, "failed to find registers\n");
-   ret = -ENOENT;
-   goto err_get_resource;
+   return -ENOENT;
}
 
rot->regs = devm_request_and_ioremap(dev, rot->regs_res);
if (!rot->regs) {
dev_err(dev, "failed to map register\n");
-   ret = -ENXIO;
-   goto err_get_resource;
+   return -ENXIO;
}
 
rot->irq = platform_get_irq(pdev, 0);
if (rot->irq < 0) {
dev_err(dev, "failed to get irq\n");
-   ret = rot->irq;
-   goto err_get_irq;
+   return rot->irq;
}
 
ret = request_threaded_irq(rot->irq, NULL, rotator_irq_handler,
IRQF_ONESHOT, "drm_rotator", rot);
if (ret < 0) {
dev_err(dev, "failed to request irq\n");
-   goto err_get_irq;
+   return ret;
}
 
rot->clock = clk_get(dev, "rotator");
@@ -723,10 +720,6 @@ err_ippdrv_register:
clk_put(rot->clock);
 err_clk_get:
free_irq(rot->irq, rot);
-err_get_irq:
-   devm_iounmap(dev, rot->regs);
-err_get_resource:
-   devm_kfree(dev, rot);
return ret;
 }
 
@@ -743,9 +736,6 @@ static int __devexit rotator_remove(struct platform_device 
*pdev)
clk_put(rot->clock);
 
free_irq(rot->irq, rot);
-   devm_iounmap(dev, rot->regs);
-
-   devm_kfree(dev, rot);
 
return 0;
 }
-- 
1.7.4.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 04/10] drm/exynos: Use devm_clk_get in exynos_drm_fimc.c

This eliminates the need for explicit clk_put and makes the
cleanup and exit path code simpler.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |   46 ++---
 1 files changed, 10 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 972aa70..c4006b8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1739,64 +1739,50 @@ static int __devinit fimc_probe(struct platform_device 
*pdev)
platform_get_device_id(pdev)->driver_data;
 
/* clock control */
-   ctx->sclk_fimc_clk = clk_get(dev, "sclk_fimc");
+   ctx->sclk_fimc_clk = devm_clk_get(dev, "sclk_fimc");
if (IS_ERR(ctx->sclk_fimc_clk)) {
dev_err(dev, "failed to get src fimc clock.\n");
return PTR_ERR(ctx->sclk_fimc_clk);
}
clk_enable(ctx->sclk_fimc_clk);
 
-   ctx->fimc_clk = clk_get(dev, "fimc");
+   ctx->fimc_clk = devm_clk_get(dev, "fimc");
if (IS_ERR(ctx->fimc_clk)) {
dev_err(dev, "failed to get fimc clock.\n");
clk_disable(ctx->sclk_fimc_clk);
-   clk_put(ctx->sclk_fimc_clk);
return PTR_ERR(ctx->fimc_clk);
}
 
-   ctx->wb_clk = clk_get(dev, "pxl_async0");
+   ctx->wb_clk = devm_clk_get(dev, "pxl_async0");
if (IS_ERR(ctx->wb_clk)) {
dev_err(dev, "failed to get writeback a clock.\n");
clk_disable(ctx->sclk_fimc_clk);
-   clk_put(ctx->sclk_fimc_clk);
-   clk_put(ctx->fimc_clk);
return PTR_ERR(ctx->wb_clk);
}
 
-   ctx->wb_b_clk = clk_get(dev, "pxl_async1");
+   ctx->wb_b_clk = devm_clk_get(dev, "pxl_async1");
if (IS_ERR(ctx->wb_b_clk)) {
dev_err(dev, "failed to get writeback b clock.\n");
clk_disable(ctx->sclk_fimc_clk);
-   clk_put(ctx->sclk_fimc_clk);
-   clk_put(ctx->fimc_clk);
-   clk_put(ctx->wb_clk);
return PTR_ERR(ctx->wb_b_clk);
}
 
-   parent_clk = clk_get(dev, ddata->parent_clk);
+   parent_clk = devm_clk_get(dev, ddata->parent_clk);
 
if (IS_ERR(parent_clk)) {
dev_err(dev, "failed to get parent clock.\n");
clk_disable(ctx->sclk_fimc_clk);
-   clk_put(ctx->sclk_fimc_clk);
-   clk_put(ctx->fimc_clk);
-   clk_put(ctx->wb_clk);
-   clk_put(ctx->wb_b_clk);
return PTR_ERR(parent_clk);
}
 
if (clk_set_parent(ctx->sclk_fimc_clk, parent_clk)) {
dev_err(dev, "failed to set parent.\n");
-   clk_put(parent_clk);
+   devm_clk_put(dev, parent_clk);
clk_disable(ctx->sclk_fimc_clk);
-   clk_put(ctx->sclk_fimc_clk);
-   clk_put(ctx->fimc_clk);
-   clk_put(ctx->wb_clk);
-   clk_put(ctx->wb_b_clk);
return -EINVAL;
}
 
-   clk_put(parent_clk);
+   devm_clk_put(dev, parent_clk);
clk_set_rate(ctx->sclk_fimc_clk, pdata->clk_rate);
 
/* resource memory */
@@ -1804,16 +1790,14 @@ static int __devinit fimc_probe(struct platform_device 
*pdev)
ctx->regs = devm_request_and_ioremap(dev, ctx->regs_res);
if (!ctx->regs) {
dev_err(dev, "failed to map registers.\n");
-   ret = -ENXIO;
-   goto err_clk;
+   return -ENXIO;
}
 
/* resource irq */
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
dev_err(dev, "failed to request irq resource.\n");
-   ret = -ENOENT;
-   goto err_clk;
+   return -ENOENT;
}
 
ctx->irq = res->start;
@@ -1821,7 +1805,7 @@ static int __devinit fimc_probe(struct platform_device 
*pdev)
IRQF_ONESHOT, "drm_fimc", ctx);
if (ret < 0) {
dev_err(dev, "failed to request irq.\n");
-   goto err_clk;
+   return ret;
}
 
/* context initailization */
@@ -1867,11 +1851,6 @@ err_ippdrv_register:
pm_runtime_disable(dev);
 err_get_irq:
free_irq(ctx->irq, ctx);
-err_clk:
-   clk_put(ctx->sclk_fimc_clk);
-   clk_put(ctx->fimc_clk);
-   clk_put(ctx->wb_clk);
-   clk_put(ctx->wb_b_clk);
 
return ret;
 }
@@ -1891,11 +1870,6 @@ static int __devexit fimc_remove(struct platform_device 
*pdev)
 
free_irq(ctx->irq, ctx);
 
-   clk_put(ctx->sclk_fimc_clk);
-   clk_put(ctx->fimc_clk);
-   clk_put(ctx->wb_clk);
-   clk_put(ctx->wb_b_clk);
-
return 0;
 }
 
-- 
1.7.4.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listin

[PATCH 03/10] drm/exynos: Remove redundant NULL check

devm_request_and_ioremap API checks for NULL. Hence explicit
NULL check is not necessary. Saves some code.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index ab75150..972aa70 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1801,12 +1801,6 @@ static int __devinit fimc_probe(struct platform_device 
*pdev)
 
/* resource memory */
ctx->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!ctx->regs_res) {
-   dev_err(dev, "failed to find registers.\n");
-   ret = -ENOENT;
-   goto err_clk;
-   }
-
ctx->regs = devm_request_and_ioremap(dev, ctx->regs_res);
if (!ctx->regs) {
dev_err(dev, "failed to map registers.\n");
-- 
1.7.4.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 02/10] drm/exynos: Remove explicit freeing using devm_* APIs in exynos_drm_fimc.c

devm_* APIs are device managed and get freed automatically when the
device detaches. Thus explicit freeing is not needed. This saves some
code.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |   30 +-
 1 files changed, 9 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 61ea242..ab75150 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1742,64 +1742,58 @@ static int __devinit fimc_probe(struct platform_device 
*pdev)
ctx->sclk_fimc_clk = clk_get(dev, "sclk_fimc");
if (IS_ERR(ctx->sclk_fimc_clk)) {
dev_err(dev, "failed to get src fimc clock.\n");
-   ret = PTR_ERR(ctx->sclk_fimc_clk);
-   goto err_ctx;
+   return PTR_ERR(ctx->sclk_fimc_clk);
}
clk_enable(ctx->sclk_fimc_clk);
 
ctx->fimc_clk = clk_get(dev, "fimc");
if (IS_ERR(ctx->fimc_clk)) {
dev_err(dev, "failed to get fimc clock.\n");
-   ret = PTR_ERR(ctx->fimc_clk);
clk_disable(ctx->sclk_fimc_clk);
clk_put(ctx->sclk_fimc_clk);
-   goto err_ctx;
+   return PTR_ERR(ctx->fimc_clk);
}
 
ctx->wb_clk = clk_get(dev, "pxl_async0");
if (IS_ERR(ctx->wb_clk)) {
dev_err(dev, "failed to get writeback a clock.\n");
-   ret = PTR_ERR(ctx->wb_clk);
clk_disable(ctx->sclk_fimc_clk);
clk_put(ctx->sclk_fimc_clk);
clk_put(ctx->fimc_clk);
-   goto err_ctx;
+   return PTR_ERR(ctx->wb_clk);
}
 
ctx->wb_b_clk = clk_get(dev, "pxl_async1");
if (IS_ERR(ctx->wb_b_clk)) {
dev_err(dev, "failed to get writeback b clock.\n");
-   ret = PTR_ERR(ctx->wb_b_clk);
clk_disable(ctx->sclk_fimc_clk);
clk_put(ctx->sclk_fimc_clk);
clk_put(ctx->fimc_clk);
clk_put(ctx->wb_clk);
-   goto err_ctx;
+   return PTR_ERR(ctx->wb_b_clk);
}
 
parent_clk = clk_get(dev, ddata->parent_clk);
 
if (IS_ERR(parent_clk)) {
dev_err(dev, "failed to get parent clock.\n");
-   ret = PTR_ERR(parent_clk);
clk_disable(ctx->sclk_fimc_clk);
clk_put(ctx->sclk_fimc_clk);
clk_put(ctx->fimc_clk);
clk_put(ctx->wb_clk);
clk_put(ctx->wb_b_clk);
-   goto err_ctx;
+   return PTR_ERR(parent_clk);
}
 
if (clk_set_parent(ctx->sclk_fimc_clk, parent_clk)) {
dev_err(dev, "failed to set parent.\n");
-   ret = -EINVAL;
clk_put(parent_clk);
clk_disable(ctx->sclk_fimc_clk);
clk_put(ctx->sclk_fimc_clk);
clk_put(ctx->fimc_clk);
clk_put(ctx->wb_clk);
clk_put(ctx->wb_b_clk);
-   goto err_ctx;
+   return -EINVAL;
}
 
clk_put(parent_clk);
@@ -1825,7 +1819,7 @@ static int __devinit fimc_probe(struct platform_device 
*pdev)
if (!res) {
dev_err(dev, "failed to request irq resource.\n");
ret = -ENOENT;
-   goto err_get_regs;
+   goto err_clk;
}
 
ctx->irq = res->start;
@@ -1833,7 +1827,7 @@ static int __devinit fimc_probe(struct platform_device 
*pdev)
IRQF_ONESHOT, "drm_fimc", ctx);
if (ret < 0) {
dev_err(dev, "failed to request irq.\n");
-   goto err_get_regs;
+   goto err_clk;
}
 
/* context initailization */
@@ -1879,15 +1873,12 @@ err_ippdrv_register:
pm_runtime_disable(dev);
 err_get_irq:
free_irq(ctx->irq, ctx);
-err_get_regs:
-   devm_iounmap(dev, ctx->regs);
 err_clk:
clk_put(ctx->sclk_fimc_clk);
clk_put(ctx->fimc_clk);
clk_put(ctx->wb_clk);
clk_put(ctx->wb_b_clk);
-err_ctx:
-   devm_kfree(dev, ctx);
+
return ret;
 }
 
@@ -1905,15 +1896,12 @@ static int __devexit fimc_remove(struct platform_device 
*pdev)
pm_runtime_disable(dev);
 
free_irq(ctx->irq, ctx);
-   devm_iounmap(dev, ctx->regs);
 
clk_put(ctx->sclk_fimc_clk);
clk_put(ctx->fimc_clk);
clk_put(ctx->wb_clk);
clk_put(ctx->wb_b_clk);
 
-   devm_kfree(dev, ctx);
-
return 0;
 }
 
-- 
1.7.4.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 01/10] drm/exynos: Use devm_kzalloc in exynos_drm_ipp.c

devm_kzalloc makes the code simpler by eliminating the need for
explicit freeing.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |9 ++---
 1 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 49eebe9..441b719 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -1895,7 +1895,7 @@ static int __devinit ipp_probe(struct platform_device 
*pdev)
struct exynos_drm_subdrv *subdrv;
int ret;
 
-   ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+   ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
 
@@ -1916,8 +1916,7 @@ static int __devinit ipp_probe(struct platform_device 
*pdev)
ctx->event_workq = create_singlethread_workqueue("ipp_event");
if (!ctx->event_workq) {
dev_err(dev, "failed to create event workqueue\n");
-   ret = -EINVAL;
-   goto err_clear;
+   return -EINVAL;
}
 
/*
@@ -1958,8 +1957,6 @@ err_cmd_workq:
destroy_workqueue(ctx->cmd_workq);
 err_event_workq:
destroy_workqueue(ctx->event_workq);
-err_clear:
-   kfree(ctx);
return ret;
 }
 
@@ -1985,8 +1982,6 @@ static int __devexit ipp_remove(struct platform_device 
*pdev)
destroy_workqueue(ctx->cmd_workq);
destroy_workqueue(ctx->event_workq);
 
-   kfree(ctx);
-
return 0;
 }
 
-- 
1.7.4.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 00/10] drm/exynos: Cleanup and update IPP drivers

Compile tested against linux-next tree (20121224).

Sachin Kamat (10):
  drm/exynos: Use devm_kzalloc in exynos_drm_ipp.c
  drm/exynos: Remove explicit freeing using devm_* APIs in
exynos_drm_fimc.c
  drm/exynos: Remove redundant NULL check
  drm/exynos: Use devm_clk_get in exynos_drm_fimc.c
  drm/exynos: Remove unnecessary devm_* freeing APIs in
exynos_drm_rotator.c
  drm/exynos: Remove redundant NULL check in exynos_drm_rotator.c
  drm/exynos: Use devm_clk_get in exynos_drm_rotator.c
  drm/exynos: Remove explicit freeing using devm_* APIs in
exynos_drm_gsc.c
  drm/exynos: Remove redundant NULL check in exynos_drm_gsc.c
  drm/exynos: Use devm_clk_get in exynos_drm_gsc.c

 drivers/gpu/drm/exynos/exynos_drm_fimc.c|   78 ++-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   30 ++-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |9 +---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   25 ++---
 4 files changed, 28 insertions(+), 114 deletions(-)

-- 
1.7.4.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57842] r200: Culling is broken when rendering to an FBO

https://bugs.freedesktop.org/show_bug.cgi?id=57842

--- Comment #9 from smoki  ---

 That D?nzer's commit is good, it inverts winding properly and it works good
but for swtcl only. My tries to make it work but for both swtcl and tcl, and
for Stefan's test case also.

 And it works for me both swtcl and tcl for those tests, but i am not very good
at programming ;).

 "Fixes fgl_glxgears and progs/demos/fbotexture after pressing 'c'."

 Yeah that both works too "pressing 'c'" now works. Pbuffered fgl_glxgears
works, but with -fbo switch - that never showing a texture on r200 :).

 So i've tested: fgl_glxgears, fbotexture, supertuxkart, fbo test from this
bug...
and also tri-cull to be sure no-fbo case work. And that all works for swtcl and
tcl on rv280.

-- 
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/20121224/909dbb80/attachment.html>

[Bug 57842] r200: Culling is broken when rendering to an FBO

https://bugs.freedesktop.org/show_bug.cgi?id=57842

--- Comment #8 from Rafa? Mu?y?o  ---
...minor correction: that r300 was for the non-galium driver (that was removed
awhile ago), but it seems that the logic in that commit was incorrect, so the
"hack" from that attachement seems to be a logic fix and most likely *is* valid
for radeon/radeon_state.c.

-- 
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/20121224/5ada3c98/attachment.html>

[Bug 58696] Choppy video playback in VLC with R600g on Radeon HD 6620G

https://bugs.freedesktop.org/show_bug.cgi?id=58696

Andreas Boll  changed:

   What|Removed |Added

  Component|Drivers/DRI/R600|Drivers/Gallium/r600

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57842] r200: Culling is broken when rendering to an FBO

https://bugs.freedesktop.org/show_bug.cgi?id=57842

--- Comment #7 from Rafa? Mu?y?o  ---
Perhaps the message in this commit
(http://cgit.freedesktop.org/mesa/mesa/commit/src/mesa/drivers/dri/r200/r200_state.c?id=60e60bb3026a269fefe1cfd3312fdf3a7e4c595f)
is of note:

Tested with r300, radeon and r200 compile tested only.


Though looking at the changes of attachment 72047, perhaps the other cards
should be rechecked too - these changes look more like the changes made in that
commit to r300, so it might not be as much of a hack as the author thought.

-- 
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/20121224/38be2f5a/attachment-0001.html>

[Bug 57842] r200: Culling is broken when rendering to an FBO