Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator

[Tomi Valkeinen]

Hi,

On 01/01/16 14:01, Pali Rohár wrote:
> Hi Tomi! Can you review this patch? It is waiting here for two years!
> 
> On Thursday 26 December 2013 00:12:39 Ivaylo Dimitrov wrote:
>> From: Ivaylo Dimitrov 
>>
>> On memory limited devices, CMA fails easily when asked to allocate
>> big chunks of memory like framebuffer memory needed for video
>> playback.
>>
>> Add boot parameter "omapfb_memsize" which allocates memory to be used
>> as dma coherent memory, so dma_alloc_attrs won't hit CMA allocator
>> when trying to allocate memory for the framebuffers

We probably need exactly the same for omapdrm, as omapfb is on the way
to being deprecated. And sounds to me that we probably need similar for
other devices which try to do large allocations (camera? video decoders?).

So I really think this should be somehow be a general option for any device.

I also wonder if CMA can be improved to not need anything like this? If
you just increase the CMA area, won't that increase the chances CMA will
work?

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 3/7] omapfb: fix error return code

[Tomi Valkeinen]

On 26/12/15 17:28, Julia Lawall wrote:
> Return a negative error code on failure.
> 
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
> 
> // 
> @@
> identifier ret; expression e1,e2;
> @@
> (
> if (\(ret < 0\|ret != 0\))
>  { ... return ret; }
> |
> ret = 0
> )
> ... when != ret = e1
> when != 
> *if(...)
> {
>   ... when != ret = e2
>   when forall
>  return ret;
> }
> // 
> 
> Signed-off-by: Julia Lawall 
> 
> ---
>  drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c |   12 
> +++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c 
> b/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c
> index 677e254..fc4cfa9 100644
> --- a/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c
> +++ b/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c
> @@ -241,22 +241,28 @@ static int tpd_probe(struct platform_device *pdev)
>  
>   gpio = devm_gpiod_get_index_optional(>dev, NULL, 0,
>   GPIOD_OUT_LOW);
> - if (IS_ERR(gpio))
> + if (IS_ERR(gpio)) {
> + r = PTR_ERR(gpio);
>   goto err_gpio;
> + }
>  
>   ddata->ct_cp_hpd_gpio = gpio;
>  
>   gpio = devm_gpiod_get_index_optional(>dev, NULL, 1,
>   GPIOD_OUT_LOW);
> - if (IS_ERR(gpio))
> + if (IS_ERR(gpio)) {
> + r = PTR_ERR(gpio);
>   goto err_gpio;
> + }
>  
>   ddata->ls_oe_gpio = gpio;
>  
>   gpio = devm_gpiod_get_index(>dev, NULL, 2,
>   GPIOD_IN);
> - if (IS_ERR(gpio))
> + if (IS_ERR(gpio)) {
> + r = PTR_ERR(gpio);
>   goto err_gpio;
> + }
>  
>   ddata->hpd_gpio = gpio;

Thanks. Looks like recent changes to the driver break the error
handling. I'll just drop those patches from my for-next branch, and let
the author fix the patches.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: OMAP display kconfig options changing

[Tomi Valkeinen]

Hi Javier, Tony,

On 22/12/15 23:18, Javier Martinez Canillas wrote:

>> But if the userspace is using any omapfb specific apps, then yes, update
>> is necessary.
>>
> 
> Yes but these people should have a migration plan anyways since omapfb
> (and fbdev in general) is going away right?

Well, I would guess most people don't know/care about that.

>> Ok. I think it's then best that I just update the defconfig to enable
>> omapfb as modules, as it is currently.
>>
> 
> In that case I think you should squash the defconfig changes with
> commit ("70ba4e05531f omapfb/displays: change CONFIG_DISPLAY_* to
> CONFIG_FB_OMAP2_*") to maintain bisectability.

Here's the diff to change the defconfig to enable the same items as before:

diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/configs/omap2plus_defconfig
index c5e1943e5427..b9581f1f0536 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -290,24 +290,23 @@ CONFIG_FB=y
 CONFIG_FIRMWARE_EDID=y
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_FB_TILEBLITTING=y
-CONFIG_OMAP2_DSS=m
-CONFIG_OMAP5_DSS_HDMI=y
-CONFIG_OMAP2_DSS_SDI=y
-CONFIG_OMAP2_DSS_DSI=y
+CONFIG_FB_OMAP5_DSS_HDMI=y
+CONFIG_FB_OMAP2_DSS_SDI=y
+CONFIG_FB_OMAP2_DSS_DSI=y
 CONFIG_FB_OMAP2=m
-CONFIG_DISPLAY_ENCODER_TFP410=m
-CONFIG_DISPLAY_ENCODER_TPD12S015=m
-CONFIG_DISPLAY_CONNECTOR_DVI=m
-CONFIG_DISPLAY_CONNECTOR_HDMI=m
-CONFIG_DISPLAY_CONNECTOR_ANALOG_TV=m
-CONFIG_DISPLAY_PANEL_DPI=m
-CONFIG_DISPLAY_PANEL_DSI_CM=m
-CONFIG_DISPLAY_PANEL_SONY_ACX565AKM=m
-CONFIG_DISPLAY_PANEL_LGPHILIPS_LB035Q02=m
-CONFIG_DISPLAY_PANEL_SHARP_LS037V7DW01=m
-CONFIG_DISPLAY_PANEL_TPO_TD028TTEC1=m
-CONFIG_DISPLAY_PANEL_TPO_TD043MTEA1=m
-CONFIG_DISPLAY_PANEL_NEC_NL8048HL11=m
+CONFIG_FB_OMAP2_ENCODER_TFP410=m
+CONFIG_FB_OMAP2_ENCODER_TPD12S015=m
+CONFIG_FB_OMAP2_CONNECTOR_DVI=m
+CONFIG_FB_OMAP2_CONNECTOR_HDMI=m
+CONFIG_FB_OMAP2_CONNECTOR_ANALOG_TV=m
+CONFIG_FB_OMAP2_PANEL_DPI=m
+CONFIG_FB_OMAP2_PANEL_DSI_CM=m
+CONFIG_FB_OMAP2_PANEL_SONY_ACX565AKM=m
+CONFIG_FB_OMAP2_PANEL_LGPHILIPS_LB035Q02=m
+CONFIG_FB_OMAP2_PANEL_SHARP_LS037V7DW01=m
+CONFIG_FB_OMAP2_PANEL_TPO_TD028TTEC1=m
+CONFIG_FB_OMAP2_PANEL_TPO_TD043MTEA1=m
+CONFIG_FB_OMAP2_PANEL_NEC_NL8048HL11=m
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_PLATFORM=y

Tony, the diff above looks like something that's safe to merge via fbdev
tree. The context contains only display related configs. Is it ok if I
squash the above change to my series to keep bisectability?

> Alternatively, the current panel and encoders Kconfig symbols could
> remain for omapfb since that's the current ones used in
> omap2plus_defconfig where omapfb is the default and have new Kconfig
> symbols for omapdrm (i.e: CONFIG_DRM_OMAP_ENCODER_TFP410).

I want to change the config symbols, as the current ones are too generic
(e.g. CONFIG_DISPLAY_PANEL_DPI doesn't mention OMAP anywhere). I think
this is a good time to change them for omapfb. But this is probably a
good time to change them for omapdrm also, so I think I'll add that change.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks

[Tomi Valkeinen]

On 25/12/15 15:29, Ivaylo Dimitrov wrote:
> 
> Hi Tomi,
> 
> On 13.01.2014 12:20, Tomi Valkeinen wrote:
>> On 2014-01-11 11:39, Ivaylo Dimitrov wrote:
>>
>>> The patch does not apply cleanly on top of rc7, however I applied it by
>>> hand. So far it seems it fixes the issue brought by
>>> c37dd677988ca50bc8bc60ab5ab053720583c168, though I didn't test if
>>> mutex_lock/mutex_unlock are complementary in every code path (at least
>>> not explicitly, I guess maemo is doing it for us anyway :) ).
>>
>> Ok, thanks.
>>
>>> So, shall I send a patch incorporating your code changes, or you will do
>>> it?
>>
>> I can handle it.
>>
>>   Tomi
>>
>>
> 
> I still don't see those fixes in mainline, shall I send a patch?

Oh, I'm sorry, I must have forgotten about that. Please, send a new patch.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 5/5] fbdev: omap2: panel-dpi: allow specification of a vcc regulator

[Tomi Valkeinen]

Hi,

On 19/12/15 22:41, Adam Ford wrote:
> Tomi,
> 
> Do you have any thought on how to approach adding sleep/delay
> functions?  I have a display that requires a small delay before and
> after the enable gpio toggle.  I assume that some may require a delay
> after the regulator starts for it to be be ready.  For now I have a
> temp hack that just inserts a blanket 300mS wait, but I'd rather have
> something mainstreamed in the device tree, but I don't want to walk
> over someone else's work either.

I don't think it makes sense to add explicit entries for these, as we'd
just end up with lots of entries in the DT files for "wait-before-vcc",
"wait-after-vcc", etc.

There was a patch series some time ago, trying to add generic power
up/down sequences defined in DT. I don't think that ever got merged, as
there wasn't a consensus on the DT side. I can't find the series right
now, as I don't remember the author or the subject...

I think that kind of generic sequence framework would make sense, and
getting it merged without the DT side should be easier. Then the drivers
could have built-in sequences for certain panels.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 3/5] fbdev: omap2: panel-dpi: drop assignment to local variable

[Tomi Valkeinen]

On 20/12/15 12:31, Uwe Kleine-König wrote:
> Hello,
> 
> On Wed, Dec 16, 2015 at 07:29:17PM +0200, Tomi Valkeinen wrote:
>> On 10/12/15 15:11, Uwe Kleine-König wrote:
>>> From: Uwe Kleine-König <u.kleine-koe...@pengutronix.de>
>>>
>>> The variable gpio is only used to store the return value of
>>> devm_gpiod_get_optional just to assign it to a member of the driver
>>> data.
>>>
>>> Get rid of this local variable and assign to driver data directly.
>>>
>>> Signed-off-by: Uwe Kleine-König <u.kleine-koe...@pengutronix.de>
>>> ---
>>>  drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 10 --
>>>  1 file changed, 4 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c 
>>> b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
>>> index e780fd4f8b46..1216341a0d19 100644
>>> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
>>> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
>>> @@ -205,13 +205,11 @@ static int panel_dpi_probe_of(struct platform_device 
>>> *pdev)
>>> int r;
>>> struct display_timing timing;
>>> struct videomode vm;
>>> -   struct gpio_desc *gpio;
>>>  
>>> -   gpio = devm_gpiod_get_optional(>dev, "enable", GPIOD_OUT_LOW);
>>> -   if (IS_ERR(gpio))
>>> -   return PTR_ERR(gpio);
>>> -
>>> -   ddata->enable_gpio = gpio;
>>> +   ddata->enable_gpio = devm_gpiod_get_optional(>dev,
>>> +"enable", GPIOD_OUT_LOW);
>>> +   if (IS_ERR(ddata->enable_gpio))
>>> +   return PTR_ERR(ddata->enable_gpio);
>>>  
>>> ddata->backlight_gpio = -ENOENT;
>>
>> I usually try to avoid writing bad values to fields. Here
>> ddata->enable_gpio may get an error ptr. It probably doesn't matter as
>> we bail out right away, but still. If devm_gpiod_get_optional's return
>> value would be NULL or valid gpio_desc*, then it'd be fine.
> 
> this is probably a matter of taste but still I don't see why people
> don't like writing to structs immediately.

I don't have a problem with writing to struct immediately. My point was
that I don't like writing invalid values to "long term storage".

What's "invalid" is of course up to the case, but here I think it's
quite clear that 'ddata->enable_gpio' should either be a valid gpiod or
NULL.

Generally, I also like to work on a resource/object in local variables
until it's "ready", and only then push it to the public storage. In my
experience that style results in less possibilities for bugs and confusion.

> With the local variable you might have
> 
>   gpio = -ESOMETHING
> 
> and
> 
>   ddata->enable_gpio = NULL;
> 
> In the case that the error is handled correctly it doesn't matter if the
> value was written to the struct or not (if you accept a little
> performance penalty for writing the value actually to memory maybe). So
> the motivation is the consideration that the error might not be handled
> correctly after a later patch, right? But when ddata->enable_gpio is a
> negative error code this probably results in a crash already during
> development of the faulty patch, while when the struct's member isn't
> assigned it probably doesn't.

Yes, my motivation is that later patches may change the behavior, and
keeping a valid value in 'data->enable_gpio' may make future patches
simpler and prevent problems.

I think it's quite common to do cleanups later, using the values in the
long term storage. Here it might mean setting enable-gpio to 0, or if
devm_* was not used, freeing the gpio, and that would result in using an
error ptr as a pointer to gpiod.

And it's quite common to later change error handling slightly so that
instead of failing, the driver continues if it doesn't actually require
the resource that it failed to get.

Of course, patches for both can and should be written correctly so that
both local and direct write to struct work correctly.

> This convinces me that writing to the struct is actually a good thing.
> 
> Additionally even though the line length of 
> 
>   gpio = devm_gpiod_get_optional(>dev, "enable", GPIOD_OUT_LOW);
>   if (IS_ERR(gpio))
>   return PTR_ERR(gpio);
> 
>   ddata->enable_gpio = gpio;
> 
> is shorter (which is good), with my approach of doing:
> 
>   ddata->enable_gpio = devm_gpiod_get_optional(>dev,
>"enable", GPIOD_OUT_LO

Re: [PATCH] OMAPDSS: fix omapfb build error due missing feat functions declaration

[Tomi Valkeinen]

Hi Javier,

On 21/12/15 20:26, Javier Martinez Canillas wrote:
> The omapfb is failing to build in -next due missing declarations for
> dss_feat_get_supported_displays() and dss_feat_get_supported_outputs():
> 
>  CC [M]  drivers/video/fbdev/omap2//omapfb/dss/dss.o
> drivers/video/fbdev/omap2//omapfb/dss/dss.c: In function 'dss_save_context':
> drivers/video/fbdev/omap2//omapfb/dss/dss.c:144:2: error: implicit 
> declaration of function 'dss_feat_get_supported_displays' 
> [-Werror=implicit-function-declaration]
> 
> Add the declaration for these functions in the dss_features.h header
> file to fix this compile error.
> 
> Also, remove the functions export since are not used outside the driver.

Thanks!

Yep, I messed that up. I thought I had tested it, but apparently I only
tested the final for-next only for omapdrm, which does compile and work.

omapdss.h is the the only file still shared between omapdrm and omapfb
after the copy-omapdss-series (I'll work on omapdss.h later), and of
course there was a change to omapdss.h which broke the build.

So I rebased the copy-omapdss-series on top of the rest of the omapdss
patches, and updated the "omapfb: copy omapdss & displays for omapfb" to
make a fresh copy of omapdss for omapfb. I think it's better to update
the series, rather than applying fixes for already confusing series.

I've pushed new version to my for-next branch.

 Tomi



signature.asc
Description: OpenPGP digital signature

OMAP display kconfig options changing

[Tomi Valkeinen]

Hi Tony,

I've just pushed a patch series to fbdev for-next branch which makes the
OMAP DRM and FB drivers independent of each other. This requires
changing the related Kconfig options.

What should I do with omap2plus_defconfig?

At the moment omap2plus_defconfig enables the omapfb driver and panels
as modules. Should I change it to do the same with the new code? Or
should I change it to use omapdrm, which is the better maintained and
developed driver (although no one has probably tried omapdrm on omap2)?

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: OMAP display kconfig options changing

[Tomi Valkeinen]

On 18/12/15 18:05, Tony Lindgren wrote:

>> Are you referring to Kconfig options? Or userspace?
> 
> Well sounds like both need updating :)

Depends... For simple fb apps, omapdrm works fine, and X with the
standard fbdev driver should work with omapdrm too.

But if the userspace is using any omapfb specific apps, then yes, update
is necessary.

>> But no, I don't have links to either.
> 
> So change the Kconfig options and then deal with the flood
> of angry emails? :) I think we need instructions..

Ok. I think it's then best that I just update the defconfig to enable
omapfb as modules, as it is currently.

We can look again at changing the default to omapdrm after we've tested
it on OMAP2 too, and we have a better idea what the user needs to take
care of.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: OMAP display kconfig options changing

[Tomi Valkeinen]

On 18/12/15 15:53, Tony Lindgren wrote:
> Hi,
> 
> * Tomi Valkeinen <tomi.valkei...@ti.com> [151218 00:55]:
>> Hi Tony,
>>
>> I've just pushed a patch series to fbdev for-next branch which makes the
>> OMAP DRM and FB drivers independent of each other. This requires
>> changing the related Kconfig options.
> 
> OK

Note that nothing has changed with omapfb and omapdrm as such. The only
(visible) change is the needed Kconfig options.

>> What should I do with omap2plus_defconfig?
>>
>> At the moment omap2plus_defconfig enables the omapfb driver and panels
>> as modules. Should I change it to do the same with the new code? Or
>> should I change it to use omapdrm, which is the better maintained and
>> developed driver (although no one has probably tried omapdrm on omap2)?
> 
> I'm all for changing omap2plus_defconfnig to use omapdrm.
> 
> Do you have a link to a page we can point people to for instructions
> for what needs to be changed to get things working with omapdrm?

Are you referring to Kconfig options? Or userspace?

But no, I don't have links to either.

For the Kconfig options, it's pretty similar to omapfb. After the
patches I'm pushing, one needs to enable DRM, DRM_OMAP, and then the
individual panel/encoder drivers (as for omapfb).

> For omap2, I can try to peek into my rack for n800.

There were a few fixes sent a few days ago which are needed for OMAP2/3.
I think both are now in Linus' tree.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: OMAP display kconfig options changing

[Tomi Valkeinen]

On 18/12/15 16:03, Adam Ford wrote:
> Tomi,
> 
> I'd like to also test the LogicPD Torpedo which has been using the FB
> drivers until this point. I just pushed some LCD info for inclusion in
> 4.5, but if I need to make changes, I'd like to do that sooner than

The DT data is the same for omapfb and omapdrm, so no changes needed.

> later.  Any insturctions would be helpful.  Will this impact people
> who use the SGX drivers?

I'm no expert, but... Yes, I think so. If you were using SGX driver with
some additional omapfb patches, it won't work with omapdrm.

omapdrm + SGX works, but it's a bit tricky setup (need extra kernel
patches, specific userspace libs...). I hope we'll get the SGX side
sorted out during the first quarter, which should make omapdrm + SGX
much easier to get running.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 4/5] fbdev: omap2: panel-dpi: allow specification of a reset gpio

[Tomi Valkeinen]

On 10/12/15 15:11, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
> 
> Some displays have a reset input. To assert that the display is
> functional the reset gpio must be deasserted.
> 
> Teach the driver to get and drive such a gpio accordingly.
> 
> Signed-off-by: Uwe Kleine-König 
> ---
>  Documentation/devicetree/bindings/video/panel-dpi.txt | 1 +
>  drivers/video/fbdev/omap2/displays-new/panel-dpi.c| 7 +++
>  2 files changed, 8 insertions(+)

DT changes should be posted to devicet...@vger.kernel.org. And, I think,
the binding document changes are usually as a separate patch.

> diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt 
> b/Documentation/devicetree/bindings/video/panel-dpi.txt
> index a40180b05bab..1a1d8f6f884f 100644
> --- a/Documentation/devicetree/bindings/video/panel-dpi.txt
> +++ b/Documentation/devicetree/bindings/video/panel-dpi.txt
> @@ -7,6 +7,7 @@ Required properties:
>  Optional properties:
>  - label: a symbolic name for the panel
>  - enable-gpios: panel enable gpio
> +- reset-gpios: GPIO to control the RESET pin
>  
>  Required nodes:
>  - "panel-timing" containing video timings
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c 
> b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> index 1216341a0d19..7e2f9e0813dc 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> @@ -32,6 +32,7 @@ struct panel_drv_data {
>   int backlight_gpio;
>  
>   struct gpio_desc *enable_gpio;
> + struct gpio_desc *reset_gpio;
>  };
>  
>  #define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
> @@ -83,6 +84,7 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
>   if (r)
>   return r;
>  
> + gpiod_set_value_cansleep(ddata->reset_gpio, 0);
>   gpiod_set_value_cansleep(ddata->enable_gpio, 1);
>  
>   if (gpio_is_valid(ddata->backlight_gpio))
> @@ -211,6 +213,11 @@ static int panel_dpi_probe_of(struct platform_device 
> *pdev)
>   if (IS_ERR(ddata->enable_gpio))
>   return PTR_ERR(ddata->enable_gpio);
>  
> + ddata->reset_gpio = devm_gpiod_get_optional(>dev,
> + "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(ddata->reset_gpio))
> + return PTR_ERR(ddata->reset_gpio);
> +
>   ddata->backlight_gpio = -ENOENT;
>  
>   r = of_get_display_timing(node, "panel-timing", );
> 

This looks a bit odd to me. This only ever sets the reset gpio to 0, on
panel enable. If we never toggle the reset, it could be set to 0 at
probe time, right?

Reset is a bit tricky. I've seen panels where you have to have only a
short reset pulse (reset high, wait a short time, reset low). If you
leave the reset high, the panel draws extra power.

So I think the best we can do in a generic way is just to ensure the
reset is not asserted.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 3/5] fbdev: omap2: panel-dpi: drop assignment to local variable

[Tomi Valkeinen]

On 10/12/15 15:11, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
> 
> The variable gpio is only used to store the return value of
> devm_gpiod_get_optional just to assign it to a member of the driver
> data.
> 
> Get rid of this local variable and assign to driver data directly.
> 
> Signed-off-by: Uwe Kleine-König 
> ---
>  drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c 
> b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> index e780fd4f8b46..1216341a0d19 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> @@ -205,13 +205,11 @@ static int panel_dpi_probe_of(struct platform_device 
> *pdev)
>   int r;
>   struct display_timing timing;
>   struct videomode vm;
> - struct gpio_desc *gpio;
>  
> - gpio = devm_gpiod_get_optional(>dev, "enable", GPIOD_OUT_LOW);
> - if (IS_ERR(gpio))
> - return PTR_ERR(gpio);
> -
> - ddata->enable_gpio = gpio;
> + ddata->enable_gpio = devm_gpiod_get_optional(>dev,
> +  "enable", GPIOD_OUT_LOW);
> + if (IS_ERR(ddata->enable_gpio))
> + return PTR_ERR(ddata->enable_gpio);
>  
>   ddata->backlight_gpio = -ENOENT;

I usually try to avoid writing bad values to fields. Here
ddata->enable_gpio may get an error ptr. It probably doesn't matter as
we bail out right away, but still. If devm_gpiod_get_optional's return
value would be NULL or valid gpio_desc*, then it'd be fine.

And the code is shorter (more readable) when using just "gpio" instead
of "ddata->enable_gpio".

So I'll leave this one out.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/5] fbdev: omap2: panel-dpi: in .disable first disable backlight then display

[Tomi Valkeinen]

On 10/12/15 15:11, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
> 
> This makes .disable operate in reverse order compared to .enable.
> 
> Signed-off-by: Uwe Kleine-König 
> ---
>  drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c 
> b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> index f7be3489f744..06b6e611e4b2 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> @@ -102,12 +102,12 @@ static void panel_dpi_disable(struct omap_dss_device 
> *dssdev)
>   if (!omapdss_device_is_enabled(dssdev))
>   return;
>  
> - if (ddata->enable_gpio)
> - gpiod_set_value_cansleep(ddata->enable_gpio, 0);
> -
>   if (gpio_is_valid(ddata->backlight_gpio))
>   gpio_set_value_cansleep(ddata->backlight_gpio, 0);
>  
> + if (ddata->enable_gpio)
> + gpiod_set_value_cansleep(ddata->enable_gpio, 0);
> +
>   in->ops.dpi->disable(in);
>  
>   dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
> 

