[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Thu, Feb 14, 2019 at 12:38 PM Rob Herring wrote: > > On Thu, Feb 14, 2019 at 2:04 PM Vasily Khoruzhick wrote: > > > > On Tue, Feb 5, 2019 at 2:24 AM Thierry Reding > > wrote: > > > > > > On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote: > > > > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote: > > > > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote: > > > > > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote: > > > > > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote: > > > > > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote: > > > > > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick > > > > > > > > > wrote: > > > > > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily > > > > > > > > > > > Khoruzhick wrote: > > > > > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need > > > > > > > > > > > > to define panel > > > > > > > > > > > > width/height or any modes/timings in dts. But this > > > > > > > > > > > > panel still may have > > > > > > > > > > > > regulator and/or backlight. > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Vasily Khoruzhick > > > > > > > > > > > > --- > > > > > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > > > > > | 7 +++ > > > > > > > > > > > > 1 file changed, 7 insertions(+) > > > > > > > > > > > > create mode 100644 > > > > > > > > > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > > > > > > > > > > > > > > > Please don't try to make panels look more generic than > > > > > > > > > > > they really are. > > > > > > > > > > > You're going to have to provide a compatible string for > > > > > > > > > > > your device that > > > > > > > > > > > is more specific than "panel-edp". You claim that you > > > > > > > > > > > don't need any > > > > > > > > > > > extra information that is panel specific, but you don't > > > > > > > > > > > know that now. > > > > > > > > > > > We have in the past thought that we didn't need things > > > > > > > > > > > like prepare > > > > > > > > > > > delay, but then we ran into situations where we did need > > > > > > > > > > > them. > > > > > > > > > > > > > > > > > > > > > > Just do what everybody else does. Provide a specific > > > > > > > > > > > compatible string > > > > > > > > > > > and match on that in the panel-simple driver. Even if you > > > > > > > > > > > can read all > > > > > > > > > > > the video timings from an EDID EEPROM, you can still > > > > > > > > > > > provide a mode in > > > > > > > > > > > the panel descriptor to serve as a fallback if for > > > > > > > > > > > example the EEPROM > > > > > > > > > > > is faulty on some device. > > > > > > > > > > > > > > > > > > > > Pinebook used several 768p panels that have slightly > > > > > > > > > > different timings > > > > > > > > > > and recent batch uses 1080p panel. > > > > > > > > > > > > > > > > > > > > What panel descriptor should I use as fallback? > > > > > > > > > > > > > > > > > > You don't use panel descriptors as fallback. The simple-panel > > > > > > > > > driver > > > > > > > > > will bind to a panel device and use the corresponding > > > > > > > > > descriptor. If > > > > > > > > > your device tree contains the correct information, the > > > > > > > > > descriptor is > > > > > > > > > correct for the panel you have. > > > > > > > > > > > > > > > > > > In other words you need to ensure that you have the correct > > > > > > > > > panel in > > > > > > > > > device tree for the board that you're using. This is exactly > > > > > > > > > the same > > > > > > > > > thing as for other devices. > > > > > > > > > > > > > > > > > > One way to to this is to have separate device trees for each > > > > > > > > > variant > > > > > > > > > of the board that you want to support. Another variant may be > > > > > > > > > to have > > > > > > > > > a common device tree and then have some early firmware update > > > > > > > > > the DTB > > > > > > > > > with the correct panel information. > > > > > > > > > > > > > > > > This would defeat the point of edp, which is to standardize the > > > > > > > > mess of > > > > > > > > panels (at least somewhat) and avoid having to change the > > > > > > > > DT/ACPI > > > > > > > > tables/firmware for every board you ship. Also, we do have DP > > > > > > > > quirking > > > > > > > > infrastructure already (using the OUI), I think if there's > > > > > > > > something that > > > > > > > > doesn't work then we should quirk it there. > > > > > > > > > > > > > > The problem is that while the attempt may have been to > > > > > > > standardize, it > > > > > > > failed. It doesn't take into account any of the details such as > > > > > > > timing > > > > > > > between things like
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Thu, Feb 14, 2019 at 2:04 PM Vasily Khoruzhick wrote: > > On Tue, Feb 5, 2019 at 2:24 AM Thierry Reding > wrote: > > > > On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote: > > > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote: > > > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote: > > > > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote: > > > > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote: > > > > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote: > > > > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick > > > > > > > > wrote: > > > > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick > > > > > > > > > > wrote: > > > > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need > > > > > > > > > > > to define panel > > > > > > > > > > > width/height or any modes/timings in dts. But this panel > > > > > > > > > > > still may have > > > > > > > > > > > regulator and/or backlight. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Vasily Khoruzhick > > > > > > > > > > > --- > > > > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > > > > | 7 +++ > > > > > > > > > > > 1 file changed, 7 insertions(+) > > > > > > > > > > > create mode 100644 > > > > > > > > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > > > > > > > > > > > > > Please don't try to make panels look more generic than they > > > > > > > > > > really are. > > > > > > > > > > You're going to have to provide a compatible string for > > > > > > > > > > your device that > > > > > > > > > > is more specific than "panel-edp". You claim that you don't > > > > > > > > > > need any > > > > > > > > > > extra information that is panel specific, but you don't > > > > > > > > > > know that now. > > > > > > > > > > We have in the past thought that we didn't need things like > > > > > > > > > > prepare > > > > > > > > > > delay, but then we ran into situations where we did need > > > > > > > > > > them. > > > > > > > > > > > > > > > > > > > > Just do what everybody else does. Provide a specific > > > > > > > > > > compatible string > > > > > > > > > > and match on that in the panel-simple driver. Even if you > > > > > > > > > > can read all > > > > > > > > > > the video timings from an EDID EEPROM, you can still > > > > > > > > > > provide a mode in > > > > > > > > > > the panel descriptor to serve as a fallback if for example > > > > > > > > > > the EEPROM > > > > > > > > > > is faulty on some device. > > > > > > > > > > > > > > > > > > Pinebook used several 768p panels that have slightly > > > > > > > > > different timings > > > > > > > > > and recent batch uses 1080p panel. > > > > > > > > > > > > > > > > > > What panel descriptor should I use as fallback? > > > > > > > > > > > > > > > > You don't use panel descriptors as fallback. The simple-panel > > > > > > > > driver > > > > > > > > will bind to a panel device and use the corresponding > > > > > > > > descriptor. If > > > > > > > > your device tree contains the correct information, the > > > > > > > > descriptor is > > > > > > > > correct for the panel you have. > > > > > > > > > > > > > > > > In other words you need to ensure that you have the correct > > > > > > > > panel in > > > > > > > > device tree for the board that you're using. This is exactly > > > > > > > > the same > > > > > > > > thing as for other devices. > > > > > > > > > > > > > > > > One way to to this is to have separate device trees for each > > > > > > > > variant > > > > > > > > of the board that you want to support. Another variant may be > > > > > > > > to have > > > > > > > > a common device tree and then have some early firmware update > > > > > > > > the DTB > > > > > > > > with the correct panel information. > > > > > > > > > > > > > > This would defeat the point of edp, which is to standardize the > > > > > > > mess of > > > > > > > panels (at least somewhat) and avoid having to change the DT/ACPI > > > > > > > tables/firmware for every board you ship. Also, we do have DP > > > > > > > quirking > > > > > > > infrastructure already (using the OUI), I think if there's > > > > > > > something that > > > > > > > doesn't work then we should quirk it there. > > > > > > > > > > > > The problem is that while the attempt may have been to standardize, > > > > > > it > > > > > > failed. It doesn't take into account any of the details such as > > > > > > timing > > > > > > between things like powering up the display and enabling the > > > > > > backlight > > > > > > or similar. I don't know how you'd want to "quirk" those kinds of > > > > > > requirements because they are highly panel specific. > > > > > > > > > > Hm right, we get these from some firmware
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Tue, Feb 5, 2019 at 2:24 AM Thierry Reding wrote: > > On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote: > > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote: > > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote: > > > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote: > > > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote: > > > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote: > > > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote: > > > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick > > > > > > > > > wrote: > > > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to > > > > > > > > > > define panel > > > > > > > > > > width/height or any modes/timings in dts. But this panel > > > > > > > > > > still may have > > > > > > > > > > regulator and/or backlight. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Vasily Khoruzhick > > > > > > > > > > --- > > > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > > > | 7 +++ > > > > > > > > > > 1 file changed, 7 insertions(+) > > > > > > > > > > create mode 100644 > > > > > > > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > > > > > > > > > > > Please don't try to make panels look more generic than they > > > > > > > > > really are. > > > > > > > > > You're going to have to provide a compatible string for your > > > > > > > > > device that > > > > > > > > > is more specific than "panel-edp". You claim that you don't > > > > > > > > > need any > > > > > > > > > extra information that is panel specific, but you don't know > > > > > > > > > that now. > > > > > > > > > We have in the past thought that we didn't need things like > > > > > > > > > prepare > > > > > > > > > delay, but then we ran into situations where we did need them. > > > > > > > > > > > > > > > > > > Just do what everybody else does. Provide a specific > > > > > > > > > compatible string > > > > > > > > > and match on that in the panel-simple driver. Even if you can > > > > > > > > > read all > > > > > > > > > the video timings from an EDID EEPROM, you can still provide > > > > > > > > > a mode in > > > > > > > > > the panel descriptor to serve as a fallback if for example > > > > > > > > > the EEPROM > > > > > > > > > is faulty on some device. > > > > > > > > > > > > > > > > Pinebook used several 768p panels that have slightly different > > > > > > > > timings > > > > > > > > and recent batch uses 1080p panel. > > > > > > > > > > > > > > > > What panel descriptor should I use as fallback? > > > > > > > > > > > > > > You don't use panel descriptors as fallback. The simple-panel > > > > > > > driver > > > > > > > will bind to a panel device and use the corresponding descriptor. > > > > > > > If > > > > > > > your device tree contains the correct information, the descriptor > > > > > > > is > > > > > > > correct for the panel you have. > > > > > > > > > > > > > > In other words you need to ensure that you have the correct panel > > > > > > > in > > > > > > > device tree for the board that you're using. This is exactly the > > > > > > > same > > > > > > > thing as for other devices. > > > > > > > > > > > > > > One way to to this is to have separate device trees for each > > > > > > > variant > > > > > > > of the board that you want to support. Another variant may be to > > > > > > > have > > > > > > > a common device tree and then have some early firmware update the > > > > > > > DTB > > > > > > > with the correct panel information. > > > > > > > > > > > > This would defeat the point of edp, which is to standardize the > > > > > > mess of > > > > > > panels (at least somewhat) and avoid having to change the DT/ACPI > > > > > > tables/firmware for every board you ship. Also, we do have DP > > > > > > quirking > > > > > > infrastructure already (using the OUI), I think if there's > > > > > > something that > > > > > > doesn't work then we should quirk it there. > > > > > > > > > > The problem is that while the attempt may have been to standardize, it > > > > > failed. It doesn't take into account any of the details such as timing > > > > > between things like powering up the display and enabling the backlight > > > > > or similar. I don't know how you'd want to "quirk" those kinds of > > > > > requirements because they are highly panel specific. > > > > > > > > Hm right, we get these from some firmware tables (and mix them with the > > > > spec one, since some of the firmware values are nonsense). I don't even > > > > know whether we can read the timings over dp aux somehow (you can power > > > > up > > > > the panel with some pessimistic values to figure those out, and you only > > > > need dp aux to work, which is much
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Tue, Feb 5, 2019 at 8:36 AM Daniel Vetter wrote: > > On Tue, Feb 05, 2019 at 11:24:19AM +0100, Thierry Reding wrote: > > On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote: > > > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote: > > > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote: > > > > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote: > > > > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote: > > > > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote: > > > > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick > > > > > > > > wrote: > > > > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick > > > > > > > > > > wrote: > > > > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need > > > > > > > > > > > to define panel > > > > > > > > > > > width/height or any modes/timings in dts. But this panel > > > > > > > > > > > still may have > > > > > > > > > > > regulator and/or backlight. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Vasily Khoruzhick > > > > > > > > > > > --- > > > > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > > > > | 7 +++ > > > > > > > > > > > 1 file changed, 7 insertions(+) > > > > > > > > > > > create mode 100644 > > > > > > > > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > > > > > > > > > > > > > Please don't try to make panels look more generic than they > > > > > > > > > > really are. > > > > > > > > > > You're going to have to provide a compatible string for > > > > > > > > > > your device that > > > > > > > > > > is more specific than "panel-edp". You claim that you don't > > > > > > > > > > need any > > > > > > > > > > extra information that is panel specific, but you don't > > > > > > > > > > know that now. > > > > > > > > > > We have in the past thought that we didn't need things like > > > > > > > > > > prepare > > > > > > > > > > delay, but then we ran into situations where we did need > > > > > > > > > > them. > > > > > > > > > > > > > > > > > > > > Just do what everybody else does. Provide a specific > > > > > > > > > > compatible string > > > > > > > > > > and match on that in the panel-simple driver. Even if you > > > > > > > > > > can read all > > > > > > > > > > the video timings from an EDID EEPROM, you can still > > > > > > > > > > provide a mode in > > > > > > > > > > the panel descriptor to serve as a fallback if for example > > > > > > > > > > the EEPROM > > > > > > > > > > is faulty on some device. > > > > > > > > > > > > > > > > > > Pinebook used several 768p panels that have slightly > > > > > > > > > different timings > > > > > > > > > and recent batch uses 1080p panel. > > > > > > > > > > > > > > > > > > What panel descriptor should I use as fallback? > > > > > > > > > > > > > > > > You don't use panel descriptors as fallback. The simple-panel > > > > > > > > driver > > > > > > > > will bind to a panel device and use the corresponding > > > > > > > > descriptor. If > > > > > > > > your device tree contains the correct information, the > > > > > > > > descriptor is > > > > > > > > correct for the panel you have. > > > > > > > > > > > > > > > > In other words you need to ensure that you have the correct > > > > > > > > panel in > > > > > > > > device tree for the board that you're using. This is exactly > > > > > > > > the same > > > > > > > > thing as for other devices. > > > > > > > > > > > > > > > > One way to to this is to have separate device trees for each > > > > > > > > variant > > > > > > > > of the board that you want to support. Another variant may be > > > > > > > > to have > > > > > > > > a common device tree and then have some early firmware update > > > > > > > > the DTB > > > > > > > > with the correct panel information. > > > > > > > > > > > > > > This would defeat the point of edp, which is to standardize the > > > > > > > mess of > > > > > > > panels (at least somewhat) and avoid having to change the DT/ACPI > > > > > > > tables/firmware for every board you ship. Also, we do have DP > > > > > > > quirking > > > > > > > infrastructure already (using the OUI), I think if there's > > > > > > > something that > > > > > > > doesn't work then we should quirk it there. > > > > > > > > > > > > The problem is that while the attempt may have been to standardize, > > > > > > it > > > > > > failed. It doesn't take into account any of the details such as > > > > > > timing > > > > > > between things like powering up the display and enabling the > > > > > > backlight > > > > > > or similar. I don't know how you'd want to "quirk" those kinds of > > > > > > requirements because they are highly panel specific. > > > > > > > > > > Hm right, we get these from some firmware
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Tue, Feb 05, 2019 at 11:24:19AM +0100, Thierry Reding wrote: > On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote: > > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote: > > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote: > > > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote: > > > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote: > > > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote: > > > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote: > > > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick > > > > > > > > > wrote: > > > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to > > > > > > > > > > define panel > > > > > > > > > > width/height or any modes/timings in dts. But this panel > > > > > > > > > > still may have > > > > > > > > > > regulator and/or backlight. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Vasily Khoruzhick > > > > > > > > > > --- > > > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > > > | 7 +++ > > > > > > > > > > 1 file changed, 7 insertions(+) > > > > > > > > > > create mode 100644 > > > > > > > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > > > > > > > > > > > Please don't try to make panels look more generic than they > > > > > > > > > really are. > > > > > > > > > You're going to have to provide a compatible string for your > > > > > > > > > device that > > > > > > > > > is more specific than "panel-edp". You claim that you don't > > > > > > > > > need any > > > > > > > > > extra information that is panel specific, but you don't know > > > > > > > > > that now. > > > > > > > > > We have in the past thought that we didn't need things like > > > > > > > > > prepare > > > > > > > > > delay, but then we ran into situations where we did need them. > > > > > > > > > > > > > > > > > > Just do what everybody else does. Provide a specific > > > > > > > > > compatible string > > > > > > > > > and match on that in the panel-simple driver. Even if you can > > > > > > > > > read all > > > > > > > > > the video timings from an EDID EEPROM, you can still provide > > > > > > > > > a mode in > > > > > > > > > the panel descriptor to serve as a fallback if for example > > > > > > > > > the EEPROM > > > > > > > > > is faulty on some device. > > > > > > > > > > > > > > > > Pinebook used several 768p panels that have slightly different > > > > > > > > timings > > > > > > > > and recent batch uses 1080p panel. > > > > > > > > > > > > > > > > What panel descriptor should I use as fallback? > > > > > > > > > > > > > > You don't use panel descriptors as fallback. The simple-panel > > > > > > > driver > > > > > > > will bind to a panel device and use the corresponding descriptor. > > > > > > > If > > > > > > > your device tree contains the correct information, the descriptor > > > > > > > is > > > > > > > correct for the panel you have. > > > > > > > > > > > > > > In other words you need to ensure that you have the correct panel > > > > > > > in > > > > > > > device tree for the board that you're using. This is exactly the > > > > > > > same > > > > > > > thing as for other devices. > > > > > > > > > > > > > > One way to to this is to have separate device trees for each > > > > > > > variant > > > > > > > of the board that you want to support. Another variant may be to > > > > > > > have > > > > > > > a common device tree and then have some early firmware update the > > > > > > > DTB > > > > > > > with the correct panel information. > > > > > > > > > > > > This would defeat the point of edp, which is to standardize the > > > > > > mess of > > > > > > panels (at least somewhat) and avoid having to change the DT/ACPI > > > > > > tables/firmware for every board you ship. Also, we do have DP > > > > > > quirking > > > > > > infrastructure already (using the OUI), I think if there's > > > > > > something that > > > > > > doesn't work then we should quirk it there. > > > > > > > > > > The problem is that while the attempt may have been to standardize, it > > > > > failed. It doesn't take into account any of the details such as timing > > > > > between things like powering up the display and enabling the backlight > > > > > or similar. I don't know how you'd want to "quirk" those kinds of > > > > > requirements because they are highly panel specific. > > > > > > > > Hm right, we get these from some firmware tables (and mix them with the > > > > spec one, since some of the firmware values are nonsense). I don't even > > > > know whether we can read the timings over dp aux somehow (you can power > > > > up > > > > the panel with some pessimistic values to figure those out, and you only > > > > need dp aux to work,
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote: > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote: > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote: > > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote: > > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote: > > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote: > > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote: > > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding > > > > > > > wrote: > > > > > > > > > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick > > > > > > > > wrote: > > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to > > > > > > > > > define panel > > > > > > > > > width/height or any modes/timings in dts. But this panel > > > > > > > > > still may have > > > > > > > > > regulator and/or backlight. > > > > > > > > > > > > > > > > > > Signed-off-by: Vasily Khoruzhick > > > > > > > > > --- > > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt| > > > > > > > > > 7 +++ > > > > > > > > > 1 file changed, 7 insertions(+) > > > > > > > > > create mode 100644 > > > > > > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > > > > > > > > > Please don't try to make panels look more generic than they > > > > > > > > really are. > > > > > > > > You're going to have to provide a compatible string for your > > > > > > > > device that > > > > > > > > is more specific than "panel-edp". You claim that you don't > > > > > > > > need any > > > > > > > > extra information that is panel specific, but you don't know > > > > > > > > that now. > > > > > > > > We have in the past thought that we didn't need things like > > > > > > > > prepare > > > > > > > > delay, but then we ran into situations where we did need them. > > > > > > > > > > > > > > > > Just do what everybody else does. Provide a specific compatible > > > > > > > > string > > > > > > > > and match on that in the panel-simple driver. Even if you can > > > > > > > > read all > > > > > > > > the video timings from an EDID EEPROM, you can still provide a > > > > > > > > mode in > > > > > > > > the panel descriptor to serve as a fallback if for example the > > > > > > > > EEPROM > > > > > > > > is faulty on some device. > > > > > > > > > > > > > > Pinebook used several 768p panels that have slightly different > > > > > > > timings > > > > > > > and recent batch uses 1080p panel. > > > > > > > > > > > > > > What panel descriptor should I use as fallback? > > > > > > > > > > > > You don't use panel descriptors as fallback. The simple-panel driver > > > > > > will bind to a panel device and use the corresponding descriptor. If > > > > > > your device tree contains the correct information, the descriptor is > > > > > > correct for the panel you have. > > > > > > > > > > > > In other words you need to ensure that you have the correct panel in > > > > > > device tree for the board that you're using. This is exactly the > > > > > > same > > > > > > thing as for other devices. > > > > > > > > > > > > One way to to this is to have separate device trees for each variant > > > > > > of the board that you want to support. Another variant may be to > > > > > > have > > > > > > a common device tree and then have some early firmware update the > > > > > > DTB > > > > > > with the correct panel information. > > > > > > > > > > This would defeat the point of edp, which is to standardize the mess > > > > > of > > > > > panels (at least somewhat) and avoid having to change the DT/ACPI > > > > > tables/firmware for every board you ship. Also, we do have DP quirking > > > > > infrastructure already (using the OUI), I think if there's something > > > > > that > > > > > doesn't work then we should quirk it there. > > > > > > > > The problem is that while the attempt may have been to standardize, it > > > > failed. It doesn't take into account any of the details such as timing > > > > between things like powering up the display and enabling the backlight > > > > or similar. I don't know how you'd want to "quirk" those kinds of > > > > requirements because they are highly panel specific. > > > > > > Hm right, we get these from some firmware tables (and mix them with the > > > spec one, since some of the firmware values are nonsense). I don't even > > > know whether we can read the timings over dp aux somehow (you can power up > > > the panel with some pessimistic values to figure those out, and you only > > > need dp aux to work, which is much simpler than the entire panel). > > > > > > > > What does make sense though imo is if we try not to stuff the edp > > > > > panel > > > > > into panel-simple, because it's anything like a simple dumb panel. > > > > > There's > > > > > also some integration awkwardness since with this panel you need to > > > > > do dp > > > >
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote: > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote: > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote: > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote: > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote: > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote: > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding > > > > > > wrote: > > > > > > > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote: > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to > > > > > > > > define panel > > > > > > > > width/height or any modes/timings in dts. But this panel still > > > > > > > > may have > > > > > > > > regulator and/or backlight. > > > > > > > > > > > > > > > > Signed-off-by: Vasily Khoruzhick > > > > > > > > --- > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt| 7 > > > > > > > > +++ > > > > > > > > 1 file changed, 7 insertions(+) > > > > > > > > create mode 100644 > > > > > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > > > > > > > Please don't try to make panels look more generic than they > > > > > > > really are. > > > > > > > You're going to have to provide a compatible string for your > > > > > > > device that > > > > > > > is more specific than "panel-edp". You claim that you don't need > > > > > > > any > > > > > > > extra information that is panel specific, but you don't know that > > > > > > > now. > > > > > > > We have in the past thought that we didn't need things like > > > > > > > prepare > > > > > > > delay, but then we ran into situations where we did need them. > > > > > > > > > > > > > > Just do what everybody else does. Provide a specific compatible > > > > > > > string > > > > > > > and match on that in the panel-simple driver. Even if you can > > > > > > > read all > > > > > > > the video timings from an EDID EEPROM, you can still provide a > > > > > > > mode in > > > > > > > the panel descriptor to serve as a fallback if for example the > > > > > > > EEPROM > > > > > > > is faulty on some device. > > > > > > > > > > > > Pinebook used several 768p panels that have slightly different > > > > > > timings > > > > > > and recent batch uses 1080p panel. > > > > > > > > > > > > What panel descriptor should I use as fallback? > > > > > > > > > > You don't use panel descriptors as fallback. The simple-panel driver > > > > > will bind to a panel device and use the corresponding descriptor. If > > > > > your device tree contains the correct information, the descriptor is > > > > > correct for the panel you have. > > > > > > > > > > In other words you need to ensure that you have the correct panel in > > > > > device tree for the board that you're using. This is exactly the same > > > > > thing as for other devices. > > > > > > > > > > One way to to this is to have separate device trees for each variant > > > > > of the board that you want to support. Another variant may be to have > > > > > a common device tree and then have some early firmware update the DTB > > > > > with the correct panel information. > > > > > > > > This would defeat the point of edp, which is to standardize the mess of > > > > panels (at least somewhat) and avoid having to change the DT/ACPI > > > > tables/firmware for every board you ship. Also, we do have DP quirking > > > > infrastructure already (using the OUI), I think if there's something > > > > that > > > > doesn't work then we should quirk it there. > > > > > > The problem is that while the attempt may have been to standardize, it > > > failed. It doesn't take into account any of the details such as timing > > > between things like powering up the display and enabling the backlight > > > or similar. I don't know how you'd want to "quirk" those kinds of > > > requirements because they are highly panel specific. > > > > Hm right, we get these from some firmware tables (and mix them with the > > spec one, since some of the firmware values are nonsense). I don't even > > know whether we can read the timings over dp aux somehow (you can power up > > the panel with some pessimistic values to figure those out, and you only > > need dp aux to work, which is much simpler than the entire panel). > > > > > > What does make sense though imo is if we try not to stuff the edp panel > > > > into panel-simple, because it's anything like a simple dumb panel. > > > > There's > > > > also some integration awkwardness since with this panel you need to do > > > > dp > > > > aux/i2c transactions to get at the information (edid alone isn't good > > > > enough for edp), and I'm not sure how exactly that's supposed to be > > > > instantiated. Maybe a special function to instantiate an edp panel, > > > > which > > > > takes both a DT node and the dp_aux controller would be much better, > > >
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 4, 2019 at 2:26 PM Vasily Khoruzhick wrote: > > On Mon, Feb 4, 2019 at 12:23 PM Rob Herring wrote: > > > > simple-panel would probably work if you stuck in some mostly compatible > > > string and provided a ddc-i2c-bus property in the device tree node. The > > > generic-ish fallback case could be implemented by providing a fallback > > > compatible string (we used to have "simple-panel", which I think would > > > still be adequate for this I suppose) and adding a dummy descriptor in > > > the driver, perhaps one with pre-defined delays that could be adjusted > > > to work for all cases, or they could just be 0. At least that way we'd > > > be explicitly documenting that we support this as a fallback. > > > > I'd like something more specific than 'simple-panel' that at least > > implies it has EDID and whatever else we think it should imply. > > > > Looking into this a bit more, why don't we just do a connector here? > > eDP has a standard connector (with power). It's just like other > > connectors, but with power and no hotplug. If someone does their own > > interface, then they should do their own connector or panel binding. > > Where do we put backlight in this case? In the connector node. You'd need a backlight supply, 'backlight-enable-gpios' and backlight phandle to pwm-backlight node. Rob -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 4, 2019 at 12:23 PM Rob Herring wrote: > > simple-panel would probably work if you stuck in some mostly compatible > > string and provided a ddc-i2c-bus property in the device tree node. The > > generic-ish fallback case could be implemented by providing a fallback > > compatible string (we used to have "simple-panel", which I think would > > still be adequate for this I suppose) and adding a dummy descriptor in > > the driver, perhaps one with pre-defined delays that could be adjusted > > to work for all cases, or they could just be 0. At least that way we'd > > be explicitly documenting that we support this as a fallback. > > I'd like something more specific than 'simple-panel' that at least > implies it has EDID and whatever else we think it should imply. > > Looking into this a bit more, why don't we just do a connector here? > eDP has a standard connector (with power). It's just like other > connectors, but with power and no hotplug. If someone does their own > interface, then they should do their own connector or panel binding. Where do we put backlight in this case? > > I'm not sure how you'd want to enforce that people provide the right > > compatible strings that way. Currently there's no way to make your panel > > work without adding a panel driver, so people are forced to write the > > DT bindings and a driver, or add support to an existing one. If we open > > this backdoor, I suspect many people will just take the easy route and > > rely on the fallback. And then what do we do when we get bug reports > > about panels not working, or requiring some quirks. How do we go and > > find out what the right compatible strings are for each board, or how to > > fix things for something we don't have access to. > > We'll simply reject anything that should be implied by compatible. And > now we can enforce with schema that DTs aren't populated with > fallbacks alone. Of course, we can't make anyone pass all schema > checks before shipping a dtb. > > Rob -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 4, 2019 at 10:56 AM Thierry Reding wrote: > > On Mon, Feb 04, 2019 at 10:27:09AM -0600, Rob Herring wrote: > > On Mon, Feb 4, 2019 at 2:24 AM Thierry Reding > > wrote: > > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote: > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding > > > > wrote: > > > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote: > > > > > > eDP panels usually have EDID EEPROM, so there's no need to define > > > > > > panel > > > > > > width/height or any modes/timings in dts. But this panel still may > > > > > > have > > > > > > regulator and/or backlight. > > > > > > > > > > > > Signed-off-by: Vasily Khoruzhick > > > > > > --- > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt| 7 > > > > > > +++ > > > > > > 1 file changed, 7 insertions(+) > > > > > > create mode 100644 > > > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > > > Please don't try to make panels look more generic than they really > > > > > are. > > > > > You're going to have to provide a compatible string for your device > > > > > that > > > > > is more specific than "panel-edp". You claim that you don't need any > > > > > extra information that is panel specific, but you don't know that now. > > > > > We have in the past thought that we didn't need things like prepare > > > > > delay, but then we ran into situations where we did need them. > > > > > > > > > > Just do what everybody else does. Provide a specific compatible string > > > > > and match on that in the panel-simple driver. Even if you can read all > > > > > the video timings from an EDID EEPROM, you can still provide a mode in > > > > > the panel descriptor to serve as a fallback if for example the EEPROM > > > > > is faulty on some device. > > > > > > > > Pinebook used several 768p panels that have slightly different timings > > > > and recent batch uses 1080p panel. > > > > > > > > What panel descriptor should I use as fallback? > > > > > > You don't use panel descriptors as fallback. The simple-panel driver > > > will bind to a panel device and use the corresponding descriptor. If > > > your device tree contains the correct information, the descriptor is > > > correct for the panel you have. > > > > > > In other words you need to ensure that you have the correct panel in > > > device tree for the board that you're using. This is exactly the same > > > thing as for other devices. > > > > > > One way to to this is to have separate device trees for each variant > > > of the board that you want to support. Another variant may be to have > > > a common device tree and then have some early firmware update the DTB > > > with the correct panel information. > > > > That can be a pain to manage especially if panels are swapped run to > > run with 2nd sources. > > > > I think it is perfectly fine to have a generic-ish fallback as long as > > it is just that, a fallback. If the panel has quirks, then you'd > > better make sure the firmware is stuffing in the right compatibles or > > that you can update the firmware. > > simple-panel would probably work if you stuck in some mostly compatible > string and provided a ddc-i2c-bus property in the device tree node. The > generic-ish fallback case could be implemented by providing a fallback > compatible string (we used to have "simple-panel", which I think would > still be adequate for this I suppose) and adding a dummy descriptor in > the driver, perhaps one with pre-defined delays that could be adjusted > to work for all cases, or they could just be 0. At least that way we'd > be explicitly documenting that we support this as a fallback. I'd like something more specific than 'simple-panel' that at least implies it has EDID and whatever else we think it should imply. Looking into this a bit more, why don't we just do a connector here? eDP has a standard connector (with power). It's just like other connectors, but with power and no hotplug. If someone does their own interface, then they should do their own connector or panel binding. > I'm not sure how you'd want to enforce that people provide the right > compatible strings that way. Currently there's no way to make your panel > work without adding a panel driver, so people are forced to write the > DT bindings and a driver, or add support to an existing one. If we open > this backdoor, I suspect many people will just take the easy route and > rely on the fallback. And then what do we do when we get bug reports > about panels not working, or requiring some quirks. How do we go and > find out what the right compatible strings are for each board, or how to > fix things for something we don't have access to. We'll simply reject anything that should be implied by compatible. And now we can enforce with schema that DTs aren't populated with fallbacks alone. Of course, we can't make anyone pass all schema checks before shipping a dtb. Rob
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 4, 2019 at 8:56 AM Thierry Reding wrote: > > I think it is perfectly fine to have a generic-ish fallback as long as > > it is just that, a fallback. If the panel has quirks, then you'd > > better make sure the firmware is stuffing in the right compatibles or > > that you can update the firmware. > > simple-panel would probably work if you stuck in some mostly compatible > string and provided a ddc-i2c-bus property in the device tree node. The > generic-ish fallback case could be implemented by providing a fallback > compatible string (we used to have "simple-panel", which I think would > still be adequate for this I suppose) and adding a dummy descriptor in > the driver, perhaps one with pre-defined delays that could be adjusted > to work for all cases, or they could just be 0. At least that way we'd > be explicitly documenting that we support this as a fallback. > > I'm not sure how you'd want to enforce that people provide the right > compatible strings that way. Currently there's no way to make your panel > work without adding a panel driver, so people are forced to write the > DT bindings and a driver, or add support to an existing one. If we open > this backdoor, I suspect many people will just take the easy route and > rely on the fallback. And then what do we do when we get bug reports > about panels not working, or requiring some quirks. How do we go and > find out what the right compatible strings are for each board, or how to > fix things for something we don't have access to. > > This all sounds like a Pandora's box to me. OK, just give me an option that will work on this platform with a single software image (keep in mind that u-boot aka "firmware" is part of this image) and that is acceptable for upstream and I'll try to implement it. > Thierry -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 4, 2019 at 8:39 AM Rob Herring wrote: > > On Mon, Feb 4, 2019 at 10:11 AM Vasily Khoruzhick wrote: > > > > On Mon, Feb 4, 2019 at 12:24 AM Thierry Reding > > wrote: > > > > > > > > Pinebook used several 768p panels that have slightly different timings > > > > and recent batch uses 1080p panel. > > > > > > > > What panel descriptor should I use as fallback? > > > > > > You don't use panel descriptors as fallback. The simple-panel driver > > > will bind to a panel device and use the corresponding descriptor. If > > > your device tree contains the correct information, the descriptor is > > > correct for the panel you have. > > > > > > In other words you need to ensure that you have the correct panel in > > > device tree for the board that you're using. This is exactly the same > > > thing as for other devices. > > > > > > One way to to this is to have separate device trees for each variant > > > of the board that you want to support. Another variant may be to have > > > a common device tree and then have some early firmware update the DTB > > > with the correct panel information. > > > > That defeats the purpose of using eDP panels. Panel can identify > > itself and report what timings it supports. > > If you are confident that this works for all panels, then the firmware > can identify the right panel and update the DTB with the correct > information. If this doesn't work in the firmware, then it is not > going to work in the kernel either and you are SOL without specific > panel information in the DT. "firmware" is u-boot and on this platform it sits on the same physical media as OS (it's either microsd or eMMC). I guess u-boot can fill in timings for kernel, but I don't see much point in it. If u-boot can't read EDID then same is true for kernel. > > If we use separate DTBs then users will have to figure out what panel > > is installed in their hardware and use appropriate software image - > > that's something I'd like to avoid. > > I think Thierry meant either way this is a firmware problem. If you > have a SKU per device and panel type, then the firmware just picks a > dtb among a set. Unfortunately it's one SKU per multiple panels. > Rob -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 04, 2019 at 10:27:09AM -0600, Rob Herring wrote: > On Mon, Feb 4, 2019 at 2:24 AM Thierry Reding > wrote: > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote: > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding > > > wrote: > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote: > > > > > eDP panels usually have EDID EEPROM, so there's no need to define > > > > > panel > > > > > width/height or any modes/timings in dts. But this panel still may > > > > > have > > > > > regulator and/or backlight. > > > > > > > > > > Signed-off-by: Vasily Khoruzhick > > > > > --- > > > > > .../devicetree/bindings/display/panel/panel-edp.txt| 7 > > > > > +++ > > > > > 1 file changed, 7 insertions(+) > > > > > create mode 100644 > > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > Please don't try to make panels look more generic than they really are. > > > > You're going to have to provide a compatible string for your device that > > > > is more specific than "panel-edp". You claim that you don't need any > > > > extra information that is panel specific, but you don't know that now. > > > > We have in the past thought that we didn't need things like prepare > > > > delay, but then we ran into situations where we did need them. > > > > > > > > Just do what everybody else does. Provide a specific compatible string > > > > and match on that in the panel-simple driver. Even if you can read all > > > > the video timings from an EDID EEPROM, you can still provide a mode in > > > > the panel descriptor to serve as a fallback if for example the EEPROM > > > > is faulty on some device. > > > > > > Pinebook used several 768p panels that have slightly different timings > > > and recent batch uses 1080p panel. > > > > > > What panel descriptor should I use as fallback? > > > > You don't use panel descriptors as fallback. The simple-panel driver > > will bind to a panel device and use the corresponding descriptor. If > > your device tree contains the correct information, the descriptor is > > correct for the panel you have. > > > > In other words you need to ensure that you have the correct panel in > > device tree for the board that you're using. This is exactly the same > > thing as for other devices. > > > > One way to to this is to have separate device trees for each variant > > of the board that you want to support. Another variant may be to have > > a common device tree and then have some early firmware update the DTB > > with the correct panel information. > > That can be a pain to manage especially if panels are swapped run to > run with 2nd sources. > > I think it is perfectly fine to have a generic-ish fallback as long as > it is just that, a fallback. If the panel has quirks, then you'd > better make sure the firmware is stuffing in the right compatibles or > that you can update the firmware. simple-panel would probably work if you stuck in some mostly compatible string and provided a ddc-i2c-bus property in the device tree node. The generic-ish fallback case could be implemented by providing a fallback compatible string (we used to have "simple-panel", which I think would still be adequate for this I suppose) and adding a dummy descriptor in the driver, perhaps one with pre-defined delays that could be adjusted to work for all cases, or they could just be 0. At least that way we'd be explicitly documenting that we support this as a fallback. I'm not sure how you'd want to enforce that people provide the right compatible strings that way. Currently there's no way to make your panel work without adding a panel driver, so people are forced to write the DT bindings and a driver, or add support to an existing one. If we open this backdoor, I suspect many people will just take the easy route and rely on the fallback. And then what do we do when we get bug reports about panels not working, or requiring some quirks. How do we go and find out what the right compatible strings are for each board, or how to fix things for something we don't have access to. This all sounds like a Pandora's box to me. Thierry -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 4, 2019 at 10:11 AM Vasily Khoruzhick wrote: > > On Mon, Feb 4, 2019 at 12:24 AM Thierry Reding > wrote: > > > > > > Pinebook used several 768p panels that have slightly different timings > > > and recent batch uses 1080p panel. > > > > > > What panel descriptor should I use as fallback? > > > > You don't use panel descriptors as fallback. The simple-panel driver > > will bind to a panel device and use the corresponding descriptor. If > > your device tree contains the correct information, the descriptor is > > correct for the panel you have. > > > > In other words you need to ensure that you have the correct panel in > > device tree for the board that you're using. This is exactly the same > > thing as for other devices. > > > > One way to to this is to have separate device trees for each variant > > of the board that you want to support. Another variant may be to have > > a common device tree and then have some early firmware update the DTB > > with the correct panel information. > > That defeats the purpose of using eDP panels. Panel can identify > itself and report what timings it supports. If you are confident that this works for all panels, then the firmware can identify the right panel and update the DTB with the correct information. If this doesn't work in the firmware, then it is not going to work in the kernel either and you are SOL without specific panel information in the DT. > If we use separate DTBs then users will have to figure out what panel > is installed in their hardware and use appropriate software image - > that's something I'd like to avoid. I think Thierry meant either way this is a firmware problem. If you have a SKU per device and panel type, then the firmware just picks a dtb among a set. Rob -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 04, 2019 at 08:11:05AM -0800, Vasily Khoruzhick wrote: > On Mon, Feb 4, 2019 at 12:24 AM Thierry Reding > wrote: > > > > > > Pinebook used several 768p panels that have slightly different timings > > > and recent batch uses 1080p panel. > > > > > > What panel descriptor should I use as fallback? > > > > You don't use panel descriptors as fallback. The simple-panel driver > > will bind to a panel device and use the corresponding descriptor. If > > your device tree contains the correct information, the descriptor is > > correct for the panel you have. > > > > In other words you need to ensure that you have the correct panel in > > device tree for the board that you're using. This is exactly the same > > thing as for other devices. > > > > One way to to this is to have separate device trees for each variant > > of the board that you want to support. Another variant may be to have > > a common device tree and then have some early firmware update the DTB > > with the correct panel information. > > That defeats the purpose of using eDP panels. Panel can identify > itself and report what timings it supports. > > If we use separate DTBs then users will have to figure out what panel > is installed in their hardware and use appropriate software image - > that's something I'd like to avoid. > > I can add a descriptor for something like "pinebook eDP panel" if it > works for you, but it won't have any display timings in it. I'd like to point you to this: http://sietch-tagr.blogspot.com/2016/04/display-panels-are-not-special.html it addresses some of your questions. Hopefully that will also help you understand that this isn't only about display timings. Thierry -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 4, 2019 at 2:24 AM Thierry Reding wrote: > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote: > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding > > wrote: > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote: > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel > > > > width/height or any modes/timings in dts. But this panel still may have > > > > regulator and/or backlight. > > > > > > > > Signed-off-by: Vasily Khoruzhick > > > > --- > > > > .../devicetree/bindings/display/panel/panel-edp.txt| 7 +++ > > > > 1 file changed, 7 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt > > > > > > Please don't try to make panels look more generic than they really are. > > > You're going to have to provide a compatible string for your device that > > > is more specific than "panel-edp". You claim that you don't need any > > > extra information that is panel specific, but you don't know that now. > > > We have in the past thought that we didn't need things like prepare > > > delay, but then we ran into situations where we did need them. > > > > > > Just do what everybody else does. Provide a specific compatible string > > > and match on that in the panel-simple driver. Even if you can read all > > > the video timings from an EDID EEPROM, you can still provide a mode in > > > the panel descriptor to serve as a fallback if for example the EEPROM > > > is faulty on some device. > > > > Pinebook used several 768p panels that have slightly different timings > > and recent batch uses 1080p panel. > > > > What panel descriptor should I use as fallback? > > You don't use panel descriptors as fallback. The simple-panel driver > will bind to a panel device and use the corresponding descriptor. If > your device tree contains the correct information, the descriptor is > correct for the panel you have. > > In other words you need to ensure that you have the correct panel in > device tree for the board that you're using. This is exactly the same > thing as for other devices. > > One way to to this is to have separate device trees for each variant > of the board that you want to support. Another variant may be to have > a common device tree and then have some early firmware update the DTB > with the correct panel information. That can be a pain to manage especially if panels are swapped run to run with 2nd sources. I think it is perfectly fine to have a generic-ish fallback as long as it is just that, a fallback. If the panel has quirks, then you'd better make sure the firmware is stuffing in the right compatibles or that you can update the firmware. Rob -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 4, 2019 at 12:24 AM Thierry Reding wrote: > > > > Pinebook used several 768p panels that have slightly different timings > > and recent batch uses 1080p panel. > > > > What panel descriptor should I use as fallback? > > You don't use panel descriptors as fallback. The simple-panel driver > will bind to a panel device and use the corresponding descriptor. If > your device tree contains the correct information, the descriptor is > correct for the panel you have. > > In other words you need to ensure that you have the correct panel in > device tree for the board that you're using. This is exactly the same > thing as for other devices. > > One way to to this is to have separate device trees for each variant > of the board that you want to support. Another variant may be to have > a common device tree and then have some early firmware update the DTB > with the correct panel information. That defeats the purpose of using eDP panels. Panel can identify itself and report what timings it supports. If we use separate DTBs then users will have to figure out what panel is installed in their hardware and use appropriate software image - that's something I'd like to avoid. I can add a descriptor for something like "pinebook eDP panel" if it works for you, but it won't have any display timings in it. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote: > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote: > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote: > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote: > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding > > > > wrote: > > > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote: > > > > > > eDP panels usually have EDID EEPROM, so there's no need to define > > > > > > panel > > > > > > width/height or any modes/timings in dts. But this panel still may > > > > > > have > > > > > > regulator and/or backlight. > > > > > > > > > > > > Signed-off-by: Vasily Khoruzhick > > > > > > --- > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt| 7 > > > > > > +++ > > > > > > 1 file changed, 7 insertions(+) > > > > > > create mode 100644 > > > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > > > Please don't try to make panels look more generic than they really > > > > > are. > > > > > You're going to have to provide a compatible string for your device > > > > > that > > > > > is more specific than "panel-edp". You claim that you don't need any > > > > > extra information that is panel specific, but you don't know that now. > > > > > We have in the past thought that we didn't need things like prepare > > > > > delay, but then we ran into situations where we did need them. > > > > > > > > > > Just do what everybody else does. Provide a specific compatible string > > > > > and match on that in the panel-simple driver. Even if you can read all > > > > > the video timings from an EDID EEPROM, you can still provide a mode in > > > > > the panel descriptor to serve as a fallback if for example the EEPROM > > > > > is faulty on some device. > > > > > > > > Pinebook used several 768p panels that have slightly different timings > > > > and recent batch uses 1080p panel. > > > > > > > > What panel descriptor should I use as fallback? > > > > > > You don't use panel descriptors as fallback. The simple-panel driver > > > will bind to a panel device and use the corresponding descriptor. If > > > your device tree contains the correct information, the descriptor is > > > correct for the panel you have. > > > > > > In other words you need to ensure that you have the correct panel in > > > device tree for the board that you're using. This is exactly the same > > > thing as for other devices. > > > > > > One way to to this is to have separate device trees for each variant > > > of the board that you want to support. Another variant may be to have > > > a common device tree and then have some early firmware update the DTB > > > with the correct panel information. > > > > This would defeat the point of edp, which is to standardize the mess of > > panels (at least somewhat) and avoid having to change the DT/ACPI > > tables/firmware for every board you ship. Also, we do have DP quirking > > infrastructure already (using the OUI), I think if there's something that > > doesn't work then we should quirk it there. > > The problem is that while the attempt may have been to standardize, it > failed. It doesn't take into account any of the details such as timing > between things like powering up the display and enabling the backlight > or similar. I don't know how you'd want to "quirk" those kinds of > requirements because they are highly panel specific. Hm right, we get these from some firmware tables (and mix them with the spec one, since some of the firmware values are nonsense). I don't even know whether we can read the timings over dp aux somehow (you can power up the panel with some pessimistic values to figure those out, and you only need dp aux to work, which is much simpler than the entire panel). > > What does make sense though imo is if we try not to stuff the edp panel > > into panel-simple, because it's anything like a simple dumb panel. There's > > also some integration awkwardness since with this panel you need to do dp > > aux/i2c transactions to get at the information (edid alone isn't good > > enough for edp), and I'm not sure how exactly that's supposed to be > > instantiated. Maybe a special function to instantiate an edp panel, which > > takes both a DT node and the dp_aux controller would be much better, > > instead of trying to auto-match against a DT compatible string and load a > > panel driver which is almost all fake. > > > > Or we teach dp_aux to register itself and somehow teach panel-edp how it > > can get hold of the dp_aux channel it needs. > > We already do that. drm_dp_aux registers as an I2C adapter that can be > used to read EDID EEPROMs using I2C-over-AUX transactions. We already > use that on some platforms. > > Also note that simple-panel already supports getting video timings from > EDID. If a DDC link is present in DT, the driver will load the modes > from EDID and use them. Could we
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote: > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote: > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote: > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding > > > wrote: > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote: > > > > > eDP panels usually have EDID EEPROM, so there's no need to define > > > > > panel > > > > > width/height or any modes/timings in dts. But this panel still may > > > > > have > > > > > regulator and/or backlight. > > > > > > > > > > Signed-off-by: Vasily Khoruzhick > > > > > --- > > > > > .../devicetree/bindings/display/panel/panel-edp.txt| 7 > > > > > +++ > > > > > 1 file changed, 7 insertions(+) > > > > > create mode 100644 > > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > Please don't try to make panels look more generic than they really are. > > > > You're going to have to provide a compatible string for your device that > > > > is more specific than "panel-edp". You claim that you don't need any > > > > extra information that is panel specific, but you don't know that now. > > > > We have in the past thought that we didn't need things like prepare > > > > delay, but then we ran into situations where we did need them. > > > > > > > > Just do what everybody else does. Provide a specific compatible string > > > > and match on that in the panel-simple driver. Even if you can read all > > > > the video timings from an EDID EEPROM, you can still provide a mode in > > > > the panel descriptor to serve as a fallback if for example the EEPROM > > > > is faulty on some device. > > > > > > Pinebook used several 768p panels that have slightly different timings > > > and recent batch uses 1080p panel. > > > > > > What panel descriptor should I use as fallback? > > > > You don't use panel descriptors as fallback. The simple-panel driver > > will bind to a panel device and use the corresponding descriptor. If > > your device tree contains the correct information, the descriptor is > > correct for the panel you have. > > > > In other words you need to ensure that you have the correct panel in > > device tree for the board that you're using. This is exactly the same > > thing as for other devices. > > > > One way to to this is to have separate device trees for each variant > > of the board that you want to support. Another variant may be to have > > a common device tree and then have some early firmware update the DTB > > with the correct panel information. > > This would defeat the point of edp, which is to standardize the mess of > panels (at least somewhat) and avoid having to change the DT/ACPI > tables/firmware for every board you ship. Also, we do have DP quirking > infrastructure already (using the OUI), I think if there's something that > doesn't work then we should quirk it there. The problem is that while the attempt may have been to standardize, it failed. It doesn't take into account any of the details such as timing between things like powering up the display and enabling the backlight or similar. I don't know how you'd want to "quirk" those kinds of requirements because they are highly panel specific. > What does make sense though imo is if we try not to stuff the edp panel > into panel-simple, because it's anything like a simple dumb panel. There's > also some integration awkwardness since with this panel you need to do dp > aux/i2c transactions to get at the information (edid alone isn't good > enough for edp), and I'm not sure how exactly that's supposed to be > instantiated. Maybe a special function to instantiate an edp panel, which > takes both a DT node and the dp_aux controller would be much better, > instead of trying to auto-match against a DT compatible string and load a > panel driver which is almost all fake. > > Or we teach dp_aux to register itself and somehow teach panel-edp how it > can get hold of the dp_aux channel it needs. We already do that. drm_dp_aux registers as an I2C adapter that can be used to read EDID EEPROMs using I2C-over-AUX transactions. We already use that on some platforms. Also note that simple-panel already supports getting video timings from EDID. If a DDC link is present in DT, the driver will load the modes from EDID and use them. > But fake mode in panel-simple sounds like the wrong approach. At least > from our experience with i915 (and I think other drivers supporting edp), > the standardization of panels for basic stuff at least worked. > Self-refresh seems an entirely different story unfortunately ... but again > quirking that for DP stuff should be done using the OUI I think. I can imagine that on x86 platforms OEMs can also easily hide some of the necessary quirks in ACPI. None of that exists on ARM or other architectures that solely rely on device tree to describe the device. Since there's no way of specifying power sequences in DT
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote: > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote: > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding > > wrote: > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote: > > > > eDP panels usually have EDID EEPROM, so there's no need to define panel > > > > width/height or any modes/timings in dts. But this panel still may have > > > > regulator and/or backlight. > > > > > > > > Signed-off-by: Vasily Khoruzhick > > > > --- > > > > .../devicetree/bindings/display/panel/panel-edp.txt| 7 +++ > > > > 1 file changed, 7 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt > > > > > > Please don't try to make panels look more generic than they really are. > > > You're going to have to provide a compatible string for your device that > > > is more specific than "panel-edp". You claim that you don't need any > > > extra information that is panel specific, but you don't know that now. > > > We have in the past thought that we didn't need things like prepare > > > delay, but then we ran into situations where we did need them. > > > > > > Just do what everybody else does. Provide a specific compatible string > > > and match on that in the panel-simple driver. Even if you can read all > > > the video timings from an EDID EEPROM, you can still provide a mode in > > > the panel descriptor to serve as a fallback if for example the EEPROM > > > is faulty on some device. > > > > Pinebook used several 768p panels that have slightly different timings > > and recent batch uses 1080p panel. > > > > What panel descriptor should I use as fallback? > > You don't use panel descriptors as fallback. The simple-panel driver > will bind to a panel device and use the corresponding descriptor. If > your device tree contains the correct information, the descriptor is > correct for the panel you have. > > In other words you need to ensure that you have the correct panel in > device tree for the board that you're using. This is exactly the same > thing as for other devices. > > One way to to this is to have separate device trees for each variant > of the board that you want to support. Another variant may be to have > a common device tree and then have some early firmware update the DTB > with the correct panel information. This would defeat the point of edp, which is to standardize the mess of panels (at least somewhat) and avoid having to change the DT/ACPI tables/firmware for every board you ship. Also, we do have DP quirking infrastructure already (using the OUI), I think if there's something that doesn't work then we should quirk it there. What does make sense though imo is if we try not to stuff the edp panel into panel-simple, because it's anything like a simple dumb panel. There's also some integration awkwardness since with this panel you need to do dp aux/i2c transactions to get at the information (edid alone isn't good enough for edp), and I'm not sure how exactly that's supposed to be instantiated. Maybe a special function to instantiate an edp panel, which takes both a DT node and the dp_aux controller would be much better, instead of trying to auto-match against a DT compatible string and load a panel driver which is almost all fake. Or we teach dp_aux to register itself and somehow teach panel-edp how it can get hold of the dp_aux channel it needs. But fake mode in panel-simple sounds like the wrong approach. At least from our experience with i915 (and I think other drivers supporting edp), the standardization of panels for basic stuff at least worked. Self-refresh seems an entirely different story unfortunately ... but again quirking that for DP stuff should be done using the OUI I think. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote: > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding > wrote: > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote: > > > eDP panels usually have EDID EEPROM, so there's no need to define panel > > > width/height or any modes/timings in dts. But this panel still may have > > > regulator and/or backlight. > > > > > > Signed-off-by: Vasily Khoruzhick > > > --- > > > .../devicetree/bindings/display/panel/panel-edp.txt| 7 +++ > > > 1 file changed, 7 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt > > > > Please don't try to make panels look more generic than they really are. > > You're going to have to provide a compatible string for your device that > > is more specific than "panel-edp". You claim that you don't need any > > extra information that is panel specific, but you don't know that now. > > We have in the past thought that we didn't need things like prepare > > delay, but then we ran into situations where we did need them. > > > > Just do what everybody else does. Provide a specific compatible string > > and match on that in the panel-simple driver. Even if you can read all > > the video timings from an EDID EEPROM, you can still provide a mode in > > the panel descriptor to serve as a fallback if for example the EEPROM > > is faulty on some device. > > Pinebook used several 768p panels that have slightly different timings > and recent batch uses 1080p panel. > > What panel descriptor should I use as fallback? You don't use panel descriptors as fallback. The simple-panel driver will bind to a panel device and use the corresponding descriptor. If your device tree contains the correct information, the descriptor is correct for the panel you have. In other words you need to ensure that you have the correct panel in device tree for the board that you're using. This is exactly the same thing as for other devices. One way to to this is to have separate device trees for each variant of the board that you want to support. Another variant may be to have a common device tree and then have some early firmware update the DTB with the correct panel information. Thierry -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding wrote: > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote: > > eDP panels usually have EDID EEPROM, so there's no need to define panel > > width/height or any modes/timings in dts. But this panel still may have > > regulator and/or backlight. > > > > Signed-off-by: Vasily Khoruzhick > > --- > > .../devicetree/bindings/display/panel/panel-edp.txt| 7 +++ > > 1 file changed, 7 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/panel/panel-edp.txt > > Please don't try to make panels look more generic than they really are. > You're going to have to provide a compatible string for your device that > is more specific than "panel-edp". You claim that you don't need any > extra information that is panel specific, but you don't know that now. > We have in the past thought that we didn't need things like prepare > delay, but then we ran into situations where we did need them. > > Just do what everybody else does. Provide a specific compatible string > and match on that in the panel-simple driver. Even if you can read all > the video timings from an EDID EEPROM, you can still provide a mode in > the panel descriptor to serve as a fallback if for example the EEPROM > is faulty on some device. Pinebook used several 768p panels that have slightly different timings and recent batch uses 1080p panel. What panel descriptor should I use as fallback? > Thierry -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote: > eDP panels usually have EDID EEPROM, so there's no need to define panel > width/height or any modes/timings in dts. But this panel still may have > regulator and/or backlight. > > Signed-off-by: Vasily Khoruzhick > --- > .../devicetree/bindings/display/panel/panel-edp.txt| 7 +++ > 1 file changed, 7 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/panel-edp.txt Please don't try to make panels look more generic than they really are. You're going to have to provide a compatible string for your device that is more specific than "panel-edp". You claim that you don't need any extra information that is panel specific, but you don't know that now. We have in the past thought that we didn't need things like prepare delay, but then we ran into situations where we did need them. Just do what everybody else does. Provide a specific compatible string and match on that in the panel-simple driver. Even if you can read all the video timings from an EDID EEPROM, you can still provide a mode in the panel descriptor to serve as a fallback if for example the EEPROM is faulty on some device. Thierry -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
