From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Clark Date: Fri, 26 Jul 2013 14:21:55 +0000 Subject: Re: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111 Message-Id: List-Id: References: <1374772648-19151-1-git-send-email-tom.cooksey@arm.com> <1374847564.3213.70.camel@hornet> In-Reply-To: <1374847564.3213.70.camel@hornet> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Pawel Moll Cc: "linux-arm-kernel@lists.infradead.org" , "linux-fbdev@vger.kernel.org" , Laurent Pinchart , "dri-devel@lists.freedesktop.org" On Fri, Jul 26, 2013 at 10:06 AM, Pawel Moll wrote: > On Thu, 2013-07-25 at 19:21 +0100, Rob Clark wrote: >> > * Only supports 640x480 mode, which is hard-coded. We intend to >> > rebase on top of CDF once it is merged, which hopefully will >> > handle a lot of the EDID parsing & mode setting for us (once >> > Pawel's CDF patches for VExpress also land). >> >> note that drm core already handles EDID parsing quite nicely.. I'm not >> entirely sure why CDF would be needed for this? >> >> What is the dependency on CDF? Is there an external encoder/bridge >> that could be shared between platforms? > > By all means. The platform we have here at ARM - Versatile Express - has > a pretty generic idea of "multimedia bus", carrying a set of RGB pixel > data and digital audio. There are three possible source of those: an > FPGA on the motherboard and two daughterboards which can take random > combination of FPGAs or test chips. In other words: the pixel data can > be generated by anything. And some of those things can be driven by > existing fbdev drivers. Now Tom is trying to make the most modern driver > for the oldest of the things ;-) > > So that's about sources. All of them are connected to yet another FPGA > which acts as a muxer (switch if you wish). And from there things are > fed to SiI9022 HDMI/DVI formatter which is pretty common in the > "embedded world". In other words: loads of other fbdev-driven display > controllers are driving them as well (googling for sii9022 reveals at > least 3 different more or less custom drivers for it). And this chip is > also a reason Tom mentioned EDID. In order to get (just access, not even > parse) it we must jump through hoops - the chip acts as a I2C master > itself and must be kindly asked to switch into a sort of I2C bridge > mode. btw, you might want to have a look at some of the existing i2c slave encoders, since that sounds a lot like what the si9022 is. There is already drivers/gpu/drm/i2c/sil164_drv.c for some other SI part. And tda998x is another more recently added hdmi encoder/formatter (the edid probing code in there might serve as a reasonable source of inspiration) > So yes, the display pipeline is exactly straight-forward... > >> btw, I think that having some share-able KMS objects is a good idea. >> I'm not entirely sure that the directions that the current CDF >> proposals are headed is necessarily the right way forward. I'd prefer >> to see small/incremental evolution of KMS (ie. add drm_bridge and >> drm_panel, and refactor the existing encoder-slave). Keeping it >> inside drm means that we can evolve it more easily, and avoid layers >> of glue code for no good reason. > > To keep the story short - I'm a great enthusiast of CDF because it > caters for both DRM *and* fbdev. Today. I'm looking forward to the day > when the last fbdev driver is kicked off the kernel, but it doesn't look > like happening soon. At the same time I couldn't care less about naming, > so if you prefer to call it drm_panel (but keep the API abstract enough > so non-DRM drivers can use them as well) - it's fine for me :-) There > are already generic mode/timing structures and DT bidnings available > (with helpers for the interesting parties), so this doesn't seem like a > unreasonable request? Well, if you have something complex enough to benefit from CDF, then you probably ought to be looking at drm/kms. If someone wants to somehow come up with some glue to re-use shareable drm/kms components from fbdev, well.. I guess I don't really care about what goes in fbdev. My main concern is that we have more than enough work to do, and have more than enough complexity. If we end up w/ bunch of glue to tie things in to drm properties, how drm helpers sequence things during modeset, locking, etc.. I just don't see that turning out well. And also, just on the logistical side, having something shared across subsystems makes changes more of a pain during the merge window. Not to mention backports to stable kernels, distro kernels, etc. It all just seems like it will be a lot of unnecessary headache. > Cheers! > > Pawel > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: robdclark@gmail.com (Rob Clark) Date: Fri, 26 Jul 2013 10:21:55 -0400 Subject: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111 In-Reply-To: <1374847564.3213.70.camel@hornet> References: <1374772648-19151-1-git-send-email-tom.cooksey@arm.com> <1374847564.3213.70.camel@hornet> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, Jul 26, 2013 at 10:06 AM, Pawel Moll wrote: > On Thu, 2013-07-25 at 19:21 +0100, Rob Clark wrote: >> > * Only supports 640x480 mode, which is hard-coded. We intend to >> > rebase on top of CDF once it is merged, which hopefully will >> > handle a lot of the EDID parsing & mode setting for us (once >> > Pawel's CDF patches for VExpress also land). >> >> note that drm core already handles EDID parsing quite nicely.. I'm not >> entirely sure why CDF would be needed for this? >> >> What is the dependency on CDF? Is there an external encoder/bridge >> that could be shared between platforms? > > By all means. The platform we have here at ARM - Versatile Express - has > a pretty generic idea of "multimedia bus", carrying a set of RGB pixel > data and digital audio. There are three possible source of those: an > FPGA on the motherboard and two daughterboards which can take random > combination of FPGAs or test chips. In other words: the pixel data can > be generated by anything. And some of those things can be driven by > existing fbdev drivers. Now Tom is trying to make the most modern driver > for the oldest of the things ;-) > > So that's about sources. All of them are connected to yet another FPGA > which acts as a muxer (switch if you wish). And from there things are > fed to SiI9022 HDMI/DVI formatter which is pretty common in the > "embedded world". In other words: loads of other fbdev-driven display > controllers are driving them as well (googling for sii9022 reveals at > least 3 different more or less custom drivers for it). And this chip is > also a reason Tom mentioned EDID. In order to get (just access, not even > parse) it we must jump through hoops - the chip acts as a I2C master > itself and must be kindly asked to switch into a sort of I2C bridge > mode. btw, you might want to have a look at some of the existing i2c slave encoders, since that sounds a lot like what the si9022 is. There is already drivers/gpu/drm/i2c/sil164_drv.c for some other SI part. And tda998x is another more recently added hdmi encoder/formatter (the edid probing code in there might serve as a reasonable source of inspiration) > So yes, the display pipeline is exactly straight-forward... > >> btw, I think that having some share-able KMS objects is a good idea. >> I'm not entirely sure that the directions that the current CDF >> proposals are headed is necessarily the right way forward. I'd prefer >> to see small/incremental evolution of KMS (ie. add drm_bridge and >> drm_panel, and refactor the existing encoder-slave). Keeping it >> inside drm means that we can evolve it more easily, and avoid layers >> of glue code for no good reason. > > To keep the story short - I'm a great enthusiast of CDF because it > caters for both DRM *and* fbdev. Today. I'm looking forward to the day > when the last fbdev driver is kicked off the kernel, but it doesn't look > like happening soon. At the same time I couldn't care less about naming, > so if you prefer to call it drm_panel (but keep the API abstract enough > so non-DRM drivers can use them as well) - it's fine for me :-) There > are already generic mode/timing structures and DT bidnings available > (with helpers for the interesting parties), so this doesn't seem like a > unreasonable request? Well, if you have something complex enough to benefit from CDF, then you probably ought to be looking at drm/kms. If someone wants to somehow come up with some glue to re-use shareable drm/kms components from fbdev, well.. I guess I don't really care about what goes in fbdev. My main concern is that we have more than enough work to do, and have more than enough complexity. If we end up w/ bunch of glue to tie things in to drm properties, how drm helpers sequence things during modeset, locking, etc.. I just don't see that turning out well. And also, just on the logistical side, having something shared across subsystems makes changes more of a pain during the merge window. Not to mention backports to stable kernels, distro kernels, etc. It all just seems like it will be a lot of unnecessary headache. > Cheers! > > Pawel > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Clark Subject: Re: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111 Date: Fri, 26 Jul 2013 10:21:55 -0400 Message-ID: References: <1374772648-19151-1-git-send-email-tom.cooksey@arm.com> <1374847564.3213.70.camel@hornet> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by gabe.freedesktop.org (Postfix) with ESMTP id 3021AE5C3E for ; Fri, 26 Jul 2013 07:21:56 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id k7so7571338oag.37 for ; Fri, 26 Jul 2013 07:21:55 -0700 (PDT) In-Reply-To: <1374847564.3213.70.camel@hornet> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Pawel Moll Cc: "linux-arm-kernel@lists.infradead.org" , "linux-fbdev@vger.kernel.org" , Laurent Pinchart , "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org On Fri, Jul 26, 2013 at 10:06 AM, Pawel Moll wrote: > On Thu, 2013-07-25 at 19:21 +0100, Rob Clark wrote: >> > * Only supports 640x480 mode, which is hard-coded. We intend to >> > rebase on top of CDF once it is merged, which hopefully will >> > handle a lot of the EDID parsing & mode setting for us (once >> > Pawel's CDF patches for VExpress also land). >> >> note that drm core already handles EDID parsing quite nicely.. I'm not >> entirely sure why CDF would be needed for this? >> >> What is the dependency on CDF? Is there an external encoder/bridge >> that could be shared between platforms? > > By all means. The platform we have here at ARM - Versatile Express - has > a pretty generic idea of "multimedia bus", carrying a set of RGB pixel > data and digital audio. There are three possible source of those: an > FPGA on the motherboard and two daughterboards which can take random > combination of FPGAs or test chips. In other words: the pixel data can > be generated by anything. And some of those things can be driven by > existing fbdev drivers. Now Tom is trying to make the most modern driver > for the oldest of the things ;-) > > So that's about sources. All of them are connected to yet another FPGA > which acts as a muxer (switch if you wish). And from there things are > fed to SiI9022 HDMI/DVI formatter which is pretty common in the > "embedded world". In other words: loads of other fbdev-driven display > controllers are driving them as well (googling for sii9022 reveals at > least 3 different more or less custom drivers for it). And this chip is > also a reason Tom mentioned EDID. In order to get (just access, not even > parse) it we must jump through hoops - the chip acts as a I2C master > itself and must be kindly asked to switch into a sort of I2C bridge > mode. btw, you might want to have a look at some of the existing i2c slave encoders, since that sounds a lot like what the si9022 is. There is already drivers/gpu/drm/i2c/sil164_drv.c for some other SI part. And tda998x is another more recently added hdmi encoder/formatter (the edid probing code in there might serve as a reasonable source of inspiration) > So yes, the display pipeline is exactly straight-forward... > >> btw, I think that having some share-able KMS objects is a good idea. >> I'm not entirely sure that the directions that the current CDF >> proposals are headed is necessarily the right way forward. I'd prefer >> to see small/incremental evolution of KMS (ie. add drm_bridge and >> drm_panel, and refactor the existing encoder-slave). Keeping it >> inside drm means that we can evolve it more easily, and avoid layers >> of glue code for no good reason. > > To keep the story short - I'm a great enthusiast of CDF because it > caters for both DRM *and* fbdev. Today. I'm looking forward to the day > when the last fbdev driver is kicked off the kernel, but it doesn't look > like happening soon. At the same time I couldn't care less about naming, > so if you prefer to call it drm_panel (but keep the API abstract enough > so non-DRM drivers can use them as well) - it's fine for me :-) There > are already generic mode/timing structures and DT bidnings available > (with helpers for the interesting parties), so this doesn't seem like a > unreasonable request? Well, if you have something complex enough to benefit from CDF, then you probably ought to be looking at drm/kms. If someone wants to somehow come up with some glue to re-use shareable drm/kms components from fbdev, well.. I guess I don't really care about what goes in fbdev. My main concern is that we have more than enough work to do, and have more than enough complexity. If we end up w/ bunch of glue to tie things in to drm properties, how drm helpers sequence things during modeset, locking, etc.. I just don't see that turning out well. And also, just on the logistical side, having something shared across subsystems makes changes more of a pain during the merge window. Not to mention backports to stable kernels, distro kernels, etc. It all just seems like it will be a lot of unnecessary headache. > Cheers! > > Pawel > >