Thanks, queued for 4.5.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 5/5] fbdev: omap2: panel-dpi: allow specification of a vcc regulator

[Tomi Valkeinen]

On 10/12/15 15:11, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
> 
> To allow supporting displays that need some logic to enable power to the
> display add support for a vcc-supply property to drive a regulator.
> 
> Signed-off-by: Uwe Kleine-König 
> ---
>  Documentation/devicetree/bindings/video/panel-dpi.txt |  1 +
>  drivers/video/fbdev/omap2/displays-new/panel-dpi.c| 13 +
>  2 files changed, 14 insertions(+)

Same comments here about the bindings.

> diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt 
> b/Documentation/devicetree/bindings/video/panel-dpi.txt
> index 1a1d8f6f884f..eaa39d1b1279 100644
> --- a/Documentation/devicetree/bindings/video/panel-dpi.txt
> +++ b/Documentation/devicetree/bindings/video/panel-dpi.txt
> @@ -8,6 +8,7 @@ Optional properties:
>  - label: a symbolic name for the panel
>  - enable-gpios: panel enable gpio
>  - reset-gpios: GPIO to control the RESET pin
> +- vcc-supply: phandle of regulator that will be used to enable power to the 
> display
>  
>  Required nodes:
>  - "panel-timing" containing video timings
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c 
> b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> index 7e2f9e0813dc..65c6d9e6862b 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -33,6 +34,7 @@ struct panel_drv_data {
>  
>   struct gpio_desc *enable_gpio;
>   struct gpio_desc *reset_gpio;
> + struct regulator *vcc_supply;
>  };
>  
>  #define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
> @@ -84,6 +86,12 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
>   if (r)
>   return r;
>  
> + r = regulator_enable(ddata->vcc_supply);
> + if (r) {
> + in->ops.dpi->disable(in);
> + return r;
> + }
> +
>   gpiod_set_value_cansleep(ddata->reset_gpio, 0);
>   gpiod_set_value_cansleep(ddata->enable_gpio, 1);
>  
> @@ -107,6 +115,7 @@ static void panel_dpi_disable(struct omap_dss_device 
> *dssdev)
>   gpio_set_value_cansleep(ddata->backlight_gpio, 0);
>  
>   gpiod_set_value_cansleep(ddata->enable_gpio, 0);
> + regulator_disable(ddata->vcc_supply);
>  
>   in->ops.dpi->disable(in);
>  
> @@ -218,6 +227,10 @@ static int panel_dpi_probe_of(struct platform_device 
> *pdev)
>   if (IS_ERR(ddata->reset_gpio))
>   return PTR_ERR(ddata->reset_gpio);
>  
> + ddata->vcc_supply = devm_regulator_get(>dev, "vcc");
> + if (IS_ERR(ddata->vcc_supply))
> + return PTR_ERR(ddata->vcc_supply);
> +
>   ddata->backlight_gpio = -ENOENT;
>  
>   r = of_get_display_timing(node, "panel-timing", );

Some panels might need to sleep before/after the regulator, but the same
goes for enable gpio. And we don't have a sane way to handle that at the
moment, so I think this is fine.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/5] fbdev: omap2: panel-dpi: simplify gpio setting

[Tomi Valkeinen]

On 10/12/15 15:11, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
> 
> gpiod_set_value_cansleep is a noop when the passed descriptor is NULL.
> So there is no need to duplicate the check for NULL; just call the
> function unconditionally instead.
> 
> Signed-off-by: Uwe Kleine-König 
> ---
>  drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c 
> b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> index 06b6e611e4b2..e780fd4f8b46 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> @@ -83,8 +83,7 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
>   if (r)
>   return r;
>  
> - if (ddata->enable_gpio)
> - gpiod_set_value_cansleep(ddata->enable_gpio, 1);
> + gpiod_set_value_cansleep(ddata->enable_gpio, 1);
>  
>   if (gpio_is_valid(ddata->backlight_gpio))
>   gpio_set_value_cansleep(ddata->backlight_gpio, 1);
> @@ -105,8 +104,7 @@ static void panel_dpi_disable(struct omap_dss_device 
> *dssdev)
>   if (gpio_is_valid(ddata->backlight_gpio))
>   gpio_set_value_cansleep(ddata->backlight_gpio, 0);
>  
> - if (ddata->enable_gpio)
> - gpiod_set_value_cansleep(ddata->enable_gpio, 0);
> + gpiod_set_value_cansleep(ddata->enable_gpio, 0);
>  
>   in->ops.dpi->disable(in);
>  
> 

Thanks, queued for 4.5.

Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/2] video:omap2:dss: fix timings for VENC to match what omapdrm expects

[Tomi Valkeinen]

On 13/12/15 20:41, H. Nikolaus Schaller wrote:

> Great that you did find the real reason of the problem.
> 
> I have tested it on the GTA04 and it also works.
> 
> Will the patches arrive in 4.5?

4.4, I hope.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/2] video:omap2:dss: fix timings for VENC to match what omapdrm expects

[Tomi Valkeinen]

On 13/11/15 12:29, H. Nikolaus Schaller wrote:
> Otherwise check_timings fails and we get a "has no modes" message
> from xrandr.
> 
> This fix makes the venc assume PAL and NTSC timings that match the
> timings synthetized by copy_timings_drm_to_omap() from omapdrm
> mode settings so that check_timings() succeeds.
> 
> Tested on: BeagleBoard XM, GTA04 and OpenPandora
> 
> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
> ---
>  drivers/video/fbdev/omap2/dss/venc.c | 12 
>  1 file changed, 12 insertions(+)

I've picked this up.

With this patch and the one below I can get tv-out working on my very old
beagleboard, and it seems to work with X also. It doesn't start automatically
as the connection state is unknown, but doing "xrandr --output None-1 --auto"
was all I needed to enable it.

 Tomi

From a4274600a5a67256b91266b0d2624b9c9028909b Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkei...@ti.com>
Date: Tue, 8 Dec 2015 18:32:14 +0200
Subject: [PATCH] drm/omap: fix fbdev pix format to support all platforms

omap_fbdev always creates a framebuffer with ARGB pixel format. On
OMAP3 we have VIDEO1 overlay that does not support ARGB, and on
OMAP2 none of the overlays support ARGB888.

This patch changes the omap_fbdev's fb to XRGB8888, which is supported
by all platforms.

Signed-off-by: Tomi Valkeinen <tomi.valkei...@ti.com>

diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index b8e4cdec28c3..24f92bea39c7 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -112,11 +112,8 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
dma_addr_t paddr;
int ret;
 
-   /* only doing ARGB32 since this is what is needed to alpha-blend
-* with video overlays:
-*/
sizes->surface_bpp = 32;
-   sizes->surface_depth = 32;
+   sizes->surface_depth = 24;
 
DBG("create fbdev: %dx%d@%d (%dx%d)", sizes->surface_width,
sizes->surface_height, sizes->surface_bpp,



signature.asc
Description: OpenPGP digital signature

Re: [patch] OMAPDSS: DSS: fix a warning message

[Tomi Valkeinen]

On 04/12/15 15:14, Dan Carpenter wrote:
> The WARN() macro has to take a condition.  The current code will just
> print the stack trace and the function name instead of the intended
> warning message.
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/video/fbdev/omap2/dss/dss.h 
> b/drivers/video/fbdev/omap2/dss/dss.h
> index 2406bcd..da3a85a 100644
> --- a/drivers/video/fbdev/omap2/dss/dss.h
> +++ b/drivers/video/fbdev/omap2/dss/dss.h
> @@ -343,7 +343,8 @@ u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt);
>  #else
>  static inline u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt)
>  {
> - WARN("%s: DSI not compiled in, returning pixel_size as 0\n", __func__);
> + WARN(1, "%s: DSI not compiled in, returning pixel_size as 0\n",
> +  __func__);
>   return 0;
>  }
>  #endif
> 

Thanks, queued for 4.5.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [patch] OMAPDSS: DSI: cleanup DSI_IRQ_ERROR_MASK define

[Tomi Valkeinen]

On 23/11/15 20:22, Dan Carpenter wrote:
> DSI_IRQ_SYNC_LOST was ORed twice so we can remove one.
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/video/fbdev/omap2/dss/dsi.c 
> b/drivers/video/fbdev/omap2/dss/dsi.c
> index b3606de..e86df6d 100644
> --- a/drivers/video/fbdev/omap2/dss/dsi.c
> +++ b/drivers/video/fbdev/omap2/dss/dsi.c
> @@ -144,7 +144,7 @@ struct dsi_reg { u16 module; u16 idx; };
>  #define DSI_IRQ_TA_TIMEOUT   (1 << 20)
>  #define DSI_IRQ_ERROR_MASK \
>   (DSI_IRQ_HS_TX_TIMEOUT | DSI_IRQ_LP_RX_TIMEOUT | DSI_IRQ_SYNC_LOST | \
> - DSI_IRQ_TA_TIMEOUT | DSI_IRQ_SYNC_LOST)
> + DSI_IRQ_TA_TIMEOUT)
>  #define DSI_IRQ_CHANNEL_MASK 0xf
>  
>  /* Virtual channel interrupts */
> 

Thanks, queued for 4.5.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] OMAPDSS: DISPC: Remove boolean comparisons

[Tomi Valkeinen]

On 15/10/15 15:29, Luis de Bethencourt wrote:
> Boolean tests do not need explicit comparison to true or false.
> 
> Signed-off-by: Luis de Bethencourt 
> ---
>  drivers/video/fbdev/omap2/dss/dispc-compat.c | 6 +++---
>  drivers/video/fbdev/omap2/dss/dispc.c| 6 +++---
>  drivers/video/fbdev/omap2/dss/manager.c  | 2 +-
>  3 files changed, 7 insertions(+), 7 deletions(-)
> 

Thanks, queued for 4.5.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/3] video: omapdss: delete unneeded of_node_put

[Tomi Valkeinen]

