* Re: [PATCH v5 1/2] video: ARM CLCD: Add DT support
From: Tomi Valkeinen @ 2014-03-07 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1394119431.4160.84.camel@hornet>
[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]
On 06/03/14 17:23, Pawel Moll wrote:
> On Thu, 2014-03-06 at 10:21 +0000, Tomi Valkeinen wrote:
>> Is this an old HW, and presumably there won't be new users for it? If
>> yes, this is probably fine.
>
> There is a DRM driver in the works, actually...
>
>> If not, you might want to look at the video
>> ports and endpoints, which is used by at least three not-yet-merged series:
>>
>> [PATCHv3 00/41] OMAPDSS: DT support v3
>> [PATCH v5 00/11] imx-drm dt bindings
>> [RFC PATCH v2 00/21] Add DSI display support for Exynos based boards
>>
>> Using bindings like that would be more future proof, even if the current
>> driver doesn't use them.
>
> ... and this makes me try to get out of its way. In other words, I fully
> agree with you, but I don't think this applies to this particular patch,
> as I'm not even trying to represent the display pipeline. The (optional)
Right, you are not, at the moment. My point was, if the driver is
extended later to support pipelines, or common panel/encoder drivers,
you (most likely) need to have similar bindings than the other people use.
Note that the same DT bindings you add here should also work for the DRM
driver in the future. So, in fact, the question is extended to: will the
fbdev or drm driver support common panels/encoders?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [patch -resend] sisfb: fix 1280x720 resolution support
From: Tomi Valkeinen @ 2014-03-07 12:20 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20140307111853.GB2351@elgon.mountain>
[-- Attachment #1: Type: text/plain, Size: 745 bytes --]
On 07/03/14 13:18, Dan Carpenter wrote:
> It uses the wrong mode index because there is no break statement.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/video/fbdev/sis/init.c b/drivers/video/fbdev/sis/init.c
> index 4f26bc28e60b..bd40f5ecd901 100644
> --- a/drivers/video/fbdev/sis/init.c
> +++ b/drivers/video/fbdev/sis/init.c
> @@ -651,6 +651,7 @@ SiS_GetModeID_LCD(int VGAEngine, unsigned int VBFlags, int HDisplay, int VDispla
> switch(VDisplay) {
> case 720:
> ModeIndex = ModeIndex_1280x720[Depth];
> + break;
> case 768:
> if(VGAEngine == SIS_300_VGA) {
> ModeIndex = ModeIndex_300_1280x768[Depth];
>
Thanks, queued for 3.15.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 00/11] SimpleDRM & Sysfb
From: Tomi Valkeinen @ 2014-03-07 12:44 UTC (permalink / raw)
To: David Herrmann
Cc: dri-devel@lists.freedesktop.org, Ingo Molnar,
linux-fbdev@vger.kernel.org, Dave Airlie, Daniel Vetter,
linux-kernel, Tom Gundersen
In-Reply-To: <CANq1E4TmACNwyANaUsWufJL1ne4pk4Gv+g4y7b6xeO=Po-SN9g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3466 bytes --]
On 06/03/14 14:16, David Herrmann wrote:
> Hi Tomi
>
> On Mon, Mar 3, 2014 at 12:22 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 03/03/14 13:09, David Herrmann wrote:
>>
>>>> What do you think, would it be possible to keep the sysfb stuff in
>>>> arch/x86, and still be able to do the rest of the stuff here? And then
>>>> move the sysfs from arch/x86 to drivers/video later?
>>>
>>> I don't think there's any need for that. Linus does conflict
>>> resolution all day long, so a short hint in Dave's pull-request (plus
>>> an example merge) should be enough. Same is true for -next, I think.
>>
>> True, but, well, the conflict with this one is not a few lines. "git
>> diff |wc -l" gives 2494 lines for the conflict. It's not really complex
>> to resolve that one, though, as it's really about copying all the stuff
>> into its new place.
>>
>> So I'm not sure if that makes Linus think "this is simple one, 30 secs
>> and done" or "who the f*** sends me this crap" ;). Especially for two
>> reasons:
>>
>> - The fb-reogranization is not very critical, and often clean-ups are
>> not worth it (although I think this one is good one, of course).
>> - Conflicting fbdev changes coming from another tree
>>
>>> And this is really just a mechanical thing, nothing hard to do. But of
>>> course, it's your decision. However, keeping the code in x86 is the
>>> wrong thing to do. As discussed with Ingo, the patch that extends
>>
>> Yes, I didn't mean keeping the code in x86 for good, but just for one
>> kernel version to make merging easier.
>>
>>> x86/sysfb is only provided for easier backporting. The followup patch
>>> immediately removes it again and adds proper video/sysfb. I'd dislike
>>> splitting these just to avoid merge conflicts. I can also maintain a
>>> merge-fixup branch in my tree, if anyone wants that.
>>
>> You can have a try at merging. If you think it's trivial, maybe it is
>> and we can just let Linus handle it:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git
>> work/fb-reorder
>
> Ok, I'm fine with delaying this one more merge-window. However, to
> make things easier, could you pick up the two fbdev cleanups? These
> are:
> fbdev: efifb: add dev->remove() callback
> fbdev: vesafb: add dev->remove() callback
>
> They only add ->remove() callbacks which are never triggered currently
> except with my sysfb series. But I'd like to drop both to make the
> series smaller.
Yes, I can take them if they work fine without the rest of the patches.
I could also take all the patches up to patch #6 via fbdev tree. Some of
the patches are for arch x86, but they seem to be still about
framebuffers. But maybe that causes conflicts with x86 tree, then =).
Then again, maybe we should just go forward and let Linus handle the
conflict. I'm planning to send the "normal" fbdev changes and the
fbdev-reorg separately (just in case Linus doesn't like the reorg), and
that already causes conflicts, very similar to what this series causes.
So in any case Linus has to handle that conflict, or use a resolution
offered by me. So if fbdev changes and this series are merged in
relatively early phase, I can then send the reorg series a bit later and
offer a conflict resolution that solves the conflicts for both series.
That way this series doesn't get delayed needlessly in the case that
Linus rejects the reorg series.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
From: Tomi Valkeinen @ 2014-03-07 12:56 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, Philipp Zabel, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <53143796.2050309@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]
On 03/03/14 10:04, Tomi Valkeinen wrote:
> Hi Rob, Pawel, Mark, Ian, Kumar,
Ping,
Any hints on how to continue with this?
> On 28/02/14 18:56, Russell King - ARM Linux wrote:
>> On Fri, Feb 28, 2014 at 06:48:35PM +0200, Tomi Valkeinen wrote:
>>> This is totally unclear to me. How does it become a public standard?
>>> What's the forum for this?
>>
>> Me too. That's where I'd hope someone on devicetree-discuss will be
>> able to help us work out what's the right approach here. :)
>
> The story briefly so far: I've implemented DT support for OMAP display,
> and created bindings for various (non-OMAP) display components,
> including generic connector bindings for DVI, HDMI and analog-tv.
>
> Russell's point was that these connector bindings are very generic, i.e.
> they are not for any particular chip from a particular vendor, but for
> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
> shouldn't define such generic bindings without consulting the whole
> device-tree community (i.e including non-linux users).
>
> So the question is, is there such a community and a forum to bring up
> this kind of things? If yes, should we bring this up there? If yes, what
> kind of things in general should be brought into the attention of
> non-linux users?
>
> What I wonder here is that while a thing like DVI connector is, of
> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
> case still the same: we're defining global bindings for hardware that
> should work for everyone, not only Linux users?
>
> Tomi
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 00/11] SimpleDRM & Sysfb
From: David Herrmann @ 2014-03-07 13:05 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev@vger.kernel.org, Daniel Vetter, linux-kernel,
dri-devel@lists.freedesktop.org, Ingo Molnar
In-Reply-To: <5319BF40.70305@ti.com>
Hi
On Fri, Mar 7, 2014 at 1:44 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 06/03/14 14:16, David Herrmann wrote:
>> Hi Tomi
>>
>> On Mon, Mar 3, 2014 at 12:22 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> On 03/03/14 13:09, David Herrmann wrote:
>>>
>>>>> What do you think, would it be possible to keep the sysfb stuff in
>>>>> arch/x86, and still be able to do the rest of the stuff here? And then
>>>>> move the sysfs from arch/x86 to drivers/video later?
>>>>
>>>> I don't think there's any need for that. Linus does conflict
>>>> resolution all day long, so a short hint in Dave's pull-request (plus
>>>> an example merge) should be enough. Same is true for -next, I think.
>>>
>>> True, but, well, the conflict with this one is not a few lines. "git
>>> diff |wc -l" gives 2494 lines for the conflict. It's not really complex
>>> to resolve that one, though, as it's really about copying all the stuff
>>> into its new place.
>>>
>>> So I'm not sure if that makes Linus think "this is simple one, 30 secs
>>> and done" or "who the f*** sends me this crap" ;). Especially for two
>>> reasons:
>>>
>>> - The fb-reogranization is not very critical, and often clean-ups are
>>> not worth it (although I think this one is good one, of course).
>>> - Conflicting fbdev changes coming from another tree
>>>
>>>> And this is really just a mechanical thing, nothing hard to do. But of
>>>> course, it's your decision. However, keeping the code in x86 is the
>>>> wrong thing to do. As discussed with Ingo, the patch that extends
>>>
>>> Yes, I didn't mean keeping the code in x86 for good, but just for one
>>> kernel version to make merging easier.
>>>
>>>> x86/sysfb is only provided for easier backporting. The followup patch
>>>> immediately removes it again and adds proper video/sysfb. I'd dislike
>>>> splitting these just to avoid merge conflicts. I can also maintain a
>>>> merge-fixup branch in my tree, if anyone wants that.
>>>
>>> You can have a try at merging. If you think it's trivial, maybe it is
>>> and we can just let Linus handle it:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git
>>> work/fb-reorder
>>
>> Ok, I'm fine with delaying this one more merge-window. However, to
>> make things easier, could you pick up the two fbdev cleanups? These
>> are:
>> fbdev: efifb: add dev->remove() callback
>> fbdev: vesafb: add dev->remove() callback
>>
>> They only add ->remove() callbacks which are never triggered currently
>> except with my sysfb series. But I'd like to drop both to make the
>> series smaller.
>
> Yes, I can take them if they work fine without the rest of the patches.
>
> I could also take all the patches up to patch #6 via fbdev tree. Some of
> the patches are for arch x86, but they seem to be still about
> framebuffers. But maybe that causes conflicts with x86 tree, then =).
>
> Then again, maybe we should just go forward and let Linus handle the
> conflict. I'm planning to send the "normal" fbdev changes and the
> fbdev-reorg separately (just in case Linus doesn't like the reorg), and
> that already causes conflicts, very similar to what this series causes.
>
> So in any case Linus has to handle that conflict, or use a resolution
> offered by me. So if fbdev changes and this series are merged in
> relatively early phase, I can then send the reorg series a bit later and
> offer a conflict resolution that solves the conflicts for both series.
>
> That way this series doesn't get delayed needlessly in the case that
> Linus rejects the reorg series.
If you can take these two patches, that's fine. They're not strictly
needed by the series and I'd be happy to see them upstream. The other
sysfb patches should be merged together, so I don't think there's much
gain in applying them through fbdev.
The DRM tree is usually merged late, anyway, so I'll see whether we
will merge simpledrm through drm-next or not. If not, it'll be 3.16
then. If you can get the fbdev merge in early, that should be enough
for us to figure it out and provide a conflict-resolution. Btw., do
you want the generic sysfb-helper in drivers/video/ or
driver/video/fbdev? It's not limited to fbdev, so I'd put it in
drivers/video/.
Thanks
David
^ permalink raw reply
* Re: [PATCH 0/4] Cleanups and fix for video/pxa3xx-gcu
From: Tomi Valkeinen @ 2014-03-07 13:08 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1394035969-32420-1-git-send-email-zonque@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]
On 06/03/14 12:53, Daniel Mack wrote:
> On 03/06/2014 11:30 AM, Tomi Valkeinen wrote:
>> On 06/03/14 12:18, Daniel Mack wrote:
>
>>>> That's clearly not the right place for it, but I
>>>> think it's easier to move it along the other files, and later move it
>>>> back to drivers/video/.
>>>
>>> Maybe it might be worth adding a subdirectory for hardware accelerators?
>>> Because this is what the pxa3xx-gcu thing is all about really. And it's
>>> only a tiny transport layer that passed commands between the hardware
>>> block and a DirectFB userspace driver.
>>
>> Well, there's drivers/gpu/. It sounds like a good match, and by "sounds"
>> I mean the word "gpu" sounds like a good match. I'm not sure if other
>> people have opinions on what drivers/gpu/ should contain, though.
I have applied this series to fbdev tree for 3.15.
> Yes, you're right. Do you think we should do that in a 2nd step maybe,
> after 3.15?
Maybe. Then again, drivers/video is not so bad a location, after fbdev
stuff has been moved to drivers/video/fbdev/. drivers/gpu doesn't seem
to have a specific maintainer, but I guess that goes through drm maintainer.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 00/11] SimpleDRM & Sysfb
From: Tomi Valkeinen @ 2014-03-07 13:52 UTC (permalink / raw)
To: David Herrmann
Cc: dri-devel@lists.freedesktop.org, Ingo Molnar,
linux-fbdev@vger.kernel.org, Dave Airlie, Daniel Vetter,
linux-kernel, Tom Gundersen
In-Reply-To: <CANq1E4QXWYQE5DWOA7F39oHFd2ZnV5Ny4ykOw1=aJT+B_umy3Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 902 bytes --]
On 07/03/14 15:05, David Herrmann wrote:
> If you can take these two patches, that's fine. They're not strictly
> needed by the series and I'd be happy to see them upstream. The other
> sysfb patches should be merged together, so I don't think there's much
> gain in applying them through fbdev.
Ok, I've applied them to fbdev tree.
> The DRM tree is usually merged late, anyway, so I'll see whether we
> will merge simpledrm through drm-next or not. If not, it'll be 3.16
> then. If you can get the fbdev merge in early, that should be enough
> for us to figure it out and provide a conflict-resolution. Btw., do
> you want the generic sysfb-helper in drivers/video/ or
> driver/video/fbdev? It's not limited to fbdev, so I'd put it in
> drivers/video/.
With a quick glance, it doesn't seem to depend on fbdev in any way,
right? That makes me think drivers/video/.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 00/11] SimpleDRM & Sysfb
From: David Herrmann @ 2014-03-07 14:06 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev@vger.kernel.org, linux-kernel,
dri-devel@lists.freedesktop.org
In-Reply-To: <5319CF23.6090103@ti.com>
Hi Tomi
On Fri, Mar 7, 2014 at 2:52 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 07/03/14 15:05, David Herrmann wrote:
>
>> If you can take these two patches, that's fine. They're not strictly
>> needed by the series and I'd be happy to see them upstream. The other
>> sysfb patches should be merged together, so I don't think there's much
>> gain in applying them through fbdev.
>
> Ok, I've applied them to fbdev tree.
Thanks!
>> The DRM tree is usually merged late, anyway, so I'll see whether we
>> will merge simpledrm through drm-next or not. If not, it'll be 3.16
>> then. If you can get the fbdev merge in early, that should be enough
>> for us to figure it out and provide a conflict-resolution. Btw., do
>> you want the generic sysfb-helper in drivers/video/ or
>> driver/video/fbdev? It's not limited to fbdev, so I'd put it in
>> drivers/video/.
>
> With a quick glance, it doesn't seem to depend on fbdev in any way,
> right? That makes me think drivers/video/.
Right! I will keep them in drivers/video/ then.
Thanks
David
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Philipp Zabel @ 2014-03-07 14:17 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree@vger.kernel.org, Linux Fbdev development list,
Russell King - ARM Linux, DRI Development, Andrzej Hajda,
Geert Uytterhoeven, Laurent Pinchart,
linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth
In-Reply-To: <53183730.5060205@ti.com>
Hi,
Am Donnerstag, den 06.03.2014, 10:52 +0200 schrieb Tomi Valkeinen:
> On 06/03/14 10:39, Geert Uytterhoeven wrote:
> > On Wed, Mar 5, 2014 at 9:41 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >> On 28/02/14 18:23, Russell King - ARM Linux wrote:
> >>
> >>> That's rather a lot of compatible strings. Another possibility is:
> >>>
> >>> compatible = "dvi-connector";
> >>> analog;
> >>> digital;
> >>> single-link;
> >>> dual-link;
> >>
> >> I made the following changes compared to the posted version. I decided
> >> to leave the "single-link" out, as it's implied if "digital" is set.
> >>
> >> Tomi
> >>
> >> @@ -6,11 +6,16 @@ Required properties:
> >>
> >> Optional properties:
> >> - label: a symbolic name for the connector
> >> -- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> >> +- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> >> +- analog: the connector has DVI analog pins
> >> +- digital: the connector has DVI digital pins
> >> +- dual-link: the connector has pins for DVI dual-link
> >>
> >> Required nodes:
> >> - Video port for DVI input
> >>
> >> +Note: One (or both) of 'analog' or 'digital' must be set.
> >
> > So dual-link needs both "digital" and "dual-link"?
>
> Yes. It is extra, but it felt clearer to me to have 'digital' as a
> matching property for 'analog'.
>
> Alternatively we could have three options:
>
> analog;
> digital-single-link;
> digital-dual-link;
>
> My reasoning to the format I chose was basically that when a connector
> supports 'digital', it contains TMDS clock and TMDS data for link 1.
> Adding dual link to that adds only TMDS data for link 2, so the second
> data link is kind of an additional feature, marked with a flag.
>
> Not a very big argument, and I'm fine with other format suggestions.
I'd prefer the analog / digital / dual-link variant for aesthetic
reasons. But looking at other connector types, I wonder if this should
be generalized even more:
For HDMI/DVI (digital) single-link means one clock pair and 3 TMDS data
pairs, dual-link means one clock pair and 6 data pairs.
On LVDS connectors, there usually are one clock pair and three (18-bit)
or four (24-bit) LVDS data pairs, in dual channel configuration two
clock pairs and 6 or 8 data pairs are used.
For DisplayPort there is no separate clock pair, but 1 to 4 data pairs,
and MIPI DSI again has one clock pair and a one or more data pairs.
There are already optional endpoint configuration properties
'data-lanes' and 'clock-lanes' for MIPI CSI-2 defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
Could/should this be aligned with the same?
regards
Philipp
^ permalink raw reply
* [PATCH] video: atmel_lcdfb: ensure the hardware is initialized with the correct mode
From: Antoine Ténart @ 2014-03-07 16:20 UTC (permalink / raw)
To: linux-arm-kernel
If no driver takeover the atmel_lcdfb, the lcd won't be in a working state
since atmel_lcdfb_set_par() will never be called. Enabling a driver which does,
like fbcon, will call the function and put atmel_lcdfb in a working state.
Fixes: b985172b328a (video: atmel_lcdfb: add device tree suport)
Signed-off-by: Antoine Ténart <antoine.tenart@free-electrons.com>
Reported-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
drivers/video/atmel_lcdfb.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index cd96162..b74e5f5d 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -1298,6 +1298,12 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
goto unregister_irqs;
}
+ ret = atmel_lcdfb_set_par(info);
+ if (ret < 0) {
+ dev_err(dev, "set par failed: %d\n", ret);
+ goto unregister_irqs;
+ }
+
dev_set_drvdata(dev, info);
/*
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCHv3 00/41] OMAPDSS: DT support v3
From: Tony Lindgren @ 2014-03-07 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <531823C5.1020008@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140305 23:32]:
> Hi Tony,
>
> On 21/01/14 12:56, Tomi Valkeinen wrote:
> > Hi,
> >
> > Here's version 3 of the DSS DT series.
>
> Can you have a look at the arch/arm/ parts in the series and ack if
> they're ok, i.e, patches 1, 2, 32.
Patches 1, 2 & 32 look OK to me, so for those please feel free to add:
Acked-by: Tony Lindgren <tony@atomide.com>
There's a minor merge conflict in pdata-quirks.c, but that's trivial
so it should be OK for you to queue those along with the DSS patches.
> Then there are the .dts patches, 22-30, for which I haven't been able to
> get any acks. I'm not sure who I should get acks from for those, but I
> don't mind adding yours if you want to give it.
>
> The .dts patches have had minor changes compared to the ones posted
> here, according to the DT bindings review comments, but nothing much has
> changed.
These will cause unnecessary merge conflicts all over the place:
Auto-merging arch/arm/boot/dts/omap4.dtsi
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap4.dtsi
Auto-merging arch/arm/boot/dts/omap4-sdp.dts
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap4-sdp.dts
Auto-merging arch/arm/boot/dts/omap4-panda-common.dtsi
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap4-panda-common.dtsi
Auto-merging arch/arm/boot/dts/omap3.dtsi
Auto-merging arch/arm/boot/dts/omap3-n900.dts
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap3-n900.dts
Auto-merging arch/arm/boot/dts/omap3-igep0020.dts
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap3-igep0020.dts
Auto-merging arch/arm/boot/dts/omap3-beagle.dts
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap3-beagle.dts
Auto-merging arch/arm/boot/dts/omap3-beagle-xm.dts
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap3-beagle-xm.dts
How about do a pull request for just the .dts changes against current
omap-for-v3.15/dt branch ASAP for me so I can pull it in? That is assuming
that just the .dts changes alone won't break anything.
Then make sure your series works both ways and maybe do a follow up
patch that flips things over after the dependencies are merged.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH] video: atmel_lcdfb: ensure the hardware is initialized with the correct mode
From: Alexandre Belloni @ 2014-03-07 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1394209254-23797-1-git-send-email-antoine.tenart@free-electrons.com>
On 07/03/2014 at 17:20:54 +0100, Antoine Ténart wrote :
> If no driver takeover the atmel_lcdfb, the lcd won't be in a working state
> since atmel_lcdfb_set_par() will never be called. Enabling a driver which does,
> like fbcon, will call the function and put atmel_lcdfb in a working state.
>
> Fixes: b985172b328a (video: atmel_lcdfb: add device tree suport)
>
> Signed-off-by: Antoine Ténart <antoine.tenart@free-electrons.com>
> Reported-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
> drivers/video/atmel_lcdfb.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index cd96162..b74e5f5d 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -1298,6 +1298,12 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
> goto unregister_irqs;
> }
>
> + ret = atmel_lcdfb_set_par(info);
> + if (ret < 0) {
> + dev_err(dev, "set par failed: %d\n", ret);
> + goto unregister_irqs;
> + }
> +
> dev_set_drvdata(dev, info);
>
> /*
> --
> 1.8.3.2
>
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH] backlight: add new LP8860 backlight driver
From: Jingoo Han @ 2014-03-10 9:10 UTC (permalink / raw)
To: 'Daniel Jeong'
Cc: linux-fbdev, linux-kernel,
'Jean-Christophe Plagniol-Villard',
'Tomi Valkeinen', 'Bryan Wu', 'Lee Jones',
'Jingoo Han'
In-Reply-To: <1393838076-4559-1-git-send-email-gshark.jeong@gmail.com>
On Monday, March 03, 2014 6:15 PM, Daniel Jeong wrote:
>
(+CC Bryan Wu, Lee Jones)
Please add Bryan Wu, Lee Jones to CC list, when you send
patches for backlight.
> This patch adds LP8860 backlight device driver.
> LP8860 is a low EMI and High performance 4 channel LED Driver of TI.
> This device driver provide the way to control brightness and currnet
(+CC Bryan Wu, Lee Jones)
s/provide/provides
s/currnet/current
> of each channel and provide the way to write eeprom.
s/provide/provides
> To support dt structure, another patch file will be sent.
>
> Signed-off-by: Daniel Jeong <gshark.jeong@gmail.com>
> ---
'To support dt structure, another patch file will be sent.' is
NOT appropriate for the commit message. So, please move it as below.
Then, this message will not be included to the commit message, when
this patch will be merged to maintainer's tree.
Signed-off-by: Daniel Jeong <gshark.jeong@gmail.com>
---
To support dt structure, another patch file will be sent.
> drivers/video/backlight/Kconfig | 7 +
> drivers/video/backlight/Makefile | 1 +
> drivers/video/backlight/lp8860_bl.c | 528 +++++++++++++++++++++++++++++++
> include/linux/platform_data/lp8860_bl.h | 54 ++++
> 4 files changed, 590 insertions(+)
> create mode 100644 drivers/video/backlight/lp8860_bl.c
> create mode 100644 include/linux/platform_data/lp8860_bl.h
>
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 5a3eb2e..908048f 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -397,6 +397,13 @@ config BACKLIGHT_LP8788
> help
> This supports TI LP8788 backlight driver.
>
> +config BACKLIGHT_LP8860
> + tristate "Backlight Driver for LP8860"
> + depends on BACKLIGHT_CLASS_DEVICE && I2C
> + select REGMAP_I2C
> + help
> + This supports TI LP8860 Backlight Driver
> +
> config BACKLIGHT_OT200
> tristate "Backlight driver for ot200 visualisation device"
> depends on BACKLIGHT_CLASS_DEVICE && CS5535_MFGPT && GPIO_CS5535
> diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
> index bb82002..cbc5ac3 100644
> --- a/drivers/video/backlight/Makefile
> +++ b/drivers/video/backlight/Makefile
> @@ -42,6 +42,7 @@ obj-$(CONFIG_BACKLIGHT_LM3639) += lm3639_bl.o
> obj-$(CONFIG_BACKLIGHT_LOCOMO) += locomolcd.o
> obj-$(CONFIG_BACKLIGHT_LP855X) += lp855x_bl.o
> obj-$(CONFIG_BACKLIGHT_LP8788) += lp8788_bl.o
> +obj-$(CONFIG_BACKLIGHT_LP8860) += lp8860_bl.o
> obj-$(CONFIG_BACKLIGHT_LV5207LP) += lv5207lp.o
> obj-$(CONFIG_BACKLIGHT_MAX8925) += max8925_bl.o
> obj-$(CONFIG_BACKLIGHT_OMAP1) += omap1_bl.o
> diff --git a/drivers/video/backlight/lp8860_bl.c b/drivers/video/backlight/lp8860_bl.c
> new file mode 100644
> index 0000000..4712e84
> --- /dev/null
> +++ b/drivers/video/backlight/lp8860_bl.c
> @@ -0,0 +1,528 @@
> +/*
> +* Simple driver for Texas Instruments lp8860 Backlight driver chip
> +*
> +* Copyright (C) 2014 Texas Instruments
> +* Author: Daniel Jeong <gshark.jeong@gmail.com>
> +* Ldd Mlp <ldd-mlp@list.ti.com>
> +*
> +* This program is free software; you can redistribute it and/or modify
> +* it under the terms of the GNU General Public License version 2 as
> +* published by the Free Software Foundation.
> +*
> +*/
> +#include <linux/module.h>
Please move this header in alphabetical order.
> +#include <linux/backlight.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/i2c.h>
> +#include <linux/platform_data/lp8860_bl.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +#include <linux/uaccess.h>
> +
> +#define REG_CL0_BRT_H 0x00
> +#define REG_CL0_BRT_L 0x01
> +#define REG_CL0_I_H 0x02
> +#define REG_CL0_I_L 0x03
> +
> +#define REG_CL1_BRT_H 0x04
> +#define REG_CL1_BRT_L 0x05
> +#define REG_CL1_I 0x06
> +
> +#define REG_CL2_BRT_H 0x07
> +#define REG_CL2_BRT_L 0x08
> +#define REG_CL2_I 0x09
> +
> +#define REG_CL3_BRT_H 0x0a
> +#define REG_CL3_BRT_L 0x0b
> +#define REG_CL3_I 0x0c
> +
> +#define REG_CONF 0x0d
> +#define REG_STATUS 0x0e
> +#define REG_ID 0x12
> +
> +#define REG_ROM_CTRL 0x19
> +#define REG_ROM_UNLOCK 0x1a
> +#define REG_ROM_START 0x60
> +#define REG_ROM_END 0x78
> +
> +#define REG_EEPROM_START 0x60
> +#define REG_EEPROM_END 0x78
> +#define REG_MAX 0xFF
> +
> +struct lp8860_chip {
> + struct device *dev;
> + struct lp8860_platform_data *pdata;
> + struct backlight_device *bled[LP8860_LED_MAX];
> + struct regmap *regmap;
> +};
> +
> +/* brightness control */
> +static int lp8860_bled_update_status(struct backlight_device *bl,
> + enum lp8860_leds nsr)
> +{
> + int ret = -EINVAL;
> + struct lp8860_chip *pchip = bl_get_data(bl);
> +
> + if (pchip->pdata->mode)
> + return 0;
> +
> + if (bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
> + bl->props.brightness = 0;
> +
> + switch (nsr) {
> + case LP8860_LED0:
> + ret = regmap_write(pchip->regmap,
> + REG_CL0_BRT_H, bl->props.brightness >> 8);
> + ret |= regmap_write(pchip->regmap,
> + REG_CL0_BRT_L, bl->props.brightness & 0xff);
> + break;
> + case LP8860_LED1:
> + ret = regmap_write(pchip->regmap,
> + REG_CL1_BRT_H,
> + (bl->props.brightness >> 8) & 0x1f);
> + ret |> + regmap_write(pchip->regmap, REG_CL1_BRT_L,
> + bl->props.brightness & 0xff);
> + break;
> + case LP8860_LED2:
> + ret = regmap_write(pchip->regmap,
> + REG_CL2_BRT_H,
> + (bl->props.brightness >> 8) & 0x1f);
> + ret |> + regmap_write(pchip->regmap, REG_CL2_BRT_L,
> + bl->props.brightness & 0xff);
> + break;
> + case LP8860_LED3:
> + ret = regmap_write(pchip->regmap,
> + REG_CL3_BRT_H,
> + (bl->props.brightness >> 8) & 0x1f);
> + ret |> + regmap_write(pchip->regmap, REG_CL3_BRT_L,
> + bl->props.brightness & 0xff);
> + break;
> + default:
> + BUG();
> + }
> + if (ret < 0)
> + dev_err(pchip->dev, "fail : i2c access to register.\n");
> + else
> + ret = bl->props.brightness;
> +
> + return ret;
> +}
> +
> +static int lp8860_bled_get_brightness(struct backlight_device *bl,
> + enum lp8860_leds nsr)
> +{
> + struct lp8860_chip *pchip = bl_get_data(bl);
> + unsigned int rval_h, rval_l;
> + int ret = -EINVAL;
> +
> + switch (nsr) {
> + case LP8860_LED0:
> + ret = regmap_read(pchip->regmap, REG_CL0_BRT_H, &rval_h);
> + ret |= regmap_read(pchip->regmap, REG_CL0_BRT_L, &rval_l);
> + break;
> + case LP8860_LED1:
> + ret = regmap_read(pchip->regmap, REG_CL1_BRT_H, &rval_h);
> + ret |= regmap_read(pchip->regmap, REG_CL1_BRT_L, &rval_l);
> + break;
> + case LP8860_LED2:
> + ret = regmap_read(pchip->regmap, REG_CL2_BRT_H, &rval_h);
> + ret |= regmap_read(pchip->regmap, REG_CL2_BRT_L, &rval_l);
> + break;
> + case LP8860_LED3:
> + ret = regmap_read(pchip->regmap, REG_CL3_BRT_H, &rval_h);
> + ret |= regmap_read(pchip->regmap, REG_CL3_BRT_L, &rval_l);
> + break;
> + default:
> + BUG();
> + }
> + if (ret < 0) {
> + dev_err(pchip->dev, "fail : i2c access to register.\n");
> + return ret;
> + }
> + bl->props.brightness = (rval_h << 8) | rval_l;
> + return bl->props.brightness;
> +}
> +
> +static int lp8860_update_status_bled0(struct backlight_device *bl)
> +{
> + return lp8860_bled_update_status(bl, LP8860_LED0);
> +}
> +
> +static int lp8860_get_brightness_bled0(struct backlight_device *bl)
> +{
> + return lp8860_bled_get_brightness(bl, LP8860_LED0);
> +}
> +
> +static int lp8860_update_status_bled1(struct backlight_device *bl)
> +{
> + return lp8860_bled_update_status(bl, LP8860_LED1);
> +}
> +
> +static int lp8860_get_brightness_bled1(struct backlight_device *bl)
> +{
> + return lp8860_bled_get_brightness(bl, LP8860_LED1);
> +}
> +
> +static int lp8860_update_status_bled2(struct backlight_device *bl)
> +{
> + return lp8860_bled_update_status(bl, LP8860_LED2);
> +}
> +
> +static int lp8860_get_brightness_bled2(struct backlight_device *bl)
> +{
> + return lp8860_bled_get_brightness(bl, LP8860_LED2);
> +}
> +
> +static int lp8860_update_status_bled3(struct backlight_device *bl)
> +{
> + return lp8860_bled_update_status(bl, LP8860_LED3);
> +}
> +
> +static int lp8860_get_brightness_bled3(struct backlight_device *bl)
> +{
> + return lp8860_bled_get_brightness(bl, LP8860_LED3);
> +}
> +
> +#define lp8860_bled_ops(_id)\
> +{\
> + .options = BL_CORE_SUSPENDRESUME,\
> + .update_status = lp8860_update_status_bled##_id,\
> + .get_brightness = lp8860_get_brightness_bled##_id,\
> +}
> +
> +static const struct backlight_ops lp8860_bled_ops[LP8860_LED_MAX] = {
> + [LP8860_LED0] = lp8860_bled_ops(0),
> + [LP8860_LED1] = lp8860_bled_ops(1),
> + [LP8860_LED2] = lp8860_bled_ops(2),
> + [LP8860_LED3] = lp8860_bled_ops(3),
> +};
> +
> +/* current control */
> +static int lp8860_set_current(struct device *dev,
> + const char *buf, enum lp8860_leds nsr)
> +{
> + struct lp8860_chip *pchip = dev_get_drvdata(dev);
> + unsigned int ival;
> + ssize_t ret;
> +
> + ret = kstrtouint(buf, 10, &ival);
> + if (ret)
> + return ret;
> +
> + switch (nsr) {
> + case LP8860_LED0:
> + ival = min_t(unsigned int, ival, LP8860_LED0_BR_MAX);
> + ret = regmap_write(pchip->regmap, REG_CL0_I_H, ival >> 8);
> + ret |= regmap_write(pchip->regmap, REG_CL0_I_L, ival & 0xff);
> + break;
> + case LP8860_LED1:
> + ival = min_t(unsigned int, ival, LP8860_LED1_BR_MAX);
> + ret = regmap_write(pchip->regmap, REG_CL1_I, ival & 0xff);
> + break;
> + case LP8860_LED2:
> + ival = min_t(unsigned int, ival, LP8860_LED2_BR_MAX);
> + ret = regmap_write(pchip->regmap, REG_CL2_I, ival & 0xff);
> + break;
> + case LP8860_LED3:
> + ival = min_t(unsigned int, ival, LP8860_LED3_BR_MAX);
> + ret = regmap_write(pchip->regmap, REG_CL3_I, ival & 0xff);
> + break;
> + default:
> + BUG();
> + }
> + if (ret < 0)
> + dev_err(pchip->dev, "fail : i2c access error.\n");
> +
> + return ret;
> +}
> +
> +static ssize_t lp8860_current_store_bled0(struct device *dev,
> + struct device_attribute *devAttr,
> + const char *buf, size_t size)
> +{
> + int ret;
> +
> + ret = lp8860_set_current(dev, buf, LP8860_LED0);
> + if (ret < 0)
> + return ret;
> + return size;
> +}
> +
> +static ssize_t lp8860_current_store_bled1(struct device *dev,
> + struct device_attribute *devAttr,
> + const char *buf, size_t size)
> +{
> + int ret;
> +
> + ret = lp8860_set_current(dev, buf, LP8860_LED1);
> + if (ret < 0)
> + return ret;
> + return size;
> +}
> +
> +static ssize_t lp8860_current_store_bled2(struct device *dev,
> + struct device_attribute *devAttr,
> + const char *buf, size_t size)
> +{
> + int ret;
> +
> + ret = lp8860_set_current(dev, buf, LP8860_LED2);
> + if (ret < 0)
> + return ret;
> + return size;
> +}
> +
> +static ssize_t lp8860_current_store_bled3(struct device *dev,
> + struct device_attribute *devAttr,
> + const char *buf, size_t size)
> +{
> + int ret;
> +
> + ret = lp8860_set_current(dev, buf, LP8860_LED3);
> + if (ret < 0)
> + return ret;
> + return size;
> +}
> +
> +#define lp8860_attr(_name, _show, _store)\
> +{\
> + .attr = {\
> + .name = _name,\
> + .mode = S_IWUSR,\
> + },\
> + .show = _show,\
> + .store = _store,\
> +}
> +
> +static struct device_attribute lp8860_dev_attr[LP8860_LED_MAX] = {
> + [LP8860_LED0] = lp8860_attr("current", NULL,
> + lp8860_current_store_bled0),
> + [LP8860_LED1] = lp8860_attr("current", NULL,
> + lp8860_current_store_bled1),
> + [LP8860_LED2] = lp8860_attr("current", NULL,
> + lp8860_current_store_bled2),
> + [LP8860_LED3] = lp8860_attr("current", NULL,
> + lp8860_current_store_bled3),
> +};
> +
> +/*
> + * eeprom write and readback to check.
> + * eeprom register range is from 60h to 78h
> + * buffer value to write data [reg] [data]
> + * e.g) to change the register 0x60 value to 0xff
> + * buffer value should be 60 ff
> + */
> +static ssize_t lp8860_eeprom_store(struct device *dev,
> + struct device_attribute *devAttr,
> + const char *buf, size_t size)
> +{
> + struct lp8860_chip *pchip = dev_get_drvdata(dev);
> + unsigned int reg, data, rval;
> + char *tok;
> + int ret;
> +
> + /* register no. */
> + tok = strsep((char **)&buf, " ,\n");
> + if (tok = NULL)
> + goto err_input;
> + ret = kstrtouint(tok, 16, ®);
> + if (ret)
> + goto err_input;
> +
> + /* register value */
> + tok = strsep((char **)&buf, " ,\n");
> + if (tok = NULL)
> + goto err_input;
> + ret = kstrtouint(tok, 16, &data);
> + if (ret)
> + goto err_input;
> + /*
> + * EEPROM Programming sequence
> + * (program data permanently from registers to NVM)
> + * 1. Unlock EEPROM by writing
> + * the unlock codes to register 1Ah(08, BA, EF)
> + * 2. Write data to EEPROM registers (address 60h...78h)
> + * 3. Write EE_PROG to 1 in address 19h. (02h to address 19h)
> + * 4. Wait 100ms
If possible, please add the reason why 100ms is necessary.
100ms is very huge delay.
> + * 5. Write EE_PROG to 0 in address 19h. (00h to address 19h)
> + */
> + if (reg < REG_EEPROM_START || reg > REG_EEPROM_END || data > 0xff)
> + goto err_input;
> + ret = regmap_write(pchip->regmap, REG_ROM_UNLOCK, 0x08);
> + ret |= regmap_write(pchip->regmap, REG_ROM_UNLOCK, 0xba);
> + ret |= regmap_write(pchip->regmap, REG_ROM_UNLOCK, 0xef);
> + ret |= regmap_write(pchip->regmap, reg, data);
> + ret |= regmap_write(pchip->regmap, REG_ROM_CTRL, 0x02);
> + msleep(100);
> + ret |= regmap_write(pchip->regmap, REG_ROM_CTRL, 0x00);
> + if (ret < 0)
> + goto err_i2c;
> +
> + /* read back */
> + ret = regmap_write(pchip->regmap, REG_ROM_UNLOCK, 0x08);
> + ret |= regmap_write(pchip->regmap, REG_ROM_UNLOCK, 0xba);
> + ret |= regmap_write(pchip->regmap, REG_ROM_UNLOCK, 0xef);
> + ret |= regmap_write(pchip->regmap, REG_ROM_CTRL, 0x01);
> + msleep(100);
> + ret |= regmap_write(pchip->regmap, REG_ROM_CTRL, 0x00);
> + ret |= regmap_read(pchip->regmap, reg, &rval);
> + if (ret < 0)
> + goto err_i2c;
> + if (rval != data)
> + dev_err(pchip->dev, "fail : eeprom did not change.\n");
> +
> + return size;
> +
> +err_i2c:
> + dev_err(pchip->dev, "fail : i2c access error.\n");
> + return ret;
> +
> +err_input:
> + dev_err(pchip->dev, "fail : input fail.\n");
> + return -EINVAL;
> +}
> +
> +static DEVICE_ATTR(eeprom, S_IWUSR, NULL, lp8860_eeprom_store);
> +
> +/* backlight register and remove */
> +static char *lp8860_bled_name[LP8860_LED_MAX] = {
> + [LP8860_LED0] = "bled0",
> + [LP8860_LED1] = "bled1",
> + [LP8860_LED2] = "bled2",
> + [LP8860_LED3] = "bled3",
> +};
> +
> +static int lp8860_backlight_remove(struct lp8860_chip *pchip)
> +{
> + int icnt;
> +
> + device_remove_file(&(pchip->bled[0]->dev), &dev_attr_eeprom);
> + for (icnt = LP8860_LED0; icnt < LP8860_LED_MAX; icnt++) {
> + if (pchip->bled[icnt]) {
> + backlight_device_unregister(pchip->bled[icnt]);
> + device_remove_file(&(pchip->bled[icnt]->dev),
> + &lp8860_dev_attr[icnt]);
> + }
> + }
> + return 0;
> +}
> +
> +static int lp8860_backlight_registers(struct lp8860_chip *pchip)
> +{
> + struct backlight_properties props;
> + struct lp8860_platform_data *pdata = pchip->pdata;
> + int icnt, ret;
> +
> + props.type = BACKLIGHT_RAW;
> + for (icnt = LP8860_LED0; icnt < LP8860_LED_MAX; icnt++) {
> + props.max_brightness = pdata->max_brt[icnt];
> + pchip->bled[icnt] > + backlight_device_register(lp8860_bled_name[icnt],
devm_* functions will make the code simpler.
Thus, please use devm_backlight_device_register(), instead of
backlight_device_register().
> + pchip->dev, pchip,
> + &lp8860_bled_ops[icnt], &props);
> + if (IS_ERR(pchip->bled[icnt])) {
> + dev_err(pchip->dev, "fail : backlight register.\n");
> + ret = PTR_ERR(pchip->bled[icnt]);
> + goto err_out;
> + }
> +
> + ret = device_create_file(&(pchip->bled[icnt]->dev),
> + &lp8860_dev_attr[icnt]);
> + if (ret < 0) {
> + dev_err(pchip->dev, "fail : to add sysfs entries.\n");
> + goto err_out;
> + }
> + }
> + /* access eeprom */
> + ret = device_create_file(&(pchip->bled[LP8860_LED0]->dev),
> + &dev_attr_eeprom);
> + if (ret < 0) {
> + dev_err(pchip->dev, "fail : to add sysfs entries.\n");
> + goto err_out;
> + }
> + return 0;
> +
> +err_out:
> + lp8860_backlight_remove(pchip);
> + return ret;
> +}
> +
> +static const struct regmap_config lp8860_regmap = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = REG_MAX,
> +};
> +
> +static int lp8860_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct lp8860_chip *pchip;
> + struct lp8860_platform_data *pdata = dev_get_platdata(&client->dev);
> + int ret, icnt;
> +
> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
> + dev_err(&client->dev, "fail : i2c functionality check.\n");
> + return -EOPNOTSUPP;
> + }
> +
> + pchip = devm_kzalloc(&client->dev,
> + sizeof(struct lp8860_chip), GFP_KERNEL);
> + if (!pchip)
> + return -ENOMEM;
> + pchip->dev = &client->dev;
> +
> + pchip->regmap = devm_regmap_init_i2c(client, &lp8860_regmap);
> + if (IS_ERR(pchip->regmap)) {
> + ret = PTR_ERR(pchip->regmap);
> + dev_err(pchip->dev, "fail : allocate i2c register map.\n");
> + return ret;
> + }
> +
> + if (pdata = NULL) {
> + pdata = devm_kzalloc(pchip->dev,
> + sizeof(struct lp8860_platform_data),
> + GFP_KERNEL);
> + if (pdata = NULL)
> + return -ENOMEM;
> + pdata->max_brt[LP8860_LED0] = 65535;
> + for (icnt = LP8860_LED1; icnt < LP8860_LED_MAX; icnt++)
> + pdata->max_brt[icnt] = 8191;
> + pchip->pdata = pdata;
> + } else {
> + pchip->pdata = pdata;
> + }
> + i2c_set_clientdata(client, pchip);
> + ret = lp8860_backlight_registers(pchip);
> + return ret;
> +}
> +
> +static int lp8860_remove(struct i2c_client *client)
> +{
> + return lp8860_backlight_remove(i2c_get_clientdata(client));
> +}
> +
> +static const struct i2c_device_id lp8860_id[] = {
> + {LP8860_NAME, 0},
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(i2c, lp8860_id);
> +static struct i2c_driver lp8860_i2c_driver = {
> + .driver = {
> + .name = LP8860_NAME,
> + },
Fix the indent style as below.
+ },
> + .probe = lp8860_probe,
> + .remove = lp8860_remove,
> + .id_table = lp8860_id,
> +};
> +
> +module_i2c_driver(lp8860_i2c_driver);
> +
> +MODULE_DESCRIPTION("Texas Instruments LP8860 Backlight Driver");
> +MODULE_AUTHOR("Daniel Jeong <gshark.jeong@gmail.com>");
> +MODULE_AUTHOR("Ldd Mlp <ldd-mlp@list.ti.com>");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/platform_data/lp8860_bl.h b/include/linux/platform_data/lp8860_bl.h
> new file mode 100644
> index 0000000..61bd0f5
> --- /dev/null
> +++ b/include/linux/platform_data/lp8860_bl.h
> @@ -0,0 +1,54 @@
> +/*
> + * Simple driver for Texas Instruments LM3642 LED Flash driver chip
> + * Copyright (C) 2014 Texas Instruments
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#ifndef __LINUX_LP8860_H
> +#define __LINUX_LP8860_H
Prefix 'LINUX' looks redundant.
Please replace '__LINUX_LP8860_H' with '__LP8860_H'.
If the datasheet of 'lp8860' is not closed, please let us
know where the datasheet is. It would be helpful for reviewing
your patch.
Best regards,
Jingoo Han
> +
> +#define LP8860_NAME "lp8860"
> +#define LP8860_ADDR 0x2d
> +
> +#define LP8860_LED0_BR_MAX 65535
> +#define LP8860_LED1_BR_MAX 8191
> +#define LP8860_LED2_BR_MAX 8191
> +#define LP8860_LED3_BR_MAX 8191
> +
> +#define LP8860_LED0_I_MAX 4095
> +#define LP8860_LED1_I_MAX 255
> +#define LP8860_LED2_I_MAX 255
> +#define LP8860_LED3_I_MAX 255
> +
> +enum lp8860_leds {
> + LP8860_LED0 = 0,
> + LP8860_LED1,
> + LP8860_LED2,
> + LP8860_LED3,
> + LP8860_LED_MAX
> +};
> +
> +enum lp8860_ctrl_mode {
> + LP8860_CTRL_I2C = 0,
> + LP8860_CTRL_I2C_PWM,
> +};
> +
> +/* struct lp8860 platform data
> + * @mode : control mode
> + * @max_brt : maximum brightness.
> + * LED0 0 ~ 65535
> + * LED1 0 ~ 8191
> + * LED2 0 ~ 8191
> + * LED3 0 ~ 8191
> + */
> +struct lp8860_platform_data {
> +
> + enum lp8860_ctrl_mode mode;
> + int max_brt[LP8860_LED_MAX];
> +};
> +
> +#endif /* __LINUX_LP8860_H */
> --
> 1.7.9.5
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Tomi Valkeinen @ 2014-03-10 10:32 UTC (permalink / raw)
To: Philipp Zabel
Cc: devicetree@vger.kernel.org, Linux Fbdev development list,
Russell King - ARM Linux, Sascha Hauer, Tomasz Figa,
DRI Development, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Geert Uytterhoeven, Laurent Pinchart,
Daniel Vetter, linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth
In-Reply-To: <1394201859.16309.14.camel@paszta.hi.pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]
On 07/03/14 16:17, Philipp Zabel wrote:
> Hi,
>
> Am Donnerstag, den 06.03.2014, 10:52 +0200 schrieb Tomi Valkeinen:
>> analog;
>> digital-single-link;
>> digital-dual-link;
>>
>> My reasoning to the format I chose was basically that when a connector
>> supports 'digital', it contains TMDS clock and TMDS data for link 1.
>> Adding dual link to that adds only TMDS data for link 2, so the second
>> data link is kind of an additional feature, marked with a flag.
>>
>> Not a very big argument, and I'm fine with other format suggestions.
>
> I'd prefer the analog / digital / dual-link variant for aesthetic
> reasons. But looking at other connector types, I wonder if this should
> be generalized even more:
>
> For HDMI/DVI (digital) single-link means one clock pair and 3 TMDS data
> pairs, dual-link means one clock pair and 6 data pairs.
>
> On LVDS connectors, there usually are one clock pair and three (18-bit)
> or four (24-bit) LVDS data pairs, in dual channel configuration two
> clock pairs and 6 or 8 data pairs are used.
>
> For DisplayPort there is no separate clock pair, but 1 to 4 data pairs,
> and MIPI DSI again has one clock pair and a one or more data pairs.
>
> There are already optional endpoint configuration properties
> 'data-lanes' and 'clock-lanes' for MIPI CSI-2 defined in
> Documentation/devicetree/bindings/media/video-interfaces.txt.
> Could/should this be aligned with the same?
Hmm. Well, at least for HDMI and DP we anyway need the connector type,
which tells the form factor, and it also tells the TMDS details. So, we
could define the lanes in a common way, but we'd still need extra
information.
For MIPI DSI and (I believe) LVDS, we don't need connectors. Connectors,
as described in this binding, are meant for standard hotpluggable
connectors to which you can connect any device that has that same connector.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v5 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2014-03-10 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5319AF00.5030602@ti.com>
On Fri, 2014-03-07 at 11:35 +0000, Tomi Valkeinen wrote:
> > ... and this makes me try to get out of its way. In other words, I fully
> > agree with you, but I don't think this applies to this particular patch,
> > as I'm not even trying to represent the display pipeline. The (optional)
>
> Right, you are not, at the moment. My point was, if the driver is
> extended later to support pipelines, or common panel/encoder drivers,
> you (most likely) need to have similar bindings than the other people use.
No argument here.
> Note that the same DT bindings you add here should also work for the DRM
> driver in the future. So, in fact, the question is extended to: will the
> fbdev
No, I don't think so. It's a end of line for it, I believe. From my
personal point of view the main goal is to fill the last gap between DT
and non-DT support on one of the Versatile Express boards - CLCD works
fine when booted with ATAGs, doesn't work when booted with DT. It looks
bad.
> or drm driver support common panels/encoders?
I would hope so, yes. VE display pipeline is quite complex (more than I
would hope ;-) so to implement KMS in a proper way (with hotplugging,
bells and whistles) it will have to know more than now. But it's out of
scope for me.
Pawel
^ permalink raw reply
* Re: [PATCH v5 1/2] video: ARM CLCD: Add DT support
From: Tomi Valkeinen @ 2014-03-10 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1394453382.3853.6.camel@hornet>
[-- Attachment #1: Type: text/plain, Size: 824 bytes --]
On 10/03/14 14:09, Pawel Moll wrote:
>> Note that the same DT bindings you add here should also work for the DRM
>> driver in the future. So, in fact, the question is extended to: will the
>> fbdev
>
> No, I don't think so. It's a end of line for it, I believe. From my
> personal point of view the main goal is to fill the last gap between DT
> and non-DT support on one of the Versatile Express boards - CLCD works
> fine when booted with ATAGs, doesn't work when booted with DT. It looks
> bad.
The DT describes the hardware, and there should be only one description
of it, no matter what the used SW is. I see compatible = "arm,pl111" in
the dts. PL111 is the LCD controller, right? What will the DRM driver
use, then, if the "arm,pl111" DT data is designed to work only for the
fbdev?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCHv3 00/41] OMAPDSS: DT support v3
From: Tomi Valkeinen @ 2014-03-10 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140307164929.GC3789@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]
On 07/03/14 18:49, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140305 23:32]:
>> Hi Tony,
>>
>> On 21/01/14 12:56, Tomi Valkeinen wrote:
>>> Hi,
>>>
>>> Here's version 3 of the DSS DT series.
>>
>> Can you have a look at the arch/arm/ parts in the series and ack if
>> they're ok, i.e, patches 1, 2, 32.
>
> Patches 1, 2 & 32 look OK to me, so for those please feel free to add:
>
> Acked-by: Tony Lindgren <tony@atomide.com>
Thanks.
> How about do a pull request for just the .dts changes against current
> omap-for-v3.15/dt branch ASAP for me so I can pull it in? That is assuming
> that just the .dts changes alone won't break anything.
Unfortunately they do break. At least pinmuxing is moved from the global
definitions to be handled by the respective display drivers, and there
are some regulator_name hacks that the DT patches remove.
I think those changes could be removed from my patches, and then added
back later when everything else has been merged.
The bigger issue is that suddenly there's lots of discussion about the
display DT bindings. If those are not resolved very soon, I guess I have
no choice but to again skip the merge window for the DSS DT changes.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCHv3 00/41] OMAPDSS: DT support v3
From: Tony Lindgren @ 2014-03-10 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <531DBCA8.80507@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140310 06:26]:
> On 07/03/14 18:49, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140305 23:32]:
> >> Hi Tony,
> >>
> >> On 21/01/14 12:56, Tomi Valkeinen wrote:
> >>> Hi,
> >>>
> >>> Here's version 3 of the DSS DT series.
> >>
> >> Can you have a look at the arch/arm/ parts in the series and ack if
> >> they're ok, i.e, patches 1, 2, 32.
> >
> > Patches 1, 2 & 32 look OK to me, so for those please feel free to add:
> >
> > Acked-by: Tony Lindgren <tony@atomide.com>
>
> Thanks.
>
> > How about do a pull request for just the .dts changes against current
> > omap-for-v3.15/dt branch ASAP for me so I can pull it in? That is assuming
> > that just the .dts changes alone won't break anything.
>
> Unfortunately they do break. At least pinmuxing is moved from the global
> definitions to be handled by the respective display drivers, and there
> are some regulator_name hacks that the DT patches remove.
OK. Will that cause regressions for omap3 as that's still also booting
in legacy mode?
> I think those changes could be removed from my patches, and then added
> back later when everything else has been merged.
Or you could have a second branch that also merges in omap-for-v3.15/dt
branch that you can send later towards the merge window after the arm-soc
changes have been merged. If you want to do that, then feel free to add
my ack also for the .dts changes:
Acked-by: Tony Lindgren <tony@atomide.com>
If however those changes get postponed to v3.16, it's best that you'll
redo the branch as I'm sure we'll have other merge issues for v3.16.
> The bigger issue is that suddenly there's lots of discussion about the
> display DT bindings. If those are not resolved very soon, I guess I have
> no choice but to again skip the merge window for the DSS DT changes.
OK, some of these more bindings can take easily six months to reach
some kind of resolution. You may be able to use TI specific unstable
bindings meanwhile if that makese sense.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
From: Rob Herring @ 2014-03-10 16:05 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Russell King - ARM Linux,
Sascha Hauer, Tomasz Figa,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Inki Dae,
Andrzej Hajda, Rob Clark, Thierry Reding, Laurent Pinchart,
Philipp Zabel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sebastian Hesselbarth
In-Reply-To: <53143796.2050309-l0cyMroinI0@public.gmane.org>
On Mon, Mar 3, 2014 at 2:04 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi Rob, Pawel, Mark, Ian, Kumar,
>
> On 28/02/14 18:56, Russell King - ARM Linux wrote:
>> On Fri, Feb 28, 2014 at 06:48:35PM +0200, Tomi Valkeinen wrote:
>>> This is totally unclear to me. How does it become a public standard?
>>> What's the forum for this?
>>
>> Me too. That's where I'd hope someone on devicetree-discuss will be
>> able to help us work out what's the right approach here. :)
>
> The story briefly so far: I've implemented DT support for OMAP display,
> and created bindings for various (non-OMAP) display components,
> including generic connector bindings for DVI, HDMI and analog-tv.
>
> Russell's point was that these connector bindings are very generic, i.e.
> they are not for any particular chip from a particular vendor, but for
> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
> shouldn't define such generic bindings without consulting the whole
> device-tree community (i.e including non-linux users).
So re-work it to be generic and send it out. DT maintainers would
rarely disagree that something shouldn't be made generic.
> So the question is, is there such a community and a forum to bring up
> this kind of things? If yes, should we bring this up there? If yes, what
> kind of things in general should be brought into the attention of
> non-linux users?
devicetree list is just that. It is not just for Linux. There is the
newly created devicetree-spec@vger.kernel.org which is for more
core/common binding discussion.
>
> What I wonder here is that while a thing like DVI connector is, of
> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
> case still the same: we're defining global bindings for hardware that
> should work for everyone, not only Linux users?
Defining the connectors in DT is a useful thing although mainly when
you have multiple connectors of the same type. Labels for composite,
SVideo, VGA, DVI, HDMI seem less useful to me. Describing position or
printed label (like front vs. rear connections) seem more useful to
me.
Rob
^ permalink raw reply
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
From: Tomi Valkeinen @ 2014-03-10 16:40 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree@vger.kernel.org, linux-fbdev,
Russell King - ARM Linux, Pawel Moll, Ian Campbell, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Rob Herring, Thierry Reding, Laurent Pinchart, Philipp Zabel,
Kumar Gala, linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth
In-Reply-To: <CAL_JsqLppZHjND_LFMxscR0WCD4Ox7vF0fDbQFoYg=TENXxY8Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2900 bytes --]
Hi Rob,
On 10/03/14 18:05, Rob Herring wrote:
>> Russell's point was that these connector bindings are very generic, i.e.
>> they are not for any particular chip from a particular vendor, but for
>> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
>> shouldn't define such generic bindings without consulting the whole
>> device-tree community (i.e including non-linux users).
>
> So re-work it to be generic and send it out. DT maintainers would
> rarely disagree that something shouldn't be made generic.
They (in this series) are already designed to be generic.
I should perhaps re-word the question: we are concerned whether these
bindings are good for all the users, not just us, and whether there
already exists something that overlaps.
Afaik, there's nothing overlapping. And I don't see why they wouldn't be
good for all users (with the few minor modifications that have been
discussed in this thread). But, if I gathered right, Russell would like
some kind of ack from someone who might know better than us.
So is it enough to have posted these, and gotten acks from the people
involved, or should we get acks from DT maintainers also?
Is there a way to get the attention of, say, BSD people, or should we
just presume they'll follow the list?
>> So the question is, is there such a community and a forum to bring up
>> this kind of things? If yes, should we bring this up there? If yes, what
>> kind of things in general should be brought into the attention of
>> non-linux users?
>
> devicetree list is just that. It is not just for Linux. There is the
> newly created devicetree-spec@vger.kernel.org which is for more
> core/common binding discussion.
Ok.
>> What I wonder here is that while a thing like DVI connector is, of
>> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
>> case still the same: we're defining global bindings for hardware that
>> should work for everyone, not only Linux users?
>
> Defining the connectors in DT is a useful thing although mainly when
> you have multiple connectors of the same type. Labels for composite,
> SVideo, VGA, DVI, HDMI seem less useful to me. Describing position or
> printed label (like front vs. rear connections) seem more useful to
> me.
My point above was that it feels mentally easier to define bindings for
one particular IP block or chip, than defining bindings for a more
generic thing like "HDMI connector". But, in the end, I believe they
both should go through similar review, and there's no such difference.
As for the labels, they can be anything that makes sense for that
particular board. It can be "HDMI Front", if such makes sense, or
"HDMI-2" if the connector has such physical printed label. Or, say,
"Main LCD", "Secondary LCD". It's a free form text that is given to the
user.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
From: Rob Herring @ 2014-03-10 20:32 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Russell King - ARM Linux,
Sascha Hauer, Tomasz Figa,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Inki Dae,
Andrzej Hajda, Rob Clark, Thierry Reding, Laurent Pinchart,
Philipp Zabel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sebastian Hesselbarth
In-Reply-To: <531DEB1A.5090509-l0cyMroinI0@public.gmane.org>
On Mon, Mar 10, 2014 at 11:40 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi Rob,
>
> On 10/03/14 18:05, Rob Herring wrote:
>
>>> Russell's point was that these connector bindings are very generic, i.e.
>>> they are not for any particular chip from a particular vendor, but for
>>> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we
>>> shouldn't define such generic bindings without consulting the whole
>>> device-tree community (i.e including non-linux users).
>>
>> So re-work it to be generic and send it out. DT maintainers would
>> rarely disagree that something shouldn't be made generic.
>
> They (in this series) are already designed to be generic.
>
> I should perhaps re-word the question: we are concerned whether these
> bindings are good for all the users, not just us, and whether there
> already exists something that overlaps.
Given this is tied into the rest of video description with endpoints
and such, you really have to look at the whole picture to answer that
question. I'd guess Linux well ahead of other OSs in terms of dealing
with the plethora of video and graphics h/w. I'd be more concerned
that the bindings are good for all h/w rather than all OS's.
> Afaik, there's nothing overlapping. And I don't see why they wouldn't be
> good for all users (with the few minor modifications that have been
> discussed in this thread). But, if I gathered right, Russell would like
> some kind of ack from someone who might know better than us.
>
> So is it enough to have posted these, and gotten acks from the people
> involved, or should we get acks from DT maintainers also?
We really leave it up to the subsystem maintainers to decide, but for
new common/generic bindings it is a good idea to get DT maintainers
ack. I'll go thru the individual patches.
> Is there a way to get the attention of, say, BSD people, or should we
> just presume they'll follow the list?
devicetree-spec was created specifically to have a lower volume list
without a bunch of Linux driver patches which aren't relevant to
people from other OSs.
>>> So the question is, is there such a community and a forum to bring up
>>> this kind of things? If yes, should we bring this up there? If yes, what
>>> kind of things in general should be brought into the attention of
>>> non-linux users?
>>
>> devicetree list is just that. It is not just for Linux. There is the
>> newly created devicetree-spec@vger.kernel.org which is for more
>> core/common binding discussion.
>
> Ok.
>
>>> What I wonder here is that while a thing like DVI connector is, of
>>> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the
>>> case still the same: we're defining global bindings for hardware that
>>> should work for everyone, not only Linux users?
>>
>> Defining the connectors in DT is a useful thing although mainly when
>> you have multiple connectors of the same type. Labels for composite,
>> SVideo, VGA, DVI, HDMI seem less useful to me. Describing position or
>> printed label (like front vs. rear connections) seem more useful to
>> me.
>
> My point above was that it feels mentally easier to define bindings for
> one particular IP block or chip, than defining bindings for a more
> generic thing like "HDMI connector". But, in the end, I believe they
> both should go through similar review, and there's no such difference.
Unless you need to describe different types of HDMI connectors, I
don't see any issue with it being generic. I certainly don't see the
need for prepending with "linux," in this case.
Rob
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Rob Herring @ 2014-03-10 21:45 UTC (permalink / raw)
To: Philipp Zabel
Cc: Russell King - ARM Linux, Tomi Valkeinen,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Laurent Pinchart, Sascha Hauer, Sebastian Hesselbarth, Rob Clark,
Inki Dae, Andrzej Hajda, Tomasz Figa, Thierry Reding
In-Reply-To: <1393604717.3802.61.camel-+qGW7pzALmz7o/J7KWpOmN53zsg1cpMQ@public.gmane.org>
On Fri, Feb 28, 2014 at 10:25 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Am Freitag, den 28.02.2014, 15:59 +0000 schrieb Russell King - ARM
> Linux:
>> On Fri, Feb 28, 2014 at 02:20:10PM +0200, Tomi Valkeinen wrote:
>> > Add DT binding documentation for DVI Connector.
>> >
>> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> > Reviewed-by: Archit Taneja <archit@ti.com>
>> > ---
>> > .../devicetree/bindings/video/dvi-connector.txt | 26 ++++++++++++++++++++++
>> > 1 file changed, 26 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/video/dvi-connector.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/video/dvi-connector.txt b/Documentation/devicetree/bindings/video/dvi-connector.txt
>> > new file mode 100644
>> > index 000000000000..6a0aff866c78
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/video/dvi-connector.txt
>> > @@ -0,0 +1,26 @@
>> > +DVI Connector
>> > +=======
>> > +
>> > +Required properties:
>> > +- compatible: "dvi-connector"
>> > +
>> > +Optional properties:
>> > +- label: a symbolic name for the connector
>> > +- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
>> > +
>> > +Required nodes:
>> > +- Video port for DVI input
>> > +
>> > +Example
>> > +-------
>> > +
>> > +dvi0: connector@0 {
>> > + compatible = "dvi-connector";
>> > + label = "dvi";
>> > +
>> > + i2c-bus = <&i2c3>;
>> > +
>> > + dvi_connector_in: endpoint {
>> > + remote-endpoint = <&tfp410_out>;
>> > + };
>> > +};
>>
>> This looks far too simplistic. There are different classes of DVI
>> connector - there is:
>>
>> DVI A - analogue only
>> DVI D - digital only (single and dual link)
>> DVI I - both (single and dual digital link)
>>
>> DRM at least makes a distinction between these three classes, and this
>> disctinction is part of the user API. How would a display system know
>> which kind of DVI connector is wired up on the board from this DT
>> description?
>
> Maybe this could be inferred from the sources connected to it. For
> example a i.MX5 board with the SoC internal TV Encoder and an external
> SiI902x HDMI encoder connected to the same DVI I connector:
>
> ipu {
> port@2 {
> ipu_di0_disp0: endpoint {
> remote-endpoint = <&sii902x_in>;
> };
> };
> port@3 {
> ipu_di1_tve: endpoint {
> remote-endpoint = <&tve_in>;
> };
> };
> };
>
> &sii902x {
> compatible = "si,sii9022";
>
> port@0 {
> sii902x_in: endpoint {
> remote-endpoint = <&ipu_di0>;
> };
> };
> port@1 {
> sii902x_out: endpoint {
> remote-endpoint = <&dvi_d_in>;
> };
> };
> };
>
> &tve {
> compatible = "fsl,imx53-tve";
> port@0 {
> tve_in: endpoint {
> remote-endpoint = <&ipu_di1>;
> };
> };
> port@1 {
> tve_out: endpoint {
> remote-endpoint = <&dvi_a_in>;
> };
> };
> };
>
> dvi-connector {
> compatible = "dvi-connector";
> ddc-i2c-bus = <&i2c3>;
>
> port {
> dvi_d_in: endpoint@0 {
> remote-endpoint = <&sii902x_out>;
> };
> dvi_a_in: endpoint@1 {
> remote-endpoint = <&tve_out>;
> };
> };
> };
>
> It should be possible to let the connector know that those two endpoints
> are connected to a TMDS source and to a VGA source, respectively.
I like this proposal over the others. Although, would dual link be a
single endpoint or 2 endpoints? How would you differentiate that?
The port node seems a bit pointless.
Rob
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Tomi Valkeinen @ 2014-03-11 6:39 UTC (permalink / raw)
To: Rob Herring, Philipp Zabel
Cc: devicetree@vger.kernel.org, linux-fbdev, Russell King - ARM Linux,
Sascha Hauer, Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda,
Rob Clark, Thierry Reding, Laurent Pinchart,
linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth
In-Reply-To: <CAL_JsqJ00Zr1tMoyR1+qHUhsNoc6Kj6s+nTZTkNTwki9HFHq8g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]
On 10/03/14 23:45, Rob Herring wrote:
> I like this proposal over the others. Although, would dual link be a
I don't like inferring the information. With the above, you can't find
out that the DVI connector has digital and analog support before all the
drivers are loaded.
> single endpoint or 2 endpoints? How would you differentiate that?
Hmm, well endpoints for a single port are exclusive. So it's either a
single port and a single endpoint, or two ports and two endpoints. I
think dual link has to be single port & endpoint, as the TMDS links need
to be driven together as a single bus.
And dual-link is not really "two links". DVI dual-link means 1 clock
lane and 6 data lanes, compared to 1 clock lane and 3 data lanes for
single-link.
> The port node seems a bit pointless.
There's another thread discussing the ports and endpoints.
The port node represents, for example, the pins for the connection for
that device. And an endpoint-endpoint link represents wires between two
ports.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Tomi Valkeinen @ 2014-03-11 6:43 UTC (permalink / raw)
To: Philipp Zabel
Cc: devicetree, linux-fbdev, Russell King - ARM Linux, Sascha Hauer,
Tomasz Figa, dri-devel, Inki Dae, Andrzej Hajda, Rob Clark,
Thierry Reding, Laurent Pinchart, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <1393604717.3802.61.camel@paszta.hi.pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
On 28/02/14 18:25, Philipp Zabel wrote:
> dvi-connector {
> compatible = "dvi-connector";
> ddc-i2c-bus = <&i2c3>;
>
> port {
> dvi_d_in: endpoint@0 {
> remote-endpoint = <&sii902x_out>;
> };
> dvi_a_in: endpoint@1 {
> remote-endpoint = <&tve_out>;
> };
> };
> };
>
> It should be possible to let the connector know that those two endpoints
> are connected to a TMDS source and to a VGA source, respectively.
I have not worked with boards that would have the analog part, so just
wondering about the above.
The above would mean that either digital or analog is in use, but not
both. Was that the intention? From the connector's perspective, the
analog and digital pins are separate, and I think they can be used at
the same time. That kind of sounds like the analog and digital pins
should be represented as separate ports.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Geert Uytterhoeven @ 2014-03-11 8:00 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree@vger.kernel.org, Linux Fbdev development list,
Russell King - ARM Linux, DRI Development, Andrzej Hajda,
Rob Herring, Laurent Pinchart,
linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth
In-Reply-To: <531EAF8F.2040400@ti.com>
On Tue, Mar 11, 2014 at 7:39 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 10/03/14 23:45, Rob Herring wrote:
>> I like this proposal over the others. Although, would dual link be a
>
> I don't like inferring the information. With the above, you can't find
> out that the DVI connector has digital and analog support before all the
> drivers are loaded.
>
>> single endpoint or 2 endpoints? How would you differentiate that?
>
> Hmm, well endpoints for a single port are exclusive. So it's either a
> single port and a single endpoint, or two ports and two endpoints. I
> think dual link has to be single port & endpoint, as the TMDS links need
> to be driven together as a single bus.
>
> And dual-link is not really "two links". DVI dual-link means 1 clock
> lane and 6 data lanes, compared to 1 clock lane and 3 data lanes for
> single-link.
What about having a property for the number of data lanes?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox