* [PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding @ 2016-06-10 17:02 Douglas Anderson 2016-06-10 18:43 ` Rob Clark ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Douglas Anderson @ 2016-06-10 17:02 UTC (permalink / raw) To: thierry.reding Cc: airlied, robh+dt, Douglas Anderson, mark.rutland, dri-devel, devicetree, linux-kernel The Starry KR122EA0SRA is a 12.2", 1920x1200 TFT-LCD panel connected using eDP interfaces. Signed-off-by: Douglas Anderson <dianders@chromium.org> --- Changes in v2: - Proper title (sorry!) .../devicetree/bindings/display/panel/starry,kr122ea0sra.txt | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt diff --git a/Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt b/Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt new file mode 100644 index 000000000000..1e87fe6078af --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt @@ -0,0 +1,7 @@ +Starry 12.2" (1920x1200 pixels) TFT LCD panel + +Required properties: +- compatible: should be "starry,kr122ea0sra" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- 2.8.0.rc3.226.g39d4020 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding 2016-06-10 17:02 [PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding Douglas Anderson @ 2016-06-10 18:43 ` Rob Clark 2016-06-10 19:52 ` Doug Anderson [not found] ` <1465578127-30330-1-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> 2016-07-11 12:07 ` Thierry Reding 2 siblings, 1 reply; 11+ messages in thread From: Rob Clark @ 2016-06-10 18:43 UTC (permalink / raw) To: Douglas Anderson Cc: Mark Rutland, devicetree, Linux Kernel Mailing List, dri-devel, Rob Herring On Fri, Jun 10, 2016 at 1:02 PM, Douglas Anderson <dianders@chromium.org> wrote: > The Starry KR122EA0SRA is a 12.2", 1920x1200 TFT-LCD panel connected > using eDP interfaces. so drive-by comment... but shouldn't eDP be probe-able? Not sure why we need panel drivers or DT bindings? BR, -R > Signed-off-by: Douglas Anderson <dianders@chromium.org> > --- > Changes in v2: > - Proper title (sorry!) > > .../devicetree/bindings/display/panel/starry,kr122ea0sra.txt | 7 +++++++ > 1 file changed, 7 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt > > diff --git a/Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt b/Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt > new file mode 100644 > index 000000000000..1e87fe6078af > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt > @@ -0,0 +1,7 @@ > +Starry 12.2" (1920x1200 pixels) TFT LCD panel > + > +Required properties: > +- compatible: should be "starry,kr122ea0sra" > + > +This binding is compatible with the simple-panel binding, which is specified > +in simple-panel.txt in this directory. > -- > 2.8.0.rc3.226.g39d4020 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding 2016-06-10 18:43 ` Rob Clark @ 2016-06-10 19:52 ` Doug Anderson 2016-06-10 22:03 ` Rob Clark 2016-06-13 11:28 ` Thierry Reding 0 siblings, 2 replies; 11+ messages in thread From: Doug Anderson @ 2016-06-10 19:52 UTC (permalink / raw) To: Rob Clark Cc: Mark Rutland, devicetree, Linux Kernel Mailing List, dri-devel, Rob Herring, Stéphane Marchesin Rob, On Fri, Jun 10, 2016 at 11:43 AM, Rob Clark <robdclark@gmail.com> wrote: > On Fri, Jun 10, 2016 at 1:02 PM, Douglas Anderson <dianders@chromium.org> wrote: >> The Starry KR122EA0SRA is a 12.2", 1920x1200 TFT-LCD panel connected >> using eDP interfaces. > > so drive-by comment... but shouldn't eDP be probe-able? Not sure why > we need panel drivers or DT bindings? I was wondering about that too. As far as I can tell: 1. We need a panel driver because that appears to be what owns a reference to the backlight / panel power regulator and that part is not auto-probable. 2. As far as I could tell, there is no way to declare a generic (unspecified) panel in the device tree. Everyone seems to include "simple-panel" in their compatible string but as far as I can tell nothing in the kernel looks at it. 3. In theory, all the info specified here should match the EDID exactly and thus (as you said) be probable. However, it sounds like (for power sequencing reasons) there might be reasons why you'd want to know exactly what panel was present beforehand. You might need to power the panel and backlight in very specific sequences, for instance. I'm not sure it's always 100% possible in all embedded designs to read the EDID before you know how the sequencing should work (but, of course, I'm a NOOB). 4. Reading the EDID can be slow. If you happen to know all the info on the panel beforehand you can significantly speed up boot speed, notably how fast you can get something on the screen. Anyway, maybe someone else who actually knows what they're talking about will chime in. ;) -Doug _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding 2016-06-10 19:52 ` Doug Anderson @ 2016-06-10 22:03 ` Rob Clark [not found] ` <CAF6AEGsZxZuSVUCqVH=8FUOTMiWBVT52xQ+Qcaqt3yF=pRmf3w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-06-13 11:28 ` Thierry Reding 1 sibling, 1 reply; 11+ messages in thread From: Rob Clark @ 2016-06-10 22:03 UTC (permalink / raw) To: Doug Anderson Cc: Mark Rutland, devicetree, Linux Kernel Mailing List, dri-devel, Rob Herring, Stéphane Marchesin On Fri, Jun 10, 2016 at 3:52 PM, Doug Anderson <dianders@chromium.org> wrote: > Rob, > > On Fri, Jun 10, 2016 at 11:43 AM, Rob Clark <robdclark@gmail.com> wrote: >> On Fri, Jun 10, 2016 at 1:02 PM, Douglas Anderson <dianders@chromium.org> wrote: >>> The Starry KR122EA0SRA is a 12.2", 1920x1200 TFT-LCD panel connected >>> using eDP interfaces. >> >> so drive-by comment... but shouldn't eDP be probe-able? Not sure why >> we need panel drivers or DT bindings? > > I was wondering about that too. As far as I can tell: > > 1. We need a panel driver because that appears to be what owns a > reference to the backlight / panel power regulator and that part is > not auto-probable. oh, hmm.. sad.. I was hoping that eDP would save us from dsi per-panel driver hell.. I guess being able to use panel-simple is at least an improvement. But panel specific sequences is sounds like panel-simple won't save us all the time :-( > 2. As far as I could tell, there is no way to declare a generic > (unspecified) panel in the device tree. Everyone seems to include > "simple-panel" in their compatible string but as far as I can tell > nothing in the kernel looks at it. > > 3. In theory, all the info specified here should match the EDID > exactly and thus (as you said) be probable. However, it sounds like > (for power sequencing reasons) there might be reasons why you'd want > to know exactly what panel was present beforehand. You might need to > power the panel and backlight in very specific sequences, for > instance. I'm not sure it's always 100% possible in all embedded > designs to read the EDID before you know how the sequencing should > work (but, of course, I'm a NOOB). > > 4. Reading the EDID can be slow. If you happen to know all the info > on the panel beforehand you can significantly speed up boot speed, > notably how fast you can get something on the screen. The theory is (although I think not true currently for most of the arm drivers) that we should be reading back from hw the current config from bootloader splash screen, to avoid a modeset (and conveniently also the need to read edid) at boot. BR, -R > > Anyway, maybe someone else who actually knows what they're talking > about will chime in. ;) > > -Doug _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <CAF6AEGsZxZuSVUCqVH=8FUOTMiWBVT52xQ+Qcaqt3yF=pRmf3w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding [not found] ` <CAF6AEGsZxZuSVUCqVH=8FUOTMiWBVT52xQ+Qcaqt3yF=pRmf3w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-06-10 22:08 ` Stéphane Marchesin 2016-06-13 11:39 ` Thierry Reding 0 siblings, 1 reply; 11+ messages in thread From: Stéphane Marchesin @ 2016-06-10 22:08 UTC (permalink / raw) To: Rob Clark Cc: Doug Anderson, Thierry Reding, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Linux Kernel Mailing List, Rob Herring On Fri, Jun 10, 2016 at 3:03 PM, Rob Clark <robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > On Fri, Jun 10, 2016 at 3:52 PM, Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote: >> Rob, >> >> On Fri, Jun 10, 2016 at 11:43 AM, Rob Clark <robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >>> On Fri, Jun 10, 2016 at 1:02 PM, Douglas Anderson <dianders@chromium.org> wrote: >>>> The Starry KR122EA0SRA is a 12.2", 1920x1200 TFT-LCD panel connected >>>> using eDP interfaces. >>> >>> so drive-by comment... but shouldn't eDP be probe-able? Not sure why >>> we need panel drivers or DT bindings? >> >> I was wondering about that too. As far as I can tell: >> >> 1. We need a panel driver because that appears to be what owns a >> reference to the backlight / panel power regulator and that part is >> not auto-probable. > > oh, hmm.. sad.. I was hoping that eDP would save us from dsi per-panel > driver hell.. I guess being able to use panel-simple is at least an > improvement. But panel specific sequences is sounds like panel-simple > won't save us all the time :-( Yes, although you can probably make things mostly work with improper sequencing and enough retries, a lot of ARM hw either requires interesting sequencing, or has broken/unreliable DDC, which translates into the use of panel simple on the sw side. > >> 2. As far as I could tell, there is no way to declare a generic >> (unspecified) panel in the device tree. Everyone seems to include >> "simple-panel" in their compatible string but as far as I can tell >> nothing in the kernel looks at it. >> >> 3. In theory, all the info specified here should match the EDID >> exactly and thus (as you said) be probable. However, it sounds like >> (for power sequencing reasons) there might be reasons why you'd want >> to know exactly what panel was present beforehand. You might need to >> power the panel and backlight in very specific sequences, for >> instance. I'm not sure it's always 100% possible in all embedded >> designs to read the EDID before you know how the sequencing should >> work (but, of course, I'm a NOOB). >> >> 4. Reading the EDID can be slow. If you happen to know all the info >> on the panel beforehand you can significantly speed up boot speed, >> notably how fast you can get something on the screen. > > The theory is (although I think not true currently for most of the arm > drivers) that we should be reading back from hw the current config > from bootloader splash screen, to avoid a modeset (and conveniently > also the need to read edid) at boot. On some devices the firmware doesn't set any video mode, so there isn't anything we can read back. That is our case :) Stéphane > > BR, > -R > >> >> Anyway, maybe someone else who actually knows what they're talking >> about will chime in. ;) >> >> -Doug -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding 2016-06-10 22:08 ` Stéphane Marchesin @ 2016-06-13 11:39 ` Thierry Reding 0 siblings, 0 replies; 11+ messages in thread From: Thierry Reding @ 2016-06-13 11:39 UTC (permalink / raw) To: Stéphane Marchesin Cc: Mark Rutland, devicetree, Doug Anderson, dri-devel, Linux Kernel Mailing List, Rob Herring [-- Attachment #1.1: Type: text/plain, Size: 4170 bytes --] On Fri, Jun 10, 2016 at 03:08:50PM -0700, Stéphane Marchesin wrote: > On Fri, Jun 10, 2016 at 3:03 PM, Rob Clark <robdclark@gmail.com> wrote: > > On Fri, Jun 10, 2016 at 3:52 PM, Doug Anderson <dianders@chromium.org> wrote: > >> Rob, > >> > >> On Fri, Jun 10, 2016 at 11:43 AM, Rob Clark <robdclark@gmail.com> wrote: > >>> On Fri, Jun 10, 2016 at 1:02 PM, Douglas Anderson <dianders@chromium.org> wrote: > >>>> The Starry KR122EA0SRA is a 12.2", 1920x1200 TFT-LCD panel connected > >>>> using eDP interfaces. > >>> > >>> so drive-by comment... but shouldn't eDP be probe-able? Not sure why > >>> we need panel drivers or DT bindings? > >> > >> I was wondering about that too. As far as I can tell: > >> > >> 1. We need a panel driver because that appears to be what owns a > >> reference to the backlight / panel power regulator and that part is > >> not auto-probable. > > > > oh, hmm.. sad.. I was hoping that eDP would save us from dsi per-panel > > driver hell.. I guess being able to use panel-simple is at least an > > improvement. But panel specific sequences is sounds like panel-simple > > won't save us all the time :-( > > Yes, although you can probably make things mostly work with improper > sequencing and enough retries, a lot of ARM hw either requires > interesting sequencing, or has broken/unreliable DDC, which translates > into the use of panel simple on the sw side. panel-simple has support for very simple sequencing. You can specify delays after the prepare and enable stages. This is useful because most panels have specific requirements when it comes to the amount of time it takes them to receive video data (after being powered up) and the amount of time it takes them to show the first valid frame after it has been received. The former is used to keep drivers from sending video data to make sure it can be properly received by the panel, and the latter is used to keep the backlight off until the first valid frame is visible on the display. This is used to avoid glitches and seems to work well enough for simple panels. More complex panels have more involved sequences, so separate drivers are required. Also note that the simple-panel driver will try to use EDID if available and only fall back to the hard-coded mode or timings if there is no DDC to probe or no modes could be parsed from EDID. > >> 2. As far as I could tell, there is no way to declare a generic > >> (unspecified) panel in the device tree. Everyone seems to include > >> "simple-panel" in their compatible string but as far as I can tell > >> nothing in the kernel looks at it. > >> > >> 3. In theory, all the info specified here should match the EDID > >> exactly and thus (as you said) be probable. However, it sounds like > >> (for power sequencing reasons) there might be reasons why you'd want > >> to know exactly what panel was present beforehand. You might need to > >> power the panel and backlight in very specific sequences, for > >> instance. I'm not sure it's always 100% possible in all embedded > >> designs to read the EDID before you know how the sequencing should > >> work (but, of course, I'm a NOOB). > >> > >> 4. Reading the EDID can be slow. If you happen to know all the info > >> on the panel beforehand you can significantly speed up boot speed, > >> notably how fast you can get something on the screen. > > > > The theory is (although I think not true currently for most of the arm > > drivers) that we should be reading back from hw the current config > > from bootloader splash screen, to avoid a modeset (and conveniently > > also the need to read edid) at boot. > > On some devices the firmware doesn't set any video mode, so there > isn't anything we can read back. That is our case :) Reading out hardware state also doesn't give you all the information that you need. I've never seen hardware that is programmed with the physical size of the panel, so there's no way to read that back and you'd still have to either parse EDID or use the value hard-coded in the simple-panel driver if you want to compute the pixel density. Thierry [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding 2016-06-10 19:52 ` Doug Anderson 2016-06-10 22:03 ` Rob Clark @ 2016-06-13 11:28 ` Thierry Reding 1 sibling, 0 replies; 11+ messages in thread From: Thierry Reding @ 2016-06-13 11:28 UTC (permalink / raw) To: Doug Anderson Cc: Mark Rutland, devicetree, Linux Kernel Mailing List, dri-devel, Rob Herring, Stéphane Marchesin [-- Attachment #1.1: Type: text/plain, Size: 3339 bytes --] On Fri, Jun 10, 2016 at 12:52:41PM -0700, Doug Anderson wrote: > Rob, > > On Fri, Jun 10, 2016 at 11:43 AM, Rob Clark <robdclark@gmail.com> wrote: > > On Fri, Jun 10, 2016 at 1:02 PM, Douglas Anderson <dianders@chromium.org> wrote: > >> The Starry KR122EA0SRA is a 12.2", 1920x1200 TFT-LCD panel connected > >> using eDP interfaces. > > > > so drive-by comment... but shouldn't eDP be probe-able? Not sure why > > we need panel drivers or DT bindings? > > I was wondering about that too. As far as I can tell: > > 1. We need a panel driver because that appears to be what owns a > reference to the backlight / panel power regulator and that part is > not auto-probable. Yes, that's one of the reasons why we still need DT nodes for panels, even on a probe-able bus. eDP has a mechanism to allow brightness control via DPCD, but I've never actually seen it implemented. Even if we had that, we'd likely need to represent supplies and GPIOs for the backlight, and we'd be back to square one. DSI also provides a means to control backlight brightness, but in the same way that eDP doesn't go all the way, we'd require external resources to be hooked up via DT again. > 2. As far as I could tell, there is no way to declare a generic > (unspecified) panel in the device tree. Everyone seems to include > "simple-panel" in their compatible string but as far as I can tell > nothing in the kernel looks at it. The ones that do are wrong and should eventually be updated. This was originally done, and the driver used to match on simple-panel as well, but in retrospect that didn't make any sense at all so it was removed from the driver again. One of the reasons why it doesn't make any sense is because even if you have an EDID that's reachable, the EDID itself doesn't fully specify the panel. Power sequences are one example of data that's not represented in EDID. > 3. In theory, all the info specified here should match the EDID > exactly and thus (as you said) be probable. However, it sounds like > (for power sequencing reasons) there might be reasons why you'd want > to know exactly what panel was present beforehand. You might need to > power the panel and backlight in very specific sequences, for > instance. I'm not sure it's always 100% possible in all embedded > designs to read the EDID before you know how the sequencing should > work (but, of course, I'm a NOOB). It doesn't really matter whether you can access EDID or not, because EDID contains absolutely nothing on the power sequences for the panel. Even if it did, there'd be no way to relate that information to the device tree binding phandles. > 4. Reading the EDID can be slow. If you happen to know all the info > on the panel beforehand you can significantly speed up boot speed, > notably how fast you can get something on the screen. The motivation for potentially duplicating this information was not that it's slow to read EDID, but that occasionally you might not be able to access EDID. There could be a number of reasons why this might happen: a device might end up with an erased or invalid EDID or the DDC used to get at the EDID might be broken (I've been told that it's fairly common for OEMs to not wire through the DDC wires in cables to reduce costs). Thierry [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <1465578127-30330-1-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>]
* Re: [PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding [not found] ` <1465578127-30330-1-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> @ 2016-06-10 17:26 ` Emil Velikov 2016-06-10 18:03 ` Doug Anderson 2016-06-14 20:00 ` Rob Herring 1 sibling, 1 reply; 11+ messages in thread From: Emil Velikov @ 2016-06-10 17:26 UTC (permalink / raw) To: Douglas Anderson Cc: Thierry Reding, Mark Rutland, devicetree, ML dri-devel, Linux-Kernel@Vger. Kernel. Org, Rob Herring Hi Douglas, On 10 June 2016 at 18:02, Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote: > The Starry KR122EA0SRA is a 12.2", 1920x1200 TFT-LCD panel connected > using eDP interfaces. > > Signed-off-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> > --- > Changes in v2: > - Proper title (sorry!) > > .../devicetree/bindings/display/panel/starry,kr122ea0sra.txt | 7 +++++++ > 1 file changed, 7 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt > > diff --git a/Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt b/Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt > new file mode 100644 > index 000000000000..1e87fe6078af > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt > @@ -0,0 +1,7 @@ > +Starry 12.2" (1920x1200 pixels) TFT LCD panel > + > +Required properties: > +- compatible: should be "starry,kr122ea0sra" > + I think you want to add 'starry' to the vendors list first [1]. Latest linus-next does not seem to have such an entry. Regards, Emil [1] Documentation/devicetree/bindings/vendor-prefixes.txt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding 2016-06-10 17:26 ` Emil Velikov @ 2016-06-10 18:03 ` Doug Anderson 0 siblings, 0 replies; 11+ messages in thread From: Doug Anderson @ 2016-06-10 18:03 UTC (permalink / raw) To: Emil Velikov Cc: Mark Rutland, devicetree, Linux-Kernel@Vger. Kernel. Org, ML dri-devel, Rob Herring Emil, On Fri, Jun 10, 2016 at 10:26 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote: > Hi Douglas, > > On 10 June 2016 at 18:02, Douglas Anderson <dianders@chromium.org> wrote: >> The Starry KR122EA0SRA is a 12.2", 1920x1200 TFT-LCD panel connected >> using eDP interfaces. >> >> Signed-off-by: Douglas Anderson <dianders@chromium.org> >> --- >> Changes in v2: >> - Proper title (sorry!) >> >> .../devicetree/bindings/display/panel/starry,kr122ea0sra.txt | 7 +++++++ >> 1 file changed, 7 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt >> >> diff --git a/Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt b/Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt >> new file mode 100644 >> index 000000000000..1e87fe6078af >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt >> @@ -0,0 +1,7 @@ >> +Starry 12.2" (1920x1200 pixels) TFT LCD panel >> + >> +Required properties: >> +- compatible: should be "starry,kr122ea0sra" >> + > I think you want to add 'starry' to the vendors list first [1]. Latest > linus-next does not seem to have such an entry. Good call. Thanks! I've posted it at <https://patchwork.kernel.org/patch/9170205/>. If you'd rather me join it to this series and repost the whole thing, let me know. -Doug _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding [not found] ` <1465578127-30330-1-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> 2016-06-10 17:26 ` Emil Velikov @ 2016-06-14 20:00 ` Rob Herring 1 sibling, 0 replies; 11+ messages in thread From: Rob Herring @ 2016-06-14 20:00 UTC (permalink / raw) To: Douglas Anderson Cc: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, airlied-cv59FeDIM0c, mark.rutland-5wv7dgnIgG8, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA On Fri, Jun 10, 2016 at 10:02:06AM -0700, Douglas Anderson wrote: > The Starry KR122EA0SRA is a 12.2", 1920x1200 TFT-LCD panel connected > using eDP interfaces. > > Signed-off-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> > --- > Changes in v2: > - Proper title (sorry!) > > .../devicetree/bindings/display/panel/starry,kr122ea0sra.txt | 7 +++++++ > 1 file changed, 7 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding 2016-06-10 17:02 [PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding Douglas Anderson 2016-06-10 18:43 ` Rob Clark [not found] ` <1465578127-30330-1-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> @ 2016-07-11 12:07 ` Thierry Reding 2 siblings, 0 replies; 11+ messages in thread From: Thierry Reding @ 2016-07-11 12:07 UTC (permalink / raw) To: Douglas Anderson Cc: mark.rutland, devicetree, linux-kernel, dri-devel, robh+dt [-- Attachment #1.1: Type: text/plain, Size: 541 bytes --] On Fri, Jun 10, 2016 at 10:02:06AM -0700, Douglas Anderson wrote: > The Starry KR122EA0SRA is a 12.2", 1920x1200 TFT-LCD panel connected > using eDP interfaces. > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > --- > Changes in v2: > - Proper title (sorry!) > > .../devicetree/bindings/display/panel/starry,kr122ea0sra.txt | 7 +++++++ > 1 file changed, 7 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt Applied both patches. Thanks, Thierry [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2016-07-11 12:07 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-06-10 17:02 [PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding Douglas Anderson 2016-06-10 18:43 ` Rob Clark 2016-06-10 19:52 ` Doug Anderson 2016-06-10 22:03 ` Rob Clark [not found] ` <CAF6AEGsZxZuSVUCqVH=8FUOTMiWBVT52xQ+Qcaqt3yF=pRmf3w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-06-10 22:08 ` Stéphane Marchesin 2016-06-13 11:39 ` Thierry Reding 2016-06-13 11:28 ` Thierry Reding [not found] ` <1465578127-30330-1-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> 2016-06-10 17:26 ` Emil Velikov 2016-06-10 18:03 ` Doug Anderson 2016-06-14 20:00 ` Rob Herring 2016-07-11 12:07 ` Thierry Reding
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).