Hi Rob, On 19/03/18 02:06, Rob Herring wrote: > On Wed, Mar 14, 2018 at 6:23 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: >> On 09/03/18 20:27, Benoit Parrot wrote: >> >>>> Is logical plane a h/w concept? >>> >>> It does represent a hardware resource. >> >> Logical plane is not a hw concept, it just describes a group of one or >> two HW planes. Then again, in the context of 2k+ displays, two HW planes >> must always be used together, so that way it could be considered a >> single HW resource. >> >>>> Really, I'm skeptical that any of this belongs in DT. For example, >>>> can't you figure out you need 2 physical planes whenever your >>>> panel/timing width is greater than 2048? >>> >>> As stated in the description I added above, we cannot have resources >>> exposed to user-space which can "disappear" dynamically. >>> Doing so would break user-space applications which rely on these >>> resources. > > Isn't this the point of atomic mode setting? If you have 2 planes > free, then you can support the mode, otherwise you fail. How would a > plane be in use if you are doing modesetting unless it is on another > display? > >> The question is, if not in DT, then where? I agree that this is not >> exactly describing the HW. But it can't be done dynamically either (or >> at least we have not figured out a way). And it must be user configurable. > > If you are plugging in a monitor, doesn't it have to be dynamic? > >> Module parameters are an option, but it would be somewhat difficult to >> give all this information there. And also, if your board has a 2k+ >> display, you must have these configurations given to the driver, it's >> not optional. > > Can't you look at the panel size on boot or module load and determine > if you need to combine planes or not. The main difference I see is > that the driver would have to figure out which planes to use rather > than DT telling it what planes to use. Is deciding which planes a hard > problem? Ok, I think the description was a bit unclear. So, the driver can do this just fine, it can reserve hw planes dynamically when needed. The problem is the userspace. When a DRM application starts, it sees a bunch of planes, and can see on which crtcs each plane can be used. The expectation is, of course, that these planes can be used normally. If the driver would dynamically reserve an additional, currently unused plane, the userspace would be totally baffled, as it fails to configure basic plane setups. For example, the userspace could see that there are two planes, usable on LCD and HDMI crtcs. But mysteriously modesetting would sometimes fail if the HDMI is 2k+ display. Setting up a plane on the HDMI would work, except when the LCD already has a plane. Setting up two planes on the LCD would work, but moving one or both planes to the HDMI would fail. Etc. We could, of course, convey this information to the userspace at runtime via the DRM properties, but then it would mean we'd need customized applications. So, as far as I can see, keeping normal DRM behavior with 2k+ displays on OMAP DSS requires a static virtual plane setup. The most simple setup would be to just split the number of available planes by 2, but then in many use cases that wastes one hw plane. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