On 12/10/15 23:43, Julia Lawall wrote:
> Device node iterators perform an of_node_put on each iteration, so putting
> an of_node_put before a continue results in a double put.
> 
> A simplified version of the semantic match that finds this problem is as
> follows (http://coccinelle.lip6.fr):
> 
> // 
> @@
> expression root,e;
> local idexpression child;
> iterator i;
> @@
> 
>  i(..., child, ...) {
>... when != of_node_get(child)
> *  of_node_put(child);
>...
> *  continue;
> }
> // 
> 
> Signed-off-by: Julia Lawall 
> 
> ---
>  drivers/video/fbdev/omap2/dss/omapdss-boot-init.c |4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Thanks, queued for 4.5.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected

[Tomi Valkeinen]

On 13/11/15 12:29, H. Nikolaus Schaller wrote:
> Include VENC in the set of drivers where it is assimed that the cable
> is always connected. Like DPI, DSI, DBI and SDI do.
> 
> Otherwise, the VENC will return cable status "unknown" and is not enabled
> by the X-server. So there is no video output signal.
> 
> Tested on: BeagleBoard XM, GTA04 and OpenPandora
> 
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  drivers/gpu/drm/omapdrm/omap_connector.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
> b/drivers/gpu/drm/omapdrm/omap_connector.c
> index 83f2a91..98ddb5d 100644
> --- a/drivers/gpu/drm/omapdrm/omap_connector.c
> +++ b/drivers/gpu/drm/omapdrm/omap_connector.c
> @@ -120,6 +120,7 @@ static enum drm_connector_status omap_connector_detect(
>   else
>   ret = connector_status_disconnected;
>   } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
> + dssdev->type == OMAP_DISPLAY_TYPE_VENC ||
>   dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
>   dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
>   dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
> 

I have no idea why VENC is not working for you when using
connector_status_unknown, but I just tested DPI with
connector_status_unknown (i.e. changed the above func to return unknown
for DPI), and it works fine with X and X omap driver. And xrandr
confirms that the connection status is unknown:

# xrandr
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 2048 x 2048
HDMI-1 disconnected (normal left inverted right x axis y axis)
None-1 unknown connection 1920x1200+0+0 (normal left inverted right x
axis y axis) 0mm x 0mm
   1920x1200 60.00*+  60.00 +

Grep also shows that there are many drivers using
connector_status_unknown, so I'm guessing it should work fine...

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: DM3730 vs 3630 DSS Cock dividers

[Tomi Valkeinen]

On 16/10/15 13:23, Tomi Valkeinen wrote:

> Ok, so the clock data in the DT and the data in the dss are in sync and
> according to the TRM. So the patch in this thread is not correct.
> 
> How about 3730? Are we sure the dpll clocks are the same for 3730 and 3630?
> 
> So both 3730 and 3630 are failing the same way?
> 
> Hmm, wait... Beagle-xm has DM3730, right? It was working fine for me
> (until the whole board died, and you can't get new ones anymore =().

Could someone with a failing board post the boot log and these from
debugfs for both with and without the patch applied:

clk/clk_summary
omapdss/clk
omapdss/dss
omapdss/dispc

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: DM3730 vs 3630 DSS Cock dividers

[Tomi Valkeinen]

On 13/10/15 10:55, Tero Kristo wrote:

> TRMs are correct, 3630 does not have x2 multiplier after DPLL4.
> 
> In the clock data, dpll4_m4x2 path is an x1 multiplier on omap3630, it
> is easier to represent this in DT than completely remove the dpll4_*x2
> nodes for omap36xx. This is how it was already before the DT clocks.
> 
> Here is a copy paste from clock debug data on omap36xx where you see the
> rate for the whole dpll4_m4 path is 96MHz:
> 
>  dpll4_m4_ck  019600
>0 0
> dpll4_m4x2_mul_ck   019600
>  0 0
>dpll4_m4x2_ck   019600
> 0 0
>   dss1_alwon_fck_3430es2   04  
> 9600  0 0
> 
> And same on omap34xx (not sure why the clock rate is totally different
> here though, but you see the x2 applied):
> 
>  dpll4_m4_ck  01   21600
>0
> 0
> dpll4_m4x2_mul_ck   01   43200
> 0 0
>dpll4_m4x2_ck   01   43200
> 0
>  0

Ok, so the clock data in the DT and the data in the dss are in sync and
according to the TRM. So the patch in this thread is not correct.

How about 3730? Are we sure the dpll clocks are the same for 3730 and 3630?

So both 3730 and 3630 are failing the same way?

Hmm, wait... Beagle-xm has DM3730, right? It was working fine for me
(until the whole board died, and you can't get new ones anymore =().

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: DM3730 vs 3630 DSS Cock dividers

[Tomi Valkeinen]

On 12.10.2015 19:00, Tony Lindgren wrote:

* Adam Ford  [151010 13:29]:

Tomi and Tony,

I am working on the LogicPD DM3730 Torpedo module.  If I try to use the
DSS, I get the same errors as mentioned in these previous messages found
here:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/255103.html

The patch is basicaly:


* >>  drivers/video/fbdev/omap2/dss/dss.c | 5 +++--

*>* >>  1 file changed, 3 insertions(+), 2 deletions(-)
*>* >>
*>* >> diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
*>* >> index d55266c..ad6561f 100644
*>* >> --- a/drivers/video/fbdev/omap2/dss/dss.c
*>* >> +++ b/drivers/video/fbdev/omap2/dss/dss.c
*>* >> @@ -707,9 +707,10 @@ static const struct dss_features
omap34xx_dss_feats __initconst = {
*>* >>   .dpi_select_source  =   _dpi_select_source_omap2_omap3,
*>* >>  };
*>* >>
*>* >> +/* Supposedly 3630 can use div 32 mult 2, but that needs to be
rechecked */
*>* >>  static const struct dss_features omap3630_dss_feats __initconst = {
*>* >> - .fck_div_max=   32,
*>* >> - .dss_fck_multiplier =   1,
*>* >> + .fck_div_max=   16,
*>* >> + .dss_fck_multiplier =   2,
*>* >
*>* > These values tell about the clock hardware, they are not settings that
*>* > can be changed to change the clock. OMAP3630 has a fixed x2 multiplier
*>* > and a divider with maximum value of 16.
*>* >
*>* >  Tomi
*>* >
*>* >*


I don't see this mainstream yet, but the patch is from a while ago.
Do you guys know if this will make it into the kernel?  Without it, I
cannot the DM3730 to DSS to operate correctly.


AFAIK 37xx is same as 3630 and does not work properly without the patch
above as we've seen.


Well, the patch is definitely wrong for 3630, as 3630 has divider range 
from 1 to 32, as seen from the CM_CLKSEL_DSS register.


I can't find the fixed x2 multiplier from the TRM, but looking at the 
.dts files, 3630 DSS gets the clock from dpll4_m4x2_ck, so maybe it is 
there. Or maybe the clocks in the .dts files are wrong, and the 
multplier in dss.c is right.


And looking at the TRM, "3.5.3.3.4 DPLL Clock Summary" hints strongly 
that there is no x2 multiplier there, so it might be that the dts clock 
files are not right.


Unfortunately I have no working omap3 devices to test this =(.

 Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: dts: am57xx-beagle-x15: set VDD_SD to always-on

[Tomi Valkeinen]

LDO1 regulator (VDD_SD) is connected to SoC's vddshv8. vddshv8 needs to
be kept always powered (see commit 5a0f93c6576a ("ARM: dts: Add
am57xx-beagle-x15"), but at the moment VDD_SD is enabled/disabled
depending on whether an SD card is inserted or not.

This patch sets LDO1 regulator to always-on.

This patch has a side effect of fixing another issue, HDMI DDC not
working when SD card is not inserted:

Why this happens is that the tpd12s015 (HDMI level shifter/ESD
protection chip) has LS_OE GPIO input, which needs to be enabled for the
HDMI DDC to work. LS_OE comes from gpio6_28. The pin that provides
gpio6_28 is powered by vddshv8, and vddshv8 comes from VDD_SD.

So when SD card is not inserted, VDD_SD is disabled, and LS_OE stays
off.

The proper fix for the HDMI DDC issue would be to maybe have the pinctrl
framework manage the pin specific power.

Apparently this fixes also a third issue (copy paste from Kishon's
patch):

ldo1_reg in addition to being connected to the io lines is also
connected to the card detect line. On card removal, omap_hsmmc
driver does a regulator_disable causing card detect line to be
pulled down. This raises a card insertion interrupt and once the
MMC core detects there is no card inserted, it does a
regulator disable which again raises a card insertion interrupt.
This happens in a loop causing infinite MMC interrupts.

Fixes: 5a0f93c6576a ("ARM: dts: Add am57xx-beagle-x15")
Cc: Kishon Vijay Abraham I <kis...@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkei...@ti.com>
Reported-by: Louis McCarthy <compeo...@gmail.com>
---
 arch/arm/boot/dts/am57xx-beagle-x15.dts | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 3a05b94f59ed..ba8ef66a16e0 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -415,11 +415,12 @@
/* SMPS9 unused */
 
ldo1_reg: ldo1 {
-   /* VDD_SD  */
+   /* VDD_SD / VDDSHV8  */
regulator-name = "ldo1";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <330>;
regulator-boot-on;
+   regulator-always-on;
};
 
ldo2_reg: ldo2 {
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 28/38] video/omap: remove invalid check

[Tomi Valkeinen]

On 21/09/15 16:34, Andrzej Hajda wrote:
> regno is unsigned so it cannot be negative.
> 
> The problem has been detected using proposed semantic patch
> scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
> 
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/video/fbdev/omap/omapfb_main.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/video/fbdev/omap/omapfb_main.c 
> b/drivers/video/fbdev/omap/omapfb_main.c
> index 1fb3ea3..393ae1b 100644
> --- a/drivers/video/fbdev/omap/omapfb_main.c
> +++ b/drivers/video/fbdev/omap/omapfb_main.c
> @@ -276,11 +276,6 @@ static int _setcolreg(struct fb_info *info, u_int regno, 
> u_int red, u_int green,
>   if (r != 0)
>   break;
>  
> - if (regno < 0) {
> - r = -EINVAL;
> - break;
> - }
> -
>   if (regno < 16) {
>   u16 pal;
>   pal = ((red >> (16 - var->red.length)) <<
> 

Thanks, queued for 4.4.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2] fbdev: omap2: connector-dvi: use of_get_i2c_adapter_by_node interface

[Tomi Valkeinen]

On 15/09/15 16:12, Vladimir Zapolskiy wrote:
> This change is needed to properly lock I2C bus driver, which serves DDC.
> 
> Prior to this change i2c_put_adapter() is misused, which may lead to
> an overflow over zero of I2C bus driver user counter.
> 
> Signed-off-by: Vladimir Zapolskiy 
> ---
> Changes from v1 to v2:
> - none, v1 is 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354990.html
> 
> The original series 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354982.html
> is separated to i2c, dri and fbdev parts, at the moment i2c part
> with new of_get_i2c_adapter_by_node() interface has been applied.
> 
>  drivers/video/fbdev/omap2/displays-new/connector-dvi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/omap2/displays-new/connector-dvi.c 
> b/drivers/video/fbdev/omap2/displays-new/connector-dvi.c
> index a8ce920..d811e6d 100644
> --- a/drivers/video/fbdev/omap2/displays-new/connector-dvi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/connector-dvi.c
> @@ -294,7 +294,7 @@ static int dvic_probe_of(struct platform_device *pdev)
>  
>   adapter_node = of_parse_phandle(node, "ddc-i2c-bus", 0);
>   if (adapter_node) {
> - adapter = of_find_i2c_adapter_by_node(adapter_node);
> + adapter = of_get_i2c_adapter_by_node(adapter_node);
>   if (adapter == NULL) {
>   dev_err(>dev, "failed to parse ddc-i2c-bus\n");
>   omap_dss_put_device(ddata->in);
> 

Thanks, queued for 4.3 fixes.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] omapdss: acx565akm: Fix module autoload for OF platform driver

[Tomi Valkeinen]

On 18/09/15 21:44, Luis de Bethencourt wrote:
> This platform driver has a OF device ID table but the OF module
> alias information is not created so module autoloading won't work.
> 
> Signed-off-by: Luis de Bethencourt 
> ---
> 
> Hello,
> 
> This patch adds the missing MODULE_DEVICE_TABLE() for OF to export
> that information so modules have the correct aliases built-in and
> autoloading works correctly.
> 
> A longer explanation by Javier Canillas can be found here:
> https://lkml.org/lkml/2015/7/30/519
> 
> Thanks,
> Luis
> 
>  drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c 
> b/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
> index 90cbc4c..c581231 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
> @@ -898,6 +898,7 @@ static const struct of_device_id acx565akm_of_match[] = {
>   { .compatible = "omapdss,sony,acx565akm", },
>   {},
>  };
> +MODULE_DEVICE_TABLE(of, acx565akm_of_match);
>  
>  static struct spi_driver acx565akm_driver = {
>   .driver = {
> 

Thanks, queued for 4.3 fixes.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH] omapdss: acx565akm: Fix module autoload for OF platform driver

[Tomi Valkeinen]

On 24/09/15 13:17, Tomi Valkeinen wrote:
> 
> 
> On 18/09/15 21:44, Luis de Bethencourt wrote:
>> This platform driver has a OF device ID table but the OF module
>> alias information is not created so module autoloading won't work.
>>
>> Signed-off-by: Luis de Bethencourt <lui...@osg.samsung.com>
>> ---
>>
>> Hello,
>>
>> This patch adds the missing MODULE_DEVICE_TABLE() for OF to export
>> that information so modules have the correct aliases built-in and
>> autoloading works correctly.
>>
>> A longer explanation by Javier Canillas can be found here:
>> https://lkml.org/lkml/2015/7/30/519
>>
>> Thanks,
>> Luis
>>
>>  drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c 
>> b/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
>> index 90cbc4c..c581231 100644
>> --- a/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
>> +++ b/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
>> @@ -898,6 +898,7 @@ static const struct of_device_id acx565akm_of_match[] = {
>>  { .compatible = "omapdss,sony,acx565akm", },
>>  {},
>>  };
>> +MODULE_DEVICE_TABLE(of, acx565akm_of_match);
>>  
>>  static struct spi_driver acx565akm_driver = {
>>  .driver = {
>>
> 
> Thanks, queued for 4.3 fixes.

Oh, there was an earlier patch from Javier already posted. So I'll pick
that one instead.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v4] OMAPDSS: hdmi: Reconfigure and restart audio when display is enabled

[Tomi Valkeinen]

On 28/08/15 17:21, Jyri Sarha wrote:
> Reconfigure and restart audio when display is enabled, if audio
> playback was active before. This is needed in a situation when an
> audio+video stream application opens the audio stream before the
> video. When video stream is opened the display mode may change and
> that aborts audio playback, because the display is momentarily
> turned off.
> 
> The audio configuration is stored when it is successfully applied and
> a boolean is set when the audio playback is started and unset when
> stopped. This data is used to reconfigure the audio when display is
> re-enabled. The audio playback is aborted if the reconfiguration fails.
> 
> A new spin lock is introduced in order to protect state variables
> related to audio playback status. This is needed for the transition
> from display enabled state (when audio start/stop commands can be
> written to HW) to display disabled state (when audio start/stop
> commands update only the hdmi.audio_playing variable) to always
> serialize correctly with the start/stop audio commands. The already
> existing mutex can not be used, because the audio start and stop
> commands are executed in atomic context.
> 
> For example: when display is turned back on we take the spinlock and
> we can be sure that the audio start/stop status will not change while
> we update the HW according to hdmi.audio_playing state and set
> hdmi.display_enabled to true. After releasing the lock
> hdmi.display_enabled is true and all audio_start and audio_stop
> commands write their stuff directly to HW.
> 
> Signed-off-by: Jyri Sarha 
> ---
> Fixed one bad sentece in the description.
> 
>  drivers/video/fbdev/omap2/dss/hdmi.h  |  9 -
>  drivers/video/fbdev/omap2/dss/hdmi4.c | 66 +-
>  drivers/video/fbdev/omap2/dss/hdmi5.c | 76 
> ---
>  3 files changed, 124 insertions(+), 27 deletions(-)

Thanks, I've queued this for 4.4.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/2] OMAPDSS: hdmi: Reconfigure and restart audio when display is enabled

[Tomi Valkeinen]

On 26/08/15 16:11, Jyri Sarha wrote:

 diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c 
 b/drivers/video/fbdev/omap2/dss/hdmi5.c
 index 7f87578..f352c4b 100644
 --- a/drivers/video/fbdev/omap2/dss/hdmi5.c
 +++ b/drivers/video/fbdev/omap2/dss/hdmi5.c
 @@ -352,6 +352,7 @@ static int read_edid(u8 *buf, int len)
  static int hdmi_display_enable(struct omap_dss_device *dssdev)
  {
   struct omap_dss_device *out = hdmi.output;
 + unsigned long flags;
   int r = 0;
  
   DSSDBG(ENTER hdmi_display_enable\n);
 @@ -370,7 +371,37 @@ static int hdmi_display_enable(struct omap_dss_device 
 *dssdev)
   goto err0;
   }
  
 + if (hdmi.audio_configured) {
 + spin_lock_irqsave(hdmi.audio_playing_lock, flags);
 + hdmi_wp_audio_core_req_enable(hdmi.wp, false);
 + hdmi_wp_audio_enable(hdmi.wp, false);
 + if (hdmi.wp_idlemode  0)
 + REG_FLD_MOD(hdmi.wp.base, HDMI_WP_SYSCONFIG,
 + hdmi.wp_idlemode, 3, 2);
 + hdmi.wp_idlemode = -1;
 + spin_unlock_irqrestore(hdmi.audio_playing_lock, flags);

Here I think the audio HW is always disabled already. It has to be,
because the whole HDMI IP has been off. So the above should not be needed.

 +
 + r = hdmi5_audio_config(hdmi.core, hdmi.wp, hdmi.audio_config,
 +hdmi.cfg.timings.pixelclock);
 + if (r) {
 + DSSERR(Error restoring audio configuration: %d, r);
 + hdmi.audio_abort_cb(hdmi.pdev-dev);
 + hdmi.audio_configured = false;
 + }
 + }
 +
 + spin_lock_irqsave(hdmi.audio_playing_lock, flags);
 + if (hdmi.audio_configured  hdmi.audio_playing) {
 + /* No-idle while playing audio, store the old value */
 + hdmi.wp_idlemode =
 + REG_GET(hdmi.wp.base, HDMI_WP_SYSCONFIG, 3, 2);
 + REG_FLD_MOD(hdmi.wp.base, HDMI_WP_SYSCONFIG, 1, 3, 2);
 +
 + hdmi_wp_audio_enable(hdmi.wp, true);
 + hdmi_wp_audio_core_req_enable(hdmi.wp, true);
 + }
   hdmi.display_enabled = true;
 + spin_unlock_irqrestore(hdmi.audio_playing_lock, flags);

Maybe you've looked at the locking carefully, but it's not obvious to
me. So is hdmi_audio_start and hdmi_audio_stop the only functions that
are called from atomic context? Every other function is protected with
the mutex?

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2] OMAPDSS: hdmi: Reconfigure and restart audio when display is enabled

[Tomi Valkeinen]

Hi,

On 28/08/15 15:24, Jyri Sarha wrote:
 Reconfigure and restart audio when display is enabled, if audio
 playback was active before. The audio configuration is stored when is

'is' - 'it' above

 is successfully applied and a boolean is set when playback has started
 and unset when stopped. This data is used to reconfigure the audio
 when display is re-enabled. Abort audio playback if reconfiguration
 fails.

It would be good to start the description by telling what the current
problem is. And probably the subject could also be better... This fixes
the audio playback when a video mode change happens (or such), right?

 A new spin lock is introduced in order to protect state variables
 related to audio playback status. This is needed for the transitions
 from display enabled state (when audio start/stop commands can be
 written to HW) to display disabled state (when audio start/stop
 commands update only the hdmi.audio_playing variable) to always
 serialize correctly with the start/stop audio commands.
 
 For example: when display is turned back on we take the spinlock and
 we can be sure that the audio start/stop status won't change while we
 update the HW according to hdmi.audio_playing state and set
 hdmi.display_enabled to true. After releasing the lock
 hdmi.display_enabled is true and all audio_start and audio_stop
 commands write their stuff directly to HW.

The question is (which was my point in the earlier mail), we already
have mutex, so why a new spinlock?

I think the answer is that audio start/stop (anything else?) are called
in atomic context, so mutex cannot be used.

Also (not exactly related to this patch), if the audio callbacks must be
atomic, could we use a workqueue to run the audio start/stop work in
non-atomic context? Protecting the whole hdmi state with a single mutex
would be much nicer.

 Signed-off-by: Jyri Sarha jsa...@ti.com
 ---
 I dropped the ASoC maintainers from the recipient list as this patch
 hardly concerns them.
 
  drivers/video/fbdev/omap2/dss/hdmi.h  |  9 +++-
  drivers/video/fbdev/omap2/dss/hdmi4.c | 69 +-
  drivers/video/fbdev/omap2/dss/hdmi5.c | 79 
 ---
  3 files changed, 130 insertions(+), 27 deletions(-)
 
 diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h 
 b/drivers/video/fbdev/omap2/dss/hdmi.h
 index e4a32fe..e48aefd 100644
 --- a/drivers/video/fbdev/omap2/dss/hdmi.h
 +++ b/drivers/video/fbdev/omap2/dss/hdmi.h
 @@ -351,13 +351,20 @@ struct omap_hdmi {
   struct regulator *vdda_reg;
  
   bool core_enabled;
 - bool display_enabled;
  
   struct omap_dss_device output;
  
   struct platform_device *audio_pdev;
   void (*audio_abort_cb)(struct device *dev);
   int wp_idlemode;
 +
 + bool audio_configured;
 + struct omap_dss_audio audio_config;
 +
 + /* This lock should be taken when booleas bellow is touched. */

typo above.

Otherwise, looks much cleaner than the previous one. I tested it and
worked fine for me: I could play audio while turning on and off the
video output, and the audio would resume, except when the video was off
for long enough.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/2] OMAPDSS: hdmi: Reconfigure and restart audio when display is enabled

[Tomi Valkeinen]

Hi,

On 26/08/15 16:11, Jyri Sarha wrote:

I few comments, for the parts I had time to review:

 diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c 
 b/drivers/video/fbdev/omap2/dss/hdmi5.c
 index 7f87578..f352c4b 100644
 --- a/drivers/video/fbdev/omap2/dss/hdmi5.c
 +++ b/drivers/video/fbdev/omap2/dss/hdmi5.c
 @@ -352,6 +352,7 @@ static int read_edid(u8 *buf, int len)
  static int hdmi_display_enable(struct omap_dss_device *dssdev)
  {
   struct omap_dss_device *out = hdmi.output;
 + unsigned long flags;
   int r = 0;
  
   DSSDBG(ENTER hdmi_display_enable\n);
 @@ -370,7 +371,37 @@ static int hdmi_display_enable(struct omap_dss_device 
 *dssdev)
   goto err0;
   }
  

I think you could refactor parts of the code below into small helper
functions:

 + if (hdmi.audio_configured) {
 + spin_lock_irqsave(hdmi.audio_playing_lock, flags);
 + hdmi_wp_audio_core_req_enable(hdmi.wp, false);
 + hdmi_wp_audio_enable(hdmi.wp, false);
 + if (hdmi.wp_idlemode  0)
 + REG_FLD_MOD(hdmi.wp.base, HDMI_WP_SYSCONFIG,
 + hdmi.wp_idlemode, 3, 2);
 + hdmi.wp_idlemode = -1;

The above looks like it's disabling audio output, the same that's done
in hdmi_audio_stop(). Adding a helper func for that makes the code more
readable.

For the wp_idlemode, I think hdmi.wp_idlemode could be initialized to a
valid value, so that it can be set at any time without the if check above.

 + spin_unlock_irqrestore(hdmi.audio_playing_lock, flags);
 +
 + r = hdmi5_audio_config(hdmi.core, hdmi.wp, hdmi.audio_config,
 +hdmi.cfg.timings.pixelclock);
 + if (r) {
 + DSSERR(Error restoring audio configuration: %d, r);
 + hdmi.audio_abort_cb(hdmi.pdev-dev);
 + hdmi.audio_configured = false;
 + }
 + }
 +
 + spin_lock_irqsave(hdmi.audio_playing_lock, flags);
 + if (hdmi.audio_configured  hdmi.audio_playing) {
 + /* No-idle while playing audio, store the old value */
 + hdmi.wp_idlemode =
 + REG_GET(hdmi.wp.base, HDMI_WP_SYSCONFIG, 3, 2);
 + REG_FLD_MOD(hdmi.wp.base, HDMI_WP_SYSCONFIG, 1, 3, 2);
 +
 + hdmi_wp_audio_enable(hdmi.wp, true);
 + hdmi_wp_audio_core_req_enable(hdmi.wp, true);

And here maybe a helper func to enable the audio output.

 + }

   hdmi.display_enabled = true;
 + spin_unlock_irqrestore(hdmi.audio_playing_lock, flags);
  
   mutex_unlock(hdmi.lock);
   return 0;
 @@ -382,17 +413,18 @@ err0:
  
  static void hdmi_display_disable(struct omap_dss_device *dssdev)
  {
 + unsigned long flags;
 +
   DSSDBG(Enter hdmi_display_disable\n);
  
   mutex_lock(hdmi.lock);
  
 - if (hdmi.audio_pdev  hdmi.audio_abort_cb)
 - hdmi.audio_abort_cb(hdmi.audio_pdev-dev);
 + spin_lock_irqsave(hdmi.audio_playing_lock, flags);
 + hdmi.display_enabled = false;
 + spin_unlock_irqrestore(hdmi.audio_playing_lock, flags);

Shouldn't something be done here in hdmi_display_disable about audio?
You probably want to keep the state flag enabled, so that we know the
user is playing audio, but you could still disable the HDMI audio HW.
I'm sure the audio output dies when the video is disabled, but being
more explicit here makes the code logic easier to follow.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: omapdss: Division by zero in kernel

[Tomi Valkeinen]

On 24/07/15 19:03, Pali Rohár wrote:
 Hello,
 
 when on N900 (real HW or qemu) I run this command
 
 / # echo 0  /sys/devices/platform/omapdss/overlay0/enabled  echo 0  
 /sys/class/graphics/fb0/size
 
 then kernel crash with this error message
 
 / # [   29.904113] Division by zero in kernel.

The problem is that fb console uses the kernel mmapped framebuffer, but
omapfb is not aware of the fb console. So the above commands free the
framebuffer, as omapfb thinks no one is using it, and then fb console
tries to touch the fb.

omapfb tracks mmaps from userspace, and refuses to free a fb it it's
mmapped.

I don't know how to fix it straight away. Maybe there's a way for omapfb
to check if the fbcon uses the fb in question, and if so, refuses to
release/resize the memory.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: omapdss: Division by zero in kernel

[Tomi Valkeinen]

On 21/08/15 11:48, Pali Rohár wrote:
 On Friday 21 August 2015 11:42:14 Tomi Valkeinen wrote:


 On 24/07/15 19:03, Pali Rohár wrote:
 Hello,

 when on N900 (real HW or qemu) I run this command

 / # echo 0  /sys/devices/platform/omapdss/overlay0/enabled  echo 0  
 /sys/class/graphics/fb0/size

 then kernel crash with this error message

 / # [   29.904113] Division by zero in kernel.

 
 Hi! Thanks for explaining.
 
 The problem is that fb console uses the kernel mmapped framebuffer, but
 omapfb is not aware of the fb console. So the above commands free the
 framebuffer, as omapfb thinks no one is using it, and then fb console
 tries to touch the fb.

 
 What about refusing those calls from fb console? So fb console will not
 know about this problem and omapfb will just ignore drawn functions?

Hmm, I'm not sure I understand what you mean... omapfb is not drawing
anything, fbcon is doing the drawing independently to the fb. And the fb
suddenly disappears without fbcon realizing that.

 omapfb tracks mmaps from userspace, and refuses to free a fb it it's
 mmapped.

 I don't know how to fix it straight away. Maybe there's a way for omapfb
 to check if the fbcon uses the fb in question, and if so, refuses to
 release/resize the memory.

  Tomi

 
 Maemo userspace (on Nokia N900) uses above commands to initialize
 graphic and Xserver. So it would be nice if disabling framebuffer would
 work even if fbcon.ko is loaded (or compiled directly into zImage).

Ok. And N900 has fbcon enabled? I wonder how it survives...

fbcon can be unbound from userspace with something like:

echo 0  /sys/class/vtconsole/vtcon1/bind

After that I think the memory can be freed.

But obviously the kernel should not crash here, no question about that.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Drop owner assignment from i2c_driver (and platform left-overs)

[Tomi Valkeinen]

On 10/07/15 09:37, Krzysztof Kozlowski wrote:
 Hi,
 
 
 The i2c drivers also do not have to set 'owner' field because
 i2c_register_driver() will do it instead.
 
 'owner' is removed from i2c drivers, which I was able to compile
 with allyesconfig (arm, arm64, i386, x86_64, ppc64).
 Only compile-tested.
 
 The coccinelle script which generated the patch was sent here:
 http://www.spinics.net/lists/kernel/msg2029903.html
 
 
 Best regards,
 Krzysztof
 
 
 Krzysztof Kozlowski (2):
   video: fbdev: Drop owner assignment from i2c_driver
   video: fbdev: Drop owner assignment from platform_driver
 
  drivers/video/fbdev/omap2/displays-new/encoder-opa362.c | 1 -
  drivers/video/fbdev/ssd1307fb.c | 1 -
  2 files changed, 2 deletions(-)
 

Thanks, queued for 4.3.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2 0/2] OMAPDSS: Fix of-node refcount issues

[Tomi Valkeinen]

On 07/08/15 14:04, Jyri Sarha wrote:
 Changes since the first version:
 - Fix commit descriptions and subject according to Tomi's comments
 
 I found couple of refcounting issues related to OMAP DSS of-node
 handling. Second patch should fix the ERROR: Bad of_node_put() on
 /encoder@0/ports/port@1 -problem.
 
 In the long run it would make sense start using of_graph_*() functions
 in OMAP DSS too. However the semantics of of_graph_*() functions are
 quite different from omapdss_of_*() counterparts. So it better to just
 fix these bugs first.
 
 Jyri Sarha (2):
   OMAPDSS: Fix node refcount leak in omapdss_of_get_next_port()
   OMAPDSS: Fix omap_dss_find_output_by_port_node() port refcount
 decrement
 
  drivers/video/fbdev/omap2/dss/dss-of.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

Thanks, I've picked these up for 4.2 fixes.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/2] OMAPDSS: of-dss: omap_dss_find_output_by_port_node() keep port refcount

[Tomi Valkeinen]

Hi,

On 06/08/15 21:41, Jyri Sarha wrote:
 The only user of dss_of_port_get_parent_device() function is
 omap_dss_find_output_by_port_node() and it assumes the refcount of the
 port parameter is not decremented by the call.
 

The subject of the patch should contain dss-of, not of-dss. Although
for both patches I think it's fine to use plain OMAPDSS:  prefix. The
subject should also say fix or such.

The description above is kind of detached. A patch description should
generally describe something in the lines of what the current behavior
is, what the problem is, and what the patch does. And the desc should be
independent of the subject.

This particular case is rather simple, and it's clear that
dss_of_port_get_parent_device() is not supposed to decrease the refcount
of the port parameter (as that kind of behavior is normally a special
case). And so it should be enough to say what the issue seen is and that
you fix the function to not decrement the parameter's refcount.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/2] OMAPDSS: dss-of: Fix node refcount leak in omapdss_of_get_next_port()

[Tomi Valkeinen]

On 06/08/15 21:41, Jyri Sarha wrote:
 Signed-off-by: Jyri Sarha jsa...@ti.com

Please always fill in the patch description. In simplest cases it may be
the same as in the subject.

 ---
  drivers/video/fbdev/omap2/dss/dss-of.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/drivers/video/fbdev/omap2/dss/dss-of.c 
 b/drivers/video/fbdev/omap2/dss/dss-of.c
 index 928ee63..ab6ef16 100644
 --- a/drivers/video/fbdev/omap2/dss/dss-of.c
 +++ b/drivers/video/fbdev/omap2/dss/dss-of.c
 @@ -60,6 +60,7 @@ omapdss_of_get_next_port(const struct device_node *parent,
   }
   prev = port;
   } while (of_node_cmp(port-name, port) != 0);
 + of_node_put(ports);

I think a blank line is needed above of_node_put().

 Tomi



signature.asc
Description: OpenPGP digital signature

[PATCH] ARM: dts: am4372.dtsi: disable rfbi

[Tomi Valkeinen]

When DSS nodes were added to am4372.dtsi, the rfbi node was not marked
as disabled. This should have been done, as the rule of thumb is to
disable all DSS nodes that are not used, and especially rfbi, as we
don't have a driver for rfbi.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 arch/arm/boot/dts/am4372.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index c80a3e233792..75831e556741 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -941,6 +941,7 @@
ti,hwmods = dss_rfbi;
clocks = disp_clk;
clock-names = fck;
+   status = disabled;
};
};
 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 11/11] OMAPDSS: HDMI: wait for framedone when stopping video

[Tomi Valkeinen]

At the moment when HDMI video output is stopped, we just clear the
enable bit and return. While it's unclear if this can cause any issues,
I think it's still better to wait for FRAMEDONE interrupt after clearing
the enable bit so that we're sure the HDMI IP has finished.

As we don't have any ready-made irq handling for HDMI, and this only
needs to be done when disabling the HDMI output, this patch implements a
simple loop with sleep, polling the FRAMEDONE bit.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/fbdev/omap2/dss/hdmi_wp.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/video/fbdev/omap2/dss/hdmi_wp.c 
b/drivers/video/fbdev/omap2/dss/hdmi_wp.c
index c15377e242cc..7c544bc56fb5 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi_wp.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi_wp.c
@@ -110,7 +110,23 @@ int hdmi_wp_video_start(struct hdmi_wp_data *wp)
 
 void hdmi_wp_video_stop(struct hdmi_wp_data *wp)
 {
+   int i;
+
+   hdmi_write_reg(wp-base, HDMI_WP_IRQSTATUS, HDMI_IRQ_VIDEO_FRAME_DONE);
+
REG_FLD_MOD(wp-base, HDMI_WP_VIDEO_CFG, false, 31, 31);
+
+   for (i = 0; i  50; ++i) {
+   u32 v;
+
+   msleep(20);
+
+   v = hdmi_read_reg(wp-base, HDMI_WP_IRQSTATUS_RAW);
+   if (v  HDMI_IRQ_VIDEO_FRAME_DONE)
+   return;
+   }
+
+   DSSERR(no HDMI FRAMEDONE when disabling output\n);
 }
 
 void hdmi_wp_video_config_format(struct hdmi_wp_data *wp,
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 05/11] OMAPDSS: DISPC: fix row_inc for OMAP3

[Tomi Valkeinen]

pixel_inc and row_inc work differently on OMAP2/3 and OMAP4+ DSS. On
OMAP2/3 DSS, the pixel_inc is _not_ added by the HW at the end of the
line, after the last pixel, whereas on OMAP4+ it is.

The driver currently works for OMAP4+, but does not handle OMAP2/3
correctly, which leads to tilted image when row_inc is used.

This patch adds a flag to DISPC driver so that the pixel_inc is added
when required.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/fbdev/omap2/dss/dispc.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/video/fbdev/omap2/dss/dispc.c 
b/drivers/video/fbdev/omap2/dss/dispc.c
index ddce8fcfc5c1..4488d9367bd3 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -95,6 +95,9 @@ struct dispc_features {
bool mstandby_workaround:1;
 
bool set_max_preload:1;
+
+   /* PIXEL_INC is not added to the last pixel of a line */
+   bool last_pixel_inc_missing:1;
 };
 
 #define DISPC_MAX_NR_FIFOS 5
@@ -2692,6 +2695,9 @@ static int dispc_ovl_setup_common(enum omap_plane plane,
dispc_ovl_set_ba1_uv(plane, p_uv_addr + offset1);
}
 
+   if (dispc.feat-last_pixel_inc_missing)
+   row_inc += pix_inc - 1;
+
dispc_ovl_set_row_inc(plane, row_inc);
dispc_ovl_set_pix_inc(plane, pix_inc);
 
@@ -3769,6 +3775,7 @@ static const struct dispc_features omap24xx_dispc_feats 
__initconst = {
.num_fifos  =   3,
.no_framedone_tv=   true,
.set_max_preload=   false,
+   .last_pixel_inc_missing =   true,
 };
 
 static const struct dispc_features omap34xx_rev1_0_dispc_feats __initconst = {
@@ -3789,6 +3796,7 @@ static const struct dispc_features 
omap34xx_rev1_0_dispc_feats __initconst = {
.num_fifos  =   3,
.no_framedone_tv=   true,
.set_max_preload=   false,
+   .last_pixel_inc_missing =   true,
 };
 
 static const struct dispc_features omap34xx_rev3_0_dispc_feats __initconst = {
@@ -3809,6 +3817,7 @@ static const struct dispc_features 
omap34xx_rev3_0_dispc_feats __initconst = {
.num_fifos  =   3,
.no_framedone_tv=   true,
.set_max_preload=   false,
+   .last_pixel_inc_missing =   true,
 };
 
 static const struct dispc_features omap44xx_dispc_feats __initconst = {
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/11] OMAPDSS: HDMI4: fix error handling

[Tomi Valkeinen]

Error handling in hdmi_power_on_full() is not correct, and could leave
resources unfreed.

Fix this by arranging the error labels correctly.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/fbdev/omap2/dss/hdmi4.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c 
b/drivers/video/fbdev/omap2/dss/hdmi4.c
index 916d47978f41..e1345abd41bb 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi4.c
@@ -229,9 +229,9 @@ static int hdmi_power_on_full(struct omap_dss_device 
*dssdev)
 err_mgr_enable:
hdmi_wp_video_stop(hdmi.wp);
 err_vid_enable:
-err_phy_cfg:
hdmi_wp_set_phy_pwr(hdmi.wp, HDMI_PHYPWRCMD_OFF);
 err_phy_pwr:
+err_phy_cfg:
 err_pll_cfg:
dss_pll_disable(hdmi.pll.pll);
 err_pll_enable:
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/11] OMAPDSS: DISPC: do only y decimation on OMAP3

[Tomi Valkeinen]

The current driver does both x and y decimation on OMAP3 DSS. Testing
shows that x decimation rarely works, leading to underflows.

The exact reason for this is unclear, as the underflows seem to happen
even with low pixel clock rates, and I would presume that if the DSS can
manage a display with 140MHz pixel clock, it could manage x decimation
with factor 2 with a low pixel clock (~30MHz).

So it is possible that there is a problem somewhere else, in memory
management, or DSS DMA, or similar. I have not found anything that would
help this.

So, to fix the downscaling scaling, this patch removes x decimation for
OMAP3. This will limit some of the more demanding downscaling scenarios,
but one could argue that using DSS to downscale such a large amount is
insane in the first place, as the produced image is rather bad quality.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/fbdev/omap2/dss/dispc.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/dispc.c 
b/drivers/video/fbdev/omap2/dss/dispc.c
index 0bdb587cb48c..646d94a71a79 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -2300,7 +2300,6 @@ static int dispc_ovl_calc_scaling_34xx(unsigned long 
pclk, unsigned long lclk,
 {
int error;
u16 in_width, in_height;
-   int min_factor = min(*decim_x, *decim_y);
const int maxsinglelinewidth =
dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
 
@@ -2349,16 +2348,8 @@ again:
}
}
 
-   if (error) {
-   if (*decim_x == *decim_y) {
-   *decim_x = min_factor;
-   ++*decim_y;
-   } else {
-   swap(*decim_x, *decim_y);
-   if (*decim_x  *decim_y)
-   ++*decim_x;
-   }
-   }
+   if (error)
+   ++*decim_y;
} while (*decim_x = *x_predecim  *decim_y = *y_predecim  error);
 
if (error) {
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/11] OMAPDSS: DISPC: check if scaling setup failed

[Tomi Valkeinen]

The DISPC's scaling code seems to presume that decimation always
succeeds, and so we always do find a suitable downscaling setup.
However, this is not the case, and the algorithm can fail.

When that happens, the code just proceeds with wrong results, causing
issues later.

Add the necessary checks to bail out if the scaling algorithm failed.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/fbdev/omap2/dss/dispc.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/video/fbdev/omap2/dss/dispc.c 
b/drivers/video/fbdev/omap2/dss/dispc.c
index 2db1c986e989..0bdb587cb48c 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -2279,6 +2279,11 @@ static int dispc_ovl_calc_scaling_24xx(unsigned long 
pclk, unsigned long lclk,
}
} while (*decim_x = *x_predecim  *decim_y = *y_predecim  error);
 
+   if (error) {
+   DSSERR(failed to find scaling settings\n);
+   return -EINVAL;
+   }
+
if (in_width  maxsinglelinewidth) {
DSSERR(Cannot scale max input width exceeded);
return -EINVAL;
@@ -2356,6 +2361,11 @@ again:
}
} while (*decim_x = *x_predecim  *decim_y = *y_predecim  error);
 
+   if (error) {
+   DSSERR(failed to find scaling settings\n);
+   return -EINVAL;
+   }
+
if (check_horiz_timing_omap3(pclk, lclk, mgr_timings, pos_x, in_width,
in_height, out_width, out_height, *five_taps)) {
DSSERR(horizontal timing too tight\n);
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/11] OMAPDSS: DISPC: work-around for errata i631

[Tomi Valkeinen]

Errata i631 description:

When in YUV4:2:0 format in 1D burst, the DISPC DMA skips lines when
fetching Chroma sampling.

Workaround:

If YUV4:2:0-1D burst is required: Set
DISPC_VIDp_ATTRIBUTES[22]DOUBLESTRIDE to 0x0 and
DISPC_VIDp_ATTRIBUTES[13:12]ROTATION to 0x1 or 0x3

The description is somewhat confusing, but testing has shown that DSS
fetches extra rows from memory when using NV12 format in 1D mode. If the
memory after the framebuffer is inaccessible, this leads to OCP errors.

The driver always uses DOUBLESTRIDE=0 when using 1D mode, so we only
need to handle the ROTATION part.

The issue exist on all OMAP4 and OMAP5 based DSS IPs.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/fbdev/omap2/dss/dispc.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/video/fbdev/omap2/dss/dispc.c 
b/drivers/video/fbdev/omap2/dss/dispc.c
index f4fc77d9d3bf..a074d8b70591 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -1741,6 +1741,15 @@ static void dispc_ovl_set_rotation_attrs(enum omap_plane 
plane, u8 rotation,
row_repeat = false;
}
 
+   /*
+* OMAP4/5 Errata i631:
+* NV12 in 1D mode must use ROTATION=1. Otherwise DSS will fetch extra
+* rows beyond the framebuffer, which may cause OCP error.
+*/
+   if (color_mode == OMAP_DSS_COLOR_NV12 
+   rotation_type != OMAP_DSS_ROT_TILER)
+   vidrot = 1;
+
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), vidrot, 13, 12);
if (dss_has_feature(FEAT_ROWREPEATENABLE))
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane),
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 04/11] OMAPDSS: DISPC: add check for scaling limits

[Tomi Valkeinen]

On OMAP3/AM43xx some scaling factors cause underflows/synclosts. After
studying this, I found that sometimes the driver uses three-tap scaling
with downscaling factor smaller than x0.5. This causes issues, as x0.5
is the limit for three-tap scaling.

The driver has FEAT_PARAM_DOWNSCALE parameter, but that seems to be for
five-tap scaling, which allows scaling down to x0.25.

This patch adds checks for both horizontal and vertical scaling. For
horizontal the HW always uses 5 taps, so the limit is x0.25.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/fbdev/omap2/dss/dispc.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/video/fbdev/omap2/dss/dispc.c 
b/drivers/video/fbdev/omap2/dss/dispc.c
index cc61513afdb4..ddce8fcfc5c1 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -2326,6 +2326,21 @@ again:
error = (error || in_width  maxsinglelinewidth * 2 ||
(in_width  maxsinglelinewidth  *five_taps) ||
!*core_clk || *core_clk  dispc_core_clk_rate());
+
+   if (!error) {
+   /* verify that we're inside the limits of scaler */
+   if (in_width / 4  out_width)
+   error = 1;
+
+   if (*five_taps) {
+   if (in_height / 4  out_height)
+   error = 1;
+   } else {
+   if (in_height / 2  out_height)
+   error = 1;
+   }
+   }
+
if (error) {
if (*decim_x == *decim_y) {
*decim_x = min_factor;
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 09/11] OMAPDSS: DISPC: scaler debug print

[Tomi Valkeinen]

Improve the DISPC debug print for scaling.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/fbdev/omap2/dss/dispc.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/dispc.c 
b/drivers/video/fbdev/omap2/dss/dispc.c
index 646d94a71a79..f8c9115cdb4b 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -2418,6 +2418,9 @@ static int dispc_ovl_calc_scaling_44xx(unsigned long 
pclk, unsigned long lclk,
return 0;
 }
 
+#define DIV_FRAC(dividend, divisor) \
+   ((dividend) * 100 / (divisor) - ((dividend) / (divisor) * 100))
+
 static int dispc_ovl_calc_scaling(unsigned long pclk, unsigned long lclk,
enum omap_overlay_caps caps,
const struct omap_video_timings *mgr_timings,
@@ -2477,8 +2480,19 @@ static int dispc_ovl_calc_scaling(unsigned long pclk, 
unsigned long lclk,
if (ret)
return ret;
 
-   DSSDBG(required core clk rate = %lu Hz\n, core_clk);
-   DSSDBG(current core clk rate = %lu Hz\n, dispc_core_clk_rate());
+   DSSDBG(%dx%d - %dx%d (%d.%02d x %d.%02d), decim %dx%d %dx%d (%d.%02d 
x %d.%02d), taps %d, req clk %lu, cur clk %lu\n,
+   width, height,
+   out_width, out_height,
+   out_width / width, DIV_FRAC(out_width, width),
+   out_height / height, DIV_FRAC(out_height, height),
+
+   decim_x, decim_y,
+   width / decim_x, height / decim_y,
+   out_width / (width / decim_x), DIV_FRAC(out_width, width / 
decim_x),
+   out_height / (height / decim_y), DIV_FRAC(out_height, height / 
decim_y),
+
+   *five_taps ? 5 : 3,
+   core_clk, dispc_core_clk_rate());
 
if (!core_clk || core_clk  dispc_core_clk_rate()) {
DSSERR(failed to set up scaling, 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 06/11] OMAPDSS: DISPC: fix 64 bit issue in 5-tap

[Tomi Valkeinen]

The DISPC driver uses 64 bit arithmetic to calculate the required clock
rate for scaling. The code does not seem to work correctly, and instead
calculates with 32 bit numbers, giving wrong result.

Fix the code by typecasting values to u64 first, so that the
calculations do happen in 64 bits.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/fbdev/omap2/dss/dispc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/dispc.c 
b/drivers/video/fbdev/omap2/dss/dispc.c
index 4488d9367bd3..2db1c986e989 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -2166,7 +2166,7 @@ static unsigned long calc_core_clk_five_taps(unsigned 
long pclk,
if (height  out_height) {
unsigned int ppl = mgr_timings-x_res;
 
-   tmp = pclk * height * out_width;
+   tmp = (u64)pclk * height * out_width;
do_div(tmp, 2 * out_height * ppl);
core_clk = tmp;
 
@@ -2174,14 +2174,14 @@ static unsigned long calc_core_clk_five_taps(unsigned 
long pclk,
if (ppl == out_width)
return 0;
 
-   tmp = pclk * (height - 2 * out_height) * out_width;
+   tmp = (u64)pclk * (height - 2 * out_height) * out_width;
do_div(tmp, 2 * out_height * (ppl - out_width));
core_clk = max_t(u32, core_clk, tmp);
}
}
 
if (width  out_width) {
-   tmp = pclk * width;
+   tmp = (u64)pclk * width;
do_div(tmp, out_width);
core_clk = max_t(u32, core_clk, tmp);
 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/11] OMAPDSS: scaling misc fixes

[Tomi Valkeinen]

Hi,

Here are some mostly scaling related fixes for omapdss, forward ported from
TI's kernel (i.e. they've seen quite a bit of testing there).

 Tomi

Tomi Valkeinen (11):
  OMAPDSS: DISPC: work-around for errata i631
  OMAPDSS: DISPC: fix predecimation for YUV modes
  OMAPDSS: DISPC: fix check_horiz_timing_omap3 args
  OMAPDSS: DISPC: add check for scaling limits
  OMAPDSS: DISPC: fix row_inc for OMAP3
  OMAPDSS: DISPC: fix 64 bit issue in 5-tap
  OMAPDSS: DISPC: check if scaling setup failed
  OMAPDSS: DISPC: do only y decimation on OMAP3
  OMAPDSS: DISPC: scaler debug print
  OMAPDSS: HDMI4: fix error handling
  OMAPDSS: HDMI: wait for framedone when stopping video

 drivers/video/fbdev/omap2/dss/dispc.c   | 114 +++-
 drivers/video/fbdev/omap2/dss/hdmi4.c   |   2 +-
 drivers/video/fbdev/omap2/dss/hdmi_wp.c |  16 +
 3 files changed, 116 insertions(+), 16 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/11] OMAPDSS: DISPC: fix check_horiz_timing_omap3 args

[Tomi Valkeinen]

After calculating the required decimation for scaling, the dispc driver
checks once more if the resulting configuration is valid by calling
check_horiz_timing_omap3().

Earlier calls to this function have correctly used in_width and
in_height as parameters, but the last call uses width and height. This
causes the driver to possibly reject scaling that would work.

This patch fixes the parameters.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/fbdev/omap2/dss/dispc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/dispc.c 
b/drivers/video/fbdev/omap2/dss/dispc.c
index db60aa98f661..cc61513afdb4 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -2338,8 +2338,8 @@ again:
}
} while (*decim_x = *x_predecim  *decim_y = *y_predecim  error);
 
-   if (check_horiz_timing_omap3(pclk, lclk, mgr_timings, pos_x, width,
-   height, out_width, out_height, *five_taps)) {
+   if (check_horiz_timing_omap3(pclk, lclk, mgr_timings, pos_x, in_width,
+   in_height, out_width, out_height, *five_taps)) {
DSSERR(horizontal timing too tight\n);
return -EINVAL;
}
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 02/11] OMAPDSS: DISPC: fix predecimation for YUV modes

[Tomi Valkeinen]

DISPC needs even input buffer width for YUV modes. The DISPC driver
doesn't check this at the moment (although omapdrm does), but worse,
when DISPC driver does x predecimation the result may be uneven. This
causes sometimes sync losts, underflows, or just visual errors.

This patch makes DISPC driver return an error if the user gives uneven
input width for a YUV buffer. It also makes the input width even in case
of predecimation.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/fbdev/omap2/dss/dispc.c | 36 +++
 1 file changed, 36 insertions(+)

diff --git a/drivers/video/fbdev/omap2/dss/dispc.c 
b/drivers/video/fbdev/omap2/dss/dispc.c
index a074d8b70591..db60aa98f661 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -2542,6 +2542,21 @@ static int dispc_ovl_setup_common(enum omap_plane plane,
if (paddr == 0  rotation_type != OMAP_DSS_ROT_TILER)
return -EINVAL;
 
+   switch (color_mode) {
+   case OMAP_DSS_COLOR_YUV2:
+   case OMAP_DSS_COLOR_UYVY:
+   case OMAP_DSS_COLOR_NV12:
+   if (in_width  1) {
+   DSSERR(input width %d is not even for YUV format\n,
+   in_width);
+   return -EINVAL;
+   }
+   break;
+
+   default:
+   break;
+   }
+
out_width = out_width == 0 ? width : out_width;
out_height = out_height == 0 ? height : out_height;
 
@@ -2572,6 +2587,27 @@ static int dispc_ovl_setup_common(enum omap_plane plane,
in_width = in_width / x_predecim;
in_height = in_height / y_predecim;
 
+   if (x_predecim  1 || y_predecim  1)
+   DSSDBG(predecimation %d x %x, new input size %d x %d\n,
+   x_predecim, y_predecim, in_width, in_height);
+
+   switch (color_mode) {
+   case OMAP_DSS_COLOR_YUV2:
+   case OMAP_DSS_COLOR_UYVY:
+   case OMAP_DSS_COLOR_NV12:
+   if (in_width  1) {
+   DSSDBG(predecimated input width is not even for YUV 
format\n);
+   DSSDBG(adjusting input width %d - %d\n,
+   in_width, in_width  ~1);
+
+   in_width = ~1;
+   }
+   break;
+
+   default:
+   break;
+   }
+
if (color_mode == OMAP_DSS_COLOR_YUV2 ||
color_mode == OMAP_DSS_COLOR_UYVY ||
color_mode == OMAP_DSS_COLOR_NV12)
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/7] OMAPDSS: refactor dss probe function

[Tomi Valkeinen]

Refactor dss probe function by extracting the setup for video plls into
a separate function. The call to this function is also moved to a
slightly earlier phase, so that in error case we can bail out more
easily.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/fbdev/omap2/dss/dss.c | 125 
 1 file changed, 69 insertions(+), 56 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/dss.c 
b/drivers/video/fbdev/omap2/dss/dss.c
index 35601ab232e3..1ce47441efe3 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -1026,14 +1026,73 @@ static void __exit dss_uninit_ports(struct 
platform_device *pdev)
} while ((port = omapdss_of_get_next_port(parent, port)) != NULL);
 }
 
+static int dss_video_pll_probe(struct platform_device *pdev)
+{
+   struct device_node *np = pdev-dev.of_node;
+   struct regulator *pll_regulator;
+   int r;
+
+   if (!np)
+   return 0;
+
+   if (of_property_read_bool(np, syscon-pll-ctrl)) {
+   dss.syscon_pll_ctrl = syscon_regmap_lookup_by_phandle(np,
+   syscon-pll-ctrl);
+   if (IS_ERR(dss.syscon_pll_ctrl)) {
+   dev_err(pdev-dev,
+   failed to get syscon-pll-ctrl regmap\n);
+   return PTR_ERR(dss.syscon_pll_ctrl);
+   }
+
+   if (of_property_read_u32_index(np, syscon-pll-ctrl, 1,
+   dss.syscon_pll_ctrl_offset)) {
+   dev_err(pdev-dev,
+   failed to get syscon-pll-ctrl offset\n);
+   return -EINVAL;
+   }
+   }
+
+   pll_regulator = devm_regulator_get(pdev-dev, vdda_video);
+   if (IS_ERR(pll_regulator)) {
+   r = PTR_ERR(pll_regulator);
+
+   switch (r) {
+   case -ENOENT:
+   pll_regulator = NULL;
+   break;
+
+   case -EPROBE_DEFER:
+   return -EPROBE_DEFER;
+
+   default:
+   DSSERR(can't get DPLL VDDA regulator\n);
+   return r;
+   }
+   }
+
+   if (of_property_match_string(np, reg-names, pll1) = 0) {
+   dss.video1_pll = dss_video_pll_init(pdev, 0, pll_regulator);
+   if (IS_ERR(dss.video1_pll))
+   return PTR_ERR(dss.video1_pll);
+   }
+
+   if (of_property_match_string(np, reg-names, pll2) = 0) {
+   dss.video2_pll = dss_video_pll_init(pdev, 1, pll_regulator);
+   if (IS_ERR(dss.video2_pll)) {
+   dss_video_pll_uninit(dss.video1_pll);
+   return PTR_ERR(dss.video2_pll);
+   }
+   }
+
+   return 0;
+}
+
 /* DSS HW IP initialisation */
 static int __init omap_dsshw_probe(struct platform_device *pdev)
 {
struct resource *dss_mem;
-   struct device_node *np = pdev-dev.of_node;
u32 rev;
int r;
-   struct regulator *pll_regulator;
 
dss.pdev = pdev;
 
@@ -1062,6 +1121,10 @@ static int __init omap_dsshw_probe(struct 
platform_device *pdev)
if (r)
goto err_setup_clocks;
 
+   r = dss_video_pll_probe(pdev);
+   if (r)
+   goto err_pll_init;
+
pm_runtime_enable(pdev-dev);
 
r = dss_runtime_get();
@@ -1088,57 +1151,6 @@ static int __init omap_dsshw_probe(struct 
platform_device *pdev)
 
dss_init_ports(pdev);
 
-   if (np  of_property_read_bool(np, syscon-pll-ctrl)) {
-   dss.syscon_pll_ctrl = syscon_regmap_lookup_by_phandle(np,
-   syscon-pll-ctrl);
-   if (IS_ERR(dss.syscon_pll_ctrl)) {
-   dev_err(pdev-dev,
-   failed to get syscon-pll-ctrl regmap\n);
-   return PTR_ERR(dss.syscon_pll_ctrl);
-   }
-
-   if (of_property_read_u32_index(np, syscon-pll-ctrl, 1,
-   dss.syscon_pll_ctrl_offset)) {
-   dev_err(pdev-dev,
-   failed to get syscon-pll-ctrl offset\n);
-   return -EINVAL;
-   }
-   }
-
-   pll_regulator = devm_regulator_get(pdev-dev, vdda_video);
-   if (IS_ERR(pll_regulator)) {
-   r = PTR_ERR(pll_regulator);
-
-   switch (r) {
-   case -ENOENT:
-   pll_regulator = NULL;
-   break;
-
-   case -EPROBE_DEFER:
-   return -EPROBE_DEFER;
-
-   default:
-   DSSERR(can't get DPLL VDDA regulator\n);
-   return r;
-   }
-   }
-
-   if (of_property_match_string(np, reg-names, pll1) = 0) {
-   dss.video1_pll = dss_video_pll_init(pdev, 0

[PATCH 6/7] OMAPDSS: componentize omapdss

[Tomi Valkeinen]

omapdss kernel module contains drivers for multiple devices, one for
each DSS submodule. The probing we have at the moment is a mess, and
doesn't give us proper deferred probing nor ensure that all the devices
are probed before omapfb/omapdrm start using omapdss.

This patch solves the mess by using the component system for DSS
submodules.

The changes to all DSS submodules (dispc, dpi, dsi, hdmi4/5, rfbi, sdi,
venc) are the same: probe  remove functions are changed to bind 
unbind, and new probe  remove functions are added which call
component_add/del.

The dss_core driver (dss.c) acts as a component master. Adding and
matching the components is simple: all dss device's child devices are
added as components.

However, we do have some dependencies between the drivers. The order in
which they should be probed is reflected by the list in core.c
(dss_output_drv_reg_funcs). The drivers are registered in that order,
which causes the components to be added in that order, which makes the
components to be bound in that order. This feels a bit fragile, and we
probably should improve the code to manage binds in random order.
However, for now, this works fine.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/fbdev/omap2/dss/dispc.c | 28 ++---
 drivers/video/fbdev/omap2/dss/dpi.c   | 26 ---
 drivers/video/fbdev/omap2/dss/dsi.c   | 25 ---
 drivers/video/fbdev/omap2/dss/dss.c   | 59 ---
 drivers/video/fbdev/omap2/dss/hdmi4.c | 26 ---
 drivers/video/fbdev/omap2/dss/hdmi5.c | 26 ---
 drivers/video/fbdev/omap2/dss/rfbi.c  | 28 ++---
 drivers/video/fbdev/omap2/dss/sdi.c   | 27 +---
 drivers/video/fbdev/omap2/dss/venc.c  | 27 +---
 9 files changed, 234 insertions(+), 38 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/dispc.c 
b/drivers/video/fbdev/omap2/dss/dispc.c
index e3417af63451..c8e34163211a 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -39,6 +39,7 @@
 #include linux/mfd/syscon.h
 #include linux/regmap.h
 #include linux/of.h
+#include linux/component.h
 
 #include video/omapdss.h
 
@@ -3882,8 +3883,9 @@ void dispc_free_irq(void *dev_id)
 EXPORT_SYMBOL(dispc_free_irq);
 
 /* DISPC HW IP initialisation */
-static int omap_dispchw_probe(struct platform_device *pdev)
+static int dispc_bind(struct device *dev, struct device *master, void *data)
 {
+   struct platform_device *pdev = to_platform_device(dev);
u32 rev;
int r = 0;
struct resource *dispc_mem;
@@ -3955,12 +3957,27 @@ err_runtime_get:
return r;
 }
 
-static int omap_dispchw_remove(struct platform_device *pdev)
+static void dispc_unbind(struct device *dev, struct device *master,
+  void *data)
 {
-   pm_runtime_disable(pdev-dev);
+   pm_runtime_disable(dev);
 
dss_uninit_overlay_managers();
+}
+
+static const struct component_ops dispc_component_ops = {
+   .bind   = dispc_bind,
+   .unbind = dispc_unbind,
+};
 
+static int dispc_probe(struct platform_device *pdev)
+{
+   return component_add(pdev-dev, dispc_component_ops);
+}
+
+static int dispc_remove(struct platform_device *pdev)
+{
+   component_del(pdev-dev, dispc_component_ops);
return 0;
 }
 
@@ -4013,7 +4030,8 @@ static const struct of_device_id dispc_of_match[] = {
 };
 
 static struct platform_driver omap_dispchw_driver = {
-   .remove = omap_dispchw_remove,
+   .probe  = dispc_probe,
+   .remove = dispc_remove,
.driver = {
.name   = omapdss_dispc,
.pm = dispc_pm_ops,
@@ -4024,7 +4042,7 @@ static struct platform_driver omap_dispchw_driver = {
 
 int __init dispc_init_platform_driver(void)
 {
-   return platform_driver_probe(omap_dispchw_driver, omap_dispchw_probe);
+   return platform_driver_register(omap_dispchw_driver);
 }
 
 void dispc_uninit_platform_driver(void)
diff --git a/drivers/video/fbdev/omap2/dss/dpi.c 
b/drivers/video/fbdev/omap2/dss/dpi.c
index a06e7558280f..fb45b6432968 100644
--- a/drivers/video/fbdev/omap2/dss/dpi.c
+++ b/drivers/video/fbdev/omap2/dss/dpi.c
@@ -32,6 +32,7 @@
 #include linux/string.h
 #include linux/of.h
 #include linux/clk.h
+#include linux/component.h
 
 #include video/omapdss.h
 
@@ -783,8 +784,9 @@ static void dpi_uninit_output_port(struct device_node *port)
omapdss_unregister_output(out);
 }
 
-static int omap_dpi_probe(struct platform_device *pdev)
+static int dpi_bind(struct device *dev, struct device *master, void *data)
 {
+   struct platform_device *pdev = to_platform_device(dev);
struct dpi_data *dpi;
 
dpi = devm_kzalloc(pdev-dev, sizeof(*dpi), GFP_KERNEL);
@@ -802,16 +804,32 @@ static int omap_dpi_probe(struct platform_device *pdev)
return 0;
 }
 
-static int omap_dpi_remove(struct platform_device *pdev)
+static void

[PATCH 7/7] OMAPDSS: simplify submodule reg/unreg code

[Tomi Valkeinen]

Now that we are using components in omapdss, there's no need for
separate handling of dss and dispc driver init. Thus we can move the dss
and dispc init and unit func pointers to the lists we use for the other
dss submodules.

We can now also handle errors returned by the registration functions
properly: if registering a driver fails, we can stop processing and
return the error.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/fbdev/omap2/dss/core.c | 46 
 1 file changed, 15 insertions(+), 31 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/core.c 
b/drivers/video/fbdev/omap2/dss/core.c
index 5c64515de818..54eeb507f9b3 100644
--- a/drivers/video/fbdev/omap2/dss/core.c
+++ b/drivers/video/fbdev/omap2/dss/core.c
@@ -245,6 +245,8 @@ static struct platform_driver omap_dss_driver = {
 
 /* INIT */
 static int (*dss_output_drv_reg_funcs[])(void) __initdata = {
+   dss_init_platform_driver,
+   dispc_init_platform_driver,
 #ifdef CONFIG_OMAP2_DSS_DSI
dsi_init_platform_driver,
 #endif
@@ -268,7 +270,7 @@ static int (*dss_output_drv_reg_funcs[])(void) __initdata = 
{
 #endif
 };
 
-static void (*dss_output_drv_unreg_funcs[])(void) __exitdata = {
+static void (*dss_output_drv_unreg_funcs[])(void) = {
 #ifdef CONFIG_OMAP5_DSS_HDMI
hdmi5_uninit_platform_driver,
 #endif
@@ -290,10 +292,10 @@ static void (*dss_output_drv_unreg_funcs[])(void) 
__exitdata = {
 #ifdef CONFIG_OMAP2_DSS_DSI
dsi_uninit_platform_driver,
 #endif
+   dispc_uninit_platform_driver,
+   dss_uninit_platform_driver,
 };
 
-static bool dss_output_drv_loaded[ARRAY_SIZE(dss_output_drv_reg_funcs)];
-
 static int __init omap_dss_init(void)
 {
int r;
@@ -303,33 +305,20 @@ static int __init omap_dss_init(void)
if (r)
return r;
 
-   r = dss_init_platform_driver();
-   if (r) {
-   DSSERR(Failed to initialize DSS platform driver\n);
-   goto err_dss;
-   }
-
-   r = dispc_init_platform_driver();
-   if (r) {
-   DSSERR(Failed to initialize dispc platform driver\n);
-   goto err_dispc;
-   }
-
-   /*
-* It's ok if the output-driver register fails. It happens, for example,
-* when there is no output-device (e.g. SDI for OMAP4).
-*/
for (i = 0; i  ARRAY_SIZE(dss_output_drv_reg_funcs); ++i) {
r = dss_output_drv_reg_funcs[i]();
-   if (r == 0)
-   dss_output_drv_loaded[i] = true;
+   if (r)
+   goto err_reg;
}
 
return 0;
 
-err_dispc:
-   dss_uninit_platform_driver();
-err_dss:
+err_reg:
+   for (i = ARRAY_SIZE(dss_output_drv_reg_funcs) - i;
+   i  ARRAY_SIZE(dss_output_drv_reg_funcs);
+   ++i)
+   dss_output_drv_unreg_funcs[i]();
+
platform_driver_unregister(omap_dss_driver);
 
return r;
@@ -339,13 +328,8 @@ static void __exit omap_dss_exit(void)
 {
int i;
 
-   for (i = 0; i  ARRAY_SIZE(dss_output_drv_unreg_funcs); ++i) {
-   if (dss_output_drv_loaded[i])
-   dss_output_drv_unreg_funcs[i]();
-   }
-
-   dispc_uninit_platform_driver();
-   dss_uninit_platform_driver();
+   for (i = 0; i  ARRAY_SIZE(dss_output_drv_unreg_funcs); ++i)
+   dss_output_drv_unreg_funcs[i]();
 
platform_driver_unregister(omap_dss_driver);
 }
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/7] OMAPDSS: remove uses of __init/__exit

[Tomi Valkeinen]

The following patches will add component handling to omapdss, improving
the handling of deferred probing. However, at the moment we're using
quite a lot of __inits and __exits in the driver, which prevent normal
dynamic probing and removal.

This patch removes most of the uses of __init and __exit.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/fbdev/omap2/dss/dispc.c | 20 ++--
 drivers/video/fbdev/omap2/dss/dpi.c   | 14 +++---
 drivers/video/fbdev/omap2/dss/dsi.c   |  6 +++---
 drivers/video/fbdev/omap2/dss/dss.c   | 26 +-
 drivers/video/fbdev/omap2/dss/dss.h   | 32 
 drivers/video/fbdev/omap2/dss/hdmi4.c |  6 +++---
 drivers/video/fbdev/omap2/dss/hdmi5.c |  6 +++---
 drivers/video/fbdev/omap2/dss/rfbi.c  |  8 
 drivers/video/fbdev/omap2/dss/sdi.c   | 12 ++--
 drivers/video/fbdev/omap2/dss/venc.c  |  8 
 10 files changed, 69 insertions(+), 69 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/dispc.c 
b/drivers/video/fbdev/omap2/dss/dispc.c
index f4fc77d9d3bf..e3417af63451 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -3692,7 +3692,7 @@ static void _omap_dispc_initial_config(void)
dispc_init_mflag();
 }
 
-static const struct dispc_features omap24xx_dispc_feats __initconst = {
+static const struct dispc_features omap24xx_dispc_feats = {
.sw_start   =   5,
.fp_start   =   15,
.bp_start   =   27,
@@ -3711,7 +3711,7 @@ static const struct dispc_features omap24xx_dispc_feats 
__initconst = {
.set_max_preload=   false,
 };
 
-static const struct dispc_features omap34xx_rev1_0_dispc_feats __initconst = {
+static const struct dispc_features omap34xx_rev1_0_dispc_feats = {
.sw_start   =   5,
.fp_start   =   15,
.bp_start   =   27,
@@ -3731,7 +3731,7 @@ static const struct dispc_features 
omap34xx_rev1_0_dispc_feats __initconst = {
.set_max_preload=   false,
 };
 
-static const struct dispc_features omap34xx_rev3_0_dispc_feats __initconst = {
+static const struct dispc_features omap34xx_rev3_0_dispc_feats = {
.sw_start   =   7,
.fp_start   =   19,
.bp_start   =   31,
@@ -3751,7 +3751,7 @@ static const struct dispc_features 
omap34xx_rev3_0_dispc_feats __initconst = {
.set_max_preload=   false,
 };
 
-static const struct dispc_features omap44xx_dispc_feats __initconst = {
+static const struct dispc_features omap44xx_dispc_feats = {
.sw_start   =   7,
.fp_start   =   19,
.bp_start   =   31,
@@ -3771,7 +3771,7 @@ static const struct dispc_features omap44xx_dispc_feats 
__initconst = {
.set_max_preload=   true,
 };
 
-static const struct dispc_features omap54xx_dispc_feats __initconst = {
+static const struct dispc_features omap54xx_dispc_feats = {
.sw_start   =   7,
.fp_start   =   19,
.bp_start   =   31,
@@ -3792,7 +3792,7 @@ static const struct dispc_features omap54xx_dispc_feats 
__initconst = {
.set_max_preload=   true,
 };
 
-static int __init dispc_init_features(struct platform_device *pdev)
+static int dispc_init_features(struct platform_device *pdev)
 {
const struct dispc_features *src;
struct dispc_features *dst;
@@ -3882,7 +3882,7 @@ void dispc_free_irq(void *dev_id)
 EXPORT_SYMBOL(dispc_free_irq);
 
 /* DISPC HW IP initialisation */
-static int __init omap_dispchw_probe(struct platform_device *pdev)
+static int omap_dispchw_probe(struct platform_device *pdev)
 {
u32 rev;
int r = 0;
@@ -3955,7 +3955,7 @@ err_runtime_get:
return r;
 }
 
-static int __exit omap_dispchw_remove(struct platform_device *pdev)
+static int omap_dispchw_remove(struct platform_device *pdev)
 {
pm_runtime_disable(pdev-dev);
 
@@ -4013,7 +4013,7 @@ static const struct of_device_id dispc_of_match[] = {
 };
 
 static struct platform_driver omap_dispchw_driver = {
-   .remove = __exit_p(omap_dispchw_remove),
+   .remove = omap_dispchw_remove,
.driver = {
.name   = omapdss_dispc,
.pm = dispc_pm_ops,
@@ -4027,7 +4027,7 @@ int __init dispc_init_platform_driver(void)
return platform_driver_probe(omap_dispchw_driver, omap_dispchw_probe);
 }
 
-void __exit dispc_uninit_platform_driver(void)
+void dispc_uninit_platform_driver(void)
 {
platform_driver_unregister(omap_dispchw_driver);
 }
diff --git a/drivers/video/fbdev/omap2/dss/dpi.c 
b/drivers/video/fbdev/omap2/dss/dpi.c
index f83e7b030249..a06e7558280f 100644
--- a/drivers/video/fbdev/omap2/dss/dpi.c

[PATCH 3/7] OMAPDSS: fix dss_init_ports error handling

[Tomi Valkeinen]

The return value of dss_init_ports() is not handled at all, causing
crashes later if the call failed.

This patch adds the error handling, and we also move the call to a
slightly earlier place to make bailing out easier.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/fbdev/omap2/dss/dss.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/dss.c 
b/drivers/video/fbdev/omap2/dss/dss.c
index 1ce47441efe3..28e6ff053b47 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -1125,6 +1125,10 @@ static int __init omap_dsshw_probe(struct 
platform_device *pdev)
if (r)
goto err_pll_init;
 
+   r = dss_init_ports(pdev);
+   if (r)
+   goto err_init_ports;
+
pm_runtime_enable(pdev-dev);
 
r = dss_runtime_get();
@@ -1149,8 +1153,6 @@ static int __init omap_dsshw_probe(struct platform_device 
*pdev)
dss.lcd_clk_source[0] = OMAP_DSS_CLK_SRC_FCK;
dss.lcd_clk_source[1] = OMAP_DSS_CLK_SRC_FCK;
 
-   dss_init_ports(pdev);
-
rev = dss_read_reg(DSS_REVISION);
printk(KERN_INFO OMAP DSS rev %d.%d\n,
FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
@@ -1167,7 +1169,8 @@ static int __init omap_dsshw_probe(struct platform_device 
*pdev)
 
 err_runtime_get:
pm_runtime_disable(pdev-dev);
-
+   dss_uninit_ports(pdev);
+err_init_ports:
if (dss.video1_pll)
dss_video_pll_uninit(dss.video1_pll);
 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/7] OMAPDSS: reorder uninit calls

[Tomi Valkeinen]

We have a list of function pointers to dss submodule uninit functions.
It makes sense to do the uninit in the reverse order to init, but that
is not currently the case.

This patch reorders the uninit calls to be the reverse of init order.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/fbdev/omap2/dss/core.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/core.c 
b/drivers/video/fbdev/omap2/dss/core.c
index 57b6a5296c87..5c64515de818 100644
--- a/drivers/video/fbdev/omap2/dss/core.c
+++ b/drivers/video/fbdev/omap2/dss/core.c
@@ -269,26 +269,26 @@ static int (*dss_output_drv_reg_funcs[])(void) __initdata 
= {
 };
 
 static void (*dss_output_drv_unreg_funcs[])(void) __exitdata = {
-#ifdef CONFIG_OMAP2_DSS_DSI
-   dsi_uninit_platform_driver,
+#ifdef CONFIG_OMAP5_DSS_HDMI
+   hdmi5_uninit_platform_driver,
 #endif
-#ifdef CONFIG_OMAP2_DSS_DPI
-   dpi_uninit_platform_driver,
+#ifdef CONFIG_OMAP4_DSS_HDMI
+   hdmi4_uninit_platform_driver,
 #endif
-#ifdef CONFIG_OMAP2_DSS_SDI
-   sdi_uninit_platform_driver,
+#ifdef CONFIG_OMAP2_DSS_VENC
+   venc_uninit_platform_driver,
 #endif
 #ifdef CONFIG_OMAP2_DSS_RFBI
rfbi_uninit_platform_driver,
 #endif
-#ifdef CONFIG_OMAP2_DSS_VENC
-   venc_uninit_platform_driver,
+#ifdef CONFIG_OMAP2_DSS_SDI
+   sdi_uninit_platform_driver,
 #endif
-#ifdef CONFIG_OMAP4_DSS_HDMI
-   hdmi4_uninit_platform_driver,
+#ifdef CONFIG_OMAP2_DSS_DPI
+   dpi_uninit_platform_driver,
 #endif
-#ifdef CONFIG_OMAP5_DSS_HDMI
-   hdmi5_uninit_platform_driver,
+#ifdef CONFIG_OMAP2_DSS_DSI
+   dsi_uninit_platform_driver,
 #endif
 };
 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/7] OMAPDSS: use components (fix probing problems)

[Tomi Valkeinen]

Hi,

I noticed that on some platforms omapdss did not probe successfully. Some
resource was not available yet, but omapdss did not manage to handle deferred
probing. The reason was the use of platform_driver_probe() in combination with
how the omapdss module handles the drivers.

To fix this properly, the component system felt fine for the job, and it seems
to work nicely.

 Tomi

Tomi Valkeinen (7):
  OMAPDSS: move 'dss_initialized' to dss driver
  OMAPDSS: refactor dss probe function
  OMAPDSS: fix dss_init_ports error handling
  OMAPDSS: remove uses of __init/__exit
  OMAPDSS: reorder uninit calls
  OMAPDSS: componentize omapdss
  OMAPDSS: simplify submodule reg/unreg code

 drivers/video/fbdev/omap2/dss/core.c  |  80 
 drivers/video/fbdev/omap2/dss/dispc.c |  42 +--
 drivers/video/fbdev/omap2/dss/dpi.c   |  36 --
 drivers/video/fbdev/omap2/dss/dsi.c   |  27 +++-
 drivers/video/fbdev/omap2/dss/dss.c   | 223 +++---
 drivers/video/fbdev/omap2/dss/dss.h   |  32 ++---
 drivers/video/fbdev/omap2/dss/hdmi4.c |  28 -
 drivers/video/fbdev/omap2/dss/hdmi5.c |  28 -
 drivers/video/fbdev/omap2/dss/rfbi.c  |  32 -
 drivers/video/fbdev/omap2/dss/sdi.c   |  35 --
 drivers/video/fbdev/omap2/dss/venc.c  |  31 +++--
 11 files changed, 396 insertions(+), 198 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/7] OMAPDSS: move 'dss_initialized' to dss driver

[Tomi Valkeinen]

We have a flag, 'dss_initialized', which tells omapfb and omapdrm if
omapdss is available. At the moment it can be set even if the dss
submodules are not all ready, in case something gets deferred.

Move the flag to dss_core driver so that it'll signal the availability
of the dss drivers move accurately.

For now, it'll signal that dss_core is ready, which is not quite correct
but still better than previously.  The following patches will add
component system to omapdss, and after those patches 'dss_initialized'
will signal that all the submodules are ready.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/fbdev/omap2/dss/core.c | 10 --
 drivers/video/fbdev/omap2/dss/dss.c  | 12 
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/core.c 
b/drivers/video/fbdev/omap2/dss/core.c
index 16751755d433..57b6a5296c87 100644
--- a/drivers/video/fbdev/omap2/dss/core.c
+++ b/drivers/video/fbdev/omap2/dss/core.c
@@ -50,8 +50,6 @@ static char *def_disp_name;
 module_param_named(def_disp, def_disp_name, charp, 0);
 MODULE_PARM_DESC(def_disp, default display name);
 
-static bool dss_initialized;
-
 const char *omapdss_get_default_display_name(void)
 {
return core.default_display_name;
@@ -65,12 +63,6 @@ enum omapdss_version omapdss_get_version(void)
 }
 EXPORT_SYMBOL(omapdss_get_version);
 
-bool omapdss_is_initialized(void)
-{
-   return dss_initialized;
-}
-EXPORT_SYMBOL(omapdss_is_initialized);
-
 struct platform_device *dss_get_core_pdev(void)
 {
return core.pdev;
@@ -333,8 +325,6 @@ static int __init omap_dss_init(void)
dss_output_drv_loaded[i] = true;
}
 
-   dss_initialized = true;
-
return 0;
 
 err_dispc:
diff --git a/drivers/video/fbdev/omap2/dss/dss.c 
b/drivers/video/fbdev/omap2/dss/dss.c
index 7f978b6a34e8..35601ab232e3 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -111,6 +111,14 @@ static const char * const dss_generic_clk_source_names[] = 
{
[OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI]   = DSI_PLL2_HSDIV_DSI,
 };
 
+static bool dss_initialized;
+
+bool omapdss_is_initialized(void)
+{
+   return dss_initialized;
+}
+EXPORT_SYMBOL(omapdss_is_initialized);
+
 static inline void dss_write_reg(const struct dss_reg idx, u32 val)
 {
__raw_writel(val, dss.base + idx.idx);
@@ -1141,6 +1149,8 @@ static int __init omap_dsshw_probe(struct platform_device 
*pdev)
 
pm_set_vt_switch(0);
 
+   dss_initialized = true;
+
return 0;
 
 err_pll_init:
@@ -1158,6 +1168,8 @@ err_setup_clocks:
 
 static int __exit omap_dsshw_remove(struct platform_device *pdev)
 {
+   dss_initialized = false;
+
if (dss.video1_pll)
dss_video_pll_uninit(dss.video1_pll);
 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fbdev: omap2: remove potential format string leak

[Tomi Valkeinen]

On 09/06/15 01:30, Kees Cook wrote:
 Since kobject_init_and_add takes a format string, make sure that the
 passed in name cannot be accidentally parsed.
 
 Signed-off-by: Kees Cook keesc...@chromium.org
 ---
  drivers/video/fbdev/omap2/dss/display-sysfs.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/video/fbdev/omap2/dss/display-sysfs.c 
 b/drivers/video/fbdev/omap2/dss/display-sysfs.c
 index 12186557a9d4..6ad0991f8259 100644
 --- a/drivers/video/fbdev/omap2/dss/display-sysfs.c
 +++ b/drivers/video/fbdev/omap2/dss/display-sysfs.c
 @@ -324,7 +324,7 @@ int display_init_sysfs(struct platform_device *pdev)
  
   for_each_dss_dev(dssdev) {
   r = kobject_init_and_add(dssdev-kobj, display_ktype,
 - pdev-dev.kobj, dssdev-alias);
 + pdev-dev.kobj, %s, dssdev-alias);
   if (r) {
   DSSERR(failed to create sysfs files\n);
   omap_dss_put_device(dssdev);
 

Thanks, queued for 4.2.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCHv4 10/10] arm/dts: am57xx-beagle-x15.dts: add HDMI

[Tomi Valkeinen]

On 03/06/15 20:16, Tony Lindgren wrote:

 OK, since there are no other merge conflicts that I'm aware of,
 it's best that you merge the whole branch. I've acked the patches,
 so for this one too:

 Ok, I can do that, but isn't this more linux-arm stuff? All the driver
 side code is already in the mainline.

 Yes but we're getting so late into merge window that I'd rather not
 take it for v4.2 at this point. And it's all DSS related.

 Please make sure you get an ack for the drivers/clk/omap change from
 Mike or Stephen though.
 
 Naturally I mean getting so close to the merge window above :)

Thanks everyone. I've pushed this to fbdev for-next.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 0/5] OMAPDSS: HDMI audio compliance fixes

[Tomi Valkeinen]

Hi,

On 22/04/15 16:22, Jyri Sarha wrote:
 I have rebased these patches from ti-linux-3.14.y on top of Linux
 4.0.0. I tested them briefly on OMAP4 and OMAP5 in my environment, but
 I could not test any channel count beyond stereo. However, there were
 no conflicts in the rebase and each fix makes sense when looking at
 the chip TRM and the relevant HDMI specs.
 
 All the changes are really minor, but most of them apply to OMAPDSS side,
 so it is probably best to merge them trough there.
 
 Best regards,
 Jyri
 
 Misael Lopez Cruz (5):
   OMAPDSS: HDMI4: Set correct CC for 8-channels layout
   OMAPDSS: HDMI5: Set valid sample order
   OMAPDSS: HDMI5: Fix AUDICONF3 bitfield offsets
   ASoC: omap-hdmi-audio: Force channel allocation only for OMAP4
   ASoC: omap-hdmi-audio: Fix invalid combination of DM_INH and CA
 
  drivers/video/fbdev/omap2/dss/hdmi4_core.c | 12 +++-
  drivers/video/fbdev/omap2/dss/hdmi5_core.c |  5 -
  sound/soc/omap/omap-hdmi-audio.c   | 12 +++-
  3 files changed, 22 insertions(+), 7 deletions(-)

I've queued these for 4.2.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCHv4 10/10] arm/dts: am57xx-beagle-x15.dts: add HDMI

[Tomi Valkeinen]

On 02/06/15 00:51, Tony Lindgren wrote:
 * Tomi Valkeinen tomi.valkei...@ti.com [150531 23:25]:
 AM57xx Beagle X15 has a HDMI output. This patch adds the device tree
 nodes required for HDMI.
 
 This one does not seem to apply to linux next, did not look
 further where it conflicts.

Looks like the change was also in -rc6. I've rebased my patches on -rc6,
and added the acks:

git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git dra7-dss-arch

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCHv4 10/10] arm/dts: am57xx-beagle-x15.dts: add HDMI

[Tomi Valkeinen]

On 03/06/15 18:44, Tony Lindgren wrote:
 * Tomi Valkeinen tomi.valkei...@ti.com [150603 04:28]:


 On 02/06/15 00:51, Tony Lindgren wrote:
 * Tomi Valkeinen tomi.valkei...@ti.com [150531 23:25]:
 AM57xx Beagle X15 has a HDMI output. This patch adds the device tree
 nodes required for HDMI.

 This one does not seem to apply to linux next, did not look
 further where it conflicts.

 Looks like the change was also in -rc6. I've rebased my patches on -rc6,
 and added the acks:

 git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git dra7-dss-arch
 
 OK, since there are no other merge conflicts that I'm aware of,
 it's best that you merge the whole branch. I've acked the patches,
 so for this one too:

Ok, I can do that, but isn't this more linux-arm stuff? All the driver
side code is already in the mainline.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCHv4 10/10] arm/dts: am57xx-beagle-x15.dts: add HDMI

[Tomi Valkeinen]

On 02/06/15 00:51, Tony Lindgren wrote:
 * Tomi Valkeinen tomi.valkei...@ti.com [150531 23:25]:
 AM57xx Beagle X15 has a HDMI output. This patch adds the device tree
 nodes required for HDMI.
 
 This one does not seem to apply to linux next, did not look
 further where it conflicts.

Looks like a trivial one line conflict, about adding an alias to .dts.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCHv3 00/10] ARM: DRA7: add display support

[Tomi Valkeinen]

On 01/06/15 08:46, Paul Walmsley wrote:
 Hi Tomi
 
 On Wed, 6 May 2015, Tomi Valkeinen wrote:
 
 This series adds the arch/arm/ side of the display support for DRA7 (DRA72x,
 DRA74x, AM54xx) SoCs. Also support for HDMI output on x15 and DRA72 EVM 
 boards
 is added.

 This series is v3, and is based on v4.1-rc2. There are no differences to v2,
 except rebased and tested.
 
 Are you still planning to move the DESHDCP clock enable to the beginning 
 of the series to avoid the warnings, per:
 
 http://www.spinics.net/lists/arm-kernel/msg410968.html

Sorry, I totally forgot that. I will do that and send a v4.

 Also, not sure if you can arrange for someone at TI to send over a DRA7xx 
 board for the testbed, but it would be nice to have a board to test these 
 patches with, to avoid issues like the one mentioned in your E-mails...

I'll forward the request.

 Tomi



signature.asc
Description: OpenPGP digital signature

[PATCHv4 03/10] arm/dts: dra7xx: add 'ti,set-rate-parent' for dss_dss_clk

[Tomi Valkeinen]

We need set-rate-parent flags for the display's clock path so that the
DSS driver can change the clock rate of the PLL.

This patchs adds the ti,set-rate-parent flag to 'dss_dss_clk' clock
node, which is only a gate clock, allowing the setting of the clock rate
to propagate to the PLL.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
 arch/arm/boot/dts/dra7xx-clocks.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi 
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 470f39c4e326..357bedeebfac 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1531,6 +1531,7 @@
clocks = dpll_per_h12x2_ck;
ti,bit-shift = 8;
reg = 0x1120;
+   ti,set-rate-parent;
};
 
dss_hdmi_clk: dss_hdmi_clk {
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv4 00/10] ARM: DRA7: add display support

[Tomi Valkeinen]

Hi,

This series adds the arch/arm/ side of the display support for DRA7 (DRA72x,
DRA74x, AM54xx) SoCs. Also support for HDMI output on x15 and DRA72 EVM boards
is added.

The difference to v4 is that the DESHDCP patches were moved to the beginning of
the series to fix boot issues if bisecting.

 Tomi

Tomi Valkeinen (10):
  arm: dra7: add DESHDCP clock
  CLK: TI: always enable DESHDCP clock
  arm/dts: dra7xx: add 'ti,set-rate-parent' for dss_dss_clk
  ARM: DRA7: hwmod: add DMM hwmod description
  ARM: DRA7: hwmod: set DSS submodule parent hwmods
  ARM: OMAP: display: change compat names to array
  ARM: OMAP2+: display: detect DRA7 DSS
  arm/dts: dra7.dtsi: add DSS support
  arm/dts: dra72-evm.dts: add HDMI
  arm/dts: am57xx-beagle-x15.dts: add HDMI

 arch/arm/boot/dts/am57xx-beagle-x15.dts   |  81 ++
 arch/arm/boot/dts/dra7.dtsi   |  43 
 arch/arm/boot/dts/dra72-evm.dts   | 110 ++
 arch/arm/boot/dts/dra72x.dtsi |  11 +++
 arch/arm/boot/dts/dra74x.dtsi |  15 
 arch/arm/boot/dts/dra7xx-clocks.dtsi  |  11 +++
 arch/arm/mach-omap2/display.c |  32 +
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c |  33 +
 drivers/clk/ti/clk-7xx.c  |   8 ++-
 9 files changed, 328 insertions(+), 16 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv4 02/10] CLK: TI: always enable DESHDCP clock

[Tomi Valkeinen]

DESHDCP clock is needed on DRA7 based SoCs to enable the DSS IP. That
clock is an odd one, as it is not supposed to be any kind of core clock
for DSS, and we don't even support HDCP, but the clock is still needed
even for the HWMOD framework to be able to reset the DSS IP.

As there's no support for multiple core clocks in the HWMOD framework,
we don't have any obvious place to enable this clock when DSS IP is
being enabled.

Furthermore, the HDMI on OMAP5 DSS is the same as on DRA7, and OMAP5
does not have any such clock configuration bit. This suggests that on
OMAP5 the DESHDCP clock is always enabled, and for DRA7 we have the
possibility to gate it.

So, as we don't have any clean way to enable and disable the clock
based on the need, this patch enables the clock at boot time, making it
work similarly to OMAP5.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/clk/ti/clk-7xx.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 2dd956b9affa..63b8323df918 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -312,7 +312,7 @@ static struct ti_dt_clk dra7xx_clks[] = {
 int __init dra7xx_dt_clk_init(void)
 {
int rc;
-   struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck;
+   struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck, *hdcp_ck;
 
ti_dt_clocks_register(dra7xx_clks);
 
@@ -348,5 +348,10 @@ int __init dra7xx_dt_clk_init(void)
if (rc)
pr_err(%s: failed to set USB_DPLL M2 OUT\n, __func__);
 
+   hdcp_ck = clk_get_sys(NULL, dss_deshdcp_clk);
+   rc = clk_prepare_enable(hdcp_ck);
+   if (rc)
+   pr_err(%s: failed to set dss_deshdcp_clk\n, __func__);
+
return rc;
 }
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv4 01/10] arm: dra7: add DESHDCP clock

[Tomi Valkeinen]

Add a new Linux clock for DRA7 based SoCs to control DESHDCP clock.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 arch/arm/boot/dts/dra7.dtsi   |  5 +
 arch/arm/boot/dts/dra7xx-clocks.dtsi  | 10 ++
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c |  1 +
 drivers/clk/ti/clk-7xx.c  |  1 +
 4 files changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5332b57b4950..db0890a36e96 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -131,6 +131,11 @@
regulator-max-microvolt 
= 300;
};
};
+
+   scm_conf_clocks: clocks {
+   #address-cells = 1;
+   #size-cells = 0;
+   };
};
 
dra7_pmx_core: pinmux@1400 {
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi 
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 3b933f74d000..470f39c4e326 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -2136,3 +2136,13 @@
clocks = dpll_usb_ck;
};
 };
+
+scm_conf_clocks {
+   dss_deshdcp_clk: dss_deshdcp_clk {
+   #clock-cells = 0;
+   compatible = ti,gate-clock;
+   clocks = l3_iclk_div;
+   ti,bit-shift = 0;
+   reg = 0x558;
+   };
+};
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 0e64c2fac0b5..817dbd87ce67 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -438,6 +438,7 @@ static struct omap_hwmod_opt_clk dss_opt_clks[] = {
{ .role = video2_clk, .clk = dss_video2_clk },
{ .role = video1_clk, .clk = dss_video1_clk },
{ .role = hdmi_clk, .clk = dss_hdmi_clk },
+   { .role = hdcp_clk, .clk = dss_deshdcp_clk },
 };
 
 static struct omap_hwmod dra7xx_dss_hwmod = {
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 5d2217ae4478..2dd956b9affa 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -305,6 +305,7 @@ static struct ti_dt_clk dra7xx_clks[] = {
DT_CLK(4882c000.timer, timer_sys_ck, timer_sys_clk_div),
DT_CLK(4882e000.timer, timer_sys_ck, timer_sys_clk_div),
DT_CLK(NULL, sys_clkin, sys_clkin1),
+   DT_CLK(NULL, dss_deshdcp_clk, dss_deshdcp_clk),
{ .node_name = NULL },
 };
 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv4 09/10] arm/dts: dra72-evm.dts: add HDMI

[Tomi Valkeinen]

DRA72 EVM has a HDMI output. This patch adds the device tree nodes
required for HDMI.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
 arch/arm/boot/dts/dra72-evm.dts | 110 
 1 file changed, 110 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index ce0390f081d9..4e1b60581782 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -19,6 +19,10 @@
reg = 0x8000 0x4000; /* 1024 MB */
};
 
+   aliases {
+   display0 = hdmi0;
+   };
+
evm_3v3: fixedregulator-evm_3v3 {
compatible = regulator-fixed;
regulator-name = evm_3v3;
@@ -35,6 +39,51 @@
compatible = linux,extcon-usb-gpio;
id-gpio = pcf_gpio_21 2 GPIO_ACTIVE_HIGH;
};
+
+   hdmi0: connector {
+   compatible = hdmi-connector;
+   label = hdmi;
+
+   type = a;
+
+   port {
+   hdmi_connector_in: endpoint {
+   remote-endpoint = tpd12s015_out;
+   };
+   };
+   };
+
+   tpd12s015: encoder {
+   compatible = ti,tpd12s015;
+
+   pinctrl-names = default;
+   pinctrl-0 = tpd12s015_pins;
+
+   gpios = pcf_hdmi 4 GPIO_ACTIVE_HIGH, /* P4, CT CP HPD */
+   pcf_hdmi 5 GPIO_ACTIVE_HIGH, /* P5, LS OE */
+   gpio7 12 GPIO_ACTIVE_HIGH;   /* gpio7_12/sp1_cs2, 
HPD */
+
+   ports {
+   #address-cells = 1;
+   #size-cells = 0;
+
+   port@0 {
+   reg = 0;
+
+   tpd12s015_in: endpoint {
+   remote-endpoint = hdmi_out;
+   };
+   };
+
+   port@1 {
+   reg = 1;
+
+   tpd12s015_out: endpoint {
+   remote-endpoint = hdmi_connector_in;
+   };
+   };
+   };
+   };
 };
 
 dra7_pmx_core {
@@ -45,6 +94,13 @@
;
};
 
+   i2c5_pins: pinmux_i2c5_pins {
+   pinctrl-single,pins = 
+   0x2b4 (PIN_INPUT | MUX_MODE10) /* mcasp1_axr0.i2c5_sda 
*/
+   0x2b8 (PIN_INPUT | MUX_MODE10) /* mcasp1_axr1.i2c5_scl 
*/
+   ;
+   };
+
nand_default: nand_default {
pinctrl-single,pins = 
0x0 (PIN_INPUT  | MUX_MODE0) /* gpmc_ad0 */
@@ -142,6 +198,19 @@
0xb8 (PIN_OUTPUT | MUX_MODE1)   /* gpmc_cs2.qspi1_cs0 */
;
};
+
+   hdmi_pins: pinmux_hdmi_pins {
+   pinctrl-single,pins = 
+   0x408 (PIN_INPUT | MUX_MODE1) /* i2c2_sda.hdmi1_ddc_scl 
*/
+   0x40c (PIN_INPUT | MUX_MODE1) /* i2c2_scl.hdmi1_ddc_sda 
*/
+   ;
+   };
+
+   tpd12s015_pins: pinmux_tpd12s015_pins {
+   pinctrl-single,pins = 
+   0x3b8 (PIN_INPUT_PULLDOWN | MUX_MODE14) /* gpio7_12 HPD 
*/
+   ;
+   };
 };
 
 i2c1 {
@@ -277,6 +346,27 @@
};
 };
 
+i2c5 {
+   status = okay;
+   pinctrl-names = default;
+   pinctrl-0 = i2c5_pins;
+   clock-frequency = 40;
+
+   pcf_hdmi: pcf8575@26 {
+   compatible = nxp,pcf8575;
+   reg = 0x26;
+   gpio-controller;
+   #gpio-cells = 2;
+   /*
+* initial state is used here to keep the mdio interface
+* selected on RU89 through SEL_VIN4_MUX_S0, VIN2_S1 and
+* VIN2_S0 driven high otherwise Ethernet stops working
+* VIN6_SEL_S0 is low, thus selecting McASP3 over VIN6
+*/
+   lines-initial-states = 0x0f2b;
+   };
+};
+
 uart1 {
status = okay;
 };
@@ -566,3 +656,23 @@
};
};
 };
+
+dss {
+   status = ok;
+
+   vdda_video-supply = ldo5_reg;
+};
+
+hdmi {
+   status = ok;
+   vdda-supply = ldo3_reg;
+
+   pinctrl-names = default;
+   pinctrl-0 = hdmi_pins;
+
+   port {
+   hdmi_out: endpoint {
+   remote-endpoint = tpd12s015_in;
+   };
+   };
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv4 08/10] arm/dts: dra7.dtsi: add DSS support

[Tomi Valkeinen]

DRA7xxx contains a very similar DSS to OMAP5. The main differences are:

* no DSI or RFBI support.
* 1 or 2 dedicated video PLLs.
* need to do additional configuration to the DRA7 CONTROL module.

DRA72xx has only one video PLL, and DRA74xx has two.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
 arch/arm/boot/dts/dra7.dtsi   | 38 ++
 arch/arm/boot/dts/dra72x.dtsi | 11 +++
 arch/arm/boot/dts/dra74x.dtsi | 15 +++
 3 files changed, 64 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index db0890a36e96..f3a8237cea39 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1474,6 +1474,44 @@
clocks = sys_clkin1;
status = disabled;
};
+
+   dss: dss@5800 {
+   compatible = ti,dra7-dss;
+   /* 'reg' defined in dra72x.dtsi and dra74x.dtsi */
+   /* 'clocks' defined in dra72x.dtsi and dra74x.dtsi */
+   status = disabled;
+   ti,hwmods = dss_core;
+   /* CTRL_CORE_DSS_PLL_CONTROL */
+   syscon-pll-ctrl = scm_conf 0x538;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   dispc@58001000 {
+   compatible = ti,dra7-dispc;
+   reg = 0x58001000 0x1000;
+   interrupts = GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH;
+   ti,hwmods = dss_dispc;
+   clocks = dss_dss_clk;
+   clock-names = fck;
+   /* CTRL_CORE_SMA_SW_1 */
+   syscon-pol = scm_conf 0x534;
+   };
+
+   hdmi: encoder@5806 {
+   compatible = ti,dra7-hdmi;
+   reg = 0x5804 0x200,
+ 0x58040200 0x80,
+ 0x58040300 0x80,
+ 0x5806 0x19000;
+   reg-names = wp, pll, phy, core;
+   interrupts = GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH;
+   status = disabled;
+   ti,hwmods = dss_hdmi;
+   clocks = dss_48mhz_clk, dss_hdmi_clk;
+   clock-names = fck, sys_clk;
+   };
+   };
};
 
thermal_zones: thermal-zones {
diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
index 03d742f8d572..eaca143faa77 100644
--- a/arch/arm/boot/dts/dra72x.dtsi
+++ b/arch/arm/boot/dts/dra72x.dtsi
@@ -34,3 +34,14 @@
interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH;
};
 };
+
+dss {
+   reg = 0x5800 0x80,
+ 0x58004054 0x4,
+ 0x58004300 0x20;
+   reg-names = dss, pll1_clkctrl, pll1;
+
+   clocks = dss_dss_clk,
+dss_video1_clk;
+   clock-names = fck, video1_clk;
+};
diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
index cc560a70926f..fa995d0ca1f2 100644
--- a/arch/arm/boot/dts/dra74x.dtsi
+++ b/arch/arm/boot/dts/dra74x.dtsi
@@ -73,3 +73,18 @@
};
};
 };
+
+dss {
+   reg = 0x5800 0x80,
+ 0x58004054 0x4,
+ 0x58004300 0x20,
+ 0x58005054 0x4,
+ 0x58005300 0x20;
+   reg-names = dss, pll1_clkctrl, pll1,
+   pll2_clkctrl, pll2;
+
+   clocks = dss_dss_clk,
+dss_video1_clk,
+dss_video2_clk;
+   clock-names = fck, video1_clk, video2_clk;
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv4 07/10] ARM: OMAP2+: display: detect DRA7 DSS

[Tomi Valkeinen]

Add platform code to detect DRA7 DSS.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 arch/arm/mach-omap2/display.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 9868d0bc7805..6ab13d18c636 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -287,6 +287,8 @@ static enum omapdss_version __init 
omap_display_get_version(void)
return OMAPDSS_VER_OMAP5;
else if (soc_is_am43xx())
return OMAPDSS_VER_AM43xx;
+   else if (soc_is_dra7xx())
+   return OMAPDSS_VER_DRA7xx;
else
return OMAPDSS_VER_UNKNOWN;
 }
