* Re: [PATCH 1/1] video: exynos: Fix S6E8AX0 LCD driver build error
From: Tomi Valkeinen @ 2014-02-12 11:51 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1392198583-1828-1-git-send-email-sachin.kamat@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 376 bytes --]
On 12/02/14 13:44, Sachin Kamat wrote:
> Btw, is this [1] your current tree as it doesn't look updated since some time?
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git
>
Yes, but I haven't pushed any 3.15 or 3.14-fixes content yet. I've been
rather busy in the previous weeks. I'll try to get the current patches
pushed today.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] video: exynos: Fix S6E8AX0 LCD driver build error
From: Sachin Kamat @ 2014-02-12 11:52 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1392198583-1828-1-git-send-email-sachin.kamat@linaro.org>
On 12 February 2014 17:21, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 12/02/14 13:44, Sachin Kamat wrote:
>
>> Btw, is this [1] your current tree as it doesn't look updated since some time?
>>
>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git
>>
>
> Yes, but I haven't pushed any 3.15 or 3.14-fixes content yet. I've been
> rather busy in the previous weeks. I'll try to get the current patches
> pushed today.
Sounds good. Thanks.
--
With warm regards,
Sachin
^ permalink raw reply
* Re: [PATCH 1/1] video: exynos: Fix S6E8AX0 LCD driver build error
From: Sachin Kamat @ 2014-02-12 11:53 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1392198583-1828-1-git-send-email-sachin.kamat@linaro.org>
On 12 February 2014 16:56, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 12/02/14 11:55, Sachin Kamat wrote:
>> On 12 February 2014 15:19, Sachin Kamat <sachin.kamat@linaro.org> wrote:
>>> Enable S6E8AX0 LCD driver only if LCD_CLASS_DEVICE is a built-in driver.
>>> Else we get the following errors due to missing symbols:
>>> drivers/built-in.o: In function `s6e8ax0_probe':
>>> :(.text+0x51aec): undefined reference to `lcd_device_register'
>>> :(.text+0x51c44): undefined reference to `lcd_device_unregister'
>>>
>>> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
>>> ---
>>> drivers/video/exynos/Kconfig | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/video/exynos/Kconfig b/drivers/video/exynos/Kconfig
>>> index 976594d578a9..eb6f2b059821 100644
>>> --- a/drivers/video/exynos/Kconfig
>>> +++ b/drivers/video/exynos/Kconfig
>>> @@ -22,7 +22,8 @@ config EXYNOS_MIPI_DSI
>>>
>>> config EXYNOS_LCD_S6E8AX0
>>> bool "S6E8AX0 MIPI AMOLED LCD Driver"
>>> - depends on (EXYNOS_MIPI_DSI && BACKLIGHT_CLASS_DEVICE && LCD_CLASS_DEVICE)
>>> + depends on EXYNOS_MIPI_DSI && BACKLIGHT_CLASS_DEVICE
>>> + depends on (LCD_CLASS_DEVICE = y)
>>> default n
>>> help
>>> If you have an S6E8AX0 MIPI AMOLED LCD Panel, say Y to enable its
>>> --
>>> 1.7.9.5
>>>
>>
>> Sorry, please ignore this.
>>
>
> Hmm? Why is the fix not needed?
You said you have already applied this for 3.14-fixes. I accidentally
sent it again.
--
With warm regards,
Sachin
^ permalink raw reply
* Re: [PATCH 1/1] video: exynos: Fix S6E8AX0 LCD driver build error
From: Sachin Kamat @ 2014-02-12 11:56 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1392198583-1828-1-git-send-email-sachin.kamat@linaro.org>
On 12 February 2014 17:12, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 12/02/14 13:41, Sachin Kamat wrote:
>> On 12 February 2014 16:56, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> On 12/02/14 11:55, Sachin Kamat wrote:
>>>> On 12 February 2014 15:19, Sachin Kamat <sachin.kamat@linaro.org> wrote:
>>>>> Enable S6E8AX0 LCD driver only if LCD_CLASS_DEVICE is a built-in driver.
>>>>> Else we get the following errors due to missing symbols:
>>>>> drivers/built-in.o: In function `s6e8ax0_probe':
>>>>> :(.text+0x51aec): undefined reference to `lcd_device_register'
>>>>> :(.text+0x51c44): undefined reference to `lcd_device_unregister'
>>>>>
>>>>> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
>>>>> ---
>>>>> drivers/video/exynos/Kconfig | 3 ++-
>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/video/exynos/Kconfig b/drivers/video/exynos/Kconfig
>>>>> index 976594d578a9..eb6f2b059821 100644
>>>>> --- a/drivers/video/exynos/Kconfig
>>>>> +++ b/drivers/video/exynos/Kconfig
>>>>> @@ -22,7 +22,8 @@ config EXYNOS_MIPI_DSI
>>>>>
>>>>> config EXYNOS_LCD_S6E8AX0
>>>>> bool "S6E8AX0 MIPI AMOLED LCD Driver"
>>>>> - depends on (EXYNOS_MIPI_DSI && BACKLIGHT_CLASS_DEVICE && LCD_CLASS_DEVICE)
>>>>> + depends on EXYNOS_MIPI_DSI && BACKLIGHT_CLASS_DEVICE
>>>>> + depends on (LCD_CLASS_DEVICE = y)
>>>>> default n
>>>>> help
>>>>> If you have an S6E8AX0 MIPI AMOLED LCD Panel, say Y to enable its
>>>>> --
>>>>> 1.7.9.5
>>>>>
>>>>
>>>> Sorry, please ignore this.
>>>>
>>>
>>> Hmm? Why is the fix not needed?
>>
>> You said you have already applied this for 3.14-fixes. I accidentally
>> sent it again.
>
> Ah ok. I thought the patch itself can be ignored (removed from my branch).
Sorry for causing the confusion and noise.
Btw, is this [1] your current tree as it doesn't look updated since some time?
[1] git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git
--
With warm regards,
Sachin
^ permalink raw reply
* Fixing the kernels backlight API
From: Hans de Goede @ 2014-02-12 15:12 UTC (permalink / raw)
To: xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Jingoo Han,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Hi All,
Quick self intro: I've been a FOSS developer for 15+ years now and I've been
working for Red Hat for 5 years. Recently I've moved to the graphics team.
One of my first tasks in the graphics team is to make the xserver run without
root rights. I'm making good progress with this, having solved almost all issues
already.
The biggest remaining stumbling block is the backlight API, because opening the
sysfs files requires root rights. I'll very likely write a little helper for this
for now, but in the long run it would be good to have a better solution.
While discussion this in the graphics devroom at Fosdem, the general consensus
seemed to be that the current backlight API is in need of an overhaul anyways.
There are several issues with the current API:
-there is no reliable way to determine the relation between a backlight
control in sysfs and the display it controls the backlight off
-on many laptops we end up with multiple providers of backlight control
all battling over control of the same backlight controller through various
firmware interfaces
-and there is no way to do acl management on it because of sysfs usage
At Fosdem it was suggested to "simply" make the backlight a property of
the connector in drm/kms and let users control it that way. From an acl pov
this makes a ton of sense, if a user controls the other display-panel settings,
then he should be able to control the backlight too.
This also nicely solves the issue of userspace having to figure out which backlight
control to use for a certain output.
Last this makes it the kernels responsibility to figure out which firmware interface
(if any) to use and tie that to the connector, rather then just exporting all of
them, including conflicting ones, and just hoping that userspace will figure things out.
Note that wrt the last point, the kernel is the one which should have all the hardware
knowledge to do this properly, after all hardware abstraction is one of the tasks of
the kernel.
I realize moving this more into the kernel, and tying things into drm is in no means
easy, but it is about time we clean up this mess.
Note that although I'm kicking of this discussion, my focus within the graphics team is
mostly on input devices, so I'm hoping that someone else will pick things up once we've
a better idea of how we would like to solve this.
Regards,
Hans
^ permalink raw reply
* Re: Fixing the kernels backlight API
From: Dave Airlie @ 2014-02-12 20:14 UTC (permalink / raw)
To: Hans de Goede, Matthew Garrett
Cc: Linux Fbdev development list, Jingoo Han,
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org, dri-devel
In-Reply-To: <52FB8F45.9060006-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> The biggest remaining stumbling block is the backlight API, because opening the
> sysfs files requires root rights. I'll very likely write a little helper for this
> for now, but in the long run it would be good to have a better solution.
>
> While discussion this in the graphics devroom at Fosdem, the general consensus
> seemed to be that the current backlight API is in need of an overhaul anyways.
>
> There are several issues with the current API:
> -there is no reliable way to determine the relation between a backlight
> control in sysfs and the display it controls the backlight off
> -on many laptops we end up with multiple providers of backlight control
> all battling over control of the same backlight controller through various
> firmware interfaces
> -and there is no way to do acl management on it because of sysfs usage
>
> At Fosdem it was suggested to "simply" make the backlight a property of
> the connector in drm/kms and let users control it that way. From an acl pov
> this makes a ton of sense, if a user controls the other display-panel settings,
> then he should be able to control the backlight too.
>
> This also nicely solves the issue of userspace having to figure out which backlight
> control to use for a certain output.
>
> Last this makes it the kernels responsibility to figure out which firmware interface
> (if any) to use and tie that to the connector, rather then just exporting all of
> them, including conflicting ones, and just hoping that userspace will figure things out.
>
> Note that wrt the last point, the kernel is the one which should have all the hardware
> knowledge to do this properly, after all hardware abstraction is one of the tasks of
> the kernel.
>
> I realize moving this more into the kernel, and tying things into drm is in no means
> easy, but it is about time we clean up this mess.
>
> Note that although I'm kicking of this discussion, my focus within the graphics team is
> mostly on input devices, so I'm hoping that someone else will pick things up once we've
> a better idea of how we would like to solve this.
>
I hate to respond with yeah no, but yeah no,
http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-04
http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-05
read down that until you see me and tagr talking, read it a few times,
and the follow on chat with dvdhrm.
The biggest problem with leaving the kernel to pick the correct one,
is the kernel simply never knows which is the
correct one, and you also have to deal with a load of problems like
runtime module deps between very misc modules
or using some kind of notifier mechanism that will turn into a locking
nightmare.
I don't mean to dissuade you from trying to "fix" this, but actually
getting a solution upstream is going to require a lot of messing
around.
Talk to Matthew Garrett, if you haven't talked to him, then you
haven't talked to anyone who understands backlights.
Dave.
^ permalink raw reply
* Re: Fixing the kernels backlight API
From: Ville Syrjälä @ 2014-02-12 20:43 UTC (permalink / raw)
To: Dave Airlie
Cc: Linux Fbdev development list, Jingoo Han,
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org, dri-devel,
Hans de Goede
In-Reply-To: <CAPM=9tyYLuoTtW69-cPx-JSuar++D5WEtYRZr_-aP7uowZpVyA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Feb 13, 2014 at 06:14:04AM +1000, Dave Airlie wrote:
> >
> > The biggest remaining stumbling block is the backlight API, because opening the
> > sysfs files requires root rights. I'll very likely write a little helper for this
> > for now, but in the long run it would be good to have a better solution.
> >
> > While discussion this in the graphics devroom at Fosdem, the general consensus
> > seemed to be that the current backlight API is in need of an overhaul anyways.
> >
> > There are several issues with the current API:
> > -there is no reliable way to determine the relation between a backlight
> > control in sysfs and the display it controls the backlight off
> > -on many laptops we end up with multiple providers of backlight control
> > all battling over control of the same backlight controller through various
> > firmware interfaces
> > -and there is no way to do acl management on it because of sysfs usage
> >
> > At Fosdem it was suggested to "simply" make the backlight a property of
> > the connector in drm/kms and let users control it that way. From an acl pov
> > this makes a ton of sense, if a user controls the other display-panel settings,
> > then he should be able to control the backlight too.
> >
> > This also nicely solves the issue of userspace having to figure out which backlight
> > control to use for a certain output.
> >
> > Last this makes it the kernels responsibility to figure out which firmware interface
> > (if any) to use and tie that to the connector, rather then just exporting all of
> > them, including conflicting ones, and just hoping that userspace will figure things out.
> >
> > Note that wrt the last point, the kernel is the one which should have all the hardware
> > knowledge to do this properly, after all hardware abstraction is one of the tasks of
> > the kernel.
> >
> > I realize moving this more into the kernel, and tying things into drm is in no means
> > easy, but it is about time we clean up this mess.
> >
> > Note that although I'm kicking of this discussion, my focus within the graphics team is
> > mostly on input devices, so I'm hoping that someone else will pick things up once we've
> > a better idea of how we would like to solve this.
> >
>
> I hate to respond with yeah no, but yeah no,
>
> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-04
> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-05
>
> read down that until you see me and tagr talking, read it a few times,
> and the follow on chat with dvdhrm.
>
> The biggest problem with leaving the kernel to pick the correct one,
> is the kernel simply never knows which is the
> correct one,
That could be solved by still allowing userspace to change the
connection between the property and the actual backlight device.
With the prop approach + atomic modeset you could also do some
slightly fancier things like changing the backlight at the same
time as doing a modeset or just adjusting some other display
related properties.
> and you also have to deal with a load of problems like
> runtime module deps between very misc modules
> or using some kind of notifier mechanism that will turn into a locking
> nightmare.
This would still be an issue though.
I like the idea of the property, but I'm not volunteering to do any
of the work.
>
> I don't mean to dissuade you from trying to "fix" this, but actually
> getting a solution upstream is going to require a lot of messing
> around.
>
> Talk to Matthew Garrett, if you haven't talked to him, then you
> haven't talked to anyone who understands backlights.
>
> Dave.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
^ permalink raw reply
* [PATCH] fbdev: Make the switch from generic to native driver less alarming
From: Adam Jackson @ 2014-02-12 21:02 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1345223444-15852-1-git-send-email-ajax@redhat.com>
Calling this "conflicting" just makes people think there's a problem
when there's not.
Signed-off-by: Adam Jackson <ajax@redhat.com>
---
drivers/video/fbmem.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 7309ac7..b6d5008 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1596,8 +1596,7 @@ static int do_remove_conflicting_framebuffers(struct apertures_struct *a,
(primary && gen_aper && gen_aper->count &&
gen_aper->ranges[0].base = VGA_FB_PHYS)) {
- printk(KERN_INFO "fb: conflicting fb hw usage "
- "%s vs %s - removing generic driver\n",
+ printk(KERN_INFO "fb: switching to %s from %s\n",
name, registered_fb[i]->fix.id);
ret = do_unregister_framebuffer(registered_fb[i]);
if (ret)
--
1.8.5.3
^ permalink raw reply related
* Re: Fixing the kernels backlight API
From: David Herrmann @ 2014-02-12 22:26 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Linux Fbdev development list, Jingoo Han, xorg-devel@lists.x.org,
dri-devel, Hans de Goede
In-Reply-To: <20140212204311.GH3891@intel.com>
Hi
On Wed, Feb 12, 2014 at 9:43 PM, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
> On Thu, Feb 13, 2014 at 06:14:04AM +1000, Dave Airlie wrote:
>> >
>> > The biggest remaining stumbling block is the backlight API, because opening the
>> > sysfs files requires root rights. I'll very likely write a little helper for this
>> > for now, but in the long run it would be good to have a better solution.
>> >
>> > While discussion this in the graphics devroom at Fosdem, the general consensus
>> > seemed to be that the current backlight API is in need of an overhaul anyways.
>> >
>> > There are several issues with the current API:
>> > -there is no reliable way to determine the relation between a backlight
>> > control in sysfs and the display it controls the backlight off
>> > -on many laptops we end up with multiple providers of backlight control
>> > all battling over control of the same backlight controller through various
>> > firmware interfaces
>> > -and there is no way to do acl management on it because of sysfs usage
>> >
>> > At Fosdem it was suggested to "simply" make the backlight a property of
>> > the connector in drm/kms and let users control it that way. From an acl pov
>> > this makes a ton of sense, if a user controls the other display-panel settings,
>> > then he should be able to control the backlight too.
>> >
>> > This also nicely solves the issue of userspace having to figure out which backlight
>> > control to use for a certain output.
>> >
>> > Last this makes it the kernels responsibility to figure out which firmware interface
>> > (if any) to use and tie that to the connector, rather then just exporting all of
>> > them, including conflicting ones, and just hoping that userspace will figure things out.
>> >
>> > Note that wrt the last point, the kernel is the one which should have all the hardware
>> > knowledge to do this properly, after all hardware abstraction is one of the tasks of
>> > the kernel.
>> >
>> > I realize moving this more into the kernel, and tying things into drm is in no means
>> > easy, but it is about time we clean up this mess.
>> >
>> > Note that although I'm kicking of this discussion, my focus within the graphics team is
>> > mostly on input devices, so I'm hoping that someone else will pick things up once we've
>> > a better idea of how we would like to solve this.
>> >
>>
>> I hate to respond with yeah no, but yeah no,
>>
>> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-04
>> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-05
>>
>> read down that until you see me and tagr talking, read it a few times,
>> and the follow on chat with dvdhrm.
>>
>> The biggest problem with leaving the kernel to pick the correct one,
>> is the kernel simply never knows which is the
>> correct one,
>
> That could be solved by still allowing userspace to change the
> connection between the property and the actual backlight device.
>
> With the prop approach + atomic modeset you could also do some
> slightly fancier things like changing the backlight at the same
> time as doing a modeset or just adjusting some other display
> related properties.
The "attach" stuff actually sounds doable, but who decides which one
to attach? You still need some user-space script during device-plug
for that.
But to be honest, the simplest way would be a "backlightd"
bus-activatable daemon. SetBacklight() then takes a DRM-connector and
brightness-value, which the daemon looks up in /sys and sets.. This
has the advantage that we can do any fancy matching in user-space. We
can provide quirks (maybe even via udev-hwdb) and other helpers for
weird setups.
Cheers
David
^ permalink raw reply
* Re: Fixing the kernels backlight API
From: Alexander E. Patrakov @ 2014-02-13 6:37 UTC (permalink / raw)
To: David Herrmann, Ville Syrjälä
Cc: Linux Fbdev development list, Jingoo Han,
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org, dri-devel,
Hans de Goede, Dave Airlie
In-Reply-To: <CANq1E4R=UVo5YVPUrdRFeobAE-qU6e-+GHZ2VJwwaa8zEO6g3Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
13.02.2014 04:26, David Herrmann wrote:
> The "attach" stuff actually sounds doable, but who decides which one
> to attach? You still need some user-space script during device-plug
> for that.
> But to be honest, the simplest way would be a "backlightd"
> bus-activatable daemon. SetBacklight() then takes a DRM-connector and
> brightness-value, which the daemon looks up in /sys and sets.. This
> has the advantage that we can do any fancy matching in user-space. We
> can provide quirks (maybe even via udev-hwdb) and other helpers for
> weird setups.
What would be done with Samsung monitors (like an old SyncMaster 770P)
that have a DVI connection, no physical buttons and have to be
controlled via DDC-CI? Currently, ddccontrol works (via /dev/i2c-*), but
only from root. I would like this use case to be covered in such a way
that it could work both in Xorg and in Wayland, and, if possible,
without races related to i2c usage from the kernel and from userspace.
--
Alexander E. Patrakov
^ permalink raw reply
* [PATCH 0/9] OMAP DSS DT bindings documentation
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
Hi,
Here is DT binding documentation for OMAP Display Subsystem. I've sent these
earlier as part of the whole DSS DT series, but I'm now sending them separately
to get comments for them.
These patches are essentially the same as what I already sent earlier. The only
difference is that I added clock information for omap3 and omap4 platforms.
Tomi
Tomi Valkeinen (9):
Doc/DT: Add OMAP DSS DT Bindings
Doc/DT: Add DT binding documentation for Analog TV Connector
Doc/DT: Add DT binding documentation for DVI Connector
Doc/DT: Add DT binding documentation for HDMI Connector
Doc/DT: Add DT binding documentation for MIPI DPI Panel
Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
Doc/DT: Add DT binding documentation for Sony acx565akm panel
Doc/DT: Add DT binding documentation for TFP410 encoder
Doc/DT: Add DT binding documentation for tpd12s015 encoder
.../bindings/video/analog-tv-connector.txt | 23 +++
.../devicetree/bindings/video/dvi-connector.txt | 26 +++
.../devicetree/bindings/video/hdmi-connector.txt | 23 +++
.../devicetree/bindings/video/panel-dpi.txt | 43 +++++
.../devicetree/bindings/video/panel-dsi-cm.txt | 26 +++
.../devicetree/bindings/video/sony,acx565akm.txt | 28 +++
.../devicetree/bindings/video/ti,omap-dss.txt | 203 +++++++++++++++++++++
.../devicetree/bindings/video/ti,omap2-dss.txt | 54 ++++++
.../devicetree/bindings/video/ti,omap3-dss.txt | 83 +++++++++
.../devicetree/bindings/video/ti,omap4-dss.txt | 111 +++++++++++
.../devicetree/bindings/video/ti,tfp410.txt | 41 +++++
.../devicetree/bindings/video/ti,tpd12s015.txt | 44 +++++
.../devicetree/bindings/video/video-ports.txt | 22 +++
13 files changed, 727 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/analog-tv-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/dvi-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/hdmi-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/panel-dpi.txt
create mode 100644 Documentation/devicetree/bindings/video/panel-dsi-cm.txt
create mode 100644 Documentation/devicetree/bindings/video/sony,acx565akm.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap2-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap3-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap4-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,tfp410.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,tpd12s015.txt
create mode 100644 Documentation/devicetree/bindings/video/video-ports.txt
--
1.8.3.2
^ permalink raw reply
* [PATCH 1/9] Doc/DT: Add OMAP DSS DT Bindings
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add device tree bindings for OMAP Display Subsystem for the following
SoCs: OMAP2, OMAP3, OMAP4.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../devicetree/bindings/video/ti,omap-dss.txt | 203 +++++++++++++++++++++
.../devicetree/bindings/video/ti,omap2-dss.txt | 54 ++++++
.../devicetree/bindings/video/ti,omap3-dss.txt | 83 +++++++++
.../devicetree/bindings/video/ti,omap4-dss.txt | 111 +++++++++++
.../devicetree/bindings/video/video-ports.txt | 22 +++
5 files changed, 473 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,omap-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap2-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap3-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap4-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/video-ports.txt
diff --git a/Documentation/devicetree/bindings/video/ti,omap-dss.txt b/Documentation/devicetree/bindings/video/ti,omap-dss.txt
new file mode 100644
index 000000000000..928d3dc6f8dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap-dss.txt
@@ -0,0 +1,203 @@
+Texas Instruments OMAP Display Subsystem
+====================
+
+Generic Description
+-------------------
+
+This document is a generic description of the OMAP Display Subsystem bindings.
+Binding details for each OMAP SoC version are described in respective binding
+documentation.
+
+The OMAP Display Subsystem (DSS) hardware consists of DSS Core, DISPC module and
+a number of encoder modules. All DSS versions contain DSS Core and DISPC, but
+the encoder modules vary.
+
+The DSS Core is the parent of the other DSS modules, and manages clock routing,
+integration to the SoC, etc.
+
+DISPC is the display controller, which reads pixels from the memory and outputs
+a RGB pixel stream to encoders.
+
+The encoder modules encode the received RGB pixel stream to a video output like
+HDMI, MIPI DPI, etc.
+
+Video Ports
+-----------
+
+The DSS Core and the encoders have video port outputs. The structure of the
+video ports is described in Documentation/devicetree/bindings/video/video-
+ports.txt, and the properties for the ports and endpoints for each encoder are
+described in the SoC's DSS binding documentation.
+
+The video ports are used to describe the connections to external hardware, like
+panels or external encoders.
+
+Aliases
+-------
+
+The board dts file may define aliases for displays to assign "displayX" style
+name for each display. If no aliases are defined, a semi-random number is used
+for the display.
+
+Example
+-------
+
+A shortened example of the DSS description for OMAP4, with non-relevant parts
+removed, defined in omap4.dtsi:
+
+dss: dss@58000000 {
+ compatible = "ti,omap4-dss", "simple-bus";
+ reg = <0x58000000 0x80>;
+ status = "disabled";
+ ti,hwmods = "dss_core";
+ clocks = <&dss_dss_clk>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dispc@58001000 {
+ compatible = "ti,omap4-dispc";
+ reg = <0x58001000 0x1000>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ ti,hwmods = "dss_dispc";
+ clocks = <&dss_dss_clk>;
+ clock-names = "fck";
+ };
+
+ hdmi: encoder@58006000 {
+ compatible = "ti,omap4-hdmi";
+ reg = <0x58006000 0x200>,
+ <0x58006200 0x100>,
+ <0x58006300 0x100>,
+ <0x58006400 0x1000>;
+ reg-names = "wp", "pll", "phy", "core";
+ interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ ti,hwmods = "dss_hdmi";
+ clocks = <&dss_48mhz_clk>, <&dss_sys_clk>;
+ clock-names = "fck", "sys_clk";
+ };
+};
+
+A shortened example of the board description for OMAP4 Panda board, defined in
+omap4-panda.dts.
+
+The Panda board has a DVI and a HDMI connector, and the board contains a TFP410
+chip (MIPI DPI to DVI encoder) and a TPD12S015 chip (HDMI ESD protection & level
+shifter). The video pipelines for the connectors are formed as follows:
+
+DSS Core --(MIPI DPI)--> TFP410 --(DVI)--> DVI Connector
+OMAP HDMI --(HDMI)--> TPD12S015 --(HDMI)--> HDMI COnnector
+
+/ {
+ aliases {
+ display0 = &dvi0;
+ display1 = &hdmi0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = "ti,tfp410";
+ gpios = <&gpio1 0 GPIO_ACTIVE_LOW>; /* 0, power-down */
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tfp410_pins>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tfp410_out: endpoint@0 {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@0 {
+ compatible = "dvi-connector";
+ label = "dvi";
+
+ i2c-bus = <&i2c3>;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = <&tfp410_out>;
+ };
+ };
+
+ tpd12s015: encoder@1 {
+ compatible = "ti,tpd12s015";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tpd12s015_pins>;
+
+ gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */
+ <&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */
+ <&gpio2 31 GPIO_ACTIVE_HIGH>; /* 63, HPD */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tpd12s015_in: endpoint@0 {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tpd12s015_out: endpoint@0 {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
+
+ hdmi0: connector@1 {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&tpd12s015_out>;
+ };
+ };
+};
+
+&dss {
+ status = "ok";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss_dpi_pins>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <&tfp410_in>;
+ data-lines = <24>;
+ };
+};
+
+&hdmi {
+ status = "ok";
+ vdda-supply = <&vdac>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss_hdmi_pins>;
+
+ hdmi_out: endpoint {
+ remote-endpoint = <&tpd12s015_in>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/video/ti,omap2-dss.txt b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt
new file mode 100644
index 000000000000..fa8bb2ed1170
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt
@@ -0,0 +1,54 @@
+Texas Instruments OMAP2 Display Subsystem
+====================+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap2-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+
+Optional nodes:
+- Video port for DPI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap2-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap2-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap2-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+
+VENC Endpoint required properties:
+
+Required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
diff --git a/Documentation/devicetree/bindings/video/ti,omap3-dss.txt b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt
new file mode 100644
index 000000000000..0023fa4b1328
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt
@@ -0,0 +1,83 @@
+Texas Instruments OMAP3 Display Subsystem
+====================+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap3-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Optional nodes:
+- Video ports:
+ - Port 0: DPI output
+ - Port 1: SDI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+SDI Endpoint required properties:
+- datapairs: number of datapairs used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap3-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+- clocks: handle to fclk
+- clock-names: "fck"
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap3-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+- clocks: handles to fclk and iclk
+- clock-names: "fck", "ick"
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap3-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+- clocks: handle to fclk
+- clock-names: "fck"
+
+VENC Endpoint required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
+
+
+DSI
+---
+
+Required properties:
+- compatible: "ti,omap3-dsi"
+- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'
+- reg-names: "proto", "phy", "pll"
+- interrupts: the DSI interrupt line
+- ti,hwmods: "dss_dsi1"
+- vdd-supply: power supply for DSI
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+DSI Endpoint required properties:
+- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,
+ DATA1+, DATA1-, ...
diff --git a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
new file mode 100644
index 000000000000..f85d6fcfa705
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
@@ -0,0 +1,111 @@
+Texas Instruments OMAP4 Display Subsystem
+====================+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap4-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Required nodes:
+- DISPC
+
+Optional nodes:
+- DSS Submodules: RFBI, VENC, DSI, HDMI
+- Video port for DPI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap4-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+- clocks: handle to fclk
+- clock-names: "fck"
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap4-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+- clocks: handles to fclk and iclk
+- clock-names: "fck", "ick"
+
+Optional nodes:
+- Video port for RFBI output
+- RFBI controlled peripherals
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap4-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Optional nodes:
+- Video port for VENC output
+
+VENC Endpoint required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
+
+
+DSI
+---
+
+Required properties:
+- compatible: "ti,omap4-dsi"
+- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'
+- reg-names: "proto", "phy", "pll"
+- interrupts: the DSI interrupt line
+- ti,hwmods: "dss_dsi1" or "dss_dsi2"
+- vdd-supply: power supply for DSI
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+Optional nodes:
+- Video port for DSI output
+- DSI controlled peripherals
+
+DSI Endpoint required properties:
+- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,
+ DATA1+, DATA1-, ...
+
+
+HDMI
+----
+
+Required properties:
+- compatible: "ti,omap4-hdmi"
+- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy',
+ 'core'
+- reg-names: "wp", "pll", "phy", "core"
+- interrupts: the HDMI interrupt line
+- ti,hwmods: "dss_hdmi"
+- vdda-supply: vdda power supply
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+Optional nodes:
+- Video port for HDMI output
diff --git a/Documentation/devicetree/bindings/video/video-ports.txt b/Documentation/devicetree/bindings/video/video-ports.txt
new file mode 100644
index 000000000000..dad4c436caae
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/video-ports.txt
@@ -0,0 +1,22 @@
+Video Ports
+=====+
+The video port bindings used for display devices is a superset of the v4l2 video
+ports described here:
+
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+The only difference is a more compact way to describe devices with only one
+endpoint. In cases like that, the 'ports' and 'port' nodes are not needed. For
+example, a DPI panel with a single input endpoint:
+
+lcd0: display@0 {
+ compatible = "samsung,lte430wq-f0c", "panel-dpi";
+
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+};
+
+The rest of the bindings are the same as in v4l2 video port bindings and not
+described here.
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/9] Doc/DT: Add DT binding documentation for Analog TV Connector
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for Analog TV Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../bindings/video/analog-tv-connector.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/analog-tv-connector.txt
diff --git a/Documentation/devicetree/bindings/video/analog-tv-connector.txt b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
new file mode 100644
index 000000000000..d6be373d8705
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
@@ -0,0 +1,23 @@
+Analog TV Connector
+=========+
+Required properties:
+- compatible: "composite-connector" or "svideo-connector"
+
+Optional properties:
+- label: a symbolic name for the connector
+
+Required nodes:
+- Video port for TV input
+
+Example
+-------
+
+tv: connector {
+ compatible = "composite-connector";
+ label = "tv";
+
+ tv_connector_in: endpoint {
+ remote-endpoint = <&venc_out>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for DVI Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@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>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for HDMI Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../devicetree/bindings/video/hdmi-connector.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/hdmi-connector.txt
diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt b/Documentation/devicetree/bindings/video/hdmi-connector.txt
new file mode 100644
index 000000000000..5d25f6a432bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt
@@ -0,0 +1,23 @@
+HDMI Connector
+=======
+
+Required properties:
+- compatible: "hdmi-connector"
+
+Optional properties:
+- label: a symbolic name for the connector
+
+Required nodes:
+- Video port for HDMI input
+
+Example
+-------
+
+hdmi0: connector@1 {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&tpd12s015_out>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for MIPI DPI Panel.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../devicetree/bindings/video/panel-dpi.txt | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/panel-dpi.txt
diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt b/Documentation/devicetree/bindings/video/panel-dpi.txt
new file mode 100644
index 000000000000..72636c6f1c67
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/panel-dpi.txt
@@ -0,0 +1,43 @@
+Generic MIPI DPI Panel
+===========
+
+Required properties:
+- compatible: "panel-dpi"
+
+Optional properties:
+- label: a symbolic name for the panel
+- gpios: panel enable gpio and backlight enable gpio
+
+Required nodes:
+- "panel-timing" containing video timings
+ (Documentation/devicetree/bindings/video/display-timing.txt)
+- Video port for DPI input
+
+Example
+-------
+
+lcd0: display@0 {
+ compatible = "samsung,lte430wq-f0c", "panel-dpi";
+ label = "lcd";
+
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+
+ panel-timing {
+ clock-frequency = <9200000>;
+ hactive = <480>;
+ vactive = <272>;
+ hfront-porch = <8>;
+ hback-porch = <4>;
+ hsync-len = <41>;
+ vback-porch = <2>;
+ vfront-porch = <4>;
+ vsync-len = <10>;
+
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for MIPI DSI Command Mode Panel.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../devicetree/bindings/video/panel-dsi-cm.txt | 26 ++++++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/panel-dsi-cm.txt
diff --git a/Documentation/devicetree/bindings/video/panel-dsi-cm.txt b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt
new file mode 100644
index 000000000000..73f422556d4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt
@@ -0,0 +1,26 @@
+Generic MIPI DSI Command Mode Panel
+=================+
+Required properties:
+- compatible: "panel-dsi-cm"
+
+Optional properties:
+- label: a symbolic name for the panel
+- gpios: panel reset gpio and TE gpio
+
+Required nodes:
+- Video port for DSI input
+
+Example
+-------
+
+lcd0: display {
+ compatible = "tpo,taal", "panel-dsi-cm";
+ label = "lcd0";
+
+ gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* 102, reset */
+
+ lcd0_in: endpoint {
+ remote-endpoint = <&dsi1_out_ep>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 7/9] Doc/DT: Add DT binding documentation for Sony acx565akm panel
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for Sony acx565akm panel
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Sebastian Reichel <sre@debian.org>
---
.../devicetree/bindings/video/sony,acx565akm.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/sony,acx565akm.txt
diff --git a/Documentation/devicetree/bindings/video/sony,acx565akm.txt b/Documentation/devicetree/bindings/video/sony,acx565akm.txt
new file mode 100644
index 000000000000..cd9cfdf7e3fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/sony,acx565akm.txt
@@ -0,0 +1,28 @@
+Sony ACX565AKM SDI Panel
+============
+
+Required properties:
+- compatible: "sony,acx565akm"
+
+Optional properties:
+- label: a symbolic name for the panel
+- gpios: panel reset gpio
+
+Required nodes:
+- Video port for SDI input
+
+Example
+-------
+
+acx565akm@2 {
+ compatible = "sony,acx565akm";
+ spi-max-frequency = <6000000>;
+ reg = <2>;
+
+ label = "lcd";
+ gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* 90 */
+
+ lcd_in: endpoint {
+ remote-endpoint = <&sdi_out>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 8/9] Doc/DT: Add DT binding documentation for TFP410 encoder
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for TFP410 encoder
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../devicetree/bindings/video/ti,tfp410.txt | 41 ++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,tfp410.txt
diff --git a/Documentation/devicetree/bindings/video/ti,tfp410.txt b/Documentation/devicetree/bindings/video/ti,tfp410.txt
new file mode 100644
index 000000000000..6a5a04627584
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,tfp410.txt
@@ -0,0 +1,41 @@
+TFP410 DPI to DVI encoder
+============+
+Required properties:
+- compatible: "ti,tfp410"
+
+Optional properties:
+- gpios: power-down gpio
+
+Required nodes:
+- Video port 0 for DPI input
+- Video port 1 for DVI output
+
+Example
+-------
+
+tfp410: encoder@0 {
+ compatible = "ti,tfp410";
+ gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tfp410_out: endpoint@0 {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 9/9] Doc/DT: Add DT binding documentation for tpd12s015 encoder
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for tpd12s015 encoder
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../devicetree/bindings/video/ti,tpd12s015.txt | 44 ++++++++++++++++++++++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,tpd12s015.txt
diff --git a/Documentation/devicetree/bindings/video/ti,tpd12s015.txt b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt
new file mode 100644
index 000000000000..26e6d32e3f20
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt
@@ -0,0 +1,44 @@
+TPD12S015 HDMI level shifter and ESD protection chip
+==========================
+
+Required properties:
+- compatible: "ti,tpd12s015"
+
+Optional properties:
+- gpios: CT CP HPD, LS OE and HPD gpios
+
+Required nodes:
+- Video port 0 for HDMI input
+- Video port 1 for HDMI output
+
+Example
+-------
+
+tpd12s015: encoder@1 {
+ compatible = "ti,tpd12s015";
+
+ gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */
+ <&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */
+ <&gpio2 31 GPIO_ACTIVE_HIGH>; /* 63, HPD */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tpd12s015_in: endpoint@0 {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tpd12s015_out: endpoint@0 {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* Re: Fixing the kernels backlight API
From: Hans de Goede @ 2014-02-13 13:41 UTC (permalink / raw)
To: Dave Airlie, Matthew Garrett
Cc: Linux Fbdev development list, Jingoo Han,
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org, dri-devel
In-Reply-To: <CAPM=9tyYLuoTtW69-cPx-JSuar++D5WEtYRZr_-aP7uowZpVyA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On 02/12/2014 09:14 PM, Dave Airlie wrote:
>>
>> The biggest remaining stumbling block is the backlight API, because opening the
>> sysfs files requires root rights. I'll very likely write a little helper for this
>> for now, but in the long run it would be good to have a better solution.
>>
>> While discussion this in the graphics devroom at Fosdem, the general consensus
>> seemed to be that the current backlight API is in need of an overhaul anyways.
>>
>> There are several issues with the current API:
>> -there is no reliable way to determine the relation between a backlight
>> control in sysfs and the display it controls the backlight off
>> -on many laptops we end up with multiple providers of backlight control
>> all battling over control of the same backlight controller through various
>> firmware interfaces
>> -and there is no way to do acl management on it because of sysfs usage
>>
>> At Fosdem it was suggested to "simply" make the backlight a property of
>> the connector in drm/kms and let users control it that way. From an acl pov
>> this makes a ton of sense, if a user controls the other display-panel settings,
>> then he should be able to control the backlight too.
>>
>> This also nicely solves the issue of userspace having to figure out which backlight
>> control to use for a certain output.
>>
>> Last this makes it the kernels responsibility to figure out which firmware interface
>> (if any) to use and tie that to the connector, rather then just exporting all of
>> them, including conflicting ones, and just hoping that userspace will figure things out.
>>
>> Note that wrt the last point, the kernel is the one which should have all the hardware
>> knowledge to do this properly, after all hardware abstraction is one of the tasks of
>> the kernel.
>>
>> I realize moving this more into the kernel, and tying things into drm is in no means
>> easy, but it is about time we clean up this mess.
>>
>> Note that although I'm kicking of this discussion, my focus within the graphics team is
>> mostly on input devices, so I'm hoping that someone else will pick things up once we've
>> a better idea of how we would like to solve this.
>>
>
> I hate to respond with yeah no, but yeah no,
>
> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-04
> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-05
>
> read down that until you see me and tagr talking, read it a few times,
> and the follow on chat with dvdhrm.
I think I'm going to save myself some time and just believe you, esp.
since you ...
>
> The biggest problem with leaving the kernel to pick the correct one,
> is the kernel simply never knows which is the
> correct one, and you also have to deal with a load of problems like
> runtime module deps between very misc modules
> or using some kind of notifier mechanism that will turn into a locking
> nightmare.
>
> I don't mean to dissuade you from trying to "fix" this, but actually
> getting a solution upstream is going to require a lot of messing
> around.
>
> Talk to Matthew Garrett, if you haven't talked to him, then you
> haven't talked to anyone who understands backlights.
Also bring up Matthew Garrett, who seems to have a knack for working on things which
involve inflicting a certain amount of pain onto the developer working on them.
I still believe we need to do better, but maybe that better needs to be done
in userspace rather then in the kernel.
More about that further down in this thread.
Regards,
Hans
^ permalink raw reply
* Re: Fixing the kernels backlight API
From: Hans de Goede @ 2014-02-13 13:49 UTC (permalink / raw)
To: David Herrmann, Ville Syrjälä
Cc: xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org,
Linux Fbdev development list, Jingoo Han, Dave Airlie, dri-devel
In-Reply-To: <CANq1E4R=UVo5YVPUrdRFeobAE-qU6e-+GHZ2VJwwaa8zEO6g3Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On 02/12/2014 11:26 PM, David Herrmann wrote:
> Hi
>
> On Wed, Feb 12, 2014 at 9:43 PM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
>> On Thu, Feb 13, 2014 at 06:14:04AM +1000, Dave Airlie wrote:
>>>>
>>>> The biggest remaining stumbling block is the backlight API, because opening the
>>>> sysfs files requires root rights. I'll very likely write a little helper for this
>>>> for now, but in the long run it would be good to have a better solution.
>>>>
>>>> While discussion this in the graphics devroom at Fosdem, the general consensus
>>>> seemed to be that the current backlight API is in need of an overhaul anyways.
>>>>
>>>> There are several issues with the current API:
>>>> -there is no reliable way to determine the relation between a backlight
>>>> control in sysfs and the display it controls the backlight off
>>>> -on many laptops we end up with multiple providers of backlight control
>>>> all battling over control of the same backlight controller through various
>>>> firmware interfaces
>>>> -and there is no way to do acl management on it because of sysfs usage
>>>>
>>>> At Fosdem it was suggested to "simply" make the backlight a property of
>>>> the connector in drm/kms and let users control it that way. From an acl pov
>>>> this makes a ton of sense, if a user controls the other display-panel settings,
>>>> then he should be able to control the backlight too.
>>>>
>>>> This also nicely solves the issue of userspace having to figure out which backlight
>>>> control to use for a certain output.
>>>>
>>>> Last this makes it the kernels responsibility to figure out which firmware interface
>>>> (if any) to use and tie that to the connector, rather then just exporting all of
>>>> them, including conflicting ones, and just hoping that userspace will figure things out.
>>>>
>>>> Note that wrt the last point, the kernel is the one which should have all the hardware
>>>> knowledge to do this properly, after all hardware abstraction is one of the tasks of
>>>> the kernel.
>>>>
>>>> I realize moving this more into the kernel, and tying things into drm is in no means
>>>> easy, but it is about time we clean up this mess.
>>>>
>>>> Note that although I'm kicking of this discussion, my focus within the graphics team is
>>>> mostly on input devices, so I'm hoping that someone else will pick things up once we've
>>>> a better idea of how we would like to solve this.
>>>>
>>>
>>> I hate to respond with yeah no, but yeah no,
>>>
>>> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-04
>>> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-05
>>>
>>> read down that until you see me and tagr talking, read it a few times,
>>> and the follow on chat with dvdhrm.
>>>
>>> The biggest problem with leaving the kernel to pick the correct one,
>>> is the kernel simply never knows which is the
>>> correct one,
>>
>> That could be solved by still allowing userspace to change the
>> connection between the property and the actual backlight device.
>>
>> With the prop approach + atomic modeset you could also do some
>> slightly fancier things like changing the backlight at the same
>> time as doing a modeset or just adjusting some other display
>> related properties.
>
> The "attach" stuff actually sounds doable, but who decides which one
> to attach? You still need some user-space script during device-plug
> for that.
> But to be honest, the simplest way would be a "backlightd"
> bus-activatable daemon. SetBacklight() then takes a DRM-connector and
> brightness-value, which the daemon looks up in /sys and sets.. This
> has the advantage that we can do any fancy matching in user-space. We
> can provide quirks (maybe even via udev-hwdb) and other helpers for
> weird setups.
This sounds like a good idea, note that at-least gnome already has
something similar in the form of the (one-shot, not daemon)
gsd-backlight-helper which also has some code to try and figure out
what is the right backlight class device to use.
Interestingly enough the xf86-video-intel driver does this on its own
using somewhat more complex logic to find the right backlight class
device to use, and then exporting this as a property on the connector
in Xrandr.
So a first rough idea of how this would work / a plan would be:
1) We have a bus-activated backlightd running as root
2) This can be asked for backlight properties on a certain drm/kms
connector
3) If there actually is a backlight for the connector, it can also be
used to change the backlight brightness
4) The xserver will get some helper functions which drivers can call
to create a backlight property on xrandr connectors
5) In the long run gsd-backlight-helper and the xf86-video-intel
backlight code can be removed
Note there also is a step:
0) Get xf86-video-intel backlight code to work without root in some
way for now
Regards,
Hans
^ permalink raw reply
* Re: Fixing the kernels backlight API
From: Hans de Goede @ 2014-02-13 13:57 UTC (permalink / raw)
To: Alexander E. Patrakov, David Herrmann, Ville Syrjälä
Cc: Dave Airlie, Linux Fbdev development list, Jingoo Han,
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org, dri-devel
In-Reply-To: <52FC683F.10905-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi,
On 02/13/2014 07:37 AM, Alexander E. Patrakov wrote:
> 13.02.2014 04:26, David Herrmann wrote:
>> The "attach" stuff actually sounds doable, but who decides which one
>> to attach? You still need some user-space script during device-plug
>> for that.
>> But to be honest, the simplest way would be a "backlightd"
>> bus-activatable daemon. SetBacklight() then takes a DRM-connector and
>> brightness-value, which the daemon looks up in /sys and sets.. This
>> has the advantage that we can do any fancy matching in user-space. We
>> can provide quirks (maybe even via udev-hwdb) and other helpers for
>> weird setups.
>
> What would be done with Samsung monitors (like an old SyncMaster 770P) that have a DVI connection, no physical buttons and have to be controlled via DDC-CI? Currently, ddccontrol works (via /dev/i2c-*), but only from root. I would like this use case to be covered in such a way that it could work both in Xorg and in Wayland, and, if possible, without races related to i2c usage from the kernel and from userspace.
The nice thing about having a userspace daemon for this is that we can
actually add some support for DCC-CI too.
WRT races between user and kernelspace, those can be avoided by using
the I2C_RDWR ioctl, in this case you can specify multipel i2c writes /
reads which will all get executed as one transaction, note this
assumes that the protocol supports repeated START conditions,
if it needs a STOP condition and still needs everything to be in
one transaction, then things become trickier. This also assumes
that the i2c controller driver used supports I2C_FUNC_I2C
Regards,
Hans
^ permalink raw reply
* Re: Fixing the kernels backlight API
From: Matthew Garrett @ 2014-02-13 17:19 UTC (permalink / raw)
To: Hans de Goede
Cc: xorg-devel@lists.x.org, Linux Fbdev development list, Jingoo Han,
dri-devel
In-Reply-To: <52FCCBA1.3070303@redhat.com>
On Thu, Feb 13, 2014 at 02:41:53PM +0100, Hans de Goede wrote:
> I still believe we need to do better, but maybe that better needs to be done
> in userspace rather then in the kernel.
One option is to put it on the connector but provide some mechanism for
userspace to define the relationship between platform/firmware
interfaces and connectors. We ought to be able to tie connectors into
the ACPI namespace and do a better job than we currently do with the
association between backlight and connector. The bigger problem is
figuring out how platform interfaces tie into things, and that's where
heuristics are probably going to be involved.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: Fixing the kernels backlight API
From: Hans de Goede @ 2014-02-13 19:43 UTC (permalink / raw)
To: Matthew Garrett
Cc: xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org,
Linux Fbdev development list, Jingoo Han, Dave Airlie, dri-devel
In-Reply-To: <20140213171932.GB4420-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
Hi,
On 02/13/2014 06:19 PM, Matthew Garrett wrote:
> On Thu, Feb 13, 2014 at 02:41:53PM +0100, Hans de Goede wrote:
>
>> I still believe we need to do better, but maybe that better needs to be done
>> in userspace rather then in the kernel.
>
> One option is to put it on the connector but provide some mechanism for
> userspace to define the relationship between platform/firmware
> interfaces and connectors. We ought to be able to tie connectors into
> the ACPI namespace and do a better job than we currently do with the
> association between backlight and connector. The bigger problem is
> figuring out how platform interfaces tie into things, and that's where
> heuristics are probably going to be involved.
Right, but as Dave Airlie pointed out that means putting links between
two completely unrelated subsystems, causing locking and module load
ordering problems.
I can understand where Dave is coming from, from a kernel pov, so this
might really be easier to just solve in userspace. I don't know if you've
seen my very rough sketch of how this could work in userspace in my other
mail. The idea would be to still make this show up on a specific connector,
but only at the xrandr level, not at the drm level, and have the xserver
talk to some kind of backlightd for this. The backlightd API should of cource
be generic enough that it can be used in wayland too.
This sounds like a reasonable and workable plan to me, but I must admit
I'm very naive when it comes to backlight stuff.
Regards,
Hans
^ 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