Add DT binding documentation for tpd12s015 encoder
Signed-off-by: Tomi Valkeinen
Reviewed-by: Archit Taneja
---
.../devicetree/bindings/video/ti,tpd12s015.txt | 44 ++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti
On 19/03/14 10:22, Philipp Zabel wrote:
> I don't disagree, either. I have no objection against the bindings
> themselves.
>
> Acked-by: Philipp Zabel
Thanks. Is the ack for this particular binding, or for the whole series?
Tomi
-- next part --
A non-text attachment
On 19/03/14 10:03, Philipp Zabel wrote:
>>> Geert's comment also applies to all other connector types. These can be
>>> input connectors, too.
>>
>> We might not need to define all the properties required by input connectors
>> now, but we need to make sure that future extensions will be
PI? Enabling mentioned
> config builds components from Kernel\drivers\video\omap2\dss and
> kernel\drivers\video\omap2\displays only. Is there any support needs to
> be available under kernel\arch\arm\mach-omap2?
>
> Regards,
> Vikash
>
>
> On Fri, May 9, 2014 at 4:49 PM,
On 12/05/14 14:33, Vikas Patil wrote:
> Hi,
>
> Re-posting as previous posting was rejected due to length.
>
> Forgot to mention, DPI pins are connected to TDF19988 chip for HDMI
> conversion.
> I have build the driver for it from
>
On 13/05/14 09:26, Vikas Patil wrote:
> Hi Tomi,
>
>>That driver cannot be used with omapdrm, which uses omapdss. There's no
> TDF19988 driver for omapdss (at least in the mainline),
> Just to better understand, could you please explain why I can't use it
> with omadrm and omapdss? Which scenario
omapdrm is now usable
> again.
> These are critical fixes which I have posted since 3.12-rcs, it would be nice
> if
> they can go in as soon as possible.
These look ok to me:
Reviewed-by: Tomi Valkeinen
Tomi
-- next part --
A non-text attachment was scr
: fix: change dev_unload order
drm/omap: Enable DT support for DMM
Tomi Valkeinen (1):
drm/omap: fix (un)registering irqs inside an irq handler
drivers/gpu/drm/omapdrm/omap_crtc.c | 11 +--
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 9 ++
drivers/gpu/drm/omapdrm
Hi,
On 2013-12-17 16:27, Chris Wilson wrote:
> We attempt to reschedule an active work which can itself corrupt the
> workqueue lists, and we may then free the work item whilst the task is
> still pending. Both of these may lead to a system deadlock and an
> unresponsive machine without any
Dave,
Ping.
Tomi
On 2014-01-09 15:31, Tomi Valkeinen wrote:
> Hi Dave,
>
> Here are some omapdrm changes for 3.14 which have been around the lists
> for some time now.
>
> Tomi
>
> The following changes since commit 802eee95bde72fd0cd0f3a5b2098375a487d1eda:
>
Hi Dave,
Any chance to get these merged for 3.14? Omapdrm driver has been broken
for quite a long time.
Tomi
On 2014-01-20 12:17, Tomi Valkeinen wrote:
> Dave,
>
> Ping.
>
> Tomi
>
> On 2014-01-09 15:31, Tomi Valkeinen wrote:
>> Hi Dave,
>>
>> Here
On 24/06/14 13:04, Tomi Valkeinen wrote:
> Make the omapdrm driver use the new HDMI ops when possible.
>
> omapdrm will call set_hdmi_mode (when available) to tell the encoder
> driver whether the monitor is a DVI or HDMI monitor, and if it's an HDMI
> monitor, om
On 22/07/14 10:49, Thierry Reding wrote:
> But what I was trying to say is that if the Read IDs command isn't an
> official DCS command, maybe it would be a better idea to use the DDB
> instead. I assume that even if it isn't the same information it would
> at least be a superset and therefore a
make[5]: Target `__build' not remade because of errors.
> make[4]: *** [drivers/gpu/drm/omapdrm] Error 2
>
> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
Acked-by: Tomi Valkeinen
Dave, I don't have any other patches for omapdrm for 3.17, so can you
apply this d
On 22/07/14 06:41, YoungJun Cho wrote:
> Yes, this command is related with Nokia.
>
> Last Friday, I met panel vendor guy for some issues.
> At the break time, I asked him for about this Read IDs(04H), why it is
> not included in DCS specification.
> He said that this command was originated by
Hi,
On 02/06/14 16:03, David Herrmann wrote:
> Hi Tomi
>
> Any chance you could give this a spin on an omap device? It shouldn't
> affect any 32bit devices, so this is mostly a cosmetic change.
> However, I'd really like to get rid of that 'TODO' item. So a
> "Tested-by:" would be really nice.
Hi,
On 06/06/14 18:20, Daniel Vetter wrote:
> Tomi/Jean can you please ack merging this through drm-intel trees? It
> just exports the vga and dummy consoles so that i915 can do what it
> needs to do.
Acked-by: Tomi Valkeinen
Tomi
-- next part --
A
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
On 28/02/14 15:43, Philipp Zabel wrote:
> Hi Tomi,
>
> Am Freitag, den 28.02.2014, 14:20 +0200 schrieb Tomi Valkeinen:
>> Add DT binding documentation for DVI Connector.
>>
>> Signed-off-by: Tomi Valkeinen
>> Reviewed-by: Archit Taneja
>> ---
>> ..
On 28/02/14 18:23, Russell King - ARM Linux wrote:
>> I guess the compatible string is the easiest way for differentation, at
>> least for the three main types, i.e. "dvi-d-connector" etc.
>>
>> "dvi-d-1l-connector" and "dvi-d-2l-connector" for the single/dual link?
>> That looks a bit funny.
>
On 01/03/14 20:58, Geert Uytterhoeven wrote:
> On Fri, Feb 28, 2014 at 5:34 PM, Russell King - ARM Linux
> wrote:
>> There's actually three HDMI connectors:
>>
>> All three connectors carry all required HDMI signals, including a TMDS
>> link. The Type B connector is slightly larger and
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 w
Hi,
On 23/01/14 16:14, David Herrmann wrote:
> Hi
>
> Another round of SimpleDRM patches. I somehow lost track of the last ones and
> as
> this is a major rewrite, I'll just start at v1 again.
>
> Some comments up-front:
>
> - @Ingo: Patch #1 and #2 are unchanged from the previous ML
On 03/03/14 12:29, David Herrmann wrote:
>> What's the status with this one? Headed for 3.15?
>>
>> Are the SimpleDRM and sysfb linked somehow? (I.e. do they need to be in
>> the same series?)
>>
>> And jfyi, the drivers/video/ changes will conflict with the
>> drivers/video/ directory
On 28/02/14 15:40, Philipp Zabel wrote:
> Am Freitag, den 28.02.2014, 14:20 +0200 schrieb Tomi Valkeinen:
>> Add DT binding documentation for MIPI DPI Panel.
>>
>> Signed-off-by: Tomi Valkeinen
>> Reviewed-by: Archit Taneja
>> ---
>> .../devicetree/b
On 27/02/14 13:54, Tomi Valkeinen wrote:
> Hi,
>
> This is a re-send of the series, with RFC removed from the subject, and a
> bunch
> of acks added.
>
> I'm cc'ing more people, to make sure this doesn't come as a surprise, and to
> make sure this is not a bad idea,
On 04/03/14 14:00, Andrzej Hajda wrote:
> I have made video path binding optional, in case of video bus
> if the specific video path is not present driver uses the bus it is
> connected to.
> In case DSI panel is controlled via different bus the path should be
> specified
> explicitly.
>
> I
On 04/03/14 21:21, Randy Dunlap wrote:
>> I have pushed this to my for-next branch. Let's see what happens... At
>> least I'm able to merge the current linux-next without any conflicts.
>
> Thanks, I'm looking at this change in linux-next now.
>
> EXYNOS_VIDEO seems to be a little bit odd. Can
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.
On 01/03/14 20:58, Geert Uytterhoeven wrote:
> On Fri, Feb 28, 2014 at 5:34 PM, Russell King - ARM Linux
> wrote:
>> There's actually three HDMI connectors:
>>
>> All three connectors carry all required HDMI signals, including a TMDS
>> link. The Type B connector is slightly larger and
On 06/03/14 10:39, Geert Uytterhoeven wrote:
> On Wed, Mar 5, 2014 at 9:41 AM, Tomi Valkeinen
> wrote:
>> On 28/02/14 18:23, Russell King - ARM Linux wrote:
>>
>>> That's rather a lot of compatible strings. Another possibility is:
>>>
>>> c
On 07/03/14 14:22, Andrzej Hajda wrote:
> I think we should even extend the bindings to fimd:
> dsi {
> port at 0 {
> dsi_0: endpoint {
> remote-endpoint=<_0>;
> }
> }
> port at 1 {
> dsi_1: endpoint {
> remote-endpoint=<_0>;
> }
On 06/03/14 14:16, David Herrmann wrote:
> Hi Tomi
>
> On Mon, Mar 3, 2014 at 12:22 PM, Tomi Valkeinen
> 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/x8
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 m
On 07/03/14 15:07, Andrzej Hajda wrote:
> On 03/07/2014 01:32 PM, Tomi Valkeinen wrote:
>> On 07/03/14 14:22, Andrzej Hajda wrote:
>>
>>> I think we should even extend the bindings to fimd:
>>> dsi {
>>> port at 0 {
>>> ds
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.
On 07/03/14 16:17, Andrzej Hajda wrote:
> On 03/07/2014 02:28 PM, Tomi Valkeinen wrote:
> (...)
>> There are many possible connections from FIMD, some of them:
>> FIMD ---> RGB panel, external
>> FIMD ---> DSI, on SoC
>> FIMD ---> eDP, on SoC
>>
required by the omapdss driver.
This patch changes the omapdrm to use the omapdss driver's hardcoded
overlay managers, which fixes the issue.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_drv.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm
h is larger than what
> userspace provided. To prevent this from causing overallocation, fix the
> minimum pitch to 0 to enforce the driver-computed pitch.
>
> Cc: Tomi Valkeinen
> Reviewed-by: Daniel Vetter
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/omapd
On 12/12/14 11:51, Javier Martinez Canillas wrote:
> Tomi and Laurent,
>
> You asked Ajay to change his series to use the video port and enpoints DT
> bindings instead of phandles, could you please review his latest version?
Looking only at the binding documentation patch, looks good to me.
ver reason this
doesn't work reliably.
This patch adds an explicit submenu for DRM and FB, making it much
clearer which options are related to FB, and which to DRM.
Signed-off-by: Tomi Valkeinen
---
drivers/video/Kconfig | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/video
.
Signed-off-by: Tomi Valkeinen
---
drivers/video/fbdev/Makefile | 16 +---
drivers/video/fbdev/core/Makefile| 16
drivers/video/fbdev/{ => core}/cfbcopyarea.c | 0
drivers/video/fbdev/{ => core}/cfbfillrect.c | 0
drivers/video
On 14/02/14 14:27, Geert Uytterhoeven wrote:
> Hi Tomi,
>
> Thanks for doing this!
>
> Acked-by: Geert Uytterhoeven
>
> On Fri, Feb 14, 2014 at 12:18 PM, Tomi Valkeinen
> wrote:
>> --- a/drivers/video/fbdev/fbmon.c
>> +++ b/drivers/video/fbdev/core/fbmon
there.
No functionality is changed, although I guess it is possible that some
subtle Makefile build order related issue could be created by this
patch.
Signed-off-by: Tomi Valkeinen
---
drivers/Makefile |4 +-
drivers/video/Kconfig | 2483
On 25/02/14 16:23, Philipp Zabel wrote:
> +Freescale i.MX DRM master device
> +
> +
> +The freescale i.MX DRM master device is a virtual device needed to list all
> +IPU or other display interface nodes that comprise the graphics subsystem.
> +
> +Required
.
Signed-off-by: Tomi Valkeinen
Acked-by: Laurent Pinchart
Acked-by: Geert Uytterhoeven
Acked-by: Rob Clark
Acked-by: Jingoo Han
---
drivers/video/fbdev/Makefile | 16 +---
drivers/video/fbdev/core/Makefile| 16
drivers/video/fbdev
ver reason this
doesn't work reliably.
This patch adds an explicit submenu for DRM and FB, making it much
clearer which options are related to FB, and which to DRM.
Signed-off-by: Tomi Valkeinen
Acked-by: Laurent Pinchart
Acked-by: Geert Uytterhoeven
Acked-by: Rob Clark
Reviewed-by:
there.
No functionality is changed, although I guess it is possible that some
subtle Makefile build order related issue could be created by this
patch.
Signed-off-by: Tomi Valkeinen
Acked-by: Laurent Pinchart
Acked-by: Geert Uytterhoeven
Acked-by: Rob Clark
Acked-by: Jingoo Han
---
drivers/Makefile
way to merge this? Normally, like any other fbdev change? As a separate
pull request, maybe at -rc2 time frame, based on -rc1? Something else?
Tomi
Tomi Valkeinen (3):
video: move fbdev to drivers/video/fbdev
fbdev: move fbdev core files to separate directory
video: Kconfig: move drm and fb
On 27/02/14 15:43, Russell King - ARM Linux wrote:
> That may be - but the problem with CDF solving this problem is that it's
> wrong. It's fixing what is in actual fact a *generic* problem in a much
> too specific way. To put it another way, it's forcing everyone to fix
> the same problem in
On 27/02/14 15:00, Russell King - ARM Linux wrote:
> On Thu, Feb 27, 2014 at 02:06:25PM +0100, Philipp Zabel wrote:
>> For the i.MX6 display subsystem there is no clear single master device,
>> and the physical configuration changes across the SoC family. The
>> i.MX6Q/i.MX6D SoCs have two
On 27/02/14 20:16, Randy Dunlap wrote:
> On 02/27/2014 03:54 AM, Tomi Valkeinen wrote:
>> Hi,
>>
>> This is a re-send of the series, with RFC removed from the subject, and a
>> bunch
>> of acks added.
>>
>> I'm cc'ing more people, to make sure this do
On 27/02/14 18:54, Philipp Zabel wrote:
>> - One IPU enabled, one disabled: nothing special here, just set the
>> other IPU to status="disabled" in the DT data. The driver for the
>> enabled IPU would register the required DRM entities.
>
> that should work. Let the enabled IPU create the
encoder.
* TPD12S015 is a HDMI companion chip, used on OMAP boards.
These patches, on top of the OMAP DSS DT work, can be found from:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
Tomi
Tomi Valkeinen (9):
Doc/DT: Add OMAP DSS DT Bindings
Doc/DT: Add DT binding
Add DT binding documentation for HDMI Connector.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Archit Taneja
---
.../devicetree/bindings/video/hdmi-connector.txt | 23 ++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/hdmi
Add DT binding documentation for MIPI DPI Panel.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Archit Taneja
---
.../devicetree/bindings/video/panel-dpi.txt| 43 ++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/panel
Add DT binding documentation for MIPI DSI Command Mode Panel.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Archit Taneja
---
.../devicetree/bindings/video/panel-dsi-cm.txt | 26 ++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings
Add DT binding documentation for Sony acx565akm panel
Signed-off-by: Tomi Valkeinen
Reviewed-by: Sebastian Reichel
Reviewed-by: Archit Taneja
---
.../devicetree/bindings/video/sony,acx565akm.txt | 28 ++
1 file changed, 28 insertions(+)
create mode 100644 Documentation
Add DT binding documentation for TFP410 encoder
Signed-off-by: Tomi Valkeinen
Reviewed-by: Archit Taneja
---
.../devicetree/bindings/video/ti,tfp410.txt| 41 ++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,tfp410
Hi,
A bit old thread, but I noticed this only now.
On 01/11/13 02:10, Dave Airlie wrote:
> But why? why should we have separate drivers for each component of a
> tightly coupled SoC?
>
> it makes no sense, having a driver node per every block in the chip
> isn't an advantage, it complicates
>
On 12/02/14 13:31, Andrzej Hajda wrote:
> The patch adds bridge and panel nodes.
> It adds also DSI properties specific for arndale board.
>
> Signed-off-by: Andrzej Hajda
> ---
> arch/arm/boot/dts/exynos5250-arndale.dts | 39
>
> 1 file changed, 39
On 28/02/14 15:31, Tomi Valkeinen wrote:
> Compared to what I've done on OMAP, you don't seem to specify the video
> inputs for the tc358764 at all. In this case it's obvious, as the chip
> is a child of the DSI master. But the chip could as well be controlled
> via i2c, and
On 28/02/14 17:59, Russell King - ARM Linux wrote:
>> +dvi0: connector at 0 {
>> +compatible = "dvi-connector";
>> +label = "dvi";
>> +
>> +i2c-bus = <>;
>> +
>> +dvi_connector_in: endpoint {
>> +remote-endpoint = <_out>;
>> +};
>> +};
>
> This looks far too
On 28/02/14 18:06, Russell King - ARM Linux wrote:
>> +hdmi0: connector at 1 {
>> +compatible = "hdmi-connector";
>> +label = "hdmi";
>> +
>> +hdmi_connector_in: endpoint {
>> +remote-endpoint = <_out>;
>> +};
>> +};
>
> It seems rather weird to have DVI connectors
On 28/02/14 18:27, Russell King - ARM Linux wrote:
> On Fri, Feb 28, 2014 at 02:20:07PM +0200, Tomi Valkeinen wrote:
>> Shortly about the display components in the series, in the order of probable
>> public interest:
>>
>> * Analog TV, DVI and HDMI Connectors repre
Add device tree bindings for OMAP Display Subsystem for the following
SoCs: OMAP2, OMAP3, OMAP4.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Archit Taneja
---
.../devicetree/bindings/video/ti,omap-dss.txt | 203 +
.../devicetree/bindings/video/ti,omap2-dss.txt | 54
Add DT binding documentation for Analog TV Connector.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Archit Taneja
---
.../bindings/video/analog-tv-connector.txt | 23 ++
1 file changed, 23 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video
Add DT binding documentation for DVI Connector.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Archit Taneja
---
.../devicetree/bindings/video/dvi-connector.txt| 26 ++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/dvi
On 12/02/14 13:31, Andrzej Hajda wrote:
> The patch adds s6e8aa0 panel node for trats2.
> It adds also trats2 specific properties for DSI
> and regulator required by panel.
>
> Signed-off-by: Andrzej Hajda
> ---
> arch/arm/boot/dts/exynos4412-trats2.dts | 47
> +
On 28/02/14 15:38, Philipp Zabel wrote:
> Hi Tomi,
>
> Am Freitag, den 28.02.2014, 14:20 +0200 schrieb Tomi Valkeinen:
>> Add DT binding documentation for Sony acx565akm panel
>>
>> Signed-off-by: Tomi Valkeinen
>> Reviewed-by: Sebastian Reich
On 28/02/14 18:13, Russell King - ARM Linux wrote:
> On Fri, Feb 28, 2014 at 02:20:16PM +0200, Tomi Valkeinen wrote:
>> Add DT binding documentation for tpd12s015 encoder
>>
>> Signed-off-by: Tomi Valkeinen
>> Reviewed-by: Archit Taneja
>> ---
>> .../dev
On 28/02/14 14:57, Sebastian Hesselbarth wrote:
> Out of curiosity, will there be DT nodes for pull-up resistors soon,
> too? ;)
If they don't work automatically, yes, we need DT nodes and drivers for
them.
> Honestly, TPD12S015 is a level shifter, there is nothing in it that
> would justify a
Add DT binding documentation for tpd12s015 encoder
Signed-off-by: Tomi Valkeinen
Reviewed-by: Archit Taneja
---
.../devicetree/bindings/video/ti,tpd12s015.txt | 44 ++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti
On 28/02/14 15:51, Sebastian Hesselbarth wrote:
>> TPD requires a power. Who turns that on? It also has two GPIOs, LS_OE
>> and CT_CP_HPD, which need to be controlled based on what the user wants
>> and the state of the HPD line. Who controls those?
>
> Strictly speaking TPD12S015 has _no_ GPIO
On 08/08/14 13:14, Thierry Reding wrote:
> On Fri, Aug 08, 2014 at 09:26:17AM +0200, Andrzej Hajda wrote:
>> On 08/07/2014 10:54 AM, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 10:39:36AM +0200, Andrzej Hajda wrote:
On 08/07/2014 09:25 AM, Thierry Reding wrote:
> On Thu, Aug 07,
On 01/07/14 21:52, Fabian Frederick wrote:
> use mm.h definition
>
> Cc: David Airlie
> Cc: Tomi Valkeinen
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Fabian Frederick
> ---
> drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
> 1 file changed, 1 insertion(
Hi,
On 02/12/14 14:41, Vikas Patil wrote:
> Hi All,
>
> What I found is UnwrapExtMemoryCallBack() function from
> eurasia_km\services4\srvkm\common\devicemem.c always calls
> omap_gem_put_pages(), however just before the crash it calls
> omap_gem_put_paddr() and it crashes in it due to NULL
On 06/12/14 21:19, Robert Nelson wrote:
>> gotcha, well I've pushed your patch. I don't really have the hw
>> unpacked and setup to test these days, but if someone confirm latest
>> master is good then I suppose I should spin a release tag for distro's
>> to pick up..
>
> Thanks Rob!
>
> I'll
Hi,
On 21/07/15 14:28, Maarten Lankhorst wrote:
> In intel it's useful to keep track of some state changes with old
> crtc state vs new state, for example to disable initial planes or
> when a modeset's prevented during fastboot.
>
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by:
On 07/08/15 19:10, Thierry Reding wrote:
> From: Thierry Reding
>
> The Direct Rendering Manager Kconfig option is already a separate menu,
> so remove the extra level to make it easier to navigate.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/video/Kconfig | 2 --
> 1 file changed, 2
On 10/08/15 14:47, Daniel Vetter wrote:
> On Mon, Aug 10, 2015 at 01:32:08PM +0300, Tomi Valkeinen wrote:
>>
>>
>> On 07/08/15 19:10, Thierry Reding wrote:
>>> From: Thierry Reding
>>>
>>> The Direct Rendering Manager Kconfig option is alread
On 29/07/15 13:12, Thierry Reding wrote:
> From: Thierry Reding
>
> The current driver name, "panel", is very generic. This causes problems
> when the driver is enabled on non-TI device tree platforms if the panel
> node is called "panel". This causes the driver name match fall-back in
>
nstead of checking for NULL.
>
> Reported-by: Dan Carpenter
>
> v2:
> - No changes
>
> Cc: Tomi Valkeinen
> Cc: Laurent Pinchart
>
> Signed-off-by: Archit Taneja
> ---
> drivers/gpu/drm/omapdrm/omap_fbdev.c | 38
> -
On 25/09/14 09:23, Thierry Reding wrote:
> How are cameras different? The CPU wants to capture video data from the
> camera, so it needs to go look for a video capture device, which in turn
> needs to involve a sensor.
Let's say we have an XXX-to-YYY encoder. We use that encoder to convert
the
On 07/10/14 10:23, Laurent Pinchart wrote:
>> You mean the bridge driver would somehow take a peek into panel1 and
>> panel2 nodes, looking for bridge specific properties? Sounds somewhat
>> fragile to me... How would the bridge driver know a property is for the
>> bridge?
>
> No, I mean the
On 06/10/14 17:40, Laurent Pinchart wrote:
>> But seriously speaking, I was thinking about this. I'd really like to
>> have a generic video-mux node, that would still somehow allow us to have
>> device specific configurations for the video sources and sinks (which
>> the endpoints provide us),
On 20/09/14 14:22, Ajay kumar wrote:
> Well, I am okay with using video ports to describe the relationship
> between the encoder, bridge and the panel.
> But, its just that I need to make use of 2 functions when phandle
> does it using just one function ;)
> -panel_node =
On 18/10/14 00:13, Jani Nikula wrote:
> Documentation/kbuild/kconfig-language.txt warns to use select with care,
> and in general use select only for non-visible symbols and for symbols
> with no dependencies, because select will force a symbol to a value
> without visiting the dependencies.
>
>
On 23/10/14 11:10, Daniel Vetter wrote:
> If we want to make BACKLIGHT_CLASS_DEVICE into a library thing then I
> guess we could do that, but we must then also drag it out of all the other
> meta options to make sure it's always available. No need I think to ditch
BACKLIGHT_CLASS_DEVICE only
On 27/10/14 13:59, Jani Nikula wrote:
>> While doing 'depends on' instead of 'select' is an "easy" fix for this,
>> I do dislike it quite a bit. It's a major pain to go around the kernel
>> config, trying to find all the dependencies that a particular driver
>> wants. If I need fb-foobar, I
it's clear that this has never worked, which means no one has used
those bindings, which should make it safe to change this.
Signed-off-by: Tomi Valkeinen
Reported-by: Laurent Pinchart
---
Documentation/devicetree/bindings/video/analog-tv-connector.txt | 4 ++--
ar
The DRM documentation says:
"If a page flip is already pending, the page_flip operation must return
-EBUSY."
Currently omapdrm returns -EINVAL instead. Fix omapdrm by returning
-EBUSY.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 2 +-
1 file changed, 1
ing a new variable, 'go_bit_set' which
is used to track the supposed state of GO bit and helps the apply worker
and irq handler handle the job without a race.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 17 +++--
1 file changed, 15 insertions(+), 2 deleti
Clear omap_obj's paddr when unmapping the memory, so that it's easier to
catch bad use of the paddr.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
required by the omapdss driver.
This patch changes the omapdrm to use the omapdss driver's hardcoded
overlay managers, which fixes the issue.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_drv.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm
to be done at the end of omap_crtc->commit().
The ugly part here is that the background work takes crtc->mutex, and
the modesetting also holds that lock, which means that the background
work never gets done. To get around this, we unclock, wait, and lock
again.
Signed-off-by: Tomi Val
DSS.
This patch fixes the issue by adding a simple pin_count, used to track
the number of pins.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_fb.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
b/drivers/gpu/drm/omapdrm
led by omap_crtc_flush().
Improve omap_crtc_flush() to flush the workqueue so that work there will
be ran.
This fixes a race issue on module unload, where an unpin work may be on
the work queue, but does not get ran before drm core starts tearing the
driver down, leading to a WARN.
Signed-off-by: T
We already wait for all scheduled work to be done on the driver's unload
function. However, I think we need to wait on preclose() also, so that
when an application closes the drm file descriptor, we are sure that
there's no left around.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm
unpin_worker() calls omap_framebuffer_unpin() without any locks, which
looks very suspicious. However, both pin and unpin are always called via
the driver's private workqueue, so the access is synchronized that way.
Add a comment to make this clear.
Signed-off-by: Tomi Valkeinen
---
drivers
701 - 800 of 3394 matches
Mail list logo