@@ -573,6 +575,7 @@ static const char * const omapdss_compat_names[] 
__initconst = {
ti,omap3-dss,
ti,omap4-dss,
ti,omap5-dss,
+   ti,dra7-dss,
 };
 
 struct device_node * __init omapdss_find_dss_of_node(void)
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv4 05/10] ARM: DRA7: hwmod: set DSS submodule parent hwmods

[Tomi Valkeinen]

Set DSS core hwmod as the parent for all the DSS submodules.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index f6b94854fafc..9961f95f52ae 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -522,6 +522,7 @@ static struct omap_hwmod dra7xx_dss_dispc_hwmod = {
},
},
.dev_attr   = dss_dispc_dev_attr,
+   .parent_hwmod   = dra7xx_dss_hwmod,
 };
 
 /*
@@ -563,6 +564,7 @@ static struct omap_hwmod dra7xx_dss_hdmi_hwmod = {
},
.opt_clks   = dss_hdmi_opt_clks,
.opt_clks_cnt   = ARRAY_SIZE(dss_hdmi_opt_clks),
+   .parent_hwmod   = dra7xx_dss_hwmod,
 };
 
 /*
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv4 06/10] ARM: OMAP: display: change compat names to array

[Tomi Valkeinen]

Simplify the DSS detection logic by creating a list of the omapdss
compat strings, instead of checking each separately with an 'if'.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 arch/arm/mach-omap2/display.c | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index f492ae147c6a..9868d0bc7805 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -568,25 +568,24 @@ void __init omapdss_early_init_of(void)
 
 }
 
+static const char * const omapdss_compat_names[] __initconst = {
+   ti,omap2-dss,
+   ti,omap3-dss,
+   ti,omap4-dss,
+   ti,omap5-dss,
+};
+
 struct device_node * __init omapdss_find_dss_of_node(void)
 {
struct device_node *node;
+   int i;
 
-   node = of_find_compatible_node(NULL, NULL, ti,omap2-dss);
-   if (node)
-   return node;
-
-   node = of_find_compatible_node(NULL, NULL, ti,omap3-dss);
-   if (node)
-   return node;
-
-   node = of_find_compatible_node(NULL, NULL, ti,omap4-dss);
-   if (node)
-   return node;
-
-   node = of_find_compatible_node(NULL, NULL, ti,omap5-dss);
-   if (node)
-   return node;
+   for (i = 0; i  ARRAY_SIZE(omapdss_compat_names); ++i) {
+   node = of_find_compatible_node(NULL, NULL,
+   omapdss_compat_names[i]);
+   if (node)
+   return node;
+   }
 
return NULL;
 }
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv4 04/10] ARM: DRA7: hwmod: add DMM hwmod description

[Tomi Valkeinen]

Add DMM hwmod entries for DRA7. This is identical to DMM on OMAP5.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 817dbd87ce67..f6b94854fafc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -49,6 +49,27 @@
  */
 
 /*
+ * 'dmm' class
+ * instance(s): dmm
+ */
+static struct omap_hwmod_class dra7xx_dmm_hwmod_class = {
+   .name   = dmm,
+};
+
+/* dmm */
+static struct omap_hwmod dra7xx_dmm_hwmod = {
+   .name   = dmm,
+   .class  = dra7xx_dmm_hwmod_class,
+   .clkdm_name = emif_clkdm,
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_EMIF_DMM_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_EMIF_DMM_CONTEXT_OFFSET,
+   },
+   },
+};
+
+/*
  * 'l3' class
  * instance(s): l3_instr, l3_main_1, l3_main_2
  */
@@ -2322,6 +2343,14 @@ static struct omap_hwmod dra7xx_wd_timer2_hwmod = {
  * Interfaces
  */
 
+/* l3_main_1 - dmm */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__dmm = {
+   .master = dra7xx_l3_main_1_hwmod,
+   .slave  = dra7xx_dmm_hwmod,
+   .clk= l3_iclk_div,
+   .user   = OCP_USER_SDMA,
+};
+
 /* l3_main_2 - l3_instr */
 static struct omap_hwmod_ocp_if dra7xx_l3_main_2__l3_instr = {
.master = dra7xx_l3_main_2_hwmod,
@@ -3290,6 +3319,7 @@ static struct omap_hwmod_ocp_if dra7xx_l4_wkup__wd_timer2 
= {
 };
 
 static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
+   dra7xx_l3_main_1__dmm,
dra7xx_l3_main_2__l3_instr,
dra7xx_l4_cfg__l3_main_1,
dra7xx_mpu__l3_main_1,
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv4 10/10] arm/dts: am57xx-beagle-x15.dts: add HDMI

[Tomi Valkeinen]

AM57xx Beagle X15 has a HDMI output. This patch adds the device tree
nodes required for HDMI.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
 arch/arm/boot/dts/am57xx-beagle-x15.dts | 81 +
 1 file changed, 81 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 15f198e4864d..f1e430507e4f 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -18,6 +18,7 @@
aliases {
rtc0 = mcp_rtc;
rtc1 = tps659038_rtc;
+   display0 = hdmi0;
};
 
memory {
@@ -102,6 +103,51 @@
pinctrl-names = default;
pinctrl-0 = extcon_usb2_pins;
};
+
+   hdmi0: connector {
+   compatible = hdmi-connector;
+   label = hdmi;
+
+   type = a;
+
+   port {
+   hdmi_connector_in: endpoint {
+   remote-endpoint = tpd12s015_out;
+   };
+   };
+   };
+
+   tpd12s015: encoder {
+   compatible = ti,tpd12s015;
+
+   pinctrl-names = default;
+   pinctrl-0 = tpd12s015_pins;
+
+   gpios = gpio7 10 GPIO_ACTIVE_HIGH,   /* gpio7_10, CT CP HPD 
*/
+   gpio6 28 GPIO_ACTIVE_HIGH,   /* gpio6_28, LS OE */
+   gpio7 12 GPIO_ACTIVE_HIGH;   /* gpio7_12/sp1_cs2, 
HPD */
+
+   ports {
+   #address-cells = 1;
+   #size-cells = 0;
+
+   port@0 {
+   reg = 0;
+
+   tpd12s015_in: endpoint {
+   remote-endpoint = hdmi_out;
+   };
+   };
+
+   port@1 {
+   reg = 1;
+
+   tpd12s015_out: endpoint {
+   remote-endpoint = hdmi_connector_in;
+   };
+   };
+   };
+   };
 };
 
 dra7_pmx_core {
@@ -121,6 +167,13 @@
;
};
 
+   hdmi_pins: pinmux_hdmi_pins {
+   pinctrl-single,pins = 
+   0x408 (PIN_INPUT | MUX_MODE1)   /* 
i2c2_sda.hdmi1_ddc_scl */
+   0x40c (PIN_INPUT | MUX_MODE1)   /* 
i2c2_scl.hdmi1_ddc_sda */
+   ;
+   };
+
i2c3_pins_default: i2c3_pins_default {
pinctrl-single,pins = 
0x2a4 (PIN_INPUT| MUX_MODE10)   /* 
mcasp1_aclkx.i2c3_sda */
@@ -277,6 +330,14 @@
0x3e8 (PIN_INPUT_PULLUP | MUX_MODE14) /* 
uart1_ctsn.gpio7_24 */
;
};
+
+   tpd12s015_pins: pinmux_tpd12s015_pins {
+   pinctrl-single,pins = 
+   0x3b0 (PIN_OUTPUT | MUX_MODE14) /* gpio7_10 
CT_CP_HPD */
+   0x3b8 (PIN_INPUT_PULLDOWN | MUX_MODE14) /* gpio7_12 HPD 
*/
+   0x370 (PIN_OUTPUT | MUX_MODE14) /* gpio6_28 
LS_OE */
+   ;
+   };
 };
 
 i2c1 {
@@ -607,3 +668,23 @@
};
};
 };
+
+dss {
+   status = ok;
+
+   vdda_video-supply = ldoln_reg;
+};
+
+hdmi {
+   status = ok;
+   vdda-supply = ldo3_reg;
+
+   pinctrl-names = default;
+   pinctrl-0 = hdmi_pins;
+
+   port {
+   hdmi_out: endpoint {
+   remote-endpoint = tpd12s015_in;
+   };
+   };
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fbdev: omap2: improve usage of gpiod API

[Tomi Valkeinen]

On 28/05/15 11:05, Uwe Kleine-König wrote:
 Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
 which appeared in v3.17-rc1, the gpiod_get* functions take an additional
 parameter that allows to specify direction and initial value for output.
 
 Also make use of gpiod_get*_optional where applicable.
 
 Apart from simplification of the affected drivers this is another step
 towards making the flags argument to gpiod_get*() mandatory.
 
 Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
 ---
  drivers/video/fbdev/omap2/displays-new/encoder-opa362.c | 12 +++-
  drivers/video/fbdev/omap2/displays-new/panel-dpi.c  | 13 
 +++--
  .../fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c |  7 +++
  .../fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c  |  9 ++---
  4 files changed, 11 insertions(+), 30 deletions(-)

Thanks, this cleans up nicely those optional cases. Queued for 4.2.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCHv3 10/10] CLK: TI: always enable DESHDCP clock

[Tomi Valkeinen]

On 20/05/15 14:47, Tero Kristo wrote:
 On 05/06/2015 01:08 PM, Tomi Valkeinen wrote:
 DESHDCP clock is needed on DRA7 based SoCs to enable the DSS IP. That
 clock is an odd one, as it is not supposed to be any kind of core clock
 for DSS, and we don't even support HDCP, but the clock is still needed
 even for the HWMOD framework to be able to reset the DSS IP.

 As there's no support for multiple core clocks in the HWMOD framework,
 we don't have any obvious place to enable this clock when DSS IP is
 being enabled.

 Furthermore, the HDMI on OMAP5 DSS is the same as on DRA7, and OMAP5
 does not have any such clock configuration bit. This suggests that on
 OMAP5 the DESHDCP clock is always enabled, and for DRA7 we have the
 possibility to gate it.

 So, as we don't have any clean way to enable and disable the clock
 based on the need, this patch enables the clock at boot time, making it
 work similarly to OMAP5.

 Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
 ---
   drivers/clk/ti/clk-7xx.c | 7 ++-
   1 file changed, 6 insertions(+), 1 deletion(-)

 diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
 index 2dd956b9affa..63b8323df918 100644
 --- a/drivers/clk/ti/clk-7xx.c
 +++ b/drivers/clk/ti/clk-7xx.c
 @@ -312,7 +312,7 @@ static struct ti_dt_clk dra7xx_clks[] = {
   int __init dra7xx_dt_clk_init(void)
   {
   int rc;
 -struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck;
 +struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck, *hdcp_ck;

   ti_dt_clocks_register(dra7xx_clks);

 @@ -348,5 +348,10 @@ int __init dra7xx_dt_clk_init(void)
   if (rc)
   pr_err(%s: failed to set USB_DPLL M2 OUT\n, __func__);

 +hdcp_ck = clk_get_sys(NULL, dss_deshdcp_clk);
 +rc = clk_prepare_enable(hdcp_ck);
 +if (rc)
 +pr_err(%s: failed to set dss_deshdcp_clk\n, __func__);
 +
   return rc;
   }

 
 You should rather use the assigned-clock properties in DT to accomplish
 this, the manual clock tweaks under the drivers/clk/ti/clk-* files
 should be converted to DT setup also.

So what should we do?

I got a confirmation from a HW guy that this clock is always enabled on
OMAP5, and that's why we haven't seen these issues there. I believe
there's a HW bug related to this, as having the HDCP clock disabled
should not prevent the use of DSS, but it does.

In my opinion the bit should just be always set, which is what this
patch does. Although I think even adding a clock node is kind of extra,
as it's clear the bit cannot be properly used.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v5 0/6] Use DRM component API in tilcdc to connect to tda998x

[Tomi Valkeinen]

On 08/05/15 14:27, Jyri Sarha wrote:
 For all that I know this should be good for taking.
 
 Changes since v4
 * Rebased on top linux-4.1-rc2
 * Drop drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_...
 * Make connector_funcs const in struct tilcdc_drm_private because
   struct drm_connector's helper_private has been qualified as const in
   linux-4.1
 * Check if a subcomponent has already triggered the unloading.
   - Fixes an oops if the external encoder is unloaded first and tilcdc after
 * Add comment to explain hijacking of external drm connectors helper hijacking
 
 Changes since v3 version of the patch-set:
 * drm/tilcdc: Add support for external tda998x encoder
  - Hijack external connectors helper functions
  - Remove select of nonexistent DRM_TILCDC_INIT in tilcdc Kconfig
  - Correct author mail address to tilcdc_exteral.h
 * drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti,tilcdc,slave binding
  - Add a header file for tilcdc_slave_compat.dtb symbol declarations
 
 Changes since v2 version of the patch-set:
 - use obj-y in Makefle for tilcdc subdir in:
   drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT
 - move to last:
   drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint
 
 Changes since first version of the patch-set:
 - Rename DRM_TILCDC_INIT to DRM_TILCDC_SLAVE_COMPAT and make it visible
 - Add separate: 
   drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint
 - Reduce info-level spam
 - Use component_master_add_with_match()
 - Be more explicit about tda998x being the only supported external encoder
 
 Remove tilcdc slave support and connect to tda998x trough its
 component DRM API. For dtb backward compatibility the code creates at
 boot time a DT overlay based on the earlier binding. The overlay
 conforms to the new graph based binding.
 
 The drm/tilcdc: Decrement refcount of ep-node from
 of_graph_get_next_endpoint should probably not be merged. The of:
 Decrement refcount of previous endpoint in of_graph_get_next_endpoint
 is eventually going to be merged and before that leaking of two
 of-node refcount increments each time the module is loaded is not that
 serious. The of-nodes live forever anyway.
 
 The merge of the dts patch can be delayed until the next merger
 window, when the other patches are already in. The
 DRM_TILCDC_SLAVE_COMPAT should keep the bbb HDMI operational until
 then.
 
 The first patch is just a bugfix and can be applied or dropped
 independently.

This works fine for me, and looks ok. There is a minor problem in the
Kconfig, where you define DRM_TILCDC_SLAVE_COMPAT before DRM_TILCDC.
That causes menuconfig to show the items wrongly.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] video: omap/h3: fix tps65010 dependency

[Tomi Valkeinen]

On 22/05/15 17:22, Arnd Bergmann wrote:
 The h3 LCD driver fails to link when tps65010 is configured
 as a loadable module:
 
 drivers/built-in.o: In function `h3_panel_disable':
 debugfs.c:(.text+0x206ac): undefined reference to 
 `tps65010_set_gpio_out_value'
 debugfs.c:(.text+0x206cc): undefined reference to 
 `tps65010_set_gpio_out_value'
 drivers/built-in.o: In function `h3_panel_enable':
 debugfs.c:(.text+0x206e0): undefined reference to 
 `tps65010_set_gpio_out_value'
 debugfs.c:(.text+0x20704): undefined reference to 
 `tps65010_set_gpio_out_value'
 
 This clarifies the dependency so we can only select it if
 the dependnecy is built-in.
 
 Signed-off-by: Arnd Bergmann a...@arndb.de
 
 diff --git a/drivers/video/fbdev/omap/Kconfig 
 b/drivers/video/fbdev/omap/Kconfig
 index 18c4cb0d5690..29d250da8a3e 100644
 --- a/drivers/video/fbdev/omap/Kconfig
 +++ b/drivers/video/fbdev/omap/Kconfig
 @@ -42,7 +42,7 @@ config FB_OMAP_LCD_MIPID
  config FB_OMAP_LCD_H3
   bool TPS65010 LCD controller on OMAP-H3
   depends on MACH_OMAP_H3
 - depends on TPS65010
 + depends on TPS65010=y
   default y
   help
 Say Y here if you want to have support for the LCD on the
 

Thanks, queued for 4.2.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCHv3 10/10] CLK: TI: always enable DESHDCP clock

[Tomi Valkeinen]

On 21/05/15 06:06, Paul Walmsley wrote:

 Enable falls under the critical clocks discussion that is ongoing. I
 assume that this is some sort of critical clock that can't be turned off?
 
 It only needs to be enabled for this particular display IP subsystem to 
 function:
 
 http://marc.info/?l=linux-omapm=142071550111482w=2
 
 I believe Tomi is taking this approach (enabling it unconditionally) to 
 avoid adding support for a secondary IP block main clock to the hwmod 

Right. I don't think that would be a simple task (correct me if I'm
wrong), and that would all be only for this one IP on this particular
SoC type.

 code.  Apparently, the chips that contain this clock gating bit are not 
 intended to be used for power-critical use cases, so there's not much 
 motivation to switch it on and off with the display controller.

Even in power-critical use cases the the power use difference should be
negligible.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCHv3 00/10] ARM: DRA7: add display support

[Tomi Valkeinen]

Hi,

On 06/05/15 13:08, Tomi Valkeinen wrote:
 Hi,
 
 This series adds the arch/arm/ side of the display support for DRA7 (DRA72x,
 DRA74x, AM54xx) SoCs. Also support for HDMI output on x15 and DRA72 EVM boards
 is added.
 
 This series is v3, and is based on v4.1-rc2. There are no differences to v2,
 except rebased and tested.
 
  Tomi
 
 Tomi Valkeinen (10):
   arm/dts: dra7xx: add 'ti,set-rate-parent' for dss_dss_clk
   ARM: DRA7: hwmod: add DMM hwmod description
   ARM: DRA7: hwmod: set DSS submodule parent hwmods
   ARM: OMAP: display: change compat names to array
   ARM: OMAP2+: display: detect DRA7 DSS
   arm/dts: dra7.dtsi: add DSS support
   arm/dts: dra72-evm.dts: add HDMI
   arm/dts: am57xx-beagle-x15.dts: add HDMI
   arm: dra7: add DESHDCP clock
   CLK: TI: always enable DESHDCP clock
 
  arch/arm/boot/dts/am57xx-beagle-x15.dts   |  81 ++
  arch/arm/boot/dts/dra7.dtsi   |  43 
  arch/arm/boot/dts/dra72-evm.dts   | 110 
 ++
  arch/arm/boot/dts/dra72x.dtsi |  11 +++
  arch/arm/boot/dts/dra74x.dtsi |  15 
  arch/arm/boot/dts/dra7xx-clocks.dtsi  |  11 +++
  arch/arm/mach-omap2/display.c |  32 +
  arch/arm/mach-omap2/omap_hwmod_7xx_data.c |  33 +
  drivers/clk/ti/clk-7xx.c  |   8 ++-
  9 files changed, 328 insertions(+), 16 deletions(-)

Ping. Any comments? Can we get this into the next merge window?

 Tomi



signature.asc
Description: OpenPGP digital signature

[PATCHv3 10/10] CLK: TI: always enable DESHDCP clock

[Tomi Valkeinen]

DESHDCP clock is needed on DRA7 based SoCs to enable the DSS IP. That
clock is an odd one, as it is not supposed to be any kind of core clock
for DSS, and we don't even support HDCP, but the clock is still needed
even for the HWMOD framework to be able to reset the DSS IP.

As there's no support for multiple core clocks in the HWMOD framework,
we don't have any obvious place to enable this clock when DSS IP is
being enabled.

Furthermore, the HDMI on OMAP5 DSS is the same as on DRA7, and OMAP5
does not have any such clock configuration bit. This suggests that on
OMAP5 the DESHDCP clock is always enabled, and for DRA7 we have the
possibility to gate it.

So, as we don't have any clean way to enable and disable the clock
based on the need, this patch enables the clock at boot time, making it
work similarly to OMAP5.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/clk/ti/clk-7xx.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 2dd956b9affa..63b8323df918 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -312,7 +312,7 @@ static struct ti_dt_clk dra7xx_clks[] = {
 int __init dra7xx_dt_clk_init(void)
 {
int rc;
-   struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck;
+   struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck, *hdcp_ck;
 
ti_dt_clocks_register(dra7xx_clks);
 
@@ -348,5 +348,10 @@ int __init dra7xx_dt_clk_init(void)
if (rc)
pr_err(%s: failed to set USB_DPLL M2 OUT\n, __func__);
 
+   hdcp_ck = clk_get_sys(NULL, dss_deshdcp_clk);
+   rc = clk_prepare_enable(hdcp_ck);
+   if (rc)
+   pr_err(%s: failed to set dss_deshdcp_clk\n, __func__);
+
return rc;
 }
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] ARM: OMAP2+: OMAP DRA7xx display-related hwmod data changes for v4.1

[Tomi Valkeinen]

Hi,

No, don't pull this, it doesn't work.

Paul, the hwmod patch cannot be picked from the DRA7 DSS series. We have
the problem with the DES HDCP clock, without that clock we will see
WARNINGs when booting if the set DSS submodule parent hwmods is applied.

We do see some errors when booting even with the current mainline,
caused by not having that clock enabled:

[0.194524] omap_hwmod: dss_core: _wait_target_disable failed
[0.194540] omap_hwmod: dss_core: _wait_target_ready failed: -16
[0.194554] omap_hwmod: dss_core: cannot be enabled for reset (3)
[0.197143] omap_hwmod: dss_dispc: _wait_target_ready failed: -16
[0.197156] omap_hwmod: dss_dispc: cannot be enabled for reset (3)
[0.199745] omap_hwmod: dss_hdmi: _wait_target_ready failed: -16
[0.199759] omap_hwmod: dss_hdmi: cannot be enabled for reset (3)

But that's still much less spam than the above plus ~4 WARNs.

I'd rather merge the DRA7 DSS patches in one go, to avoid issues related
to the HDPC clock.

 Tomi

On 04/04/15 02:08, Tony Lindgren wrote:
 Hi Arnd  Olof,
 
 Please feel free to pull this directly from Paul.
 
 Regards,
 
 Tony
 
 * Paul Walmsley p...@pwsan.com [150403 12:55]:
 Hi Tony

 The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:

   Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
 tags/for-v4.1/omap-hwmod-b

 for you to fetch changes up to 0d75ebdd3230b3d085812df80ec54138828cc76a:

   ARM: DRA7: hwmod: set DSS submodule parent hwmods (2015-04-03 13:15:07 
 -0600)

 
 OMAP DRA7xx display-related hwmod data changes for v4.1

 Add DMM hwmod data for DRA7xx, and set the parent hwmods fields
 appropriately for the DRA7xx DSS submodules as we've done for
 other OMAP devices.

 Note that I do not have a DRA7xx board, and thus cannot boot-test
 these patches.

 Basic build, boot, and PM idle test logs are available at:

 http://www.pwsan.com/omap/testlogs/omap-hwmod-b-for-v4.1/20150403123702/

 
 Tomi Valkeinen (2):
   ARM: DRA7: hwmod: add DMM hwmod description
   ARM: DRA7: hwmod: set DSS submodule parent hwmods

  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 32 
 +++
  1 file changed, 32 insertions(+)



 vmlinux object size
 (delta in bytes from test_v4.0-rc1 
 (c517d838eb7d07bbe9507871fab3931deccff539)):
text data  bsstotal  kernel
   0000  omap1_defconfig
   0000  omap1_defconfig_1510innovator_only
   0000  omap1_defconfig_5912osk_only
   0 +1920 +192  multi_v7_defconfig
   0 +2160 +216  omap2plus_defconfig
   0000  omap2plus_defconfig_2430sdp_only
   0000  omap2plus_defconfig_am33xx_only
   0000  omap2plus_defconfig_am43xx_only
   0 +2240 +224  omap2plus_defconfig_cpupm
   0 +1920 +192  omap2plus_defconfig_dra7xx_only
   0000  omap2plus_defconfig_n800_multi_omap2xxx
   0000  omap2plus_defconfig_n800_only_a
   0 +1920 +192  omap2plus_defconfig_no_pm
   0000  omap2plus_defconfig_omap2_4_only
   0000  omap2plus_defconfig_omap3_4_only
   0000  omap2plus_defconfig_omap5_only
   0000  rmk_omap3430_ldp_allnoconfig
   0000  rmk_omap3430_ldp_oldconfig
  +80   -80  rmk_omap4430_sdp_allnoconfig
   0000  rmk_omap4430_sdp_oldconfig

 Boot-time memory difference
 (delta in bytes from test_v4.0-rc1 
 (c517d838eb7d07bbe9507871fab3931deccff539))
   avail  rsrvd   high  freed  board  kconfig
 -4k 4k  .  .  4460pandaesomap2plus_defconfig
-12k12k  .  .  4460varsomom   omap2plus_defconfig
 -4k 4k  .  .  5430es2sbct54  omap2plus_defconfig

 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 




signature.asc
Description: OpenPGP digital signature

Re: [PATCHv2 03/10] ARM: DRA7: hwmod: set DSS submodule parent hwmods

[Tomi Valkeinen]

On 03/04/15 22:03, Paul Walmsley wrote:
 On Tue, 24 Mar 2015, Tomi Valkeinen wrote:
 
 Set DSS core hwmod as the parent for all the DSS submodules.

 Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
 
 Thanks, queued.  Will send a pull request for this to Tony today, but it  
 may not make it for v4.1.  
 
 Note that I cannot boot test this since I do not have a DRA7xx board.

As I mentioned in the reply to the pull request, we can't cherry pick
this patch, we need the HDCP clock.

This series should be changed so that the HDCP clock is handled in the
beginning of the series to keep bisect working. I'll do that for the
next version, which I probably would need to do in any case as Tero's
series is still under work.

Or if we want to get DRA7 DSS support in earlier, we could just use my
earlier simple patch which enables the HDCP clock.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3 0/7] Use DRM component API in tilcdc to connect to tda998x

[Tomi Valkeinen]

Hi,

On 18/03/15 11:06, Jyri Sarha wrote:
 I think the patches 1-5 are ready for merging. See the details below.

I applied these on top of v4.0-rc3, booted up BBB, and loaded the modules. 
After doing that and waiting a few secs:

# ./s-bbb.sh 
[   15.237139] sysrq: SysRq : Changing Loglevel
[   15.241646] sysrq: Loglevel set to 9
[   15.319762] [drm] Initialized drm 1.1.0 20060810
[   15.588122] tda998x 0-0070: found TDA19988
[   15.594824] tilcdc 4830e000.lcdc: bound 0-0070 (ops tda998x_ops [tda998x])
[   15.602034] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   15.609011] [drm] No driver support for vblank timestamp query.
[   15.700798] tilcdc 4830e000.lcdc: fb0:  frame buffer device
[   15.706757] tilcdc 4830e000.lcdc: registered panic notifier
[   15.712659] [drm] Initialized tilcdc 1.0.0 20121205 on minor 0
# 
# [   25.789364] [ cut here ]
[   25.794315] WARNING: CPU: 0 PID: 50 at 
drivers/gpu/drm/tilcdc/tilcdc_crtc.c:269 tilcdc_crtc_mode_set+0x5ec/0x648 
[tilcdc]()
[   25.805999] Modules linked in: tilcdc tda998x drm_kms_helper drm
[   25.812325] CPU: 0 PID: 50 Comm: kworker/0:2 Not tainted 
4.0.0-rc3-7-g5fbf26ebaf12 #7
[   25.820893] Hardware name: Generic AM33XX (Flattened Device Tree)
[   25.827359] Workqueue: events output_poll_execute [drm_kms_helper]
[   25.833819] Backtrace: 
[   25.836439] [c0013550] (dump_backtrace) from [c0013764] 
(show_stack+0x18/0x1c)
[   25.844380]  r6:c09d4228 r5:c09d4228 r4: r3:dd3604c0
[   25.850338] [c001374c] (show_stack) from [c066bbc0] 
(dump_stack+0xa4/0xd4)
[   25.857927] [c066bb1c] (dump_stack) from [c0044d28] 
(warn_slowpath_common+0x84/0xc0)
[   25.866401]  r6:010d r5:bf0a010c r4: r3:dd3604c0
[   25.872348] [c0044ca4] (warn_slowpath_common) from [c0044e08] 
(warn_slowpath_null+0x24/0x2c)
[   25.881543]  r8:dd50 r7:000f r6:bf0a25f0 r5:dd6b1400 r4:dd4e6800
[   25.888617] [c0044de4] (warn_slowpath_null) from [bf0a010c] 
(tilcdc_crtc_mode_set+0x5ec/0x648 [tilcdc])
[   25.898849] [bf09fb20] (tilcdc_crtc_mode_set [tilcdc]) from [bf06d874] 
(drm_crtc_helper_set_mode+0x2b0/0x4f0 [drm_kms_helper])
[   25.911132]  r10:dd4e6bf0 r9:dd4e6800 r8:dd4e2e80 r7:dd6b1400 r6:0001 
r5:dd50
[   25.919372]  r4:bf09fb20
[   25.922061] [bf06d5c4] (drm_crtc_helper_set_mode [drm_kms_helper]) from 
[bf06e450] (drm_crtc_helper_set_config+0x768/0x9c8 [drm_kms_helper])
[   25.935612]  r10: r9:dd73d980 r8:dd4e6bf0 r7:bf031808 r6:dd4e6be4 
r5:dd4e6bd8
[   25.943827]  r4:dd50
[   25.946758] [bf06dce8] (drm_crtc_helper_set_config [drm_kms_helper]) from 
[bf00dcfc] (drm_mode_set_config_internal+0x6c/0xf4 [drm])
[   25.959518]  r10:0001 r9: r8:dd4b4b40 r7:dd50 r6:0001 
r5:0028
[   25.967767]  r4:dd4b46c0
[   25.970558] [bf00dc90] (drm_mode_set_config_internal [drm]) from 
[bf077a88] (restore_fbdev_mode+0xe0/0x100 [drm_kms_helper])
[   25.982672]  r7:dd73d980 r6:0001 r5:0028 r4:
[   25.988698] [bf0779a8] (restore_fbdev_mode [drm_kms_helper]) from 
[bf0799cc] (drm_fb_helper_restore_fbdev_mode_unlocked+0x24/0x64 
[drm_kms_helper])
[   26.002884]  r9:dd4e6be4 r8:bf031808 r7:dd4e6800 r6:dd4e6800 r5:dd4b46c0 
r4:dd4b4b40
[   26.011104] [bf0799a8] (drm_fb_helper_restore_fbdev_mode_unlocked 
[drm_kms_helper]) from [bf079a2c] (drm_fb_helper_set_par+0x20/0x3c 
[drm_kms_helper])
[   26.025562]  r6:dd4e6800 r5:dd4b46c0 r4: r3:
[   26.031556] [bf079a0c] (drm_fb_helper_set_par [drm_kms_helper]) from 
[bf079968] (drm_fb_helper_hotplug_event+0x90/0xd0 [drm_kms_helper])
[   26.044753]  r4:dd4b4b40 r3:
[   26.048557] [bf0798d8] (drm_fb_helper_hotplug_event [drm_kms_helper]) from 
[bf07a7c4] (drm_fbdev_cma_hotplug_event+0x18/0x1c [drm_kms_helper])
[   26.062289]  r7:dd4e6a40 r6:0001 r5:dd4e6c38 r4:dd4e6800
[   26.068300] [bf07a7ac] (drm_fbdev_cma_hotplug_event [drm_kms_helper]) from 
[bf0a217c] (tilcdc_fb_output_poll_changed+0x18/0x1c [tilcdc])
[   26.081521] [bf0a2164] (tilcdc_fb_output_poll_changed [tilcdc]) from 
[bf06f388] (drm_kms_helper_hotplug_event+0x2c/0x30 [drm_kms_helper])
[   26.094840] [bf06f35c] (drm_kms_helper_hotplug_event [drm_kms_helper]) 
from [bf06f448] (output_poll_execute+0x6c/0x18c [drm_kms_helper])
[   26.108027]  r4:dd4e6bd8 r3:
[   26.111809] [bf06f3dc] (output_poll_execute [drm_kms_helper]) from 
[c005c704] (process_one_work+0x1e8/0x560)
[   26.122456]  r10:dfa1b700 r9: r8:c0a0c0b8 r7:dd51deb0 r6:dfa157c0 
r5:dd4b4d40
[   26.130696]  r4:dd4e6c38
[   26.133353] [c005c51c] (process_one_work) from [c005d42c] 
(worker_thread+0x160/0x4c4)
[   26.141914]  r10:dfa157c0 r9:0008 r8:dd4b4d58 r7:dd4b4d40 r6:c005d304 
r5:dfa157f0
[   26.150153]  r4:dfa157c0
[   26.152812] [c005d2cc] (worker_thread) from [c0061e38] 
(kthread+0xf0/0x110)
[   26.160465]  r10: r9: r8: r7:c005d2cc r6:dd4b4d40 
r5:dd509cc0
[   26.168704]  r4:
[   26.171362] [c0061d48] (kthread) from [c000f6d0] 

[PATCHv2 06/10] arm/dts: dra7.dtsi: add DSS support

[Tomi Valkeinen]

DRA7xxx contains a very similar DSS to OMAP5. The main differences are:

* no DSI or RFBI support.
* 1 or 2 dedicated video PLLs.
* need to do additional configuration to the DRA7 CONTROL module.

DRA72xx has only one video PLL, and DRA74xx has two.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
 arch/arm/boot/dts/dra7.dtsi   | 38 ++
 arch/arm/boot/dts/dra72x.dtsi | 11 +++
 arch/arm/boot/dts/dra74x.dtsi | 15 +++
 3 files changed, 64 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8e50ca3fc102..312ede660b23 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1445,6 +1445,44 @@
clocks = sys_clkin1;
status = disabled;
};
+
+   dss: dss@5800 {
+   compatible = ti,dra7-dss;
+   /* 'reg' defined in dra72x.dtsi and dra74x.dtsi */
+   /* 'clocks' defined in dra72x.dtsi and dra74x.dtsi */
+   status = disabled;
+   ti,hwmods = dss_core;
+   /* CTRL_CORE_DSS_PLL_CONTROL */
+   syscon-pll-ctrl = scm_conf 0x538;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   dispc@58001000 {
+   compatible = ti,dra7-dispc;
+   reg = 0x58001000 0x1000;
+   interrupts = GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH;
+   ti,hwmods = dss_dispc;
+   clocks = dss_dss_clk;
+   clock-names = fck;
+   /* CTRL_CORE_SMA_SW_1 */
+   syscon-pol = scm_conf 0x534;
+   };
+
+   hdmi: encoder@5806 {
+   compatible = ti,dra7-hdmi;
+   reg = 0x5804 0x200,
+ 0x58040200 0x80,
+ 0x58040300 0x80,
+ 0x5806 0x19000;
+   reg-names = wp, pll, phy, core;
+   interrupts = GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH;
+   status = disabled;
+   ti,hwmods = dss_hdmi;
+   clocks = dss_48mhz_clk, dss_hdmi_clk;
+   clock-names = fck, sys_clk;
+   };
+   };
};
 };
 
diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
index e5a3d23a3df1..0866866c8e94 100644
--- a/arch/arm/boot/dts/dra72x.dtsi
+++ b/arch/arm/boot/dts/dra72x.dtsi
@@ -28,3 +28,14 @@
interrupts = GIC_SPI DIRECT_IRQ(131) IRQ_TYPE_LEVEL_HIGH;
};
 };
+
+dss {
+   reg = 0x5800 0x80,
+ 0x58004054 0x4,
+ 0x58004300 0x20;
+   reg-names = dss, pll1_clkctrl, pll1;
+
+   clocks = dss_dss_clk,
+dss_video1_clk;
+   clock-names = fck, video1_clk;
+};
diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
index 10173fab1a15..1a4f4970aaad 100644
--- a/arch/arm/boot/dts/dra74x.dtsi
+++ b/arch/arm/boot/dts/dra74x.dtsi
@@ -67,3 +67,18 @@
};
};
 };
+
+dss {
+   reg = 0x5800 0x80,
+ 0x58004054 0x4,
+ 0x58004300 0x20,
+ 0x58005054 0x4,
+ 0x58005300 0x20;
+   reg-names = dss, pll1_clkctrl, pll1,
+   pll2_clkctrl, pll2;
+
+   clocks = dss_dss_clk,
+dss_video1_clk,
+dss_video2_clk;
+   clock-names = fck, video1_clk, video2_clk;
+};
-- 
2.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 00/10] ARM: DRA7: add display support

[Tomi Valkeinen]

Hi,

This series adds the arch/arm/ side of the display support for DRA7 (DRA72x,
DRA74x, AM54xx) SoCs. Also support for HDMI output on x15 and DRA72 EVM boards
is added.

This series is v2, and is based on Tero's [PATCHv5 00/35] ARM: OMAP2+:
PRCM/SCM cleanups against 4.0-rc series. The difference to v1 is that the
DESHDCP clock is a real clock, even if we still always enable it at boot time.

 Tomi

Tomi Valkeinen (10):
  arm/dts: dra7xx: add 'ti,set-rate-parent' for dss_dss_clk
  ARM: DRA7: hwmod: add DMM hwmod description
  ARM: DRA7: hwmod: set DSS submodule parent hwmods
  ARM: OMAP: display: change compat names to array
  ARM: OMAP2+: display: detect DRA7 DSS
  arm/dts: dra7.dtsi: add DSS support
  arm/dts: dra72-evm.dts: add HDMI
  arm/dts: am57xx-beagle-x15.dts: add HDMI
  arm: dra7: add DESHDCP clock
  CLK: TI: always enable DESHDCP clock

 arch/arm/boot/dts/am57xx-beagle-x15.dts   |  81 ++
 arch/arm/boot/dts/dra7.dtsi   |  43 
 arch/arm/boot/dts/dra72-evm.dts   | 110 ++
 arch/arm/boot/dts/dra72x.dtsi |  11 +++
 arch/arm/boot/dts/dra74x.dtsi |  15 
 arch/arm/boot/dts/dra7xx-clocks.dtsi  |  11 +++
 arch/arm/mach-omap2/display.c |  32 +
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c |  33 +
 drivers/clk/ti/clk-7xx.c  |   8 ++-
 9 files changed, 328 insertions(+), 16 deletions(-)

-- 
2.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 07/10] arm/dts: dra72-evm.dts: add HDMI

[Tomi Valkeinen]

DRA72 EVM has a HDMI output. This patch adds the device tree nodes
required for HDMI.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
 arch/arm/boot/dts/dra72-evm.dts | 110 
 1 file changed, 110 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 4d8711713610..c752d7aa302d 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -19,6 +19,10 @@
reg = 0x8000 0x4000; /* 1024 MB */
};
 
+   aliases {
+   display0 = hdmi0;
+   };
+
evm_3v3: fixedregulator-evm_3v3 {
compatible = regulator-fixed;
regulator-name = evm_3v3;
@@ -35,6 +39,51 @@
compatible = linux,extcon-usb-gpio;
id-gpio = pcf_gpio_21 2 GPIO_ACTIVE_HIGH;
};
+
+   hdmi0: connector {
+   compatible = hdmi-connector;
+   label = hdmi;
+
+   type = a;
+
+   port {
+   hdmi_connector_in: endpoint {
+   remote-endpoint = tpd12s015_out;
+   };
+   };
+   };
+
+   tpd12s015: encoder {
+   compatible = ti,tpd12s015;
+
+   pinctrl-names = default;
+   pinctrl-0 = tpd12s015_pins;
+
+   gpios = pcf_hdmi 4 GPIO_ACTIVE_HIGH, /* P4, CT CP HPD */
+   pcf_hdmi 5 GPIO_ACTIVE_HIGH, /* P5, LS OE */
+   gpio7 12 GPIO_ACTIVE_HIGH;   /* gpio7_12/sp1_cs2, 
HPD */
+
+   ports {
+   #address-cells = 1;
+   #size-cells = 0;
+
+   port@0 {
+   reg = 0;
+
+   tpd12s015_in: endpoint {
+   remote-endpoint = hdmi_out;
+   };
+   };
+
+   port@1 {
+   reg = 1;
+
+   tpd12s015_out: endpoint {
+   remote-endpoint = hdmi_connector_in;
+   };
+   };
+   };
+   };
 };
 
 dra7_pmx_core {
@@ -45,6 +94,13 @@
;
};
 
+   i2c5_pins: pinmux_i2c5_pins {
+   pinctrl-single,pins = 
+   0x2b4 (PIN_INPUT | MUX_MODE10) /* mcasp1_axr0.i2c5_sda 
*/
+   0x2b8 (PIN_INPUT | MUX_MODE10) /* mcasp1_axr1.i2c5_scl 
*/
+   ;
+   };
+
nand_default: nand_default {
pinctrl-single,pins = 
0x0 (PIN_INPUT  | MUX_MODE0) /* gpmc_ad0 */
@@ -144,6 +200,19 @@
0xb8 (PIN_OUTPUT | MUX_MODE1)   /* gpmc_cs2.qspi1_cs0 */
;
};
+
+   hdmi_pins: pinmux_hdmi_pins {
+   pinctrl-single,pins = 
+   0x408 (PIN_INPUT | MUX_MODE1) /* i2c2_sda.hdmi1_ddc_scl 
*/
+   0x40c (PIN_INPUT | MUX_MODE1) /* i2c2_scl.hdmi1_ddc_sda 
*/
+   ;
+   };
+
+   tpd12s015_pins: pinmux_tpd12s015_pins {
+   pinctrl-single,pins = 
+   0x3b8 (PIN_INPUT_PULLDOWN | MUX_MODE14) /* gpio7_12 HPD 
*/
+   ;
+   };
 };
 
 i2c1 {
@@ -280,6 +349,27 @@
};
 };
 
+i2c5 {
+   status = okay;
+   pinctrl-names = default;
+   pinctrl-0 = i2c5_pins;
+   clock-frequency = 40;
+
+   pcf_hdmi: pcf8575@26 {
+   compatible = nxp,pcf8575;
+   reg = 0x26;
+   gpio-controller;
+   #gpio-cells = 2;
+   /*
+* initial state is used here to keep the mdio interface
+* selected on RU89 through SEL_VIN4_MUX_S0, VIN2_S1 and
+* VIN2_S0 driven high otherwise Ethernet stops working
+* VIN6_SEL_S0 is low, thus selecting McASP3 over VIN6
+*/
+   lines-initial-states = 0x0f2b;
+   };
+};
+
 uart1 {
status = okay;
 };
@@ -569,3 +659,23 @@
};
};
 };
+
+dss {
+   status = ok;
+
+   vdda_video-supply = ldo5_reg;
+};
+
+hdmi {
+   status = ok;
+   vdda-supply = ldo3_reg;
+
+   pinctrl-names = default;
+   pinctrl-0 = hdmi_pins;
+
+   port {
+   hdmi_out: endpoint {
+   remote-endpoint = tpd12s015_in;
+   };
+   };
+};
-- 
2.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 10/10] CLK: TI: always enable DESHDCP clock

[Tomi Valkeinen]

DESHDCP clock is needed on DRA7 based SoCs to enable the DSS IP. That
clock is an odd one, as it is not supposed to be any kind of core clock
for DSS, and we don't even support HDCP, but the clock is still needed
even for the HWMOD framework to be able to reset the DSS IP.

As there's no support for multiple core clocks in the HWMOD framework,
we don't have any obvious place to enable this clock when DSS IP is
being enabled.

Furthermore, the HDMI on OMAP5 DSS is the same as on DRA7, and OMAP5
does not have any such clock configuration bit. This suggests that on
OMAP5 the DESHDCP clock is always enabled, and for DRA7 we have the
possibility to gate it.

So, as we don't have any clean way to enable and disable the clock
based on the need, this patch enables the clock at boot time, making it
work similarly to OMAP5.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/clk/ti/clk-7xx.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 7b859ec31a14..e132d0677c03 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -308,7 +308,7 @@ static struct ti_dt_clk dra7xx_clks[] = {
 int __init dra7xx_dt_clk_init(void)
 {
int rc;
-   struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck;
+   struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck, *hdcp_ck;
 
ti_dt_clocks_register(dra7xx_clks);
 
@@ -344,5 +344,10 @@ int __init dra7xx_dt_clk_init(void)
if (rc)
pr_err(%s: failed to set USB_DPLL M2 OUT\n, __func__);
 
+   hdcp_ck = clk_get_sys(NULL, dss_deshdcp_clk);
+   rc = clk_prepare_enable(hdcp_ck);
+   if (rc)
+   pr_err(%s: failed to set dss_deshdcp_clk\n, __func__);
+
return rc;
 }
-- 
2.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 02/10] ARM: DRA7: hwmod: add DMM hwmod description

[Tomi Valkeinen]

Add DMM hwmod entries for DRA7. This is identical to DMM on OMAP5.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index e8692e7675b8..c236ea9bb940 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -49,6 +49,27 @@
  */
 
 /*
+ * 'dmm' class
+ * instance(s): dmm
+ */
+static struct omap_hwmod_class dra7xx_dmm_hwmod_class = {
+   .name   = dmm,
+};
+
+/* dmm */
+static struct omap_hwmod dra7xx_dmm_hwmod = {
+   .name   = dmm,
+   .class  = dra7xx_dmm_hwmod_class,
+   .clkdm_name = emif_clkdm,
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_EMIF_DMM_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_EMIF_DMM_CONTEXT_OFFSET,
+   },
+   },
+};
+
+/*
  * 'l3' class
  * instance(s): l3_instr, l3_main_1, l3_main_2
  */
@@ -2313,6 +2334,14 @@ static struct omap_hwmod dra7xx_wd_timer2_hwmod = {
  * Interfaces
  */
 
+/* l3_main_1 - dmm */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__dmm = {
+   .master = dra7xx_l3_main_1_hwmod,
+   .slave  = dra7xx_dmm_hwmod,
+   .clk= l3_iclk_div,
+   .user   = OCP_USER_SDMA,
+};
+
 /* l3_main_2 - l3_instr */
 static struct omap_hwmod_ocp_if dra7xx_l3_main_2__l3_instr = {
.master = dra7xx_l3_main_2_hwmod,
@@ -3265,6 +3294,7 @@ static struct omap_hwmod_ocp_if dra7xx_l4_wkup__wd_timer2 
= {
 };
 
 static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
+   dra7xx_l3_main_1__dmm,
dra7xx_l3_main_2__l3_instr,
dra7xx_l4_cfg__l3_main_1,
dra7xx_mpu__l3_main_1,
-- 
2.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 08/10] arm/dts: am57xx-beagle-x15.dts: add HDMI

[Tomi Valkeinen]

AM57xx Beagle X15 has a HDMI output. This patch adds the device tree
nodes required for HDMI.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
 arch/arm/boot/dts/am57xx-beagle-x15.dts | 81 +
 1 file changed, 81 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 03750af3b49a..7184fc16d31e 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -19,6 +19,7 @@
aliases {
rtc0 = mcp_rtc;
rtc1 = tps659038_rtc;
+   display0 = hdmi0;
};
 
memory {
@@ -102,6 +103,51 @@
pinctrl-names = default;
pinctrl-0 = extcon_usb2_pins;
};
+
+   hdmi0: connector {
+   compatible = hdmi-connector;
+   label = hdmi;
+
+   type = a;
+
+   port {
+   hdmi_connector_in: endpoint {
+   remote-endpoint = tpd12s015_out;
+   };
+   };
+   };
+
+   tpd12s015: encoder {
+   compatible = ti,tpd12s015;
+
+   pinctrl-names = default;
+   pinctrl-0 = tpd12s015_pins;
+
+   gpios = gpio7 10 GPIO_ACTIVE_HIGH,   /* gpio7_10, CT CP HPD 
*/
+   gpio6 28 GPIO_ACTIVE_HIGH,   /* gpio6_28, LS OE */
+   gpio7 12 GPIO_ACTIVE_HIGH;   /* gpio7_12/sp1_cs2, 
HPD */
+
+   ports {
+   #address-cells = 1;
+   #size-cells = 0;
+
+   port@0 {
+   reg = 0;
+
+   tpd12s015_in: endpoint {
+   remote-endpoint = hdmi_out;
+   };
+   };
+
+   port@1 {
+   reg = 1;
+
+   tpd12s015_out: endpoint {
+   remote-endpoint = hdmi_connector_in;
+   };
+   };
+   };
+   };
 };
 
 dra7_pmx_core {
@@ -121,6 +167,13 @@
;
};
 
+   hdmi_pins: pinmux_hdmi_pins {
+   pinctrl-single,pins = 
+   0x408 (PIN_INPUT | MUX_MODE1)   /* 
i2c2_sda.hdmi1_ddc_scl */
+   0x40c (PIN_INPUT | MUX_MODE1)   /* 
i2c2_scl.hdmi1_ddc_sda */
+   ;
+   };
+
i2c3_pins_default: i2c3_pins_default {
pinctrl-single,pins = 
0x2a4 (PIN_INPUT| MUX_MODE10)   /* 
mcasp1_aclkx.i2c3_sda */
@@ -277,6 +330,14 @@
0x3e8 (PIN_INPUT_PULLUP | MUX_MODE14) /* 
uart1_ctsn.gpio7_24 */
;
};
+
+   tpd12s015_pins: pinmux_tpd12s015_pins {
+   pinctrl-single,pins = 
+   0x3b0 (PIN_OUTPUT | MUX_MODE14) /* gpio7_10 
CT_CP_HPD */
+   0x3b8 (PIN_INPUT_PULLDOWN | MUX_MODE14) /* gpio7_12 HPD 
*/
+   0x370 (PIN_OUTPUT | MUX_MODE14) /* gpio6_28 
LS_OE */
+   ;
+   };
 };
 
 i2c1 {
@@ -560,3 +621,23 @@
 usb2 {
dr_mode = peripheral;
 };
+
+dss {
+   status = ok;
+
+   vdda_video-supply = ldoln_reg;
+};
+
+hdmi {
+   status = ok;
+   vdda-supply = ldo3_reg;
+
+   pinctrl-names = default;
+   pinctrl-0 = hdmi_pins;
+
+   port {
+   hdmi_out: endpoint {
+   remote-endpoint = tpd12s015_in;
+   };
+   };
+};
-- 
2.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 01/10] arm/dts: dra7xx: add 'ti,set-rate-parent' for dss_dss_clk

[Tomi Valkeinen]

We need set-rate-parent flags for the display's clock path so that the
DSS driver can change the clock rate of the PLL.

This patchs adds the ti,set-rate-parent flag to 'dss_dss_clk' clock
node, which is only a gate clock, allowing the setting of the clock rate
to propagate to the PLL.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
 arch/arm/boot/dts/dra7xx-clocks.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi 
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 4bdcbd61ce47..0d76233840e6 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1451,6 +1451,7 @@
clocks = dpll_per_h12x2_ck;
ti,bit-shift = 8;
reg = 0x1120;
+   ti,set-rate-parent;
};
 
dss_hdmi_clk: dss_hdmi_clk {
-- 
2.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 05/10] ARM: OMAP2+: display: detect DRA7 DSS

[Tomi Valkeinen]

Add platform code to detect DRA7 DSS.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 arch/arm/mach-omap2/display.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 9868d0bc7805..6ab13d18c636 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -287,6 +287,8 @@ static enum omapdss_version __init 
omap_display_get_version(void)
return OMAPDSS_VER_OMAP5;
else if (soc_is_am43xx())
return OMAPDSS_VER_AM43xx;
+   else if (soc_is_dra7xx())
+   return OMAPDSS_VER_DRA7xx;
else
return OMAPDSS_VER_UNKNOWN;
 }
@@ -573,6 +575,7 @@ static const char * const omapdss_compat_names[] 
__initconst = {
ti,omap3-dss,
ti,omap4-dss,
ti,omap5-dss,
+   ti,dra7-dss,
 };
 
 struct device_node * __init omapdss_find_dss_of_node(void)
-- 
2.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 04/10] ARM: OMAP: display: change compat names to array

[Tomi Valkeinen]

Simplify the DSS detection logic by creating a list of the omapdss
compat strings, instead of checking each separately with an 'if'.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 arch/arm/mach-omap2/display.c | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index f492ae147c6a..9868d0bc7805 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -568,25 +568,24 @@ void __init omapdss_early_init_of(void)
 
 }
 
+static const char * const omapdss_compat_names[] __initconst = {
+   ti,omap2-dss,
+   ti,omap3-dss,
+   ti,omap4-dss,
+   ti,omap5-dss,
+};
+
 struct device_node * __init omapdss_find_dss_of_node(void)
 {
struct device_node *node;
+   int i;
 
-   node = of_find_compatible_node(NULL, NULL, ti,omap2-dss);
-   if (node)
-   return node;
-
-   node = of_find_compatible_node(NULL, NULL, ti,omap3-dss);
-   if (node)
-   return node;
-
-   node = of_find_compatible_node(NULL, NULL, ti,omap4-dss);
-   if (node)
-   return node;
-
-   node = of_find_compatible_node(NULL, NULL, ti,omap5-dss);
-   if (node)
-   return node;
+   for (i = 0; i  ARRAY_SIZE(omapdss_compat_names); ++i) {
+   node = of_find_compatible_node(NULL, NULL,
+   omapdss_compat_names[i]);
+   if (node)
+   return node;
+   }
 
return NULL;
 }
-- 
2.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 09/10] arm: dra7: add DESHDCP clock

[Tomi Valkeinen]

Add a new Linux clock for DRA7 based SoCs to control DESHDCP clock.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 arch/arm/boot/dts/dra7.dtsi   |  5 +
 arch/arm/boot/dts/dra7xx-clocks.dtsi  | 10 ++
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c |  1 +
 drivers/clk/ti/clk-7xx.c  |  1 +
 4 files changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 312ede660b23..c06f30a76f5c 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -123,6 +123,11 @@
regulator-max-microvolt 
= 300;
};
};
+
+   scm_conf_clocks: clocks {
+   #address-cells = 1;
+   #size-cells = 0;
+   };
};
 
dra7_pmx_core: pinmux@1400 {
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi 
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 0d76233840e6..a93754cf5e2f 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -2057,3 +2057,13 @@
clocks = dpll_usb_ck;
};
 };
+
+scm_conf_clocks {
+   dss_deshdcp_clk: dss_deshdcp_clk {
+   #clock-cells = 0;
+   compatible = ti,gate-clock;
+   clocks = l3_iclk_div;
+   ti,bit-shift = 0;
+   reg = 0x558;
+   };
+};
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 0411b838b4fa..97e3d7a62729 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -459,6 +459,7 @@ static struct omap_hwmod_opt_clk dss_opt_clks[] = {
{ .role = video2_clk, .clk = dss_video2_clk },
{ .role = video1_clk, .clk = dss_video1_clk },
{ .role = hdmi_clk, .clk = dss_hdmi_clk },
+   { .role = hdcp_clk, .clk = dss_deshdcp_clk },
 };
 
 static struct omap_hwmod dra7xx_dss_hwmod = {
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index ee32f4deebf4..7b859ec31a14 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -301,6 +301,7 @@ static struct ti_dt_clk dra7xx_clks[] = {
DT_CLK(48824000.timer, timer_sys_ck, timer_sys_clk_div),
DT_CLK(48826000.timer, timer_sys_ck, timer_sys_clk_div),
DT_CLK(NULL, sys_clkin, sys_clkin1),
+   DT_CLK(NULL, dss_deshdcp_clk, dss_deshdcp_clk),
{ .node_name = NULL },
 };
 
-- 
2.3.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html