[bug report] drm/bridge: Add ti-tfp410 DVI transmitter driver

2016-12-07 Thread Jyri Sarha 
On 12/07/16 16:46, Daniel Vetter wrote:
>> > This implementation is a hack in the first place. The code will be
>> > removed when DRM has a proper generic connector support.
> Hm, what's this generic drm connector thing you talk about? What's it for?
> Asking since I haven't seen that yet nor heard in a discussion ...

After looking up this comment from Laurent:

On 11/10/16 14:15, Laurent Pinchart wrote [1]:
>> > The implementation side is not so critical, because it more easily
>> > changed, but should I create an independent generic platform-device
>> > driver for such DVI/HDMI connector or just implement the connector side
>> > within tfp410 driver?
> Longer term I'd like to go for connector drivers, but it might take a
bit of
> infrastructure work. If you can give it a try it would be great !
Otherwise
> I'm fine with handling that in the tfp410 driver for now.
>

... I think I miss understood it. He was probably referring to the
infrastructure needed in the tfp410 driver. I'll try to get that done
for 4.11 or 4.12.

Best regards,
Jyri

[1]
https://lists.freedesktop.org/archives/dri-devel/2016-November/123337.html

[Bug 99019] "Star Ruler 2" game will freeze the system

2016-12-07 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=99019

Bug ID: 99019
   Summary: "Star Ruler 2" game will freeze the system
   Product: Mesa
   Version: 13.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: johnz at lunarg.com
QA Contact: dri-devel at lists.freedesktop.org

Overview:
"Star Ruler 2" freezes the system immediately after choosing "New Game". This
forces the user to hit the reset on the computer.

Steps to reproduce:
The game will load to the menu screen and as soon as you double click for "New
Game" the system will freeze. 

Linux and Hardware:
This problem has been experienced on Ubuntu 16.10 -- using AMD's R9 Fury,
RX470, and RX470 graphic cards. 

Mesa Builds:
The problem has been reproduced on Mesa 13.0.2 (git-2722144) and Mesa 13.0.1
(git-f2f487e)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/f1657934/attachment.html>

[PULL] MXSFB driver

2016-12-07 Thread Marek Vasut 
On 12/07/2016 09:53 PM, Dave Airlie wrote:
 Yeah, already done.
>>>
>>> Just tried to build drm-next/mxsfb I get:
>>>
>>> drivers/built-in.o: In function `mxsfb_probe':
>>> core.c:(.text+0x9ce9c): undefined reference to `drm_panel_attach'
>>> core.c:(.text+0x9cff0): undefined reference to `drm_panel_detach'
>>> drivers/built-in.o: In function `mxsfb_panel_connector_destroy':
>>> core.c:(.text+0x9d614): undefined reference to `drm_panel_detach'
>>> drivers/built-in.o: In function `mxsfb_create_output':
>>> core.c:(.text+0x9d68c): undefined reference to `of_drm_find_panel'
>>> make: *** [Makefile:962: vmlinux] Error 1
>>>
>>> I guess there is a select DRM_PANEL missing.
>>
>> Aw snap, I think imx_v6_v7_defconfig selects DRM_PANEL already, so this
>> was never caught. Which is the path of least resistance, additional
>> patch or respinning the whole PR ?
> 
> Just send patch to list and then a pull request for it.
> 

Patch is out, sorry for the hassle.

-- 
Best regards,
Marek Vasut

[PATCH] drm: mxsfb: Select DRM_PANEL

2016-12-07 Thread Marek Vasut 
Select DRM_PANEL, since the MXSFB driver depends on it. Otherwise,
we get the following error when compiling:

drivers/built-in.o: In function `mxsfb_probe':
core.c:(.text+0x9ce9c): undefined reference to `drm_panel_attach'
core.c:(.text+0x9cff0): undefined reference to `drm_panel_detach'
drivers/built-in.o: In function `mxsfb_panel_connector_destroy':
core.c:(.text+0x9d614): undefined reference to `drm_panel_detach'
drivers/built-in.o: In function `mxsfb_create_output':
core.c:(.text+0x9d68c): undefined reference to `of_drm_find_panel'
make: *** [Makefile:962: vmlinux] Error 1

Signed-off-by: Marek Vasut 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Reported-by: Stefan Agner 
---
 drivers/gpu/drm/mxsfb/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
index 0b6cb59..e9a8d90 100644
--- a/drivers/gpu/drm/mxsfb/Kconfig
+++ b/drivers/gpu/drm/mxsfb/Kconfig
@@ -11,6 +11,7 @@ config DRM_MXSFB
select DRM_KMS_HELPER
select DRM_KMS_FB_HELPER
select DRM_KMS_CMA_HELPER
+   select DRM_PANEL
help
  Choose this option if you have an i.MX23/i.MX28/i.MX6SX MXSFB
  LCD controller.
-- 
2.10.2

[PATCH] drm: Take ownership of the dmabuf->obj when exporting

2016-12-07 Thread Chris Wilson 
Currently the reference for the dmabuf->obj is incremented for the
dmabuf in drm_gem_prime_handle_to_fd() (at the high level userspace
interface), but is released in drm_gem_dmabuf_release() (the lowlevel
handler). Improve the symmetry of the dmabuf->obj ownership by acquiring
the reference in drm_gem_dmabuf_export(). This makes it easier to use
the prime functions directly.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_prime.c   | 9 +
 drivers/gpu/drm/vgem/vgem_fence.c | 1 -
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index b22a94dd7b53..5ef946d5a32d 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -300,8 +300,11 @@ struct dma_buf *drm_gem_dmabuf_export(struct drm_device 
*dev,
struct dma_buf *dma_buf;

dma_buf = dma_buf_export(exp_info);
-   if (!IS_ERR(dma_buf))
-   drm_dev_ref(dev);
+   if (IS_ERR(dma_buf))
+   return dma_buf;
+
+   drm_dev_ref(dev);
+   drm_gem_object_reference(exp_info->priv);

return dma_buf;
 }
@@ -472,8 +475,6 @@ static struct dma_buf *export_and_register_object(struct 
drm_device *dev,
 */
obj->dma_buf = dmabuf;
get_dma_buf(obj->dma_buf);
-   /* Grab a new ref since the callers is now used by the dma-buf */
-   drm_gem_object_reference(obj);

return dmabuf;
 }
diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
b/drivers/gpu/drm/vgem/vgem_fence.c
index 9cb00a5d5d08..da25dfe7b80e 100644
--- a/drivers/gpu/drm/vgem/vgem_fence.c
+++ b/drivers/gpu/drm/vgem/vgem_fence.c
@@ -126,7 +126,6 @@ static int attach_dmabuf(struct drm_device *dev,
return PTR_ERR(dmabuf);

obj->dma_buf = dmabuf;
-   drm_gem_object_reference(obj);
return 0;
 }

-- 
2.11.0

[PULL] drm-intel-next-fixes

2016-12-07 Thread Jani Nikula 

Hi Dave, first set of fixes for drm-next/v4.10-rc1.

BR,
Jani.

The following changes since commit e9cbc4bd0140e1d4e0172e2fe8fe07ba278e5980:

  drm/i915: Update DRIVER_DATE to 20161121 (2016-11-21 09:45:03 +0100)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel 
tags/drm-intel-next-fixes-2016-12-07

for you to fetch changes up to 7a9e10253e9e52451bbe80ddb2874368dbd240a3:

  drm/i915: Move priority bumping for flips earlier (2016-12-05 11:00:32 +0200)


Chris Wilson (5):
  drm/i915: Complete requests in nop_submit_request
  drm/i915/debugfs: Drop i915_hws_info
  drm/i915/debugfs: Increment return value of gt.next_seqno
  drm/i915: Hold a reference on the request for its fence chain
  drm/i915: Move priority bumping for flips earlier

Du, Changbin (1):
  drm/i915/gvt: fix missing init param.primary

Jani Nikula (1):
  Merge tag 'gvt-next-2016-11-30' of https://github.com/01org/gvt-linux 
into drm-intel-next-fixes

Libin Yang (1):
  drm/i915/audio: fix hdmi audio noise issue

Ville Syrjälä (3):
  drm/i915: Make skl_write_{plane,cursor}_wm() static
  drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things
  drm/i915: Initialize dev_priv->atomic_cdclk_freq at init time

Xiaoguang Chen (1):
  drm/i915/gvt: fix getting 64bit bar size error

Zhenyu Wang (1):
  drm/i915/gvt: fix lock not released bug for dispatch_workload() err path

 drivers/gpu/drm/i915/gvt/gvt.h  |  2 ++
 drivers/gpu/drm/i915/gvt/scheduler.c| 10 ++
 drivers/gpu/drm/i915/gvt/vgpu.c |  1 +
 drivers/gpu/drm/i915/i915_debugfs.c | 27 +-
 drivers/gpu/drm/i915/i915_gem.c |  2 ++
 drivers/gpu/drm/i915/i915_gem_request.c | 34 ++---
 drivers/gpu/drm/i915/i915_sw_fence.h|  5 +
 drivers/gpu/drm/i915/intel_audio.c  |  7 +--
 drivers/gpu/drm/i915/intel_display.c| 11 +++
 drivers/gpu/drm/i915/intel_pm.c | 14 +++---
 10 files changed, 63 insertions(+), 50 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v4 4/4] drm: allow to use mmuless SoC

2016-12-07 Thread Arnd Bergmann 
On Wednesday, December 7, 2016 4:19:52 PM CET Benjamin Gaignard wrote:
> +unsigned long drm_gem_cma_get_unmapped_area(struct file *filp,
> +   unsigned long addr,
> +   unsigned long len,
> +   unsigned long pgoff,
> +   unsigned long flags)
> +{
> +   return -EINVAL;
> +}
> 

This must be 'static inline'.

Arnd

[PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check

2016-12-07 Thread Laurent Pinchart 
Hi Eric,

On Wednesday 07 Dec 2016 11:16:32 Eric Anholt wrote:
> Maxime Ripard  writes:
> > [ Unknown signature status ]
> > 
> > On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu Tsai wrote:
> >> The panels shipped with Allwinner devices are very "generic", i.e.
> >> they do not have model numbers or reliable sources of information
> >> for the timings (that we know of) other than the fex files shipped
> >> on them. The dot clock frequency provided in the fex files have all
> >> been rounded to the nearest MHz, as that is the unit used in them.
> >> 
> >> We were using the simple panel "urt,umsh-8596md-t" as a substitute
> >> for the A13 Q8 tablets in the absence of a specific model for what
> >> may be many different but otherwise timing compatible panels. This
> >> was usable without any visual artifacts or side effects, until the
> >> dot clock rate check was added in commit bb43d40d7c83 ("drm/sun4i:
> >> rgb: Validate the clock rate").
> >> 
> >> The reason this check fails is because the dotclock frequency for
> >> this model is 33.26 MHz, which is not achievable with our dot clock
> >> hardware, and the rate returned by clk_round_rate deviates slightly,
> >> causing the driver to reject the display mode.
> >> 
> >> The LCD panels have some tolerance on the dot clock frequency, even
> >> if it's not specified in their datasheets.
> >> 
> >> This patch adds a 5% tolerence to the dot clock check.
> > 
> > As we discussed already, I really believe this is just as arbitrary as
> > the current behaviour.
> > 
> > Some panels require an exact frequency, some have a minimal frequency
> > but no maximum, some have a maximum frequency but no minimal, and I
> > guess most of them deviates by how much exactly they can take (and
> > possibly can take more easily a higher frequency, but are less
> > tolerant if you take a frequency lower than the nominal.
> > 
> > And we cannot remove that check entirely, since some bridges will
> > report out of range frequencies for higher modes that we know we
> > cannot reach.
> > 
> > We could just try to see if the screen pixel clock frequency is out of
> > the pixel clock range we can generate, but then we will loop back on
> > how much out of range is it exactly, and is it within the screen
> > tolerancy.
> > 
> > We have an API to deal with the panel tolerancies in the DRM panel
> > framework, we can (and should) use it.
> > 
> > I'm not sure how others usually deal with this though. I think I
> > remember Eric telling me that for the RPi they just adjusted the
> > timings a bit, but they only really had a single panel to deal with.
> 
> For RPi, you just adjust the pixel clock of the panel's mode to be
> whatever the platform can support, and expand the blanking intervals to
> get the refresh rate back to desired.  This is nothing like what the
> datasheet says, but it's not important what the datasheet says, it's
> important what makes the product work.
> 
> Our clock driver looks for the best matching clock that's not over the
> target rate.  This is somewhat unfortunate, as you end up slightly
> inflating your requested clocks so that a possible clock lands under
> that.  I'd rather we chose the closest matching clock, but then people
> get worried about what if selected clock rate is 1% higher than expected
> (the answer is "nothing").

But if the closest match is 10% off and higher results could be different, in 
which case a lower match that is 11% off might be better. The hard part is to 
decide where to set the limit, and I'm afraid the answer is likely system-
dependent.

> I think this patch is a fine solution, and the alternative would be to
> just drop the mode high/low check and say that if you're pairing a panel
> with some display hardware, it's up to you to make sure that the panel's
> mode actually scans out successfully.  Then, since compatible strings
> are cheap, you can use a new one if necessary to attach better modes to
> the panel for a particular clock driver by adjusting your timings to get
> closer to the refresh rates you want.

Given that timings tolerance can be system-dependent and not only panel-
dependent, it would make sense to specify them in DT (possibly an optional 
properties with reasonable default values computed by drivers).

-- 
Regards,

Laurent Pinchart

[PULL] MXSFB driver

2016-12-07 Thread Marek Vasut 
On 12/07/2016 08:22 PM, Stefan Agner wrote:
> On 2016-12-06 04:36, Marek Vasut wrote:
>> On 12/06/2016 08:53 AM, Daniel Vetter wrote:
>>> On Tue, Dec 06, 2016 at 11:08:06AM +1000, Dave Airlie wrote:
 On 2 December 2016 at 04:02, Marek Vasut  wrote:
> Hi,
>
> as asked by Daniel, I collected the MXSFB DT Acks and the driver and
> wrapped it into PR (below).

 Hi Marek

 this isn't pullable as-is as it seems to be based on -next tree or 
 something.

 Please create pull requests based on a Linus or drm-next base,
>>>
>>> Please base on drm-next, to make sure you can (and do) use latest drm code
>>> with all the latest refactorings applied.
>>
>> Yeah, already done.
> 
> Just tried to build drm-next/mxsfb I get:
> 
> drivers/built-in.o: In function `mxsfb_probe':
> core.c:(.text+0x9ce9c): undefined reference to `drm_panel_attach'
> core.c:(.text+0x9cff0): undefined reference to `drm_panel_detach'
> drivers/built-in.o: In function `mxsfb_panel_connector_destroy':
> core.c:(.text+0x9d614): undefined reference to `drm_panel_detach'
> drivers/built-in.o: In function `mxsfb_create_output':
> core.c:(.text+0x9d68c): undefined reference to `of_drm_find_panel'
> make: *** [Makefile:962: vmlinux] Error 1
> 
> I guess there is a select DRM_PANEL missing.

Aw snap, I think imx_v6_v7_defconfig selects DRM_PANEL already, so this
was never caught. Which is the path of least resistance, additional
patch or respinning the whole PR ?


-- 
Best regards,
Marek Vasut

[PATCH v2 2/3] drm/edid: Implement SCDC support detection

2016-12-07 Thread Jani Nikula 
On Tue, 06 Dec 2016, Daniel Vetter  wrote:
> On Mon, Dec 05, 2016 at 06:11:44PM +0100, Thierry Reding wrote:
>> On Mon, Dec 05, 2016 at 05:21:24PM +0100, Daniel Vetter wrote:
>> > On Mon, Dec 05, 2016 at 12:11:46PM +0100, Thierry Reding wrote:
>> > > On Mon, Dec 05, 2016 at 09:16:27AM +0100, Daniel Vetter wrote:
>> > > > On Mon, Dec 05, 2016 at 08:57:43AM +0100, Thierry Reding wrote:
>> > > > > On Sat, Dec 03, 2016 at 04:35:24AM +, Sharma, Shashank wrote:
>> > > > > > Hi Thierry, 
>> > > > > > 
>> > > > > > If you can please have a look on this patch, I had written one to 
>> > > > > > parse HF-VSDB, which was covering SCDC detection too. 
>> > > > > > https://patchwork.kernel.org/patch/9452259/ 
>> > > > > 
>> > > > > I think there had been pushback before about caching capabilities 
>> > > > > from
>> > > > > EDID, so from that point of view my patch is more inline with 
>> > > > > existing
>> > > > > EDID parsing API.
>> > > > 
>> > > > Hm, where was that pushback? We do have a bit a mess between explicitly
>> > > > parsing stuff (e.g. eld) and stuffing parsed data into 
>> > > > drm_display_info.
>> > > 
>> > > You did object to a very similar patch some time ago that did a similar
>> > > thing for DPCD stuff. And also Villa had commented on an earlier patch
>> > > from Jose about concerns of bloating core structures:
>> > > 
>> > >  https://patchwork.freedesktop.org/patch/104806/
>> > 
>> > DPCD I complained about because somehow we ended up with 2 sets of
>> > helpers, one filling a struct and the others returning directly. I
>> > objected to the fact that there's 2 (and imo your patch duplicated even
>> > more), not that I think one approach is clearly inferior to the other.
>> 
>> My recollection is that I had proposed that I do the work of
>> transitioning users of the parsers to the cached information but you had
>> said that it wasn't worth the churn and that we should just go with the
>> existing scheme of passing around the DPCD buffer and extending the
>> parsers as necessary.
>
> Hm, I guess it wasn't clear to me that you've offered to do all the
> conversions. Doing that would be awesome I think (but quite a bit of
> work), and if we bother with it, parsing into a struct is imo the better
> idea long-term.

I'm concerned about invalidating the data in the structs at the right
times. We keep having issues with that whenever we cache stuff.

BR,
Jani.



>
>> From that I inferred that the same would be true for EDID and since we
>> already have a couple of helpers that operate on struct edid * and which
>> return features, continuing that scheme was preferred.
>> 
>> Anyway, I don't really care either way. Maybe you and Ville can duke it
>> out whether or not we want all of the fields parsed, irrespective of
>> whether or not they will be used. Then I'll go with whatever you decide.
>> 
>> > Demanding that there's some real users is also a valid point.
>> > 
>> > > > I think long-term stuffing it into drm_display_info is probably better,
>> > > > since then we only have 1 interaction point between the probe code and 
>> > > > the
>> > > > atomic_check code. That should be useful for eventually fixing the 
>> > > > lack of
>> > > > locking between the two, if I ever get around to that ;-)
>> > > 
>> > > I don't really have objections to caching the results of parsing, it's
>> > > what I had proposed and what seemed most natural back when I was working
>> > > on the DPCD helpers. But if we now agree that this is the preferred way
>> > > to do things, then we should at least agree that it applies to all areas
>> > > for the sake of consistency.
>> > > 
>> > > Also, it might be worth looking into improving the structures, and maybe
>> > > adding new ones to order things more conveniently or at least group them
>> > > in some logical way. In my opinion some of our data structures are
>> > > becoming somewhat... unwieldy.
>> > 
>> > We're pretty good at consuming fairly invasive refactorings in drm-misc.
>> > So it just boils down to get some agreement on what things should look
>> > like (+1 from my side to parsing stuff into structs as a general idea),
>> > and then massaging all the existing users of the "wrong" interface using
>> > cocci and sed.
>> > 
>> > Unfortunately "just" ;-)
>> 
>> I think by now it would be useful to have a nested structure within
>> struct drm_display_info that contains HDMI specific bits. We already
>> have a number of candidates that could be extracted into such a
>> structure (drm_detect_hdmi_monitor(), drm_detect_monitor_audio(),
>> drm_rgb_quant_range_selectable(), ...).
>> 
>> Another possibility would be to subclass struct drm_display_info, as
>> in:
>> 
>>  struct drm_hdmi_info {
>>  struct drm_display_info display;
>> 
>>  /* HDMI specific information */
>>  ...
>>  };
>> 
>> Or yet another would be to create struct drm_hdmi_info as a separate
>> structure and provide a helper which will extract the necessary inf

[RFC] Using DC in amdgpu for upcoming GPU

2016-12-07 Thread Harry Wentland 
We propose to use the Display Core (DC) driver for display support on
AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In 
order to avoid a flag day the plan is to only support uGPU initially and 
transition to older ASICs gradually.

The DC component has received extensive testing within AMD for DCE8, 10, 
and 11 GPUs and is being prepared for uGPU. Support should be better 
than amdgpu's current display support.

  * All of our QA effort is focused on DC
  * All of our CQE effort is focused on DC
  * All of our OEM preloads and custom engagements use DC
  * DC behavior mirrors what we do for other OSes

The new asic utilizes a completely re-designed atom interface, so we 
cannot easily leverage much of the existing atom-based code.

We've introduced DC to the community earlier in 2016 and received a fair 
amount of feedback. Some of what we've addressed so far are:

  * Self-contain ASIC specific code. We did a bunch of work to pull
common sequences into dc/dce and leave ASIC specific code in
separate folders.
  * Started to expose AUX and I2C through generic kernel/drm
functionality and are mostly using that. Some of that code is still
needlessly convoluted. This cleanup is in progress.
  * Integrated Dave and Jerome’s work on removing abstraction in bios
parser.
  * Retire adapter service and asic capability
  * Remove some abstraction in GPIO

Since a lot of our code is shared with pre- and post-silicon validation 
suites changes need to be done gradually to prevent breakages due to a 
major flag day.  This, coupled with adding support for new asics and 
lots of new feature introductions means progress has not been as quick 
as we would have liked. We have made a lot of progress none the less.

The remaining concerns that were brought up during the last review that 
we are working on addressing:

  * Continue to cleanup and reduce the abstractions in DC where it
makes sense.
  * Removing duplicate code in I2C and AUX as we transition to using the
DRM core interfaces.  We can't fully transition until we've helped
fill in the gaps in the drm core that we need for certain features.
  * Making sure Atomic API support is correct.  Some of the semantics of
the Atomic API were not particularly clear when we started this,
however, that is improving a lot as the core drm documentation
improves.  Getting this code upstream and in the hands of more
atomic users will further help us identify and rectify any gaps we
have.

Unfortunately we cannot expose code for uGPU yet. However refactor / 
cleanup work on DC is public.  We're currently transitioning to a public 
patch review. You can follow our progress on the amd-gfx mailing list. 
We value community feedback on our work.

As an appendix I've included a brief overview of the how the code 
currently works to make understanding and reviewing the code easier.

Prior discussions on DC:

  * https://lists.freedesktop.org/archives/dri-devel/2016-March/103398.html
  * 
https://lists.freedesktop.org/archives/dri-devel/2016-February/100524.html

Current version of DC:

  * 
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7

Once Alex pulls in the latest patches:

  * 
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7

Best Regards,
Harry



*** Appendix: A Day in the Life of a Modeset ***


Below is a high-level overview of a modeset with dc. Some of this might 
be a little out-of-date since it's based on my XDC presentation but it 
should be more-or-less the same.

amdgpu_dm_atomic_commit()
{
   /* setup atomic state */
   drm_atomic_helper_prepare_planes(dev, state);
   drm_atomic_helper_swap_state(dev, state);
   drm_atomic_helper_update_legacy_modeset_state(dev, state);

   /* create or remove targets */

   /
* *** Call into DC to commit targets with list of all known targets
/
   /* DC is optimized not to do anything if 'targets' didn't change. */
   dc_commit_targets(dm->dc, commit_targets, commit_targets_count)
   {
 /**
  * *** Build context (function also used for validation)
  **/
 result = core_dc->res_pool->funcs->validate_with_context(
core_dc,set,target_count,context);

 /**
  * *** Apply safe power state
  **/
 pplib_apply_safe_state(core_dc);

 /
  * *** Apply the context to HW (p

[Bug 99013] [regression, bisected] radeonsi: commit 4c8c13b3 "Use amdgcn intrinsics for fs interpolation" makes system unusable

2016-12-07 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=99013

--- Comment #4 from Christoph Haag  ---
Which makes bisecting a lot harder, but understandable that the devs don't want
to have the burden of having many intermediate workarounds in the code that's
not used for any of the actual llvm releases.

But what I came here to say is that I have llvm 3.9.0 from the Archlinux Repos
and this commit breaks everything for me too.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/ab5fcbbc/attachment.html>

[Bug 97980] [amdgpu] New kernel warning during shutdown

2016-12-07 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=97980

--- Comment #19 from Alex Deucher  ---
Created attachment 128372
  --> https://bugs.freedesktop.org/attachment.cgi?id=128372&action=edit
alternative patch

Does this patch also work?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/0407df2c/attachment.html>

[Bug 98638] Panic on shutdown with AMDGPU and Ubuntu Plymouth

2016-12-07 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=98638

Alex Deucher  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #12 from Alex Deucher  ---


*** This bug has been marked as a duplicate of bug 97980 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/b9b4e43a/attachment.html>

[Bug 97980] [amdgpu] New kernel warning during shutdown

2016-12-07 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=97980

Alex Deucher  changed:

   What|Removed |Added

 CC||ernstp at gmail.com

--- Comment #18 from Alex Deucher  ---
*** Bug 98638 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/74dc0fa3/attachment.html>

[Bug 99013] [regression, bisected] radeonsi: commit 4c8c13b3 "Use amdgcn intrinsics for fs interpolation" makes system unusable

2016-12-07 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=99013

--- Comment #3 from Marek Olšák  ---
Older LLVM from svn is officially unsupported. Latest LLVM from svn usually
works with Mesa git, but not always.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/e22b1e1e/attachment.html>

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

2016-12-07 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #40 from iuno at posteo.net ---
Is anyone looking into this or are you expecting us to switch over to -pro with
dal/dc asap?

I have the exact same problem with both radeon and amdgpu. I don't know if this
problem has always existed, it did since I remember. 144 Hz is unusable, so I
always went back to 120 Hz.

It works with the Intel iGPU on the exact same monitor, I also checked edid and
modelines. It has always worked on windows.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/521adfc8/attachment.html>

[PATCH 02/18] drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is setting

2016-12-07 Thread Ville Syrjälä 
On Thu, Dec 01, 2016 at 09:29:09PM +0100, Hans de Goede wrote:
> Set the CHV_GPIO_GPIOEN bit when updating GPIOs from chv_exec_gpio.
> 
> Fixes: a0a6d4ffd2ad ("drm/i915/dsi: add support for gpio elements on CHV")
> Cc: stable at vger.kernel.org
> Cc: Jani Nikula 
> Cc: Ville Syrjälä 
> Signed-off-by: Hans de Goede 
> Reviewed-by: Ville Syrjälä 

Pushed to dinq. Thanks for the patch.

> ---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 579d2f5..47cd1b2 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -300,7 +300,8 @@ static void chv_exec_gpio(struct drm_i915_private 
> *dev_priv,
>   mutex_lock(&dev_priv->sb_lock);
>   vlv_iosf_sb_write(dev_priv, port, cfg1, 0);
>   vlv_iosf_sb_write(dev_priv, port, cfg0,
> -   CHV_GPIO_GPIOCFG_GPO | CHV_GPIO_GPIOTXSTATE(value));
> +   CHV_GPIO_GPIOEN | CHV_GPIO_GPIOCFG_GPO |
> +   CHV_GPIO_GPIOTXSTATE(value));
>   mutex_unlock(&dev_priv->sb_lock);
>  }
>  
> -- 
> 2.9.3

-- 
Ville Syrjälä
Intel OTC

[PATCH v2] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET

2016-12-07 Thread Ville Syrjälä 
On Fri, Dec 02, 2016 at 04:01:28PM +0100, Hans de Goede wrote:
> Looking at the ADF code from the Android kernel sources for a
> cherrytrail tablet I noticed that it is calling the
> MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.
> 
> Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences
> in panel prepare/unprepare hooks") the mainline i915 code was doing the
> same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET /
> MIPI_SEQ_DEASSERT_RESET.
> 
> Looking at the naming of the sequences that is the right thing to do,
> but the problem is, that the old mainline code and the ADF code was
> actually calling the right sequence (tested on a cube iwork8 air tablet),
> and the swapping of the calling breaks things.
> 
> This breakage was likely not noticed in testing because on cherrytrail,
> currently chv_exec_gpio ends up disabling the gpio pins rather then
> setting them (this is fixed in the next patch in this patch-set).
> 
> This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's
> places in the enum defining them, so that their (new) names match their
> actual use.
> 
> Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...")
> Cc: Jani Nikula 
> Cc: Ville Syrjälä 
> Signed-off-by: Hans de Goede 
> Acked-by: Jani Nikula 
> ---
> Changes in v2:
> -Add a comment to the enum explaining that the assert/reassert names
>  are swapped in the spec

Pushed to dinq. Thanks for the patch.

I sucked in the changelog again. In the future please include it in
the actual commit message, cause that's how we like it.

> ---
>  drivers/gpu/drm/i915/intel_bios.h  | 12 +---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |  4 ++--
>  2 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.h 
> b/drivers/gpu/drm/i915/intel_bios.h
> index 8405b5a..7e3545f 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -46,14 +46,20 @@ struct edp_power_seq {
>   u16 t11_t12;
>  } __packed;
>  
> -/* MIPI Sequence Block definitions */
> +/*
> + * MIPI Sequence Block definitions
> + *
> + * Note the VBT spec has AssertReset / DeassertReset swapped from their
> + * usual naming, we use the proper names here to avoid confusion when
> + * reading the code.
> + */
>  enum mipi_seq {
>   MIPI_SEQ_END = 0,
> - MIPI_SEQ_ASSERT_RESET,
> + MIPI_SEQ_DEASSERT_RESET,/* Spec says MipiAssertResetPin */
>   MIPI_SEQ_INIT_OTP,
>   MIPI_SEQ_DISPLAY_ON,
>   MIPI_SEQ_DISPLAY_OFF,
> - MIPI_SEQ_DEASSERT_RESET,
> + MIPI_SEQ_ASSERT_RESET,  /* Spec says MipiDeassertResetPin */
>   MIPI_SEQ_BACKLIGHT_ON,  /* sequence block v2+ */
>   MIPI_SEQ_BACKLIGHT_OFF, /* sequence block v2+ */
>   MIPI_SEQ_TEAR_ON,   /* sequence block v2+ */
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 0d8ff00..579d2f5 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -376,11 +376,11 @@ static const fn_mipi_elem_exec exec_elem[] = {
>   */
>  
>  static const char * const seq_name[] = {
> - [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
> + [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
>   [MIPI_SEQ_INIT_OTP] = "MIPI_SEQ_INIT_OTP",
>   [MIPI_SEQ_DISPLAY_ON] = "MIPI_SEQ_DISPLAY_ON",
>   [MIPI_SEQ_DISPLAY_OFF]  = "MIPI_SEQ_DISPLAY_OFF",
> - [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
> + [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
>   [MIPI_SEQ_BACKLIGHT_ON] = "MIPI_SEQ_BACKLIGHT_ON",
>   [MIPI_SEQ_BACKLIGHT_OFF] = "MIPI_SEQ_BACKLIGHT_OFF",
>   [MIPI_SEQ_TEAR_ON] = "MIPI_SEQ_TEAR_ON",
> -- 
> 2.9.3

-- 
Ville Syrjälä
Intel OTC

[PATCH] drm: hdlcd: Work properly in big-endian mode

2016-12-07 Thread Ilia Mirkin 
On Wed, Dec 7, 2016 at 11:42 AM, Robin Murphy  wrote:
> By comparison, the same use-cases (fbcon and fb-test) under the same
> big-endian kernel do *not* show the same problem with nouveau driving a
> PCIe 7600GT card, which led me to believe it was HDLCD-specific.

Just to randomly insert info here... NV11+ cards have a "big endian"
mode, where you can do 32-bit mmio from a big-endian cpu, and the card
will auto-swap those. There are similar additional bits that make
operating and accelerating off a big-endian CPU tolerable. Some care
has gone into the kernel to make sure that all that stuff works. (One
of those bits is that data gets byteswapped on upload to VRAM by
virtue of being uploaded by sticking data into a pushbuf, as I
recall.)

  -ilia

[RFC] drm: Enable dynamic debug for DRM_[DEV]_DEBUG*

2016-12-07 Thread Robert Bragg 
gt; -#define DRM_DEBUG_PRIME(fmt, ...)\
> > - drm_printk(KERN_DEBUG, DRM_UT_PRIME, fmt, ##__VA_ARGS__)
> > + _DRM_DEV_DEBUG(dev, DRM_UT_PRIME, fmt, ##args)
> > +#define DRM_DEBUG_PRIME(fmt, args...)
>   \
> > + _DRM_DEBUG(DRM_UT_PRIME, fmt, ##args)
> >
> >  #define DRM_DEV_DEBUG_ATOMIC(dev, fmt, args...)
>   \
> > - drm_dev_printk(dev, KERN_DEBUG, DRM_UT_ATOMIC, __func__, "",\
> > -fmt, ##args)
> > -#define DRM_DEBUG_ATOMIC(fmt, ...)   \
> > - drm_printk(KERN_DEBUG, DRM_UT_ATOMIC, fmt, ##__VA_ARGS__)
> > + _DRM_DEV_DEBUG(dev, DRM_UT_ATOMIC, fmt, ##args)
> > +#define DRM_DEBUG_ATOMIC(fmt, args...)
>  \
> > + _DRM_DEBUG(DRM_UT_ATOMIC, fmt, ##args)
> >
> >  #define DRM_DEV_DEBUG_VBL(dev, fmt, args...) \
> > - drm_dev_printk(dev, KERN_DEBUG, DRM_UT_VBL, __func__, "", fmt,  \
> > -##args)
> > -#define DRM_DEBUG_VBL(fmt, ...)  \
> > - drm_printk(KERN_DEBUG, DRM_UT_VBL, fmt, ##__VA_ARGS__)
> > + _DRM_DEV_DEBUG(dev, DRM_UT_VBL, fmt, ##args)
> > +#define DRM_DEBUG_VBL(fmt, args...)  \
> > + _DRM_DEBUG(DRM_UT_VBL, fmt, ##args)
> >
> > -#define _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, level, fmt, args...)  \
> > +#define _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, category, fmt,
> args...)   \
> > +({   \
> > + static DEFINE_RATELIMIT_STATE(_rs,  \
> > +   DEFAULT_RATELIMIT_INTERVAL,   \
> > +   DEFAULT_RATELIMIT_BURST); \
> > + if (__ratelimit(&_rs))  \
> > + _DRM_DEV_DEBUG(dev, DRM_UT_ ## category, fmt, ##args);  \
> > +})
> > +#define _DRM_DEFINE_DEBUG_RATELIMITED(category, fmt, args...)\
> >  ({   \
> >   static DEFINE_RATELIMIT_STATE(_rs,  \
> > DEFAULT_RATELIMIT_INTERVAL,   \
> > DEFAULT_RATELIMIT_BURST); \
> >   if (__ratelimit(&_rs))  \
> > - drm_dev_printk(dev, KERN_DEBUG, DRM_UT_ ## level,   \
> > -__func__, "", fmt, ##args);  \
> > + _DRM_DEBUG(DRM_UT_ ## category, fmt, ##args);   \
> >  })
> >
> >  /**
> > @@ -268,21 +313,24 @@ struct dma_buf_attachment;
> >   * \param arg arguments
> >   */
> >  #define DRM_DEV_DEBUG_RATELIMITED(dev, fmt, args...) \
> > - DEV__DRM_DEFINE_DEBUG_RATELIMITED(dev, CORE, fmt, ##args)
> > + _DRM_DEFINE_DEBUG_RATELIMITED(dev, CORE, fmt, ##args)
> >  #define DRM_DEBUG_RATELIMITED(fmt, args...)  \
> > - DRM_DEV_DEBUG_RATELIMITED(NULL, fmt, ##args)
> > + _DRM_DEFINE_DEBUG_RATELIMITED(CORE, fmt, ##args)
> > +
> >  #define DRM_DEV_DEBUG_DRIVER_RATELIMITED(dev, fmt, args...)  \
> >   _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, DRIVER, fmt, ##args)
> >  #define DRM_DEBUG_DRIVER_RATELIMITED(fmt, args...)   \
> > - DRM_DEV_DEBUG_DRIVER_RATELIMITED(NULL, fmt, ##args)
> > + _DRM_DEV_DEFINE_DEBUG_RATELIMITED(DRIVER, fmt, ##args)
> > +
> >  #define DRM_DEV_DEBUG_KMS_RATELIMITED(dev, fmt, args...) \
> >   _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, KMS, fmt, ##args)
> >  #define DRM_DEBUG_KMS_RATELIMITED(fmt, args...)
>   \
> > - DRM_DEV_DEBUG_KMS_RATELIMITED(NULL, fmt, ##args)
> > + _DRM_DEFINE_DEBUG_RATELIMITED(KMS, fmt, ##args)
> > +
> >  #define DRM_DEV_DEBUG_PRIME_RATELIMITED(dev, fmt, args...)   \
> >   _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, PRIME, fmt, ##args)
> >  #define DRM_DEBUG_PRIME_RATELIMITED(fmt, args...)\
> > - DRM_DEV_DEBUG_PRIME_RATELIMITED(NULL, fmt, ##args)
> > + _DRM_DEFINE_DEBUG_RATELIMITED(PRIME, fmt, ##args)
> >
> >  /* Format strings and argument splitters to simplify printing
> >   * various "complex" objects
>
> Since I brought up some changes for the debug stuff itself, would it make
> sense to split that from the general macro rework for all the non-debug
> output, and merge that first?
>
> Another thing to look into: I think it'd be good to move all the print
> definitions into drm_print.[hc], since drmP.h is a mess, and drm_drv.c not
> really the right place. That would then also allow us to easily document
> all the variants, and put something like the intro message for this commit
> into the overview DOC: section.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/ff4a879d/attachment-0001.html>

[Nouveau] 4.9-rc7 nouveau fails on arm64 64k page kernel but works with 4k

2016-12-07 Thread Alexandre Courbot 
On Wed, Dec 7, 2016 at 6:53 PM, Michel Dänzer  wrote:
> On 07/12/16 06:39 PM, Alexandre Courbot wrote:
>> On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin  wrote:
>>> That's right -- nouveau currently requires 4k page sizes to work. This is a
>>> software limitation, not a hardware one though.
>>
>> Looking at the trace I wonder - is the limitation in Nouveau or in TTM?
>
> Nouveau. Non-4K page sizes work fine with radeon (and presumably amdgpu).

Thanks for the precision. I will check if Tegra iGPUs are also
affected by this - if they are then it gives me a good excuse to take
care of this bug.

[Nouveau] 4.9-rc7 nouveau fails on arm64 64k page kernel but works with 4k

2016-12-07 Thread Michel Dänzer 
On 07/12/16 06:39 PM, Alexandre Courbot wrote:
> On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin  wrote:
>> That's right -- nouveau currently requires 4k page sizes to work. This is a
>> software limitation, not a hardware one though.
> 
> Looking at the trace I wonder - is the limitation in Nouveau or in TTM?

Nouveau. Non-4K page sizes work fine with radeon (and presumably amdgpu).


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH] drm: hdlcd: Work properly in big-endian mode

2016-12-07 Thread Ville Syrjälä 
On Wed, Dec 07, 2016 at 04:57:14PM +0100, Daniel Vetter wrote:
> On Wed, Dec 07, 2016 at 03:31:40PM +, Robin Murphy wrote:
> > Under a big-endian kernel, colours on the framebuffer all come out a
> > delightful shade of wrong, since we fail to take the reversed byte
> > order into account. Fortunately, the HDLCD has a control bit to make it
> > automatically byteswap big-endian data; let's use it as appropriate.
> > 
> > Signed-off-by: Robin Murphy 
> 
> fourcc codes (and the drm fourcc codes) are supposed to be little-endian.
> All of them. So either we fix up the drivers and userspace to set that
> flag correctly (which would mean hdlcd should expose twice as many
> formats, each one with the little and big endian mode).
> 
> Or we nuke the big endian flag from drm fourcc. Adding AMD folks who afaik
> are the only other ones who ever cared about big endian in drm.

I don't like the idea of nuking the flag. If the fb endianness is
defined by the CPU, how would userspace even know that it would have
to byteswap the data when feeding it to the device if the device
and CPU don't agree on the endianness?

> -Daniel
> 
> > ---
> >  drivers/gpu/drm/arm/hdlcd_crtc.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c 
> > b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > index 28341b32067f..eceb7bed5dd0 100644
> > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > @@ -63,6 +63,7 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
> > uint32_t pixel_format;
> > struct simplefb_format *format = NULL;
> > int i;
> > +   u32 reg;
> >  
> > pixel_format = crtc->primary->state->fb->pixel_format;
> >  
> > @@ -76,7 +77,11 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
> >  
> > /* HDLCD uses 'bytes per pixel', zero means 1 byte */
> > btpp = (format->bits_per_pixel + 7) / 8;
> > -   hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, (btpp - 1) << 3);
> > +   reg = (btpp - 1) << 3;
> > +#ifdef __BIG_ENDIAN
> > +   reg |= HDLCD_PIXEL_FMT_BIG_ENDIAN;
> > +#endif
> > +   hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, reg);
> >  
> > /*
> >  * The format of the HDLCD_REG__SELECT register is:
> > -- 
> > 2.10.2.dirty
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC

[Nouveau] 4.9-rc7 nouveau fails on arm64 64k page kernel but works with 4k

2016-12-07 Thread Alexandre Courbot 
On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin  wrote:
> That's right -- nouveau currently requires 4k page sizes to work. This is a
> software limitation, not a hardware one though.

Looking at the trace I wonder - is the limitation in Nouveau or in TTM?

>
>
> On Dec 1, 2016 5:13 PM, "Jeremy Linton"  wrote:
>
> Hi,
>
> I placed a 9600GT in a softiron 3k running fedora 25, and the nouveau driver
> failed to claim the device with :
>
> [drm] Initialized
> nouveau :01:00.0: NVIDIA G94 (094100a1)
> nouveau :01:00.0: bios: version 62.94.0d.00.04
> nouveau: probe of :01:00.0 failed with error -22
>
> Which with a little bit of debugging seems to be a failure in:
>
> [77216.692605] [] ttm_bo_validate+0xb0/0x1e8 [ttm]
> [77216.698697] [] ttm_bo_init+0x354/0x410 [ttm]
> [77216.704706] [] nouveau_bo_new+0x1f4/0x314 [nouveau]
> [77216.711308] [] nv50_display_create+0x10c/0xa1c
> [nouveau]
> [77216.718340] [] nouveau_display_create+0x50c/0x59c
> [nouveau]
> [77216.725632] [] nouveau_drm_load+0x22c/0x8c0 [nouveau]
> [77216.732286] [] drm_dev_register+0xc0/0xf0 [drm]
> [77216.738409] [] drm_get_pci_dev+0xbc/0x188 [drm]
> [77216.744663] [] nouveau_drm_probe+0x180/0x208 [nouveau]
> [77216.751354] [] local_pci_probe+0x50/0xb4
> [77216.756827] [] pci_device_probe+0xf8/0x148
> [77216.762474] [] driver_probe_device+0x284/0x420
> [77216.768467] [] __driver_attach+0x120/0x124
> [77216.774115] [] bus_for_each_dev+0x6c/0xac
> [77216.779673] [] driver_attach+0x2c/0x34
> [77216.784972] [] bus_add_driver+0x244/0x2b0
> [77216.790531] [] driver_register+0x68/0xfc
> [77216.796004] [] __pci_register_driver+0x60/0x6c
> [77216.802047] [] drm_pci_init+0x108/0x138 [drm]
> [77216.808146] [] nouveau_drm_init+0x158/0x1 [nouveau]
> [77216.814922] [] do_one_initcall+0x44/0x128
> [77216.820483] [] do_init_module+0x68/0x1e0
> [77216.825957] [] load_module+0xfac/0x12bc
> [77216.831343] [] SyS_finit_module+0xe4/0xf0
> [77216.836902] [] el0_svc_naked+0x24/0x28
>
> By default fedora is using a 64k page kernel, switching to a mainline
> 4.9-rc7 kernel using the same configuration the same problem exists (there
> are a couple others, mentioned briefly in the defect). Changing the mainline
> kernel from 64k to 4k pages corrects the problem and a terminal display can
> be seen.
>
> The fedora defect is:
> https://bugzilla.redhat.com/show_bug.cgi?id=1400623
>
>
> Thanks,
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
>

[RFC v2] drm: Enable dynamic debug for DRM_[DEV]_DEBUG*

2016-12-07 Thread Robert Bragg 
This is still missing corresponding documentation changes, and I haven't
moved anything to drm_print.h yet, as suggested.

Sending out with a few functional improvements first to get agreement
before documenting anything (changes summarised in v2: section below)

In particular, affecting the output format, I stole an idea from Tvrtko
Ursulin to have the prefix for messages be based on the driver name,
such as "[i915]" instead of always being "[drm]".

Depending on peoples thoughts on compatibility, we could consider
removing the prefix given that the dynamic debug control interface has a
way of specifying that messages should include a module name, function
or line info like:

echo "module i915 +mfp" > dynamic_debug/control

That would enable all i915 debug messages with a module and function
prefix.

A trade-off would be that anyone only using the drm.drm_debug interface
to control messages would loose some information. If we really wanted we
could have the best of both by adding a utility printing api that can
recognise when printing due to a dynamic debug control query vs
drm.drm_debug to conditionally add the prefix.

--- >8 --- (git am --scissors)

Dynamic debug messages (ref: Documentation/dynamic-debug-howto.txt)
allow fine grained control over which debug messages are enabled with
runtime control through /sysfs/kernel/debug/dynamic_debug/control

This provides more control than the current drm.drm_debug parameter
which for some use cases is impractical to use given how chatty
some drm debug categories are.

For example all debug messages in i915_drm.c can be enabled with:
echo "file i915_perf.c +p" > dynamic_debug/control

This doesn't strictly maintain format compatibility with the previous
debug messages since the category is now added as part of the prefix
like "[drm][kms] No FB found". Adding the categories with a consistent
format makes it possible to enable categories with a dynamic debug
query like: echo "format [kms] +p" > dynamic_debug/control

This maintains support for enabling debug messages using the drm_debug
parameter. If dynamic debug is not enabled via CONFIG_DYNAMIC_DEBUG the
debug messages essentially work as before, except with the inclusion of
categories in the format strings as described above.

This removes the drm_[dev_]printk wrappers considering that the dynamic
debug macros are only useful if they can track the __FILE__, __func__
and __LINE__ where they are called. The wrapper didn't seem necessary in
the DRM_UT_NONE case with no category flag.

The non _DEV macros are no longer defined in terms of passing NULL to a
_DEV variant to avoid have the core.c dev_printk implementation adding
"(NULL device *)". The previous drm_[dev_]prink function used to handle
this as a special case.

Instead of using DRM_NAME to add [drm] to the start of every message,
the prefix is now based on module_name(THIS_MODULE) so it will be [drm]
or e.g. [i915] for the Intel driver. Later we might consider removing
the prefix altogether considering that the dynamic debug control
interface has a way of optionally adding the module, function or line to
the formatting of messages.

v2:
Add categories to format like "[drm][kms] No FB found"
Only single conditional call per message (macros expand to less code)
Uses __dynamic_pr_debug/dev_dbg for dynamic formatting features
Use module name for msg prefix like [drm] or [i915]

Signed-off-by: Robert Bragg 
Cc: dri-devel at lists.freedesktop.org
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/drm_drv.c |  47 ---
 include/drm/drmP.h| 202 +-
 2 files changed, 127 insertions(+), 122 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index f74b7d0..25d00aa 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -65,53 +65,6 @@ static struct idr drm_minors_idr;

 static struct dentry *drm_debugfs_root;

-#define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
-
-void drm_dev_printk(const struct device *dev, const char *level,
-   unsigned int category, const char *function_name,
-   const char *prefix, const char *format, ...)
-{
-   struct va_format vaf;
-   va_list args;
-
-   if (category != DRM_UT_NONE && !(drm_debug & category))
-   return;
-
-   va_start(args, format);
-   vaf.fmt = format;
-   vaf.va = &args;
-
-   if (dev)
-   dev_printk(level, dev, DRM_PRINTK_FMT, function_name, prefix,
-  &vaf);
-   else
-   printk("%s" DRM_PRINTK_FMT, level, function_name, prefix, &vaf);
-
-   va_end(args);
-}
-EXPORT_SYMBOL(drm_dev_printk);
-
-void drm_printk(const char *level, unsigned int category,
-   const char *format, ...)
-{
-   struct va_format vaf;
-   va_list args;
-
-   if (category != DRM_UT_NONE && !(drm_debug & category))
-   return;
-
-   va_start(args, format)

[Bug 99013] [regression, bisected] radeonsi: commit 4c8c13b3 "Use amdgcn intrinsics for fs interpolation" makes system unusable

2016-12-07 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=99013

--- Comment #2 from Alexandre Demers  ---
(In reply to Michel Dänzer from comment #1)
> (In reply to Alexandre Demers from comment #0)
> > LLVM 4.0.0svn r288795
> 
> The Mesa commit you bisected requires LLVM SVN r288865 ("AMDGPU: Add
> llvm.amdgcn.interp.mov intrinsic") or newer.

Isn't there a check done against LLVM's version? Does it have the needed
granularity to point to a given a commit/revision?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/3596769f/attachment.html>

[PATCH] drm/atomic: Don't reject reflect-only rotations

2016-12-07 Thread Ville Syrjälä 
On Wed, Dec 07, 2016 at 04:54:40PM +0100, Daniel Vetter wrote:
> On Wed, Dec 07, 2016 at 05:13:24PM +0200, Ville Syrjälä wrote:
> > On Wed, Dec 07, 2016 at 03:52:29PM +0100, Daniel Vetter wrote:
> > > On Wed, Dec 07, 2016 at 01:32:57PM +, Chris Wilson wrote:
> > > > On Wed, Dec 07, 2016 at 12:18:19PM +, Brian Starkey wrote:
> > > > > The check to reject combinations of multiple rotation angles is overly
> > > > > restrictive and has the side-effect of also failing any rotation value
> > > > > which consists only of reflections.
> > > > > 
> > > > > Fix this by relaxing the check to ignore values which contain no
> > > > > rotation flags.
> > > > > 
> > > > > Fixes: 6e0c7c3358d4 ("drm/atomic: Reject attempts to use multiple 
> > > > > rotation angles at once")
> > > > > Signed-off-by: Brian Starkey 
> > > > 
> > > > >  drivers/gpu/drm/drm_atomic.c |3 ++-
> > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_atomic.c 
> > > > > b/drivers/gpu/drm/drm_atomic.c
> > > > > index 362e3ea..44f4030 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > > @@ -846,7 +846,8 @@ int drm_atomic_plane_set_property(struct 
> > > > > drm_plane *plane,
> > > > >   } else if (property == config->prop_src_h) {
> > > > >   state->src_h = val;
> > > > >   } else if (property == plane->rotation_property) {
> > > > > - if (!is_power_of_2(val & DRM_ROTATE_MASK))
> > > > > + if ((val & DRM_ROTATE_MASK) &&
> > > > 
> > > > If val & DRM_ROTATE_MASK is zero, val must be REFLECT_X | REFLECT_Y.
> > > 
> > > While we bikeshed this check: Validation like this should be somewhere
> > > behind ->atomic_check, since if it's only here then you can sneak invalid
> > > stuff in through the legacy/compat set_property ioctls.
> > 
> > Not if you use drm_atomic_helper_plane_set_property().
> 
> Oh right, I mixed up the callchain maze in my head again. I still feel
> like putting all the validation code in one place might be a good idea.
> But yeah not strictly needed.

Well, we do quite a bit of checking already earlier. Eg.
drm_property_change_valid(), and obj ID lookups. I think this sort of
"totally invalid use of the API" check fits in pretty well with that
crowd.

-- 
Ville Syrjälä
Intel OTC

[drm:drm-exclusive-objects 34/34] htmldocs: include/drm/drm_mode_object.h:61: warning: No description found for parameter 'exclusive_access'

2016-12-07 Thread kbuild test robot 
clude/drm/drm_mode_object.h Daniel Vetter 2016-08-29  63  /**
a2511a55 include/drm/drm_mode_object.h Daniel Vetter 2016-08-29  64   * struct 
drm_object_properties - property tracking for &drm_mode_object
a2511a55 include/drm/drm_mode_object.h Daniel Vetter 2016-08-29  65   */
52217195 include/drm/drm_modeset.h Daniel Vetter 2016-08-12  66  struct 
drm_object_properties {
a2511a55 include/drm/drm_mode_object.h Daniel Vetter 2016-08-29  67 /**
a2511a55 include/drm/drm_mode_object.h Daniel Vetter 2016-08-29  68  * 
@count: number of valid properties, must be less than or equal to
a2511a55 include/drm/drm_mode_object.h Daniel Vetter 2016-08-29  69  * 
DRM_OBJECT_MAX_PROPERTY.

:: The code at line 61 was first introduced by commit
:: 7520a277d97be6e8a8ec038bb5ed01f40d4f9aeb drm: Extract 
drm_framebuffer.[hc]

:: TO: Daniel Vetter 
:: CC: Daniel Vetter 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 6425 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/92bb6381/attachment.gz>

[Intel-gfx] [RFC 0/5] DRM logging tidy

2016-12-07 Thread Robert Bragg 
On Tue, Dec 6, 2016 at 6:57 PM, Tvrtko Ursulin  wrote:

> From: Tvrtko Ursulin 
>
> I wasn't here at the beginnings of DRM so I might have gotten this wrong,
> however the existance of DRM_NAME suggested to me that the intention was to
> allow individual drivers to override it and get appropriate prefixes in
> their
> log messages.
>
> I can't see that any driver is using it like that but I still thought it
> would
> be neat to do that. That way we could have our log messages look more
> obviously ours. For example after this series we have:
>
>  [i915] Memory usable by graphics device = 4096M
>  [i915] VT-d active for gfx access
>  [i915] Replacing VGA console driver
>  [i915] ACPI BIOS requests an excessive sleep of 2 ms, using 1500 ms
> instead
>  [i915] Finished loading DMC firmware i915/skl_dmc_ver1_26.bin (v1.26)
>  [i915] Disabling framebuffer compression (FBC) to prevent screen flicker
> with VT-d enabled
>  [i915] GuC firmware load skipped
>  [i915] Initialized i915 1.6.0 20161205 for :00:02.0 on minor 0
>  [i915] DRM_I915_DEBUG enabled
>  [i915] DRM_I915_DEBUG_GEM enabled
>  [i915] RC6 on
>
> Previously all that was prefixed with "[drm]" which was OK but I think the
> above is even better.
>
> Also to consider is that recent drm_printk work has removed (it hardcoded)
> DRM_NAME from DRM_ERROR and DRM_DEBUG macros, while leaving it with the
> rest
> (DRM_INFO, NOTE and WARNING) creating a bit of a inconsistency.
>

I wonder if I can maybe fold some of this idea into my related DRM_DEBUG
[RFC] sent out recently:
https://lists.freedesktop.org/archives/dri-devel/2016-December/126094.html

Instead of using DRM_NAME, I've experimented with updating my changes
adding support for dynamic debug to add a prefix based on
module_name(THIS_MODULE) for a similar result

One thing to consider here is that with the addition of dynamic debug
support this prefix arguably becomes redundant because the
dynamic_debug/control interface lets you choose to add a module name or
function prefix to messages, e.g. like:

echo "module i915 +mfp" > dynamic_debug/control

I've ignored the redundancy because my change still allows enabling
messages with the drm.drm_debug parameter and in that case the prefix is
still useful.

Br,
- Robert



> This series also makes all the logging macros use drm_printk, but also
> makes DRM_NAME passed in from the macro wrappers in all cases. So drivers
> can override it regardless of the log level.
>
> And finally, the series also removes a bit of redundant data from the debug
> messages effectively converting this:
>
>  [drm:edp_panel_off [i915]] Wait for panel power off time
>
> Into this:
>
>  [edp_panel_off [i915]] Wait for panel power off time
>
> Which still has all the data in it.
>
> Tvrtko Ursulin (5):
>   drm/i915: Give our log messages our name
>   drm: Respect driver set DRM_NAME in drm_printk
>   drm: Respect driver set DRM_NAME in drm_dev_printk
>   drm: Use drm_printk for all logging macros
>   drm: Do not log driver prefix in debug messages
>
>  drivers/gpu/drm/drm_drv.c   | 39 +++--
>  drivers/gpu/drm/i915/i915_drv.c |  3 +-
>  include/drm/drmP.h  | 94 --
> ---
>  include/drm/drm_drv.h   | 11 ++---
>  include/uapi/drm/i915_drm.h |  3 ++
>  5 files changed, 92 insertions(+), 58 deletions(-)
>
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/4fb87cc8/attachment-0001.html>

[PATCH] drm/mxsfb: fix pixel clock polarity

2016-12-07 Thread Stefan Agner 
On 2016-12-07 16:59, Stefan Agner wrote:
> On 2016-12-07 16:49, Marek Vasut wrote:
>> On 12/08/2016 01:27 AM, Stefan Agner wrote:
>>> The DRM subsystem specifies the pixel clock polarity from a
>>> controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means
>>> the controller drives the data on pixel clocks falling edge.
>>> That is the controllers DOTCLK_POL=0 (Default is data launched
>>> at negative edge).
>>>
>>> Also change the data enable logic to be high active by default
>>> and only change if explicitly requested via bus_flags. With
>>> that defaults are:
>>> - Data enable: high active
>>> - Pixel clock polarity: controller drives data on negative edge
>>>
>>> Signed-off-by: Stefan Agner 
>>> ---
>>> Hi Marek,
>>
>> Hi, that was quick, thanks for checking this.
> 
> Yeah, I couldn't wait seeing it flying :-)
> 
>>
>>> I discovered this while testing on a i.MX 7 eLCDIF IP. Particularly the
>>> non-standard DE polarity was causing issues. I was using a EDT display
>>> which is part of simple panel driver since a while now and does not
>>> specify any bus_flags currently... Of course I could (and probably should)
>>> add the proper bus_flags there too, but there are several displays
>>> which do not specify any polarity and likely rely on sensible driver
>>> standards (which is afact high active for the DE signal).
>>
>> I actually use a panel which requires correct settings of the flags, see
>> e0932f9d7ba9a16f99a84943b720f109de8e3e06 in mainline , so this patch
>> would break things for me. So I wonder whether you should fix the panel
>> driver or whether the mxsfb should be fixed ?
> 
> If you ask me, mxsfb.
> 
> Ok, there are actually two things, one is a bug, one is a default
> change.
> 
> The bug: Pixel clock polarity is clearly defined to be controller
> centric (see comments around DRM_BUS_FLAG_PIXDATA_*EDGE in
> include/drm/drm_connector.h). The driver does it wrong currently.
> 
> This might affect your display, and if it does, it is actually wrong
> also in your display... However, since it is a bug, I think it is not
> really a debate, it should be fixed...

FWIW, it seems that Ortustech com43h4m85ulc samples on falling edge, so
DRM_BUS_FLAG_PIXDATA_POSEDGE seems right. And it means that DOTCLK_POL
should be 1 (inverted), so with this patch the polarity should actually
be correct for that panel.

--
Stefan

> The default change: Data enable should be high by default because that
> is what most displays require, including yours. This won't break your
> display, since you request DRM_BUS_FLAG_DE_HIGH anyway...
> 
> We could debate whether that default change is necessary, but since it
> also won't affect your display, I think it is a worthwhile change.
> 
> --
> Stefan
> 
> 
>>
>>> --
>>> Stefan
>>>
>>>  drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 11 +--
>>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c 
>>> b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>>> index 0818903..4bcc8a3 100644
>>> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>>> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>>> @@ -168,9 +168,16 @@ static void mxsfb_crtc_mode_set_nofb(struct 
>>> mxsfb_drm_private *mxsfb)
>>> vdctrl0 |= VDCTRL0_HSYNC_ACT_HIGH;
>>> if (m->flags & DRM_MODE_FLAG_PVSYNC)
>>> vdctrl0 |= VDCTRL0_VSYNC_ACT_HIGH;
>>> -   if (bus_flags & DRM_BUS_FLAG_DE_HIGH)
>>> +   /* Data Enable should be high active by default */
>>> +   if (!(bus_flags & DRM_BUS_FLAG_DE_LOW))
>>> vdctrl0 |= VDCTRL0_ENABLE_ACT_HIGH;
>>> -   if (bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
>>> +   /*
>>> +* Note: DRM_BUS_FLAG_PIXDATA defines are controller centric,
>>> +* controllers VDCTRL0_DOTCLK is display centric.
>>> +* Drive on positive edige  -> display samples on falling edge
>>> +* DRM_BUS_FLAG_PIXDATA_POSEDGE -> VDCTRL0_DOTCLK_ACT_FALLING
>>> +*/
>>> +   if (bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
>>> vdctrl0 |= VDCTRL0_DOTCLK_ACT_FALLING;
>>>
>>> writel(vdctrl0, mxsfb->base + LCDC_VDCTRL0);
>>>

[PATCH v4 2/4] fbmem: add a default get_fb_unmapped_area function

2016-12-07 Thread Laurent Pinchart 
Hi Benjamin,

On Wednesday 07 Dec 2016 15:57:49 Benjamin Gaignard wrote:
> 2016-12-07 15:35 GMT+01:00 Laurent Pinchart:
> > On Wednesday 07 Dec 2016 11:06:49 Benjamin Gaignard wrote:
> >> Allow generic frame-buffer to provide a default
> >> get_fb_unmapped_area function if specific devices need it.
> >> 
> >> Usually this function is defined in architecture directories but
> >> define it here may limit code duplication especially for all ARM
> >> platforms without MMU.
> > 
> > I still would like to see an explanation why an architecture-specific
> > version is sometimes needed, and why this implementation is a reasonable
> > default. Furthermore, it looks very similar to the blackfin
> > implementation, so if you can't unify the two I'd like to know why.
> 
> Obviously I don't know all the legacy behind this function but it is
> definitively link to architectures memory mapping strategies in no MMU
> cases.
> 
> I think this function is a reasonable default when the architecture is
> doing a direct mapping (no translation) of the memory like it is done in
> ARM.
> 
> Unlike what I propose blackfin implementation doesn't do any check on pgoff
> and length and always return fb base address even is an offset has been
> requested. I don't know if it is on purpose or just because nobody has
> never try to mmap blackfin framebuffer with an offset...

And that's exactly what I'd like you to try and find out :-) git blame and 
contacting the original authors of that code could be a first step.

> >> version 4:
> >> - introdude a configuration flag to be independent of architecture
> >> 
> >> Signed-off-by: Benjamin Gaignard 
> >> ---
> >> 
> >>  drivers/video/fbdev/Kconfig  |  8 
> >>  drivers/video/fbdev/core/fbmem.c | 15 +++
> >>  2 files changed, 23 insertions(+)
> >> 
> >> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> >> index 5d3b0db..922e4ea 100644
> >> --- a/drivers/video/fbdev/Kconfig
> >> +++ b/drivers/video/fbdev/Kconfig
> >> @@ -138,6 +138,14 @@ config FB_SYS_IMAGEBLIT
> >> 
> >> blitting. This is used by drivers that don't provide their own
> >> (accelerated) version and the framebuffer is in system RAM.
> >> 
> >> +config FB_PROVIDE_GET_FB_UNMAPPED_AREA
> >> + bool
> >> + depends on FB
> >> + default n
> >> + ---help---
> >> +   Allow generic frame-buffer to provide get_fb_unmapped_area
> >> +   function.
> >> +
> >> 
> >>  menuconfig FB_FOREIGN_ENDIAN
> >>  
> >>   bool "Framebuffer foreign endianness support"
> >>   depends on FB
> >> 
> >> diff --git a/drivers/video/fbdev/core/fbmem.c
> >> b/drivers/video/fbdev/core/fbmem.c index 76c1ad9..22321a2 100644
> >> --- a/drivers/video/fbdev/core/fbmem.c
> >> +++ b/drivers/video/fbdev/core/fbmem.c
> >> @@ -1492,6 +1492,21 @@ static long fb_compat_ioctl(struct file *file,
> >> unsigned int cmd, return 0;
> >> 
> >>  }
> >> 
> >> +#ifdef CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA
> >> +unsigned long get_fb_unmapped_area(struct file *filp,
> >> +unsigned long addr, unsigned long len,
> >> +unsigned long pgoff, unsigned long
> >> flags)
> >> +{
> >> + struct fb_info * const info = filp->private_data;
> >> + unsigned long fb_size = PAGE_ALIGN(info->fix.smem_len);
> >> +
> >> + if (pgoff > fb_size || len > fb_size - pgoff)
> >> + return -EINVAL;
> >> +
> >> + return (unsigned long)info->screen_base + pgoff;
> >> +}
> >> +#endif
> >> +
> >> 
> >>  static const struct file_operations fb_fops = {
> >>  
> >>   .owner =THIS_MODULE,
> >>   .read = fb_read,
> > 
> > --
> > Regards,
> > 
> > Laurent Pinchart

-- 
Regards,

Laurent Pinchart

[PATCH] drm/atomic: Don't reject reflect-only rotations

2016-12-07 Thread Ville Syrjälä 
On Wed, Dec 07, 2016 at 03:52:29PM +0100, Daniel Vetter wrote:
> On Wed, Dec 07, 2016 at 01:32:57PM +, Chris Wilson wrote:
> > On Wed, Dec 07, 2016 at 12:18:19PM +, Brian Starkey wrote:
> > > The check to reject combinations of multiple rotation angles is overly
> > > restrictive and has the side-effect of also failing any rotation value
> > > which consists only of reflections.
> > > 
> > > Fix this by relaxing the check to ignore values which contain no
> > > rotation flags.
> > > 
> > > Fixes: 6e0c7c3358d4 ("drm/atomic: Reject attempts to use multiple 
> > > rotation angles at once")
> > > Signed-off-by: Brian Starkey 
> > 
> > >  drivers/gpu/drm/drm_atomic.c |3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index 362e3ea..44f4030 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -846,7 +846,8 @@ int drm_atomic_plane_set_property(struct drm_plane 
> > > *plane,
> > >   } else if (property == config->prop_src_h) {
> > >   state->src_h = val;
> > >   } else if (property == plane->rotation_property) {
> > > - if (!is_power_of_2(val & DRM_ROTATE_MASK))
> > > + if ((val & DRM_ROTATE_MASK) &&
> > 
> > If val & DRM_ROTATE_MASK is zero, val must be REFLECT_X | REFLECT_Y.
> 
> While we bikeshed this check: Validation like this should be somewhere
> behind ->atomic_check, since if it's only here then you can sneak invalid
> stuff in through the legacy/compat set_property ioctls.

Not if you use drm_atomic_helper_plane_set_property().

-- 
Ville Syrjälä
Intel OTC

[PATCH] drm/mxsfb: fix pixel clock polarity

2016-12-07 Thread Stefan Agner 
On 2016-12-07 16:49, Marek Vasut wrote:
> On 12/08/2016 01:27 AM, Stefan Agner wrote:
>> The DRM subsystem specifies the pixel clock polarity from a
>> controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means
>> the controller drives the data on pixel clocks falling edge.
>> That is the controllers DOTCLK_POL=0 (Default is data launched
>> at negative edge).
>>
>> Also change the data enable logic to be high active by default
>> and only change if explicitly requested via bus_flags. With
>> that defaults are:
>> - Data enable: high active
>> - Pixel clock polarity: controller drives data on negative edge
>>
>> Signed-off-by: Stefan Agner 
>> ---
>> Hi Marek,
> 
> Hi, that was quick, thanks for checking this.

Yeah, I couldn't wait seeing it flying :-)

> 
>> I discovered this while testing on a i.MX 7 eLCDIF IP. Particularly the
>> non-standard DE polarity was causing issues. I was using a EDT display
>> which is part of simple panel driver since a while now and does not
>> specify any bus_flags currently... Of course I could (and probably should)
>> add the proper bus_flags there too, but there are several displays
>> which do not specify any polarity and likely rely on sensible driver
>> standards (which is afact high active for the DE signal).
> 
> I actually use a panel which requires correct settings of the flags, see
> e0932f9d7ba9a16f99a84943b720f109de8e3e06 in mainline , so this patch
> would break things for me. So I wonder whether you should fix the panel
> driver or whether the mxsfb should be fixed ?

If you ask me, mxsfb.

Ok, there are actually two things, one is a bug, one is a default
change.

The bug: Pixel clock polarity is clearly defined to be controller
centric (see comments around DRM_BUS_FLAG_PIXDATA_*EDGE in
include/drm/drm_connector.h). The driver does it wrong currently.

This might affect your display, and if it does, it is actually wrong
also in your display... However, since it is a bug, I think it is not
really a debate, it should be fixed...

The default change: Data enable should be high by default because that
is what most displays require, including yours. This won't break your
display, since you request DRM_BUS_FLAG_DE_HIGH anyway...

We could debate whether that default change is necessary, but since it
also won't affect your display, I think it is a worthwhile change.

--
Stefan


> 
>> --
>> Stefan
>>
>>  drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 11 +--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c 
>> b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>> index 0818903..4bcc8a3 100644
>> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>> @@ -168,9 +168,16 @@ static void mxsfb_crtc_mode_set_nofb(struct 
>> mxsfb_drm_private *mxsfb)
>>  vdctrl0 |= VDCTRL0_HSYNC_ACT_HIGH;
>>  if (m->flags & DRM_MODE_FLAG_PVSYNC)
>>  vdctrl0 |= VDCTRL0_VSYNC_ACT_HIGH;
>> -if (bus_flags & DRM_BUS_FLAG_DE_HIGH)
>> +/* Data Enable should be high active by default */
>> +if (!(bus_flags & DRM_BUS_FLAG_DE_LOW))
>>  vdctrl0 |= VDCTRL0_ENABLE_ACT_HIGH;
>> -if (bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
>> +/*
>> + * Note: DRM_BUS_FLAG_PIXDATA defines are controller centric,
>> + * controllers VDCTRL0_DOTCLK is display centric.
>> + * Drive on positive edige  -> display samples on falling edge
>> + * DRM_BUS_FLAG_PIXDATA_POSEDGE -> VDCTRL0_DOTCLK_ACT_FALLING
>> + */
>> +if (bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
>>  vdctrl0 |= VDCTRL0_DOTCLK_ACT_FALLING;
>>
>>  writel(vdctrl0, mxsfb->base + LCDC_VDCTRL0);
>>

[GIT PULL] drm/fsl-dcu: fixes and cleanup around fbdev for v4.10

2016-12-07 Thread Stefan Agner 
Hi Dave,

I did not rebase it, but it should still merge fine. This time with a
tag...

Some fixes and cleanup, mainly around fbdev emulation. It also adds a
new module parameter which allows to specify the color depth/bpp for
the fbdev emulation (like the IMX DRM driver).

There have been some fixes in that driver which are not yet in
drm-next, but it seems to merge cleanly...

--
Stefan

The following changes since commit 7625e05286cf3f37c8a5e633379a4d014ddbe555:

  Merge branch 'drm-tda998x-devel' of git://git.armlinux.org.uk/~rmk/linux-arm 
into drm-next (2016-11-25 09:55:33 +1000)

are available in the git repository at:

  http://git.agner.ch/git/linux-drm-fsl-dcu.git tags/drm-fsl-dcu-for-next

for you to fetch changes up to 73fe26a48659abd2b85d2f87d3cf2400ddb313d7:

  drm/fsl-dcu: introduce kernel parameter to specify fbdev depth (2016-11-28 
17:33:59 -0800)


Fabio Estevam (2):
  drm/fsl-dcu: Remove unneeded NULL check
  drm/fsl-dcu: Propagate the real error code

Stefan Agner (4):
  drm/fsl-dcu: unload driver before disabling clocks
  drm/fsl-dcu: disable outputs before unloading driver
  drm/fsl-dcu: remove separate compilation unit for fbdev emulation
  drm/fsl-dcu: introduce kernel parameter to specify fbdev depth

 drivers/gpu/drm/fsl-dcu/Makefile|  1 -
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   | 26 ++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h   |  1 -
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c | 23 ---
 4 files changed, 18 insertions(+), 33 deletions(-)
 delete mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c

[PATCH 12/12] gpu: ipu-v3: Add smfc and ic client devices

2016-12-07 Thread Steve Longerbeam 
Adds IPU client devices for the SMFC and IC task units.

Signed-off-by: Steve Longerbeam 
---
 drivers/gpu/ipu-v3/ipu-common.c | 87 +++--
 include/video/imx-ipu-v3.h  |  3 ++
 2 files changed, 87 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index b6ca36b..729581d 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1161,18 +1161,77 @@ static struct ipu_platform_reg client_reg[] = {
.pdata = {
.type = IPU_CSI,
.csi = 0,
-   .dma[0] = IPUV3_CHANNEL_CSI0,
-   .dma[1] = -EINVAL,
+   .dma[0] = -EINVAL,
},
.name = "imx-ipuv3-csi",
}, {
.pdata = {
.type = IPU_CSI,
.csi = 1,
+   .dma[0] = -EINVAL,
+   },
+   .name = "imx-ipuv3-csi",
+   }, {
+   .pdata = {
+   .type = IPU_SMFC,
+   .smfc = 0,
+   .dma[0] = IPUV3_CHANNEL_CSI0,
+   .dma[1] = -EINVAL,
+   },
+   .name = "imx-ipuv3-smfc",
+   }, {
+   .pdata = {
+   .type = IPU_SMFC,
+   .smfc = 1,
.dma[0] = IPUV3_CHANNEL_CSI1,
.dma[1] = -EINVAL,
},
-   .name = "imx-ipuv3-csi",
+   .name = "imx-ipuv3-smfc",
+   }, {
+   .pdata = {
+   .type = IPU_IC,
+   .ic_task = IC_TASK_ENCODER,
+   .ic = 0,
+   .dma[0] = IPUV3_CHANNEL_IC_PRP_ENC_MEM,
+   .dma[1] = -EINVAL,
+   },
+   .name = "imx-ipuv3-ic",
+   }, {
+   .pdata = {
+   .type = IPU_IC,
+   .ic_task = IC_TASK_VIEWFINDER,
+   .ic = 0,
+   .dma[0] = IPUV3_CHANNEL_IC_PRP_VF_MEM,
+   .dma[1] = -EINVAL,
+   },
+   .name = "imx-ipuv3-ic",
+   }, {
+   .pdata = {
+   .type = IPU_IC,
+   .ic_task = IC_TASK_POST_PROCESSOR,
+   .ic = 0,
+   .dma[0] = IPUV3_CHANNEL_IC_PP_MEM,
+   .dma[1] = -EINVAL,
+   },
+   .name = "imx-ipuv3-ic",
+   }, {
+   .pdata = {
+   .type = IPU_IC,
+   .ic_task = IC_TASK_POST_PROCESSOR,
+   .ic = 1,
+   .dma[0] = IPUV3_CHANNEL_IC_PP_MEM,
+   .dma[1] = -EINVAL,
+   },
+   .name = "imx-ipuv3-ic",
+   }, {
+   .pdata = {
+   .type = IPU_IC,
+   .ic_task = IC_TASK_POST_PROCESSOR,
+   .ic = 2,
+   .dma[0] = IPUV3_CHANNEL_IC_PP_MEM,
+   .dma[1] = -EINVAL,
+   },
+   .name = "imx-ipuv3-ic",
}, {
.pdata = {
.type = IPU_DI,
@@ -1213,6 +1272,28 @@ of_get_ipu_client_node(struct ipu_soc *ipu, struct 
ipu_platform_reg *reg)
 "ipu%d_csi", ipu->id + 1);
client_id = reg->pdata.csi;
break;
+   case IPU_SMFC:
+   snprintf(node_name, sizeof(node_name), "ipu%d_smfc",
+ipu->id + 1);
+   client_id = reg->pdata.smfc;
+   break;
+   case IPU_IC:
+   switch (reg->pdata.ic_task) {
+   case IC_TASK_ENCODER:
+   snprintf(node_name, sizeof(node_name),
+"ipu%d_ic_prpenc", ipu->id + 1);
+   break;
+   case IC_TASK_VIEWFINDER:
+   snprintf(node_name, sizeof(node_name),
+"ipu%d_ic_prpvf", ipu->id + 1);
+   break;
+   case IC_TASK_POST_PROCESSOR:
+   snprintf(node_name, sizeof(node_name),
+"ipu%d_ic_pp", ipu->id + 1);
+   break;
+   }
+   client_id = reg->pdata.ic;
+   break;
case IPU_DI:
snprintf(node_name, sizeof(node_name),
 "ipu%d_di", ipu->id + 1);
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 7709af7..4e70ca4 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -418,6 +418,9 @@ int ipu_rot_mode_to_degrees(int *degrees, enum 
ipu_rotate_mode mode,
 struct ipu_client_platformdata {
enum ipu_unit_type type;

[PATCH 11/12] gpu: ipu-v3: lookup ipu client nodes by name

2016-12-07 Thread Steve Longerbeam 
To allow for IPU clients containing multiple ports, they are no longer
a single port node name, but have a name of the format
"ipu_". So we can no longer use of_graph_get_port_by_id()
to lookup the client node.

Create the function of_get_ipu_client_node() that looks up the client
node by node name and unit id. The ipu_unit_type enumeration is added
to the client_reg[] entries to compose the node names.

Signed-off-by: Steve Longerbeam 
---
 drivers/gpu/ipu-v3/ipu-common.c | 55 +++--
 1 file changed, 47 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 97218af..b6ca36b 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1159,6 +1159,7 @@ struct ipu_platform_reg {
 static struct ipu_platform_reg client_reg[] = {
{
.pdata = {
+   .type = IPU_CSI,
.csi = 0,
.dma[0] = IPUV3_CHANNEL_CSI0,
.dma[1] = -EINVAL,
@@ -1166,6 +1167,7 @@ static struct ipu_platform_reg client_reg[] = {
.name = "imx-ipuv3-csi",
}, {
.pdata = {
+   .type = IPU_CSI,
.csi = 1,
.dma[0] = IPUV3_CHANNEL_CSI1,
.dma[1] = -EINVAL,
@@ -1173,6 +1175,7 @@ static struct ipu_platform_reg client_reg[] = {
.name = "imx-ipuv3-csi",
}, {
.pdata = {
+   .type = IPU_DI,
.di = 0,
.dc = 5,
.dp = IPU_DP_FLOW_SYNC_BG,
@@ -1182,6 +1185,7 @@ static struct ipu_platform_reg client_reg[] = {
.name = "imx-ipuv3-crtc",
}, {
.pdata = {
+   .type = IPU_DI,
.di = 1,
.dc = 1,
.dp = -EINVAL,
@@ -1195,6 +1199,46 @@ static struct ipu_platform_reg client_reg[] = {
 static DEFINE_MUTEX(ipu_client_id_mutex);
 static int ipu_client_id;

+static struct device_node *
+of_get_ipu_client_node(struct ipu_soc *ipu, struct ipu_platform_reg *reg)
+{
+   struct device *dev = ipu->dev;
+   struct device_node *client;
+   char node_name[32];
+   u32 id, client_id = 0;
+
+   switch (reg->pdata.type) {
+   case IPU_CSI:
+   snprintf(node_name, sizeof(node_name),
+"ipu%d_csi", ipu->id + 1);
+   client_id = reg->pdata.csi;
+   break;
+   case IPU_DI:
+   snprintf(node_name, sizeof(node_name),
+"ipu%d_di", ipu->id + 1);
+   client_id = reg->pdata.di;
+   break;
+   default:
+   client = NULL;
+   goto out;
+   }
+
+   for_each_child_of_node(dev->of_node, client) {
+   if (client->name &&
+   (of_node_cmp(client->name, node_name) == 0)) {
+   of_property_read_u32(client, "reg", &id);
+   if (id == client_id)
+   break;
+   }
+   }
+out:
+   if (!client)
+   dev_info(dev, "no %s%d node in %s, not using %s%d\n",
+node_name, client_id, dev->of_node->full_name,
+node_name, client_id);
+   return client;
+}
+
 static int ipu_add_client_devices(struct ipu_soc *ipu, unsigned long ipu_base)
 {
struct device *dev = ipu->dev;
@@ -1211,15 +1255,10 @@ static int ipu_add_client_devices(struct ipu_soc *ipu, 
unsigned long ipu_base)
struct platform_device *pdev;
struct device_node *of_node;

-   /* Associate subdevice with the corresponding port node */
-   of_node = of_graph_get_port_by_id(dev->of_node, i);
-   if (!of_node) {
-   dev_info(dev,
-"no port@%d node in %s, not using %s%d\n",
-i, dev->of_node->full_name,
-(i / 2) ? "DI" : "CSI", i % 2);
+   /* Associate subdevice with the corresponding client node */
+   of_node = of_get_ipu_client_node(ipu, reg);
+   if (!of_node)
continue;
-   }

pdev = platform_device_alloc(reg->name, id++);
if (!pdev) {
-- 
2.7.4

[PATCH 10/12] gpu: ipu-v3: Add ipu_unit_type enumeration

2016-12-07 Thread Steve Longerbeam 
Adds an enumeration of the major IPUv3 subunits. Provide that info
in struct ipu_client_platformdata to more easily determine the IPU
client type.

Signed-off-by: Steve Longerbeam 
---
 include/video/imx-ipu-v3.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 53cd07c..7709af7 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -28,6 +28,23 @@ enum ipuv3_type {
IPUV3H,
 };

+/*
+ * Enumeration of the major IPU subunits
+ */
+enum ipu_unit_type {
+   IPU_IDMAC = 0,
+   IPU_CM,
+   IPU_CSI,
+   IPU_SMFC,
+   IPU_IC,
+   IPU_VDI,
+   IPU_IRT,
+   IPU_DC,
+   IPU_DI,
+   IPU_DP,
+   IPU_DMFC,
+};
+
 #define IPU_PIX_FMT_GBR24  v4l2_fourcc('G', 'B', 'R', '3')

 /*
@@ -399,6 +416,7 @@ int ipu_rot_mode_to_degrees(int *degrees, enum 
ipu_rotate_mode mode,
bool hflip, bool vflip);

 struct ipu_client_platformdata {
+   enum ipu_unit_type type;
int csi;
int di;
int dc;
-- 
2.7.4

[PATCH 09/12] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder

2016-12-07 Thread Steve Longerbeam 
Enables the ADV7180 decoder sensor. The ADV7180 connects to the
parallel-bus mux input on ipu1_csi0_mux.

On the sabreauto, two analog video inputs are routed to the ADV7180,
composite on Ain1, and composite on Ain3. Those inputs are defined
via inputs and input-names under the ADV7180 node. The ADV7180 power
pin is via max7310_b port expander.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 62 
 1 file changed, 62 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index d74882a..9222026 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -147,10 +147,48 @@
gpio-controller;
#gpio-cells = <2>;
};
+
+   camera: adv7180 at 21 {
+   compatible = "adi,adv7180";
+   reg = <0x21>;
+   powerdown-gpios = <&max7310_b 2 
GPIO_ACTIVE_LOW>;
+   interrupt-parent = <&gpio1>;
+   interrupts = <27 0x8>;
+   inputs = <0x00 0x02>;
+   input-names = "ADV7180 Composite on Ain1",
+   "ADV7180 Composite on Ain3";
+
+   port {
+   adv7180_to_ipu1_csi0_mux: endpoint {
+   remote-endpoint = 
<&ipu1_csi0_mux_from_parallel_sensor>;
+   bus-width = <8>;
+   };
+   };
+   };
};
};
 };

+&ipu1_smfc0 {
+   fim {
+   enable = <1>;
+   };
+};
+
+&ipu1_csi0_from_ipu1_csi0_mux {
+   bus-width = <8>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+   remote-endpoint = <&adv7180_to_ipu1_csi0_mux>;
+   bus-width = <8>;
+};
+
+&ipu1_csi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_ipu1_csi0>;
+};
+
 &clks {
assigned-clocks = <&clks IMX6QDL_PLL4_BYPASS_SRC>,
  <&clks IMX6QDL_PLL4_BYPASS>,
@@ -451,6 +489,30 @@
>;
};

+   pinctrl_ipu1_csi0: ipu1grp-csi0 {
+   fsl,pins = <
+   MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04   
0x8000
+   MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05   
0x8000
+   MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06   
0x8000
+   MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07   
0x8000
+   MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08   
0x8000
+   MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09   
0x8000
+   MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10  
0x8000
+   MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11  
0x8000
+   MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12  
0x8000
+   MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13  
0x8000
+   MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14  
0x8000
+   MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15  
0x8000
+   MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16  
0x8000
+   MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17  
0x8000
+   MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18  
0x8000
+   MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19  
0x8000
+   MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 
0x8000
+   MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC
0x8000
+   MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC   
0x8000
+   >;
+   };
+
pinctrl_pwm3: pwm1grp {
fsl,pins = <
MX6QDL_PAD_SD4_DAT1__PWM3_OUT   0x1b0b1
-- 
2.7.4

[PATCH 08/12] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture

2016-12-07 Thread Steve Longerbeam 
Add pinctrl groups for both GPT input capture channels.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 944a4fa..d74882a 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -457,6 +457,18 @@
>;
};

+   pinctrl_gpt_input_capture0: gptinputcapture0grp {
+   fsl,pins = <
+   MX6QDL_PAD_SD1_DAT0__GPT_CAPTURE1   
0x8000
+   >;
+   };
+
+   pinctrl_gpt_input_capture1: gptinputcapture1grp {
+   fsl,pins = <
+   MX6QDL_PAD_SD1_DAT1__GPT_CAPTURE2   
0x8000
+   >;
+   };
+
pinctrl_spdif: spdifgrp {
fsl,pins = <
MX6QDL_PAD_KEY_COL3__SPDIF_IN 0x1b0b0
-- 
2.7.4

[PATCH 07/12] ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b

2016-12-07 Thread Steve Longerbeam 
The reset pin to the port expander chip (MAX7310) is controlled by a gpio,
so define a reset-gpios property to control it. There are three MAX7310's
on the SabreAuto CPU card (max7310_[abc]), but all use the same pin for
their reset. Since all can't acquire the same pin, assign it to max7310_b,
that chip is needed by more functions (usb and adv7180).

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 043d20c..944a4fa 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -136,6 +136,9 @@
reg = <0x32>;
gpio-controller;
#gpio-cells = <2>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_max7310>;
+   reset-gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
};

max7310_c: gpio at 34 {
@@ -442,6 +445,12 @@
>;
};

+   pinctrl_max7310: max7310grp {
+   fsl,pins = <
+   MX6QDL_PAD_SD2_DAT0__GPIO1_IO15 0x8000
+   >;
+   };
+
pinctrl_pwm3: pwm1grp {
fsl,pins = <
MX6QDL_PAD_SD4_DAT1__PWM3_OUT   0x1b0b1
-- 
2.7.4

[PATCH 06/12] ARM: dts: imx6-sabreauto: create i2cmux for i2c3

2016-12-07 Thread Steve Longerbeam 
The sabreauto uses a steering pin to select between the SDA signal on
i2c3 bus, and a data-in pin for an SPI NOR chip. Use i2cmux to control
this steering pin. Idle state of the i2cmux selects SPI NOR. This is not
a classic way to use i2cmux, since one side of the mux selects something
other than an i2c bus, but it works and is probably the cleanest
solution. Note that if one thread is attempting to access SPI NOR while
another thread is accessing i2c3, the SPI NOR access will fail since the
i2cmux has selected the SDA pin rather than SPI NOR data-in. This couldn't
be avoided in any case, the board is not designed to allow concurrent
i2c3 and SPI NOR functions (and the default device-tree does not enable
SPI NOR anyway).

Devices hanging off i2c3 should now be defined under i2cmux, so
that the steering pin can be properly controlled to access those
devices. The port expanders (MAX7310) are thus moved into i2cmux.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 65 +---
 1 file changed, 44 insertions(+), 21 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index e000e6f..043d20c 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -108,6 +108,44 @@
default-brightness-level = <7>;
status = "okay";
};
+
+   i2cmux {
+   compatible = "i2c-mux-gpio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_i2c3mux>;
+   mux-gpios = <&gpio5 4 0>;
+   i2c-parent = <&i2c3>;
+   idle-state = <0>;
+
+   i2c at 1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   max7310_a: gpio at 30 {
+   compatible = "maxim,max7310";
+   reg = <0x30>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   max7310_b: gpio at 32 {
+   compatible = "maxim,max7310";
+   reg = <0x32>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   max7310_c: gpio at 34 {
+   compatible = "maxim,max7310";
+   reg = <0x34>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+   };
+   };
 };

 &clks {
@@ -291,27 +329,6 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c3>;
status = "okay";
-
-   max7310_a: gpio at 30 {
-   compatible = "maxim,max7310";
-   reg = <0x30>;
-   gpio-controller;
-   #gpio-cells = <2>;
-   };
-
-   max7310_b: gpio at 32 {
-   compatible = "maxim,max7310";
-   reg = <0x32>;
-   gpio-controller;
-   #gpio-cells = <2>;
-   };
-
-   max7310_c: gpio at 34 {
-   compatible = "maxim,max7310";
-   reg = <0x34>;
-   gpio-controller;
-   #gpio-cells = <2>;
-   };
 };

 &iomuxc {
@@ -419,6 +436,12 @@
>;
};

+   pinctrl_i2c3mux: i2c3muxgrp {
+   fsl,pins = <
+   MX6QDL_PAD_EIM_A24__GPIO5_IO04 0x8000
+   >;
+   };
+
pinctrl_pwm3: pwm1grp {
fsl,pins = <
MX6QDL_PAD_SD4_DAT1__PWM3_OUT   0x1b0b1
-- 
2.7.4

[PATCH 05/12] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors

2016-12-07 Thread Steve Longerbeam 
Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.

The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.

The OV5640 connects to the input port on the MIPI CSI-2 receiver on
mipi_csi. It is set to transmit over MIPI virtual channel 1.

Until the OV5652 sensor module compatible with the SabreSD becomes
available for testing, the ov5642 node is currently disabled.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6dl-sabresd.dts   |   5 ++
 arch/arm/boot/dts/imx6q-sabresd.dts|   5 ++
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 114 -
 3 files changed, 123 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6dl-sabresd.dts 
b/arch/arm/boot/dts/imx6dl-sabresd.dts
index 1e45f2f..6cf7a50 100644
--- a/arch/arm/boot/dts/imx6dl-sabresd.dts
+++ b/arch/arm/boot/dts/imx6dl-sabresd.dts
@@ -15,3 +15,8 @@
model = "Freescale i.MX6 DualLite SABRE Smart Device Board";
compatible = "fsl,imx6dl-sabresd", "fsl,imx6dl";
 };
+
+&ipu1_csi1_from_ipu1_csi1_mux {
+   data-lanes = <0 1>;
+   clock-lanes = <2>;
+};
diff --git a/arch/arm/boot/dts/imx6q-sabresd.dts 
b/arch/arm/boot/dts/imx6q-sabresd.dts
index 9cbdfe7..8c1d7ad 100644
--- a/arch/arm/boot/dts/imx6q-sabresd.dts
+++ b/arch/arm/boot/dts/imx6q-sabresd.dts
@@ -23,3 +23,8 @@
 &sata {
status = "okay";
 };
+
+&ipu1_csi1_from_mipi_vc1 {
+   data-lanes = <0 1>;
+   clock-lanes = <2>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 8e9e0d9..e36e1e7 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -10,6 +10,7 @@
  * http://www.gnu.org/copyleft/gpl.html
  */

+#include 
 #include 
 #include 

@@ -146,6 +147,33 @@
};
 };

+&ipu1_csi0_from_ipu1_csi0_mux {
+   bus-width = <8>;
+   data-shift = <12>; /* Lines 19:12 used */
+   hsync-active = <1>;
+   vsync-active = <1>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+   remote-endpoint = <&ov5642_to_ipu1_csi0_mux>;
+};
+
+&ipu1_csi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_ipu1_csi0>;
+};
+
+&mipi_csi {
+   status = "okay";
+};
+
+/* Incoming port from sensor */
+&mipi_csi_from_mipi_sensor {
+   remote-endpoint = <&ov5640_to_mipi_csi>;
+   data-lanes = <0 1>;
+   clock-lanes = <2>;
+};
+
 &audmux {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_audmux>;
@@ -214,7 +242,33 @@
0x8014 /* 4:FN_DMICCDAT */
0x /* 5:Default */
>;
-   };
+   };
+
+   camera: ov5642 at 3c {
+   compatible = "ovti,ov5642";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_ov5642>;
+   clocks = <&clks IMX6QDL_CLK_CKO>;
+   clock-names = "xclk";
+   reg = <0x3c>;
+   xclk = <2400>;
+   DOVDD-supply = <&vgen4_reg>; /* 1.8v */
+   AVDD-supply = <&vgen5_reg>;  /* 2.8v, rev C board is VGEN3
+   rev B board is VGEN5 */
+   DVDD-supply = <&vgen2_reg>;  /* 1.5v*/
+   pwdn-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>; /* SD1_DAT0 */
+   reset-gpios = <&gpio1 17 GPIO_ACTIVE_LOW>; /* SD1_DAT1 */
+   status = "disabled";
+
+   port {
+   ov5642_to_ipu1_csi0_mux: endpoint {
+   remote-endpoint = 
<&ipu1_csi0_mux_from_parallel_sensor>;
+   bus-width = <8>;
+   hsync-active = <1>;
+   vsync-active = <1>;
+   };
+   };
+   };
 };

 &i2c2 {
@@ -322,6 +376,34 @@
};
};
};
+
+   mipi_camera: ov5640 at 3c {
+   compatible = "ovti,ov5640_mipi";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_ov5640>;
+   reg = <0x3c>;
+   clocks = <&clks IMX6QDL_CLK_CKO>;
+   clock-names = "xclk";
+   xclk = <2400>;
+   DOVDD-supply = <&vgen4_reg>; /* 1.8v */
+   AVDD-supply = <&vgen5_reg>;  /* 2.8v, rev C board is VGEN3
+   rev B board is VGEN5 */
+   DVDD-supply = <&vgen2_reg>;  /* 1.5v*/
+   pwdn-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>; /* SD1_DAT2 */
+   reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>; /* SD1_CLK */
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ov5640_to_mipi_csi: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint = <&mipi_csi_from_mipi_sensor>;
+   data-lanes = <0 1>;
+

[PATCH 04/12] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

2016-12-07 Thread Steve Longerbeam 
Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.
Both hang off the same i2c2 bus, so they require different (and non-
default) i2c slave addresses.

The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.

The OV5640 connects to the input port on the MIPI CSI-2 receiver on
mipi_csi. It is set to transmit over MIPI virtual channel 1.

Note there is a pin conflict with GPIO6. This pin functions as a power
input pin to the OV5642, but ENET uses it as the h/w workaround for
erratum ERR006687, to wake-up the ARM cores on normal RX and TX packet
done events (see 6261c4c8). So workaround 6261c4c8 is reverted here to
support the OV5642, and the "fsl,err006687-workaround-present" boolean
also must be removed. The result is that the CPUidle driver will no longer
allow entering the deep idle states on the sabrelite.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6dl-sabrelite.dts   |   5 ++
 arch/arm/boot/dts/imx6q-sabrelite.dts|   6 ++
 arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 122 ++-
 3 files changed, 129 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx6dl-sabrelite.dts 
b/arch/arm/boot/dts/imx6dl-sabrelite.dts
index 0f06ca5..fec2524 100644
--- a/arch/arm/boot/dts/imx6dl-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6dl-sabrelite.dts
@@ -48,3 +48,8 @@
model = "Freescale i.MX6 DualLite SABRE Lite Board";
compatible = "fsl,imx6dl-sabrelite", "fsl,imx6dl";
 };
+
+&ipu1_csi1_from_ipu1_csi1_mux {
+   data-lanes = <0 1>;
+   clock-lanes = <2>;
+};
diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts 
b/arch/arm/boot/dts/imx6q-sabrelite.dts
index 66d10d8..9e2d26d 100644
--- a/arch/arm/boot/dts/imx6q-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
@@ -52,3 +52,9 @@
 &sata {
status = "okay";
 };
+
+&ipu1_csi1_from_mipi_vc1 {
+   data-lanes = <0 1>;
+   clock-lanes = <2>;
+};
+
diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
index 81dd6cd..d7fcb1a2 100644
--- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
@@ -39,6 +39,8 @@
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
  */
+
+#include 
 #include 
 #include 

@@ -96,6 +98,15 @@
};
};

+   mipi_xclk: mipi_xclk {
+   compatible = "pwm-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2200>;
+   clock-output-names = "mipi_pwm3";
+   pwms = <&pwm3 0 45>; /* 1 / 45 ns = 22 MHz */
+   status = "okay";
+   };
+
gpio-keys {
compatible = "gpio-keys";
pinctrl-names = "default";
@@ -220,6 +231,22 @@
};
 };

+&ipu1_csi0_from_ipu1_csi0_mux {
+   bus-width = <8>;
+   data-shift = <12>; /* Lines 19:12 used */
+   hsync-active = <1>;
+   vync-active = <1>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+   remote-endpoint = <&ov5642_to_ipu1_csi0_mux>;
+};
+
+&ipu1_csi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_ipu1_csi0>;
+};
+
 &audmux {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_audmux>;
@@ -271,9 +298,6 @@
txd1-skew-ps = <0>;
txd2-skew-ps = <0>;
txd3-skew-ps = <0>;
-   interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
- <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
-   fsl,err006687-workaround-present;
status = "okay";
 };

@@ -302,6 +326,52 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c2>;
status = "okay";
+
+   camera: ov5642 at 42 {
+   compatible = "ovti,ov5642";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_ov5642>;
+   clocks = <&clks IMX6QDL_CLK_CKO2>;
+   clock-names = "xclk";
+   reg = <0x42>;
+   xclk = <2400>;
+   reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
+   pwdn-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
+   gp-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
+
+   port {
+   ov5642_to_ipu1_csi0_mux: endpoint {
+   remote-endpoint = 
<&ipu1_csi0_mux_from_parallel_sensor>;
+   bus-width = <8>;
+   hsync-active = <1>;
+   vsync-active = <1>;
+   };
+   };
+   };
+
+   mipi_camera: ov5640 at 40 {
+   compatible = "ovti,ov5640_mipi";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_ov5640>;
+   clocks = <&mipi_xclk>;
+   clock-names = "xclk";
+   reg = <0x40>;
+   xclk = <2200>;
+   reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>; /* NANDF_D5 */
+   pwdn-

[PATCH 03/12] ARM: dts: imx6qdl: add video capture devices and connections

2016-12-07 Thread Steve Longerbeam 
From: Philipp Zabel 

This patch adds the IPU subunit devices involved in video capture and
image conversion, and defines all the possible hardware connections
between them via OF graphs.

External to the IPU:

Video input multiplexers are defined that multiplex inputs from camera
sensors and the MIPI-CSI2 gasket, to the IPU CSIs.

On i.MX6Q/D two two-input multiplexers in front of IPU1 CSI0 and IPU2 CSI1
allow to select between CSI0/1 parallel input pads and the MIPI CSI-2 virtual
channels 0/3.

On i.MX6DL/S two five-input multiplexers in front of IPU1 CSI0 and IPU1 CSI1
allow to select between CSI0/1 parallel input pads and any of the four MIPI
CSI-2 virtual channels.

Internal to the IPU:

The IPU CSI, SMFC, IC-PRPENC, IC-PRPVF, and IC-PP subunits are added
as children of the IPUs, along with the hardware-supported connections
between them.

Finally, a media device node is defined. A video camera interface
and mem2mem device are defined as children of the media device.

Signed-off-by: Steve Longerbeam 
Signed-off-by: Philipp Zabel 
---
 arch/arm/boot/dts/imx6dl.dtsi  | 190 
 arch/arm/boot/dts/imx6q.dtsi   | 487 +
 arch/arm/boot/dts/imx6qdl.dtsi | 368 +++
 3 files changed, 1045 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 1ade195..4bab076 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -109,6 +109,120 @@
compatible = "fsl,imx-gpu-subsystem";
cores = <&gpu_2d>, <&gpu_3d>;
};
+
+   ipu1_csi0_mux: ipu1_csi0_mux at 34 {
+   compatible = "imx-video-mux";
+   reg = <0x34 0x07>;
+   gpr = <&gpr>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "okay";
+   sink-ports = <5>;
+
+   port at 0 {
+   reg = <0>;
+
+   ipu1_csi0_mux_from_mipi_vc0: endpoint {
+   remote-endpoint = <&mipi_vc0_to_ipu1_csi0_mux>;
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+
+   ipu1_csi0_mux_from_mipi_vc1: endpoint {
+   remote-endpoint = <&mipi_vc1_to_ipu1_csi0_mux>;
+   };
+   };
+
+   port at 2 {
+   reg = <2>;
+
+   ipu1_csi0_mux_from_mipi_vc2: endpoint {
+   remote-endpoint = <&mipi_vc2_to_ipu1_csi0_mux>;
+   };
+   };
+
+   port at 3 {
+   reg = <3>;
+
+   ipu1_csi0_mux_from_mipi_vc3: endpoint {
+   remote-endpoint = <&mipi_vc3_to_ipu1_csi0_mux>;
+   };
+   };
+
+   port at 4 {
+   reg = <4>;
+
+   ipu1_csi0_mux_from_parallel_sensor: endpoint {
+   };
+   };
+
+   port at 5 {
+   reg = <5>;
+
+   ipu1_csi0_mux_to_ipu1_csi0: endpoint {
+   remote-endpoint = 
<&ipu1_csi0_from_ipu1_csi0_mux>;
+   };
+   };
+   };
+
+   ipu1_csi1_mux: ipu1_csi1_mux at 34 {
+   compatible = "imx-video-mux";
+   reg = <0x34 0x38>;
+   gpr = <&gpr>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "okay";
+   sink-ports = <5>;
+
+   port at 0 {
+   reg = <0>;
+
+   ipu1_csi1_mux_from_mipi_vc0: endpoint {
+   remote-endpoint = <&mipi_vc0_to_ipu1_csi1_mux>;
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+
+   ipu1_csi1_mux_from_mipi_vc1: endpoint {
+   remote-endpoint = <&mipi_vc1_to_ipu1_csi1_mux>;
+   };
+   };
+
+   port at 2 {
+   reg = <2>;
+
+   ipu1_csi1_mux_from_mipi_vc2: endpoint {
+   remote-endpoint = <&mipi_vc2_to_ipu1_csi1_mux>;
+   };
+   };
+
+   port at 3 {
+   reg = <3>;
+
+   ipu1_csi1_mux_from_mipi_vc3: endpoint {
+   remote-endpoint = <&mipi_vc3_to_ipu1_csi1_mux>;
+   };
+   };
+
+   port at 4 {
+   reg = <4>;
+
+   ipu1_csi1_mux_from_parallel_sensor: endpoint {
+   };
+   };
+
+   port at 5 {
+   reg = <5>;
+
+   ipu1_csi1

[PATCH 02/12] ARM: dts: imx6qdl: rename ipu client nodes

2016-12-07 Thread Steve Longerbeam 
To allow for IPU client devices that are composed of more than one
port for input and output (SMFC and IC), change the nodes from being
a single port node to nodes that can contain multiple ports. Rename
the nodes to use the following format: "ipu_".

The IPUv3 driver will then need to lookup the client nodes by name
rather than by port id.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6q.dtsi   | 12 ++--
 arch/arm/boot/dts/imx6qdl.dtsi | 12 ++--
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index e9a5d0b..2b261ba 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -141,18 +141,18 @@
clock-names = "bus", "di0", "di1";
resets = <&src 4>;

-   ipu2_csi0: port at 0 {
+   ipu2_csi0: ipu2_csi at 0 {
reg = <0>;
};

-   ipu2_csi1: port at 1 {
+   ipu2_csi1: ipu2_csi at 1 {
reg = <1>;
};

-   ipu2_di0: port at 2 {
+   ipu2_di0: ipu2_di at 0 {
#address-cells = <1>;
#size-cells = <0>;
-   reg = <2>;
+   reg = <0>;

ipu2_di0_disp0: disp0-endpoint {
};
@@ -174,10 +174,10 @@
};
};

-   ipu2_di1: port at 3 {
+   ipu2_di1: ipu2_di at 1 {
#address-cells = <1>;
#size-cells = <0>;
-   reg = <3>;
+   reg = <1>;

ipu2_di1_hdmi: hdmi-endpoint {
remote-endpoint = <&hdmi_mux_3>;
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index e01e5d5..2465187 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1226,18 +1226,18 @@
clock-names = "bus", "di0", "di1";
resets = <&src 2>;

-   ipu1_csi0: port at 0 {
+   ipu1_csi0: ipu1_csi at 0 {
reg = <0>;
};

-   ipu1_csi1: port at 1 {
+   ipu1_csi1: ipu1_csi at 1 {
reg = <1>;
};

-   ipu1_di0: port at 2 {
+   ipu1_di0: ipu1_di at 0 {
#address-cells = <1>;
#size-cells = <0>;
-   reg = <2>;
+   reg = <0>;

ipu1_di0_disp0: disp0-endpoint {
};
@@ -1259,10 +1259,10 @@
};
};

-   ipu1_di1: port at 3 {
+   ipu1_di1: ipu1_di at 1 {
#address-cells = <1>;
#size-cells = <0>;
-   reg = <3>;
+   reg = <1>;

ipu1_di1_disp1: disp1-endpoint {
};
-- 
2.7.4

[PATCH 01/12] ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node

2016-12-07 Thread Steve Longerbeam 
Add to the MIPI CSI2 receiver node: compatible string, interrupt sources,
clocks.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index b13b0b2..e01e5d5 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1121,7 +1121,14 @@
};

mipi_csi: mipi at 021dc000 {
+   compatible = "fsl,imx-mipi-csi2";
reg = <0x021dc000 0x4000>;
+   interrupts = <0 100 0x04>, <0 101 0x04>;
+   clocks = <&clks IMX6QDL_CLK_HSI_TX>,
+<&clks IMX6QDL_CLK_VIDEO_27M>,
+<&clks IMX6QDL_CLK_EIM_SEL>;
+   clock-names = "dphy_clk", "cfg_clk", "pix_clk";
+   status = "disabled";
};

mipi_dsi: mipi at 021e {
-- 
2.7.4

[PATCH 00/12] i.MX media devices and connections

2016-12-07 Thread Steve Longerbeam 
Hi Philipp, Sascha, Shawn, et al,

I've been working for the past few months on a media driver for i.MX.
In addition to the media entities for the IPU-external units involved
with video capture (video mux and MIPI CSI-2 receiver), I've created
media entities for the IPU CSI, SMFC, and IC subunits. The IC entities
carry out scaling, CSC, horizontal/vertical flip, and rotation. In
addition, the IC-PRPVF entity carries out motion compensated
de-interlace.

The following series adds the OF device nodes and graphs that define
all the possible hardware connections supported by the i.MX involved
in video capture and image conversion.

Here are some of the pipelines defined by the OF graphs:

CSI -> IC-PRPENC
CSI -> IC-PRPVF
CSI -> IC-PRPVF -> IC-PP
CSI -> SMFC
CSI -> SMFC -> IC-PRPVF
CSI -> SMFC -> IC-PP
CSI -> SMFC -> IC-PRPVF -> IC-PP

You will notice that three IC-PP nodes are defined (ipu1_ic_pp0,
ipu1_ic_pp1, ipu1_ic_pp2, and same for ipu2). The reason for that
is that the IC-PP media entity uses the new ipu-image-conversion
API, which allows for multiple conversion contexts to be created.
Each IC-PP entity thus creates its own conversion context, and there
can be any number of IC-PP entities instantiated as needed by the OF
graph.

Camera sensor nodes are also added for the SabreAuto, SabreSD, and
SabreLite reference platforms.

The media driver is now in fairly good shape. It parses the OF graphs
to create the media pads and links. All the pipelines defined by the
OF graphs have been tested and are working. My media driver work is
at:

git at github.com:slongerbeam/mediatree.git, branch imx-media-staging-md-v2.

For an overview of the pipelines supported and usage notes for the
reference boards, you can refer to Documentation/media/v4l-drivers/imx.rst.

I realize there is collision here with the recent patch series posted by
Philipp, particularly around the video multiplexer and mipi csi-2 receiver
subdevs and OF graphs, as well as v4l2 capture drivers.



Philipp Zabel (1):
  ARM: dts: imx6qdl: add video capture devices and connections

Steve Longerbeam (11):
  ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node
  ARM: dts: imx6qdl: rename ipu client nodes
  ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors
  ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
  ARM: dts: imx6-sabreauto: create i2cmux for i2c3
  ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b
  ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
  ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
  gpu: ipu-v3: Add ipu_unit_type enumeration
  gpu: ipu-v3: lookup ipu client nodes by name
  gpu: ipu-v3: Add smfc and ic client devices

 arch/arm/boot/dts/imx6dl-sabrelite.dts   |   5 +
 arch/arm/boot/dts/imx6dl-sabresd.dts |   5 +
 arch/arm/boot/dts/imx6dl.dtsi| 190 
 arch/arm/boot/dts/imx6q-sabrelite.dts|   6 +
 arch/arm/boot/dts/imx6q-sabresd.dts  |   5 +
 arch/arm/boot/dts/imx6q.dtsi | 497 ++-
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 148 +++--
 arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 122 +++-
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi   | 114 ++-
 arch/arm/boot/dts/imx6qdl.dtsi   | 385 +++-
 drivers/gpu/ipu-v3/ipu-common.c  | 142 -
 include/video/imx-ipu-v3.h   |  21 ++
 12 files changed, 1593 insertions(+), 47 deletions(-)

-- 
2.7.4

[PATCH] drm: hdlcd: Work properly in big-endian mode

2016-12-07 Thread Daniel Vetter 
On Wed, Dec 07, 2016 at 03:31:40PM +, Robin Murphy wrote:
> Under a big-endian kernel, colours on the framebuffer all come out a
> delightful shade of wrong, since we fail to take the reversed byte
> order into account. Fortunately, the HDLCD has a control bit to make it
> automatically byteswap big-endian data; let's use it as appropriate.
> 
> Signed-off-by: Robin Murphy 

fourcc codes (and the drm fourcc codes) are supposed to be little-endian.
All of them. So either we fix up the drivers and userspace to set that
flag correctly (which would mean hdlcd should expose twice as many
formats, each one with the little and big endian mode).

Or we nuke the big endian flag from drm fourcc. Adding AMD folks who afaik
are the only other ones who ever cared about big endian in drm.
-Daniel

> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c 
> b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 28341b32067f..eceb7bed5dd0 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -63,6 +63,7 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
>   uint32_t pixel_format;
>   struct simplefb_format *format = NULL;
>   int i;
> + u32 reg;
>  
>   pixel_format = crtc->primary->state->fb->pixel_format;
>  
> @@ -76,7 +77,11 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
>  
>   /* HDLCD uses 'bytes per pixel', zero means 1 byte */
>   btpp = (format->bits_per_pixel + 7) / 8;
> - hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, (btpp - 1) << 3);
> + reg = (btpp - 1) << 3;
> +#ifdef __BIG_ENDIAN
> + reg |= HDLCD_PIXEL_FMT_BIG_ENDIAN;
> +#endif
> + hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, reg);
>  
>   /*
>* The format of the HDLCD_REG__SELECT register is:
> -- 
> 2.10.2.dirty
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/atomic: Don't reject reflect-only rotations

2016-12-07 Thread Daniel Vetter 
On Wed, Dec 07, 2016 at 05:13:24PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 07, 2016 at 03:52:29PM +0100, Daniel Vetter wrote:
> > On Wed, Dec 07, 2016 at 01:32:57PM +, Chris Wilson wrote:
> > > On Wed, Dec 07, 2016 at 12:18:19PM +, Brian Starkey wrote:
> > > > The check to reject combinations of multiple rotation angles is overly
> > > > restrictive and has the side-effect of also failing any rotation value
> > > > which consists only of reflections.
> > > > 
> > > > Fix this by relaxing the check to ignore values which contain no
> > > > rotation flags.
> > > > 
> > > > Fixes: 6e0c7c3358d4 ("drm/atomic: Reject attempts to use multiple 
> > > > rotation angles at once")
> > > > Signed-off-by: Brian Starkey 
> > > 
> > > >  drivers/gpu/drm/drm_atomic.c |3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > > index 362e3ea..44f4030 100644
> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > @@ -846,7 +846,8 @@ int drm_atomic_plane_set_property(struct drm_plane 
> > > > *plane,
> > > > } else if (property == config->prop_src_h) {
> > > > state->src_h = val;
> > > > } else if (property == plane->rotation_property) {
> > > > -   if (!is_power_of_2(val & DRM_ROTATE_MASK))
> > > > +   if ((val & DRM_ROTATE_MASK) &&
> > > 
> > > If val & DRM_ROTATE_MASK is zero, val must be REFLECT_X | REFLECT_Y.
> > 
> > While we bikeshed this check: Validation like this should be somewhere
> > behind ->atomic_check, since if it's only here then you can sneak invalid
> > stuff in through the legacy/compat set_property ioctls.
> 
> Not if you use drm_atomic_helper_plane_set_property().

Oh right, I mixed up the callchain maze in my head again. I still feel
like putting all the validation code in one place might be a good idea.
But yeah not strictly needed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm: hdlcd: Work properly in big-endian mode

2016-12-07 Thread Robin Murphy 
On 07/12/16 16:42, Robin Murphy wrote:
> On 07/12/16 15:57, Daniel Vetter wrote:
>> On Wed, Dec 07, 2016 at 03:31:40PM +, Robin Murphy wrote:
>>> Under a big-endian kernel, colours on the framebuffer all come out a
>>> delightful shade of wrong, since we fail to take the reversed byte
>>> order into account. Fortunately, the HDLCD has a control bit to make it
>>> automatically byteswap big-endian data; let's use it as appropriate.
>>>
>>> Signed-off-by: Robin Murphy 
>>
>> fourcc codes (and the drm fourcc codes) are supposed to be little-endian.
>> All of them. So either we fix up the drivers and userspace to set that
>> flag correctly (which would mean hdlcd should expose twice as many
>> formats, each one with the little and big endian mode).
> 
> AFAICS, SIMPLEFB_FORMATS *is* supposed to be explicitly little-endian
> modes. I see that DRM_FORMAT_BIG_ENDIAN exists, but nothing in-tree ever
> sets it :/
> 
> My vague (and probably wrong) assumption was that the HDLCD is still
> expecting little-endian data, but the the CPU is writing framebuffer
> data as host-endian words, hence what the HDLCD thinks is xRGB is
> actually RGBx under a big-endian kernel - It's certainly consistent
> between kernel (fbcon) and userspace (fb-test[1]): white is yellow, blue
> is black, green is red and red is green. I don't know how to test
> "proper" DRM (I've failed to get X to work with the Arch Linux ARM
> distro I have on there at the moment).
> 
> Once again I'm somewhat out of my depth here - I just found a thing that
> seemed appropriate and visibly resolved the immediate problem :)
> By comparison, the same use-cases (fbcon and fb-test) under the same
> big-endian kernel do *not* show the same problem with nouveau driving a
> PCIe 7600GT card, which led me to believe it was HDLCD-specific.

Off the back of that, upon closer inspection, nv_crtc_commit() would
appear to already be doing very much the equivalent thing to what I'm
doing in this patch, so now I have no idea whether this is right or
everything's wrong.

Robin.

> [1]:https://github.com/prpplague/fb-test-app
> 
>> Or we nuke the big endian flag from drm fourcc. Adding AMD folks who afaik
>> are the only other ones who ever cared about big endian in drm.
>> -Daniel
>>
>>> ---
>>>  drivers/gpu/drm/arm/hdlcd_crtc.c | 7 ++-
>>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c 
>>> b/drivers/gpu/drm/arm/hdlcd_crtc.c
>>> index 28341b32067f..eceb7bed5dd0 100644
>>> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
>>> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
>>> @@ -63,6 +63,7 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
>>> uint32_t pixel_format;
>>> struct simplefb_format *format = NULL;
>>> int i;
>>> +   u32 reg;
>>>  
>>> pixel_format = crtc->primary->state->fb->pixel_format;
>>>  
>>> @@ -76,7 +77,11 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
>>>  
>>> /* HDLCD uses 'bytes per pixel', zero means 1 byte */
>>> btpp = (format->bits_per_pixel + 7) / 8;
>>> -   hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, (btpp - 1) << 3);
>>> +   reg = (btpp - 1) << 3;
>>> +#ifdef __BIG_ENDIAN
>>> +   reg |= HDLCD_PIXEL_FMT_BIG_ENDIAN;
>>> +#endif
>>> +   hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, reg);
>>>  
>>> /*
>>>  * The format of the HDLCD_REG__SELECT register is:
>>> -- 
>>> 2.10.2.dirty
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

[Mesa-dev] [PATCH libdrm v2 5/5] xf86drm: implement an OpenBSD specific drmGetDevice2

2016-12-07 Thread Emil Velikov 
On 6 December 2016 at 05:12, Jonathan Gray  wrote:
> On Mon, Dec 05, 2016 at 05:56:40PM +, Emil Velikov wrote:
>> On 1 December 2016 at 04:18, Jonathan Gray  wrote:
>> > DRI devices on OpenBSD are not in their own directory.  They reside in
>> > /dev with a large number of statically generated /dev nodes.
>> >
>> > Avoid stat'ing all of /dev on OpenBSD by implementing this custom path.
>> >
>> > v2:
>> >- use drmGetMinorType to get node type
>> >- adapt to drmProcessPciDevice changes
>> >- verify drmParseSubsystemType type is PCI
>> >- add a comment describing why this was added
>> >
>> Thanks for the update Jonathan.
>>
>> I've pulled v2 in master,
>> Emil
>
> Thanks, going over what went in I see drmGetMinorNameForFD and
> the OpenBSD drmGetDevice2 paths need to be adjusted to have the correct
> minor for the control/render nodes.
>
> ie
>
> base = drmGetMinorBase(type);
> if (min < base)
> return error;
>
> min -= base;
>
> I'll send another patch for this.
>
> And the common code could be split into a shared function?
>
I don't have a strong preference either way, bth.

> drmGetDeviceNameFromFd2 would do the same thing as
> drmGetDeviceNameFromFd on OpenBSD as far as I can tell so that could be
> another shared function instead of the current "missing implementation"
> warning.  Or should drmGetDeviceNameFromFd purposefully not handle
> render/control nodes?
drmGetDeviceNameFromFd has historically handled only card nodes, so
I'd keep that as-is.
The "2" should handle any node imaginable.

Please, spin the patches when you can and give the OpenBSD
implementations a test. I'd like to get those in for the next release
- in the next week or so. This way we can use the less annoying
drmGetDevice[s]2 in Mesa :-)

Thanks
Emil

[PATCH] drm: hdlcd: Work properly in big-endian mode

2016-12-07 Thread Robin Murphy 
On 07/12/16 15:57, Daniel Vetter wrote:
> On Wed, Dec 07, 2016 at 03:31:40PM +, Robin Murphy wrote:
>> Under a big-endian kernel, colours on the framebuffer all come out a
>> delightful shade of wrong, since we fail to take the reversed byte
>> order into account. Fortunately, the HDLCD has a control bit to make it
>> automatically byteswap big-endian data; let's use it as appropriate.
>>
>> Signed-off-by: Robin Murphy 
> 
> fourcc codes (and the drm fourcc codes) are supposed to be little-endian.
> All of them. So either we fix up the drivers and userspace to set that
> flag correctly (which would mean hdlcd should expose twice as many
> formats, each one with the little and big endian mode).

AFAICS, SIMPLEFB_FORMATS *is* supposed to be explicitly little-endian
modes. I see that DRM_FORMAT_BIG_ENDIAN exists, but nothing in-tree ever
sets it :/

My vague (and probably wrong) assumption was that the HDLCD is still
expecting little-endian data, but the the CPU is writing framebuffer
data as host-endian words, hence what the HDLCD thinks is xRGB is
actually RGBx under a big-endian kernel - It's certainly consistent
between kernel (fbcon) and userspace (fb-test[1]): white is yellow, blue
is black, green is red and red is green. I don't know how to test
"proper" DRM (I've failed to get X to work with the Arch Linux ARM
distro I have on there at the moment).

Once again I'm somewhat out of my depth here - I just found a thing that
seemed appropriate and visibly resolved the immediate problem :)
By comparison, the same use-cases (fbcon and fb-test) under the same
big-endian kernel do *not* show the same problem with nouveau driving a
PCIe 7600GT card, which led me to believe it was HDLCD-specific.

Robin.

[1]:https://github.com/prpplague/fb-test-app

> Or we nuke the big endian flag from drm fourcc. Adding AMD folks who afaik
> are the only other ones who ever cared about big endian in drm.
> -Daniel
> 
>> ---
>>  drivers/gpu/drm/arm/hdlcd_crtc.c | 7 ++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c 
>> b/drivers/gpu/drm/arm/hdlcd_crtc.c
>> index 28341b32067f..eceb7bed5dd0 100644
>> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
>> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
>> @@ -63,6 +63,7 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
>>  uint32_t pixel_format;
>>  struct simplefb_format *format = NULL;
>>  int i;
>> +u32 reg;
>>  
>>  pixel_format = crtc->primary->state->fb->pixel_format;
>>  
>> @@ -76,7 +77,11 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
>>  
>>  /* HDLCD uses 'bytes per pixel', zero means 1 byte */
>>  btpp = (format->bits_per_pixel + 7) / 8;
>> -hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, (btpp - 1) << 3);
>> +reg = (btpp - 1) << 3;
>> +#ifdef __BIG_ENDIAN
>> +reg |= HDLCD_PIXEL_FMT_BIG_ENDIAN;
>> +#endif
>> +hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, reg);
>>  
>>  /*
>>   * The format of the HDLCD_REG__SELECT register is:
>> -- 
>> 2.10.2.dirty
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH v4 2/4] fbmem: add a default get_fb_unmapped_area function

2016-12-07 Thread Laurent Pinchart 
Hi Benjamin,

Thank you for the patch.

On Wednesday 07 Dec 2016 11:06:49 Benjamin Gaignard wrote:
> Allow generic frame-buffer to provide a default
> get_fb_unmapped_area function if specific devices need it.
> 
> Usually this function is defined in architecture directories but
> define it here may limit code duplication especially for all ARM
> platforms without MMU.

I still would like to see an explanation why an architecture-specific version 
is sometimes needed, and why this implementation is a reasonable default. 
Furthermore, it looks very similar to the blackfin implementation, so if you 
can't unify the two I'd like to know why.

> version 4:
> - introdude a configuration flag to be independent of architecture
> 
> Signed-off-by: Benjamin Gaignard 
> ---
>  drivers/video/fbdev/Kconfig  |  8 
>  drivers/video/fbdev/core/fbmem.c | 15 +++
>  2 files changed, 23 insertions(+)
> 
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 5d3b0db..922e4ea 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -138,6 +138,14 @@ config FB_SYS_IMAGEBLIT
> blitting. This is used by drivers that don't provide their own
> (accelerated) version and the framebuffer is in system RAM.
> 
> +config FB_PROVIDE_GET_FB_UNMAPPED_AREA
> + bool
> + depends on FB
> + default n
> + ---help---
> +   Allow generic frame-buffer to provide get_fb_unmapped_area
> +   function.
> +
>  menuconfig FB_FOREIGN_ENDIAN
>   bool "Framebuffer foreign endianness support"
>   depends on FB
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c index 76c1ad9..22321a2 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1492,6 +1492,21 @@ static long fb_compat_ioctl(struct file *file,
> unsigned int cmd, return 0;
>  }
> 
> +#ifdef CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA
> +unsigned long get_fb_unmapped_area(struct file *filp,
> +unsigned long addr, unsigned long len,
> +unsigned long pgoff, unsigned long flags)
> +{
> + struct fb_info * const info = filp->private_data;
> + unsigned long fb_size = PAGE_ALIGN(info->fix.smem_len);
> +
> + if (pgoff > fb_size || len > fb_size - pgoff)
> + return -EINVAL;
> +
> + return (unsigned long)info->screen_base + pgoff;
> +}
> +#endif
> +
>  static const struct file_operations fb_fops = {
>   .owner =THIS_MODULE,
>   .read = fb_read,

-- 
Regards,

Laurent Pinchart

[PATCH v4 3/4] drm: compile drm_vm.c only when needed

2016-12-07 Thread Laurent Pinchart 
Hi Benjamin,

Thank you for the patch.

On Wednesday 07 Dec 2016 11:06:50 Benjamin Gaignard wrote:
> drm_vm.c functions are only need for DRM_LEGACY and DRM_NOUVEAU.
> Use a new DRM_VM to define when drm_vm.c in needed.
> 
> stub drm_legacy_vma_flush() to avoid compilation issues
> 
> version 4:
> - a "config DRM_VM" in Kconfig
> 
> Signed-off-by: Benjamin Gaignard 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/Kconfig | 5 +
>  drivers/gpu/drm/Makefile| 3 ++-
>  drivers/gpu/drm/drm_legacy.h| 7 +++
>  drivers/gpu/drm/nouveau/Kconfig | 1 +
>  4 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 8d9cf73..83ac815 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -121,6 +121,10 @@ config DRM_KMS_CMA_HELPER
>   help
> Choose this if you need the KMS CMA helper functions
> 
> +config DRM_VM
> + bool
> + depends on DRM
> +
>  source "drivers/gpu/drm/i2c/Kconfig"
> 
>  source "drivers/gpu/drm/arm/Kconfig"
> @@ -246,6 +250,7 @@ source "drivers/gpu/drm/zte/Kconfig"
>  menuconfig DRM_LEGACY
>   bool "Enable legacy drivers (DANGEROUS)"
>   depends on DRM
> + select DRM_VM
>   help
> Enable legacy DRI1 drivers. Those drivers expose unsafe and 
dangerous
> APIs to user-space, which can be used to circumvent access
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index e10e935..5b73b16 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -5,7 +5,7 @@
>  drm-y   :=   drm_auth.o drm_bufs.o drm_cache.o \
>   drm_context.o drm_dma.o \
>   drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
> - drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
> + drm_lock.o drm_memory.o drm_drv.o \
>   drm_scatter.o drm_pci.o \
>   drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
>   drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
> @@ -18,6 +18,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
>   drm_plane.o drm_color_mgmt.o drm_print.o \
>   drm_dumb_buffers.o drm_mode_config.o
> 
> +drm-$(CONFIG_DRM_VM) += drm_vm.o
>  drm-$(CONFIG_COMPAT) += drm_ioc32.o
>  drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
>  drm-$(CONFIG_PCI) += ati_pcigart.o
> diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
> index c6f422e..e4bb5ad 100644
> --- a/drivers/gpu/drm/drm_legacy.h
> +++ b/drivers/gpu/drm/drm_legacy.h
> @@ -74,7 +74,14 @@ int drm_legacy_getmap_ioctl(struct drm_device *dev, void
> *data, int drm_legacy_mapbufs(struct drm_device *d, void *v, struct
> drm_file *f); int drm_legacy_dma_ioctl(struct drm_device *d, void *v,
> struct drm_file *f);
> 
> +#ifdef CONFIG_DRM_VM
>  void drm_legacy_vma_flush(struct drm_device *d);
> +#else
> +static inline void drm_legacy_vma_flush(struct drm_device *d)
> +{
> + /* do nothing */
> +}
> +#endif
> 
>  /*
>   * AGP Support
> diff --git a/drivers/gpu/drm/nouveau/Kconfig
> b/drivers/gpu/drm/nouveau/Kconfig index 2922a82..0f2f0af 100644
> --- a/drivers/gpu/drm/nouveau/Kconfig
> +++ b/drivers/gpu/drm/nouveau/Kconfig
> @@ -16,6 +16,7 @@ config DRM_NOUVEAU
>   select INPUT if ACPI && X86
>   select THERMAL if ACPI && X86
>   select ACPI_VIDEO if ACPI && X86
> + select DRM_VM
>   help
> Choose this option for open-source NVIDIA support.

-- 
Regards,

Laurent Pinchart

[PATCH v4 4/4] drm: allow to use mmuless SoC

2016-12-07 Thread Laurent Pinchart 
Hi Benjamin,

Thank you for the patch.

On Wednesday 07 Dec 2016 11:06:51 Benjamin Gaignard wrote:
> Some SoC without MMU have display driver where a drm/kms driver
> could be implemented.
> 
> Before doing such kind of thing drm/kms must allow to use mmuless devices.
> This patch propose to remove MMU configuration flag and add a cma helper
> function to help implementing mmuless display driver
> 
> version 4:
> - add documentation about drm_gem_cma_get_unmapped_area()
> - stub it MMU case
> 
> Signed-off-by: Benjamin Gaignard 
> ---
>  Documentation/gpu/drm-mm.rst | 11 ++
>  drivers/gpu/drm/Kconfig  |  4 +--
>  drivers/gpu/drm/drm_gem_cma_helper.c | 69 +
>  include/drm/drm_gem_cma_helper.h | 17 +
>  4 files changed, 99 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index bca8085..6e7efab 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -303,6 +303,17 @@ created.
>  Drivers that want to map the GEM object upfront instead of handling page
>  faults can implement their own mmap file operation handler.
> 
> +For platforms without MMU GEM care provides a helper method

s/GEM care/the GEM core/

> +:c:func:`drm_gem_cma_get_unmapped_area`. The mmap() routines will call
> +this to get a proposed address for the mapping.
> +
> +To use :c:func:`drm_gem_cma_get_unmapped_area`, drivers must fill the
> +struct :c:type:`struct file_operations ` get_unmapped_area
> +field with a pointer on :c:func:`drm_gem_cma_get_unmapped_area`.
> +
> +More detailed information about get_unmapped_area can be found in
> +Documentation/nommu-mmap.txt
> +
>  Memory Coherency
>  
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 83ac815..0eae4ad 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -6,7 +6,7 @@
>  #
>  menuconfig DRM
>   tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI 
support)"
> - depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU && HAS_DMA
> + depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
>   select HDMI
>   select FB_CMDLINE
>   select I2C
> @@ -98,7 +98,7 @@ config DRM_LOAD_EDID_FIRMWARE
> 
>  config DRM_TTM
>   tristate
> - depends on DRM
> + depends on DRM && MMU
>   help
> GPU memory management subsystem for devices with multiple
> GPU memory types. Will be enabled automatically if a device driver
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/drm/drm_gem_cma_helper.c index 1d6c335..01016b1 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -358,6 +358,75 @@ int drm_gem_cma_mmap(struct file *filp, struct
> vm_area_struct *vma) }
>  EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);
> 
> +#ifndef CONFIG_MMU
> +/**
> + * drm_gem_cma_get_unmapped_area - propose address for mapping in noMMU
> cases
> + * @filp: file object
> + * @addr: memory address
> + * @len: buffer size
> + * @pgoff: page offset
> + * @flags: memory flags
> + *
> + * This function is used in noMMU platforms to propose address mapping
> + * for a given buffer.

I would add

"It's intended to be used as a direct handler for the :c:type:`struct 
file_operations ` .get_unmapped_area() operation."

Apart from that,

Reviewed-by: Laurent Pinchart 

> + * Returns:
> + * mapping address on success or a negative error code on failure
> + */
> +unsigned long drm_gem_cma_get_unmapped_area(struct file *filp,
> + unsigned long addr,
> + unsigned long len,
> + unsigned long pgoff,
> + unsigned long flags)
> +{
> + struct drm_gem_cma_object *cma_obj;
> + struct drm_gem_object *obj = NULL;
> + struct drm_file *priv = filp->private_data;
> + struct drm_device *dev = priv->minor->dev;
> + struct drm_vma_offset_node *node;
> +
> + if (drm_device_is_unplugged(dev))
> + return -ENODEV;
> +
> + drm_vma_offset_lock_lookup(dev->vma_offset_manager);
> + node = drm_vma_offset_exact_lookup_locked(dev->vma_offset_manager,
> +   pgoff,
> +   len >> PAGE_SHIFT);
> + if (likely(node)) {
> + obj = container_of(node, struct drm_gem_object, vma_node);
> + /*
> +  * When the object is being freed, after it hits 0-refcnt it
> +  * proceeds to tear down the object. In the process it will
> +  * attempt to remove the VMA offset and so acquire this
> +  * mgr->vm_lock.  Therefore if we find an object with a 0-
refcnt
> +  * that matches our range, we know it is in the process of 
being
> +  * destroyed and will be freed as soon a

[PATCH v4 2/4] fbmem: add a default get_fb_unmapped_area function

2016-12-07 Thread Benjamin Gaignard 
Hi Thomas,

in commit 59bd00c8 (Blackfin: fix framebuffer mmap bug for nommu) you
have introduce
get_fb_unmapped_area() for blackfin architecture.

I'm proposing a patch to have a default function in fbmem which
slightly does the same.

Do you think is new function could also fit with blackfin architecture needs ?
or does this architecture have specific requirements ?

Regards,
Benjamin

2016-12-07 16:19 GMT+01:00 Laurent Pinchart :
> Hi Benjamin,
>
> On Wednesday 07 Dec 2016 15:57:49 Benjamin Gaignard wrote:
>> 2016-12-07 15:35 GMT+01:00 Laurent Pinchart:
>> > On Wednesday 07 Dec 2016 11:06:49 Benjamin Gaignard wrote:
>> >> Allow generic frame-buffer to provide a default
>> >> get_fb_unmapped_area function if specific devices need it.
>> >>
>> >> Usually this function is defined in architecture directories but
>> >> define it here may limit code duplication especially for all ARM
>> >> platforms without MMU.
>> >
>> > I still would like to see an explanation why an architecture-specific
>> > version is sometimes needed, and why this implementation is a reasonable
>> > default. Furthermore, it looks very similar to the blackfin
>> > implementation, so if you can't unify the two I'd like to know why.
>>
>> Obviously I don't know all the legacy behind this function but it is
>> definitively link to architectures memory mapping strategies in no MMU
>> cases.
>>
>> I think this function is a reasonable default when the architecture is
>> doing a direct mapping (no translation) of the memory like it is done in
>> ARM.
>>
>> Unlike what I propose blackfin implementation doesn't do any check on pgoff
>> and length and always return fb base address even is an offset has been
>> requested. I don't know if it is on purpose or just because nobody has
>> never try to mmap blackfin framebuffer with an offset...
>
> And that's exactly what I'd like you to try and find out :-) git blame and
> contacting the original authors of that code could be a first step.
>
>> >> version 4:
>> >> - introdude a configuration flag to be independent of architecture
>> >>
>> >> Signed-off-by: Benjamin Gaignard 
>> >> ---
>> >>
>> >>  drivers/video/fbdev/Kconfig  |  8 
>> >>  drivers/video/fbdev/core/fbmem.c | 15 +++
>> >>  2 files changed, 23 insertions(+)
>> >>
>> >> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>> >> index 5d3b0db..922e4ea 100644
>> >> --- a/drivers/video/fbdev/Kconfig
>> >> +++ b/drivers/video/fbdev/Kconfig
>> >> @@ -138,6 +138,14 @@ config FB_SYS_IMAGEBLIT
>> >>
>> >> blitting. This is used by drivers that don't provide their own
>> >> (accelerated) version and the framebuffer is in system RAM.
>> >>
>> >> +config FB_PROVIDE_GET_FB_UNMAPPED_AREA
>> >> + bool
>> >> + depends on FB
>> >> + default n
>> >> + ---help---
>> >> +   Allow generic frame-buffer to provide get_fb_unmapped_area
>> >> +   function.
>> >> +
>> >>
>> >>  menuconfig FB_FOREIGN_ENDIAN
>> >>
>> >>   bool "Framebuffer foreign endianness support"
>> >>   depends on FB
>> >>
>> >> diff --git a/drivers/video/fbdev/core/fbmem.c
>> >> b/drivers/video/fbdev/core/fbmem.c index 76c1ad9..22321a2 100644
>> >> --- a/drivers/video/fbdev/core/fbmem.c
>> >> +++ b/drivers/video/fbdev/core/fbmem.c
>> >> @@ -1492,6 +1492,21 @@ static long fb_compat_ioctl(struct file *file,
>> >> unsigned int cmd, return 0;
>> >>
>> >>  }
>> >>
>> >> +#ifdef CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA
>> >> +unsigned long get_fb_unmapped_area(struct file *filp,
>> >> +unsigned long addr, unsigned long len,
>> >> +unsigned long pgoff, unsigned long
>> >> flags)
>> >> +{
>> >> + struct fb_info * const info = filp->private_data;
>> >> + unsigned long fb_size = PAGE_ALIGN(info->fix.smem_len);
>> >> +
>> >> + if (pgoff > fb_size || len > fb_size - pgoff)
>> >> + return -EINVAL;
>> >> +
>> >> + return (unsigned long)info->screen_base + pgoff;
>> >> +}
>> >> +#endif
>> >> +
>> >>
>> >>  static const struct file_operations fb_fops = {
>> >>
>> >>   .owner =THIS_MODULE,
>> >>   .read = fb_read,
>> >
>> > --
>> > Regards,
>> >
>> > Laurent Pinchart
>
> --
> Regards,
>
> Laurent Pinchart
>

[PATCH] drm/mxsfb: fix pixel clock polarity

2016-12-07 Thread Stefan Agner 
The DRM subsystem specifies the pixel clock polarity from a
controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means
the controller drives the data on pixel clocks falling edge.
That is the controllers DOTCLK_POL=0 (Default is data launched
at negative edge).

Also change the data enable logic to be high active by default
and only change if explicitly requested via bus_flags. With
that defaults are:
- Data enable: high active
- Pixel clock polarity: controller drives data on negative edge

Signed-off-by: Stefan Agner 
---
Hi Marek,

I discovered this while testing on a i.MX 7 eLCDIF IP. Particularly the
non-standard DE polarity was causing issues. I was using a EDT display
which is part of simple panel driver since a while now and does not
specify any bus_flags currently... Of course I could (and probably should)
add the proper bus_flags there too, but there are several displays
which do not specify any polarity and likely rely on sensible driver
standards (which is afact high active for the DE signal).

--
Stefan

 drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c 
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 0818903..4bcc8a3 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -168,9 +168,16 @@ static void mxsfb_crtc_mode_set_nofb(struct 
mxsfb_drm_private *mxsfb)
vdctrl0 |= VDCTRL0_HSYNC_ACT_HIGH;
if (m->flags & DRM_MODE_FLAG_PVSYNC)
vdctrl0 |= VDCTRL0_VSYNC_ACT_HIGH;
-   if (bus_flags & DRM_BUS_FLAG_DE_HIGH)
+   /* Data Enable should be high active by default */
+   if (!(bus_flags & DRM_BUS_FLAG_DE_LOW))
vdctrl0 |= VDCTRL0_ENABLE_ACT_HIGH;
-   if (bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
+   /*
+* Note: DRM_BUS_FLAG_PIXDATA defines are controller centric,
+* controllers VDCTRL0_DOTCLK is display centric.
+* Drive on positive edige  -> display samples on falling edge
+* DRM_BUS_FLAG_PIXDATA_POSEDGE -> VDCTRL0_DOTCLK_ACT_FALLING
+*/
+   if (bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
vdctrl0 |= VDCTRL0_DOTCLK_ACT_FALLING;

writel(vdctrl0, mxsfb->base + LCDC_VDCTRL0);
-- 
2.10.2

[PATCH v5 3/4] ARM: dts: da850-lcdk: add the vga-bridge node

2016-12-07 Thread Laurent Pinchart 
Hi Bartosz,

Thank you for the patch.

On Wednesday 07 Dec 2016 11:42:44 Bartosz Golaszewski wrote:
> Add the vga-bridge node to the board DT together with corresponding
> ports and vga connector. This allows to retrieve the edid info from
> the display automatically.
> 
> Signed-off-by: Bartosz Golaszewski 
> ---
>  arch/arm/boot/dts/da850-lcdk.dts | 67 
>  1 file changed, 67 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts
> b/arch/arm/boot/dts/da850-lcdk.dts index afcb482..39602eb 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -51,6 +51,51 @@
>   system-clock-frequency = <24576000>;
>   };
>   };
> +
> + vga-bridge {
> + compatible = "ti,ths8135";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + vga_bridge_in: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&lcdc_out_vga>;
> + };
> + };
> +
> + port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + vga_bridge_out: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&vga_con_in>;
> + };
> + };
> + };
> + };
> +
> + vga {
> + compatible = "vga-connector";
> +
> + ddc-i2c-bus = <&i2c0>;
> +
> + port {
> + vga_con_in: endpoint {
> + remote-endpoint = <&vga_bridge_out>;
> + };
> + };
> + };
>  };
> 
>  &pmx_core {
> @@ -236,3 +281,25 @@
>  &memctrl {
>   status = "okay";
>  };
> +
> +&lcdc {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_pins>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + lcdc_out: port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + lcdc_out_vga: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&vga_bridge_in>;
> + };
> + };

Just to make sure you're aware, when there's a single endpoint you can 
simplify the DT by omitting the endpoint number. This would become

lcdc_out: port at 1 {
reg = <1>;

lcdc_out_vga: endpoint {
remote-endpoint = <&vga_bridge_in>;
};
};

It's entirely up to you, both get my

Reviewed-by: Laurent Pinchart 

> + };
> +};

-- 
Regards,

Laurent Pinchart

[PATCH v5 2/4] drm: bridge: add support for TI ths8135

2016-12-07 Thread Laurent Pinchart 
Hi Bartosz,

Thank you for the patch.

On Wednesday 07 Dec 2016 11:45:11 Bartosz Golaszewski wrote:
> 2016-12-07 11:42 GMT+01:00 Bartosz Golaszewski :
> > THS8135 is a configurable video DAC. Add DT bindings for this chip and
> > use the dumb-vga-dac driver for now as no configuration is required to
> > make it work.
> > 
> > Signed-off-by: Bartosz Golaszewski 
> > ---
> > 
> >  .../bindings/display/bridge/ti,ths8135.txt | 52 +
> >  drivers/gpu/drm/bridge/dumb-vga-dac.c  |  1 +

You might be asked by DT maintainers to split this in two, but regardless of 
whether it's one patch or two, you can add my

Reviewed-by: Laurent Pinchart 

> >  2 files changed, 53 insertions(+)
> >  create mode 100644
> >  Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt> 
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> > b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt new
> > file mode 100644
> > index 000..23cd8ee
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> > @@ -0,0 +1,52 @@
> > +THS8135 Video DAC
> > +-
> > +
> > +This is the binding for Texas Instruments THS8135 Video DAC bridge.
> > +
> > +Required properties:
> > +
> > +- compatible: Must be "ti,ths8135"
> > +
> > +Required nodes:
> > +
> > +This device has two video ports. Their connections are modelled using the
> > OF +graph bindings specified in
> > Documentation/devicetree/bindings/graph.txt. +
> > +- Video port 0 for RGB input
> > +- Video port 1 for VGA output
> > +
> > +Example
> > +---
> > +
> > +vga-bridge {
> > +   compatible = "ti,ths8135";
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   port at 0 {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   reg = <0>;
> > +
> > +   vga_bridge_in: endpoint at 0 {
> > +   reg = <0>;
> > +   remote-endpoint = <&lcdc_out_vga>;
> > +   };
> > +   };
> > +
> > +   port at 1 {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   reg = <1>;
> > +
> > +   vga_bridge_out: endpoint at 0 {
> > +   reg = <0>;
> > +   remote-endpoint = <&vga_con_in>;
> > +   };
> > +   };
> > +   };
> > +};
> > diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> > b/drivers/gpu/drm/bridge/dumb-vga-dac.c index afec232..498fa75 100644
> > --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> > +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> > @@ -204,6 +204,7 @@ static int dumb_vga_remove(struct platform_device
> > *pdev)> 
> >  static const struct of_device_id dumb_vga_match[] = {
> >  
> > { .compatible = "dumb-vga-dac" },
> > 
> > +   { .compatible = "ti,ths8135" },
> > 
> > {},
> >  
> >  };
> >  MODULE_DEVICE_TABLE(of, dumb_vga_match);
> > 
> > --
> > 2.9.3
> 
> + Maxime
> 
> Sorry, I forgot to include your e-mail.
> 
> Bartosz

-- 
Regards,

Laurent Pinchart

[bug report] drm/bridge: Add ti-tfp410 DVI transmitter driver

2016-12-07 Thread Jyri Sarha 
On 12/06/16 15:28, Dan Carpenter wrote:
> Hello Jyri Sarha,
> 
> The patch dc55ac3b52e6: "drm/bridge: Add ti-tfp410 DVI transmitter
> driver" from Oct 31, 2016, leads to the following static checker
> warning:
> 
>   drivers/gpu/drm/bridge/ti-tfp410.c:141 tfp410_get_connector_ddc()
>   warn: missing error code here? 'of_graph_get_remote_port_parent()' 
> failed.
> 
> drivers/gpu/drm/bridge/ti-tfp410.c
>128  static int tfp410_get_connector_ddc(struct tfp410 *dvi)
>129  {
>130  struct device_node *ep = NULL, *connector_node = NULL;
>131  struct device_node *ddc_phandle = NULL;
>132  int ret = 0;
>133  
>134  /* port at 1 is the connector node */
>135  ep = of_graph_get_endpoint_by_regs(dvi->dev->of_node, 1, -1);
>136  if (!ep)
>137  goto fail;
> ^
>138  
>139  connector_node = of_graph_get_remote_port_parent(ep);
>140  if (!connector_node)
>141  goto fail;
> ^
> 
> 
>142  
>143  ddc_phandle = of_parse_phandle(connector_node, "ddc-i2c-bus", 
> 0);
>144  if (!ddc_phandle)
>145  goto fail;
> ^
> 
> All these goto fails feel like we should be returning an error code.
> Otherwise we could change the name to "goto success;"?
> 

The label text could be seen misleading, but code runs as I intended it.
If we can not extract the ddc i2c controller from the binding, we simply
continue without it. The only exception is if we find the phandle but
not the i2c controller, yet.

This implementation is a hack in the first place. The code will be
removed when DRM has a proper generic connector support.

Best regards,
Jyri

>146  
>147  dvi->ddc = of_get_i2c_adapter_by_node(ddc_phandle);
>148  if (dvi->ddc)
>149  dev_info(dvi->dev, "Connector's ddc i2c bus found\n");
>150  else
>151  ret = -EPROBE_DEFER;
>152  
>153  fail:
>154  of_node_put(ep);
>155  of_node_put(connector_node);
>156  of_node_put(ddc_phandle);
>157  return ret;
>158  }
> 
> regards,
> dan carpenter
>

[PATCH v4 4/4] drm: allow to use mmuless SoC

2016-12-07 Thread Benjamin Gaignard 
Some SoC without MMU have display driver where a drm/kms driver
could be implemented.

Before doing such kind of thing drm/kms must allow to use mmuless devices.
This patch propose to remove MMU configuration flag and add a cma helper
function to help implementing mmuless display driver

version 4:
- add documentation about drm_gem_cma_get_unmapped_area()
- stub it MMU case

Signed-off-by: Benjamin Gaignard 
---
 Documentation/gpu/drm-mm.rst | 11 ++
 drivers/gpu/drm/Kconfig  |  4 +-
 drivers/gpu/drm/drm_gem_cma_helper.c | 71 
 include/drm/drm_gem_cma_helper.h | 17 +
 4 files changed, 101 insertions(+), 2 deletions(-)

diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index bca8085..9d4aa11 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -303,6 +303,17 @@ created.
 Drivers that want to map the GEM object upfront instead of handling page
 faults can implement their own mmap file operation handler.

+For platforms without MMU the GEM core provides a helper method
+:c:func:`drm_gem_cma_get_unmapped_area`. The mmap() routines will call
+this to get a proposed address for the mapping.
+
+To use :c:func:`drm_gem_cma_get_unmapped_area`, drivers must fill the
+struct :c:type:`struct file_operations ` get_unmapped_area
+field with a pointer on :c:func:`drm_gem_cma_get_unmapped_area`.
+
+More detailed information about get_unmapped_area can be found in
+Documentation/nommu-mmap.txt
+
 Memory Coherency
 

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 83ac815..0eae4ad 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -6,7 +6,7 @@
 #
 menuconfig DRM
tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI 
support)"
-   depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU && HAS_DMA
+   depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
select HDMI
select FB_CMDLINE
select I2C
@@ -98,7 +98,7 @@ config DRM_LOAD_EDID_FIRMWARE

 config DRM_TTM
tristate
-   depends on DRM
+   depends on DRM && MMU
help
  GPU memory management subsystem for devices with multiple
  GPU memory types. Will be enabled automatically if a device driver
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 1d6c335..19908bb 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -358,6 +358,77 @@ int drm_gem_cma_mmap(struct file *filp, struct 
vm_area_struct *vma)
 }
 EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);

+#ifndef CONFIG_MMU
+/**
+ * drm_gem_cma_get_unmapped_area - propose address for mapping in noMMU cases
+ * @filp: file object
+ * @addr: memory address
+ * @len: buffer size
+ * @pgoff: page offset
+ * @flags: memory flags
+ *
+ * This function is used in noMMU platforms to propose address mapping
+ * for a given buffer.
+ * It's intended to be used as a direct handler for the struct &file_operations
+ * .get_unmapped_area() operation.
+ *
+ * Returns:
+ * mapping address on success or a negative error code on failure.
+ */
+unsigned long drm_gem_cma_get_unmapped_area(struct file *filp,
+   unsigned long addr,
+   unsigned long len,
+   unsigned long pgoff,
+   unsigned long flags)
+{
+   struct drm_gem_cma_object *cma_obj;
+   struct drm_gem_object *obj = NULL;
+   struct drm_file *priv = filp->private_data;
+   struct drm_device *dev = priv->minor->dev;
+   struct drm_vma_offset_node *node;
+
+   if (drm_device_is_unplugged(dev))
+   return -ENODEV;
+
+   drm_vma_offset_lock_lookup(dev->vma_offset_manager);
+   node = drm_vma_offset_exact_lookup_locked(dev->vma_offset_manager,
+ pgoff,
+ len >> PAGE_SHIFT);
+   if (likely(node)) {
+   obj = container_of(node, struct drm_gem_object, vma_node);
+   /*
+* When the object is being freed, after it hits 0-refcnt it
+* proceeds to tear down the object. In the process it will
+* attempt to remove the VMA offset and so acquire this
+* mgr->vm_lock.  Therefore if we find an object with a 0-refcnt
+* that matches our range, we know it is in the process of being
+* destroyed and will be freed as soon as we release the lock -
+* so we have to check for the 0-refcnted object and treat it as
+* invalid.
+*/
+   if (!kref_get_unless_zero(&obj->refcount))
+   obj = NULL;
+   }
+
+   drm_vma_offset_unlock_lookup(dev->vma_offset_manager);
+
+   if (!o

[PATCH v4 4/4] drm: allow to use mmuless SoC

2016-12-07 Thread Eric Engestrom 
On Wednesday, 2016-12-07 16:19:52 +0100, Benjamin Gaignard wrote:
> Some SoC without MMU have display driver where a drm/kms driver
> could be implemented.
> 
> Before doing such kind of thing drm/kms must allow to use mmuless devices.
> This patch propose to remove MMU configuration flag and add a cma helper
> function to help implementing mmuless display driver
> 
> version 4:
> - add documentation about drm_gem_cma_get_unmapped_area()
> - stub it MMU case
> 
> Signed-off-by: Benjamin Gaignard 
> ---
>  Documentation/gpu/drm-mm.rst | 11 ++
>  drivers/gpu/drm/Kconfig  |  4 +-
>  drivers/gpu/drm/drm_gem_cma_helper.c | 71 
> 
>  include/drm/drm_gem_cma_helper.h | 17 +
>  4 files changed, 101 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index bca8085..9d4aa11 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -303,6 +303,17 @@ created.
>  Drivers that want to map the GEM object upfront instead of handling page
>  faults can implement their own mmap file operation handler.
>  
> +For platforms without MMU the GEM core provides a helper method
> +:c:func:`drm_gem_cma_get_unmapped_area`. The mmap() routines will call
> +this to get a proposed address for the mapping.
> +
> +To use :c:func:`drm_gem_cma_get_unmapped_area`, drivers must fill the
> +struct :c:type:`struct file_operations ` get_unmapped_area
> +field with a pointer on :c:func:`drm_gem_cma_get_unmapped_area`.
> +
> +More detailed information about get_unmapped_area can be found in
> +Documentation/nommu-mmap.txt
> +
>  Memory Coherency
>  
>  
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 83ac815..0eae4ad 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -6,7 +6,7 @@
>  #
>  menuconfig DRM
>   tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI 
> support)"
> - depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU && HAS_DMA
> + depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
>   select HDMI
>   select FB_CMDLINE
>   select I2C
> @@ -98,7 +98,7 @@ config DRM_LOAD_EDID_FIRMWARE
>  
>  config DRM_TTM
>   tristate
> - depends on DRM
> + depends on DRM && MMU
>   help
> GPU memory management subsystem for devices with multiple
> GPU memory types. Will be enabled automatically if a device driver
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 1d6c335..19908bb 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -358,6 +358,77 @@ int drm_gem_cma_mmap(struct file *filp, struct 
> vm_area_struct *vma)
>  }
>  EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);
>  
> +#ifndef CONFIG_MMU
> +/**
> + * drm_gem_cma_get_unmapped_area - propose address for mapping in noMMU cases
> + * @filp: file object
> + * @addr: memory address
> + * @len: buffer size
> + * @pgoff: page offset
> + * @flags: memory flags
> + *
> + * This function is used in noMMU platforms to propose address mapping
> + * for a given buffer.
> + * It's intended to be used as a direct handler for the struct 
> &file_operations
> + * .get_unmapped_area() operation.
> + *
> + * Returns:
> + * mapping address on success or a negative error code on failure.
> + */
> +unsigned long drm_gem_cma_get_unmapped_area(struct file *filp,
> + unsigned long addr,
> + unsigned long len,
> + unsigned long pgoff,
> + unsigned long flags)
> +{
> + struct drm_gem_cma_object *cma_obj;
> + struct drm_gem_object *obj = NULL;
> + struct drm_file *priv = filp->private_data;
> + struct drm_device *dev = priv->minor->dev;
> + struct drm_vma_offset_node *node;
> +
> + if (drm_device_is_unplugged(dev))
> + return -ENODEV;
> +
> + drm_vma_offset_lock_lookup(dev->vma_offset_manager);
> + node = drm_vma_offset_exact_lookup_locked(dev->vma_offset_manager,
> +   pgoff,
> +   len >> PAGE_SHIFT);
> + if (likely(node)) {
> + obj = container_of(node, struct drm_gem_object, vma_node);
> + /*
> +  * When the object is being freed, after it hits 0-refcnt it
> +  * proceeds to tear down the object. In the process it will
> +  * attempt to remove the VMA offset and so acquire this
> +  * mgr->vm_lock.  Therefore if we find an object with a 0-refcnt
> +  * that matches our range, we know it is in the process of being
> +  * destroyed and will be freed as soon as we release the lock -
> +  * so we have to check for the 0-refcnted object and trea

[PATCH] drm/atomic: Don't reject reflect-only rotations

2016-12-07 Thread Ville Syrjälä 
On Wed, Dec 07, 2016 at 12:18:19PM +, Brian Starkey wrote:
> The check to reject combinations of multiple rotation angles is overly
> restrictive and has the side-effect of also failing any rotation value
> which consists only of reflections.
> 
> Fix this by relaxing the check to ignore values which contain no
> rotation flags.
> 
> Fixes: 6e0c7c3358d4 ("drm/atomic: Reject attempts to use multiple rotation 
> angles at once")
> Signed-off-by: Brian Starkey 
> ---
>  drivers/gpu/drm/drm_atomic.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 362e3ea..44f4030 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -846,7 +846,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
>   } else if (property == config->prop_src_h) {
>   state->src_h = val;
>   } else if (property == plane->rotation_property) {
> - if (!is_power_of_2(val & DRM_ROTATE_MASK))
> + if ((val & DRM_ROTATE_MASK) &&
> + !is_power_of_2(val & DRM_ROTATE_MASK))

NAK. You must always set one and only one rotation bit.

>   return -EINVAL;
>   state->rotation = val;
>   } else if (property == plane->zpos_property) {
> -- 
> 1.7.9.5

-- 
Ville Syrjälä
Intel OTC

[RESEND PATCH v2 4/7] drm/vc4: Add support for the VEC (Video Encoder) IP

2016-12-07 Thread Boris Brezillon 
On Mon, 5 Dec 2016 17:50:13 -0800
Florian Fainelli  wrote:

> On 12/02/2016 05:48 AM, Boris Brezillon wrote:
> > The VEC IP is a TV DAC, providing support for PAL and NTSC standards.
> > 
> > Signed-off-by: Boris Brezillon 
> > ---  
> 
> > diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
> > new file mode 100644
> > index ..2d4256fcc6f2
> > --- /dev/null
> > +++ b/drivers/gpu/drm/vc4/vc4_vec.c
> > @@ -0,0 +1,657 @@
> > +/*
> > + * Copyright (C) 2016 Broadcom Limited  
> 
> The standard copyright template post acquisition is just Broadcom, not
> Broadcom Limited, nor Broadcom corporation. Can you audit your entire
> submission and fix this up accordingly?

This is the only patch adding a copyright header.
Eric, can you fix that when applying the series or should I resend a
new version?

[PATCH] drm: hdlcd: Work properly in big-endian mode

2016-12-07 Thread liviu.du...@arm.com 
On Wed, Dec 07, 2016 at 03:31:40PM +, Robin Murphy wrote:
> Under a big-endian kernel, colours on the framebuffer all come out a
> delightful shade of wrong, 

So you are saying that wrong is only a 1 bit value?


> since we fail to take the reversed byte
> order into account. Fortunately, the HDLCD has a control bit to make it
> automatically byteswap big-endian data; let's use it as appropriate.
> 
> Signed-off-by: Robin Murphy 

Change looks good to me, but as Daniel has mentioned, we should have failed
the modesetting as the buffer we are passed should be in the wrong fourcc 
format.

Any way I can play with a big-endian filesystem that you can share?

Best regards,
Liviu

> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c 
> b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 28341b32067f..eceb7bed5dd0 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -63,6 +63,7 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
>   uint32_t pixel_format;
>   struct simplefb_format *format = NULL;
>   int i;
> + u32 reg;
>  
>   pixel_format = crtc->primary->state->fb->pixel_format;
>  
> @@ -76,7 +77,11 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
>  
>   /* HDLCD uses 'bytes per pixel', zero means 1 byte */
>   btpp = (format->bits_per_pixel + 7) / 8;
> - hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, (btpp - 1) << 3);
> + reg = (btpp - 1) << 3;
> +#ifdef __BIG_ENDIAN
> + reg |= HDLCD_PIXEL_FMT_BIG_ENDIAN;
> +#endif
> + hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, reg);
>  
>   /*
>* The format of the HDLCD_REG__SELECT register is:
> -- 
> 2.10.2.dirty
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯

[PATCH v4 2/4] fbmem: add a default get_fb_unmapped_area function

2016-12-07 Thread Benjamin Gaignard 
2016-12-07 15:35 GMT+01:00 Laurent Pinchart :
> Hi Benjamin,
>
> Thank you for the patch.
>
> On Wednesday 07 Dec 2016 11:06:49 Benjamin Gaignard wrote:
>> Allow generic frame-buffer to provide a default
>> get_fb_unmapped_area function if specific devices need it.
>>
>> Usually this function is defined in architecture directories but
>> define it here may limit code duplication especially for all ARM
>> platforms without MMU.
>
> I still would like to see an explanation why an architecture-specific version
> is sometimes needed, and why this implementation is a reasonable default.
> Furthermore, it looks very similar to the blackfin implementation, so if you
> can't unify the two I'd like to know why.

Obviously I don't know all the legacy behind this function but it is
definitively link
to architectures memory mapping strategies in no MMU cases.

I think this function is a reasonable default when the architecture is
doing a direct
mapping (no translation) of the memory like it is done in ARM.

Unlike what I propose blackfin implementation doesn't do any check on pgoff and
length and always return fb base address even is an offset has been requested.
I don't know if it is on purpose or just because nobody has never try to mmap
blackfin framebuffer with an offset...

>
>> version 4:
>> - introdude a configuration flag to be independent of architecture
>>
>> Signed-off-by: Benjamin Gaignard 
>> ---
>>  drivers/video/fbdev/Kconfig  |  8 
>>  drivers/video/fbdev/core/fbmem.c | 15 +++
>>  2 files changed, 23 insertions(+)
>>
>> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>> index 5d3b0db..922e4ea 100644
>> --- a/drivers/video/fbdev/Kconfig
>> +++ b/drivers/video/fbdev/Kconfig
>> @@ -138,6 +138,14 @@ config FB_SYS_IMAGEBLIT
>> blitting. This is used by drivers that don't provide their own
>> (accelerated) version and the framebuffer is in system RAM.
>>
>> +config FB_PROVIDE_GET_FB_UNMAPPED_AREA
>> + bool
>> + depends on FB
>> + default n
>> + ---help---
>> +   Allow generic frame-buffer to provide get_fb_unmapped_area
>> +   function.
>> +
>>  menuconfig FB_FOREIGN_ENDIAN
>>   bool "Framebuffer foreign endianness support"
>>   depends on FB
>> diff --git a/drivers/video/fbdev/core/fbmem.c
>> b/drivers/video/fbdev/core/fbmem.c index 76c1ad9..22321a2 100644
>> --- a/drivers/video/fbdev/core/fbmem.c
>> +++ b/drivers/video/fbdev/core/fbmem.c
>> @@ -1492,6 +1492,21 @@ static long fb_compat_ioctl(struct file *file,
>> unsigned int cmd, return 0;
>>  }
>>
>> +#ifdef CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA
>> +unsigned long get_fb_unmapped_area(struct file *filp,
>> +unsigned long addr, unsigned long len,
>> +unsigned long pgoff, unsigned long flags)
>> +{
>> + struct fb_info * const info = filp->private_data;
>> + unsigned long fb_size = PAGE_ALIGN(info->fix.smem_len);
>> +
>> + if (pgoff > fb_size || len > fb_size - pgoff)
>> + return -EINVAL;
>> +
>> + return (unsigned long)info->screen_base + pgoff;
>> +}
>> +#endif
>> +
>>  static const struct file_operations fb_fops = {
>>   .owner =THIS_MODULE,
>>   .read = fb_read,
>
> --
> Regards,
>
> Laurent Pinchart
>



-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

[RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel

2016-12-07 Thread Daniel Vetter 
On Wed, Dec 07, 2016 at 08:57:23AM +0800, Ayaka wrote:
> 
> 
> 從我的 iPad 傳送
> 
> > Thierry Reding  於 2016年12月6日 
> > 下午11:46 寫道：
> > 
> >> On Tue, Sep 20, 2016 at 03:02:51AM +0800, Randy Li wrote:
> >> The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
> >> supported by the simple panel driver.
> >> 
> >> Signed-off-by: Randy Li 
> >> ---
> >> .../display/panel/chunghwa,claa070wp03xg.txt   |  7 ++
> >> drivers/gpu/drm/panel/panel-simple.c   | 27 
> >> ++
> >> 2 files changed, 34 insertions(+)
> >> create mode 100644 
> >> Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
> > 
> > Applied, thanks.
> Wait, it is RFC, not pass the test.

Well 2 months of silence, it's reasonable to assume that this works for
you ... I guess you need to supply a fixup patch asap ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/atomic: Don't reject reflect-only rotations

2016-12-07 Thread Daniel Vetter 
On Wed, Dec 07, 2016 at 01:32:57PM +, Chris Wilson wrote:
> On Wed, Dec 07, 2016 at 12:18:19PM +, Brian Starkey wrote:
> > The check to reject combinations of multiple rotation angles is overly
> > restrictive and has the side-effect of also failing any rotation value
> > which consists only of reflections.
> > 
> > Fix this by relaxing the check to ignore values which contain no
> > rotation flags.
> > 
> > Fixes: 6e0c7c3358d4 ("drm/atomic: Reject attempts to use multiple rotation 
> > angles at once")
> > Signed-off-by: Brian Starkey 
> 
> >  drivers/gpu/drm/drm_atomic.c |3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 362e3ea..44f4030 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -846,7 +846,8 @@ int drm_atomic_plane_set_property(struct drm_plane 
> > *plane,
> > } else if (property == config->prop_src_h) {
> > state->src_h = val;
> > } else if (property == plane->rotation_property) {
> > -   if (!is_power_of_2(val & DRM_ROTATE_MASK))
> > +   if ((val & DRM_ROTATE_MASK) &&
> 
> If val & DRM_ROTATE_MASK is zero, val must be REFLECT_X | REFLECT_Y.

While we bikeshed this check: Validation like this should be somewhere
behind ->atomic_check, since if it's only here then you can sneak invalid
stuff in through the legacy/compat set_property ioctls.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm: Allow CAP_PRIME on !MODESET

2016-12-07 Thread Daniel Vetter 
vgem (and our igt tests using vgem) need this. I suspect etnaviv will
fare similarly.

v2. Make it build. Oops.

Fixes: d5264ed3823a ("drm: Return -ENOTSUPP when called for KMS cap with a 
non-KMS driver")
Cc: Michel Dänzer 
Cc: Alex Deucher 
Cc: Chris Wilson 
Reviewed-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_ioctl.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 0a900bd4575d..a16b6fbd1004 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -234,10 +234,15 @@ static int drm_getcap(struct drm_device *dev, void *data, 
struct drm_file *file_

req->value = 0;

-   /* Only one cap makes sense with a UMS driver: */
-   if (req->capability == DRM_CAP_TIMESTAMP_MONOTONIC) {
+   /* Only some caps make sense with UMS/render-only drivers. */
+   switch (req->capability) {
+   case DRM_CAP_TIMESTAMP_MONOTONIC:
req->value = drm_timestamp_monotonic;
return 0;
+   case DRM_CAP_PRIME:
+   req->value |= dev->driver->prime_fd_to_handle ? 
DRM_PRIME_CAP_IMPORT : 0;
+   req->value |= dev->driver->prime_handle_to_fd ? 
DRM_PRIME_CAP_EXPORT : 0;
+   return 0;
}

/* Other caps only work with KMS drivers */
@@ -258,10 +263,6 @@ static int drm_getcap(struct drm_device *dev, void *data, 
struct drm_file *file_
case DRM_CAP_DUMB_PREFER_SHADOW:
req->value = dev->mode_config.prefer_shadow;
break;
-   case DRM_CAP_PRIME:
-   req->value |= dev->driver->prime_fd_to_handle ? 
DRM_PRIME_CAP_IMPORT : 0;
-   req->value |= dev->driver->prime_handle_to_fd ? 
DRM_PRIME_CAP_EXPORT : 0;
-   break;
case DRM_CAP_ASYNC_PAGE_FLIP:
req->value = dev->mode_config.async_page_flip;
break;
-- 
2.10.2

[PATCH v4 4/4] drm: allow to use mmuless SoC

2016-12-07 Thread Daniel Vetter 
On Wed, Dec 07, 2016 at 04:32:44PM +0200, Laurent Pinchart wrote:
> Hi Benjamin,
> 
> Thank you for the patch.
> 
> On Wednesday 07 Dec 2016 11:06:51 Benjamin Gaignard wrote:
> > Some SoC without MMU have display driver where a drm/kms driver
> > could be implemented.
> > 
> > Before doing such kind of thing drm/kms must allow to use mmuless devices.
> > This patch propose to remove MMU configuration flag and add a cma helper
> > function to help implementing mmuless display driver
> > 
> > version 4:
> > - add documentation about drm_gem_cma_get_unmapped_area()
> > - stub it MMU case
> > 
> > Signed-off-by: Benjamin Gaignard 
> > ---
> >  Documentation/gpu/drm-mm.rst | 11 ++
> >  drivers/gpu/drm/Kconfig  |  4 +--
> >  drivers/gpu/drm/drm_gem_cma_helper.c | 69 +
> >  include/drm/drm_gem_cma_helper.h | 17 +
> >  4 files changed, 99 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> > index bca8085..6e7efab 100644
> > --- a/Documentation/gpu/drm-mm.rst
> > +++ b/Documentation/gpu/drm-mm.rst
> > @@ -303,6 +303,17 @@ created.
> >  Drivers that want to map the GEM object upfront instead of handling page
> >  faults can implement their own mmap file operation handler.
> > 
> > +For platforms without MMU GEM care provides a helper method
> 
> s/GEM care/the GEM core/
> 
> > +:c:func:`drm_gem_cma_get_unmapped_area`. The mmap() routines will call
> > +this to get a proposed address for the mapping.
> > +
> > +To use :c:func:`drm_gem_cma_get_unmapped_area`, drivers must fill the
> > +struct :c:type:`struct file_operations ` get_unmapped_area
> > +field with a pointer on :c:func:`drm_gem_cma_get_unmapped_area`.
> > +
> > +More detailed information about get_unmapped_area can be found in
> > +Documentation/nommu-mmap.txt
> > +
> >  Memory Coherency
> >  
> > 
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index 83ac815..0eae4ad 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -6,7 +6,7 @@
> >  #
> >  menuconfig DRM
> > tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI 
> support)"
> > -   depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU && HAS_DMA
> > +   depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
> > select HDMI
> > select FB_CMDLINE
> > select I2C
> > @@ -98,7 +98,7 @@ config DRM_LOAD_EDID_FIRMWARE
> > 
> >  config DRM_TTM
> > tristate
> > -   depends on DRM
> > +   depends on DRM && MMU
> > help
> >   GPU memory management subsystem for devices with multiple
> >   GPU memory types. Will be enabled automatically if a device driver
> > diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> > b/drivers/gpu/drm/drm_gem_cma_helper.c index 1d6c335..01016b1 100644
> > --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> > @@ -358,6 +358,75 @@ int drm_gem_cma_mmap(struct file *filp, struct
> > vm_area_struct *vma) }
> >  EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);
> > 
> > +#ifndef CONFIG_MMU
> > +/**
> > + * drm_gem_cma_get_unmapped_area - propose address for mapping in noMMU
> > cases
> > + * @filp: file object
> > + * @addr: memory address
> > + * @len: buffer size
> > + * @pgoff: page offset
> > + * @flags: memory flags
> > + *
> > + * This function is used in noMMU platforms to propose address mapping
> > + * for a given buffer.
> 
> I would add
> 
> "It's intended to be used as a direct handler for the :c:type:`struct 
> file_operations ` .get_unmapped_area() operation."

If' it's kernel-doc you can use shortcuts to autogenerate the links. Only
works with kernel-doc comments though, not with .rst in general:

"It's intended to be used as a direct handler for the struct 
&file_operations .get_unmapped_area() operation."

And +1 from me on sprinkling links all over docs. We might want to do that
for all the fbdev fops, for consistency.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[bug report] drm/bridge: Add ti-tfp410 DVI transmitter driver

2016-12-07 Thread Daniel Vetter 
On Wed, Dec 07, 2016 at 04:20:34PM +0200, Jyri Sarha wrote:
> On 12/06/16 15:28, Dan Carpenter wrote:
> > Hello Jyri Sarha,
> > 
> > The patch dc55ac3b52e6: "drm/bridge: Add ti-tfp410 DVI transmitter
> > driver" from Oct 31, 2016, leads to the following static checker
> > warning:
> > 
> > drivers/gpu/drm/bridge/ti-tfp410.c:141 tfp410_get_connector_ddc()
> > warn: missing error code here? 'of_graph_get_remote_port_parent()' 
> > failed.
> > 
> > drivers/gpu/drm/bridge/ti-tfp410.c
> >128  static int tfp410_get_connector_ddc(struct tfp410 *dvi)
> >129  {
> >130  struct device_node *ep = NULL, *connector_node = NULL;
> >131  struct device_node *ddc_phandle = NULL;
> >132  int ret = 0;
> >133  
> >134  /* port at 1 is the connector node */
> >135  ep = of_graph_get_endpoint_by_regs(dvi->dev->of_node, 1, 
> > -1);
> >136  if (!ep)
> >137  goto fail;
> > ^
> >138  
> >139  connector_node = of_graph_get_remote_port_parent(ep);
> >140  if (!connector_node)
> >141  goto fail;
> > ^
> > 
> > 
> >142  
> >143  ddc_phandle = of_parse_phandle(connector_node, 
> > "ddc-i2c-bus", 0);
> >144  if (!ddc_phandle)
> >145  goto fail;
> > ^
> > 
> > All these goto fails feel like we should be returning an error code.
> > Otherwise we could change the name to "goto success;"?
> > 
> 
> The label text could be seen misleading, but code runs as I intended it.
> If we can not extract the ddc i2c controller from the binding, we simply
> continue without it. The only exception is if we find the phandle but
> not the i2c controller, yet.
> 
> This implementation is a hack in the first place. The code will be
> removed when DRM has a proper generic connector support.

Hm, what's this generic drm connector thing you talk about? What's it for?
Asking since I haven't seen that yet nor heard in a discussion ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm: hdlcd: Work properly in big-endian mode

2016-12-07 Thread Robin Murphy 
Under a big-endian kernel, colours on the framebuffer all come out a
delightful shade of wrong, since we fail to take the reversed byte
order into account. Fortunately, the HDLCD has a control bit to make it
automatically byteswap big-endian data; let's use it as appropriate.

Signed-off-by: Robin Murphy 
---
 drivers/gpu/drm/arm/hdlcd_crtc.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 28341b32067f..eceb7bed5dd0 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -63,6 +63,7 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
uint32_t pixel_format;
struct simplefb_format *format = NULL;
int i;
+   u32 reg;

pixel_format = crtc->primary->state->fb->pixel_format;

@@ -76,7 +77,11 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)

/* HDLCD uses 'bytes per pixel', zero means 1 byte */
btpp = (format->bits_per_pixel + 7) / 8;
-   hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, (btpp - 1) << 3);
+   reg = (btpp - 1) << 3;
+#ifdef __BIG_ENDIAN
+   reg |= HDLCD_PIXEL_FMT_BIG_ENDIAN;
+#endif
+   hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, reg);

/*
 * The format of the HDLCD_REG__SELECT register is:
-- 
2.10.2.dirty

[PATCH v5 3/4] ARM: dts: da850-lcdk: add the vga-bridge node

2016-12-07 Thread Bartosz Golaszewski 
2016-12-07 15:25 GMT+01:00 Laurent Pinchart :
> Hi Bartosz,
>
> Thank you for the patch.
>
> On Wednesday 07 Dec 2016 11:42:44 Bartosz Golaszewski wrote:
>> Add the vga-bridge node to the board DT together with corresponding
>> ports and vga connector. This allows to retrieve the edid info from
>> the display automatically.
>>
>> Signed-off-by: Bartosz Golaszewski 
>> ---
>>  arch/arm/boot/dts/da850-lcdk.dts | 67 
>>  1 file changed, 67 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/da850-lcdk.dts
>> b/arch/arm/boot/dts/da850-lcdk.dts index afcb482..39602eb 100644
>> --- a/arch/arm/boot/dts/da850-lcdk.dts
>> +++ b/arch/arm/boot/dts/da850-lcdk.dts
>> @@ -51,6 +51,51 @@
>>   system-clock-frequency = <24576000>;
>>   };
>>   };
>> +
>> + vga-bridge {
>> + compatible = "ti,ths8135";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port at 0 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0>;
>> +
>> + vga_bridge_in: endpoint at 0 {
>> + reg = <0>;
>> + remote-endpoint = <&lcdc_out_vga>;
>> + };
>> + };
>> +
>> + port at 1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>> +
>> + vga_bridge_out: endpoint at 0 {
>> + reg = <0>;
>> + remote-endpoint = <&vga_con_in>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + vga {
>> + compatible = "vga-connector";
>> +
>> + ddc-i2c-bus = <&i2c0>;
>> +
>> + port {
>> + vga_con_in: endpoint {
>> + remote-endpoint = <&vga_bridge_out>;
>> + };
>> + };
>> + };
>>  };
>>
>>  &pmx_core {
>> @@ -236,3 +281,25 @@
>>  &memctrl {
>>   status = "okay";
>>  };
>> +
>> +&lcdc {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&lcd_pins>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + lcdc_out: port at 1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>> +
>> + lcdc_out_vga: endpoint at 0 {
>> + reg = <0>;
>> + remote-endpoint = <&vga_bridge_in>;
>> + };
>> + };
>
> Just to make sure you're aware, when there's a single endpoint you can
> simplify the DT by omitting the endpoint number. This would become
>
> lcdc_out: port at 1 {
> reg = <1>;
>
> lcdc_out_vga: endpoint {
> remote-endpoint = <&vga_bridge_in>;
> };
> };
>
> It's entirely up to you, both get my
>
> Reviewed-by: Laurent Pinchart 
>
>> + };
>> +};
>
> --
> Regards,
>
> Laurent Pinchart
>

Hi Laurent,

thanks for the hint, I'll change it if there's going to be a new
version of the series.

Best regards,
Bartosz Golaszewski

[PATCH 10/10] virtio: enable endian checks for sparse builds

2016-12-07 Thread Michael S. Tsirkin 
On Wed, Dec 07, 2016 at 07:25:51AM +0100, Johannes Berg wrote:
> On Tue, 2016-12-06 at 17:41 +0200, Michael S. Tsirkin wrote:
> 
> > It seems that there should be a better way to do it,
> > but this works too.
> 
> In some cases there might be:
> 
> > --- a/drivers/s390/virtio/Makefile
> > +++ b/drivers/s390/virtio/Makefile
> > @@ -6,6 +6,8 @@
> >  # it under the terms of the GNU General Public License (version 2
> > only)
> >  # as published by the Free Software Foundation.
> >  
> > +CFLAGS_virtio_ccw.o += -D__CHECK_ENDIAN__
> > +CFLAGS_kvm_virtio.o += -D__CHECK_ENDIAN__
> >  s390-virtio-objs := virtio_ccw.o
> >  ifdef CONFIG_S390_GUEST_OLD_TRANSPORT
> >  s390-virtio-objs += kvm_virtio.o
> 
> Here you could use
> 
> ccflags-y += -D__CHECK_ENDIAN__
> 
> for example, or even
> 
> subdir-ccflags-y += -D__CHECK_ENDIAN__
> 
> (in case any subdirs ever get added here)

Oh right. I forgot this directory only has virtio stuff.

> > --- a/drivers/vhost/Makefile
> > +++ b/drivers/vhost/Makefile
> > @@ -1,3 +1,4 @@
> > +ccflags-y := -D__CHECK_ENDIAN__
> 
> Looks like you did that here and in some other places though - so
> perhaps the s390 one was intentionally different?
> 
> > --- a/net/packet/Makefile
> > +++ b/net/packet/Makefile
> > @@ -2,6 +2,7 @@
> >  # Makefile for the packet AF.
> >  #
> >  
> > +ccflags-y := -D__CHECK_ENDIAN__
> 
> Technically this is slightly more than advertised, but I guess that
> still makes sense if it's clean now.
> 
> johannes

[Nouveau] 4.9-rc7 nouveau fails on arm64 64k page kernel but works with 4k

2016-12-07 Thread Ilia Mirkin 
On Wed, Dec 7, 2016 at 4:57 AM, Alexandre Courbot  wrote:
> On Wed, Dec 7, 2016 at 6:53 PM, Michel Dänzer  wrote:
>> On 07/12/16 06:39 PM, Alexandre Courbot wrote:
>>> On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin  
>>> wrote:
 That's right -- nouveau currently requires 4k page sizes to work. This is a
 software limitation, not a hardware one though.
>>>
>>> Looking at the trace I wonder - is the limitation in Nouveau or in TTM?
>>
>> Nouveau. Non-4K page sizes work fine with radeon (and presumably amdgpu).
>
> Thanks for the precision. I will check if Tegra iGPUs are also
> affected by this - if they are then it gives me a good excuse to take
> care of this bug.

For the most part it's confusion in the (nouveau) code as to what's a
gpu page and what's a cpu page (and the shifts involved). There are
some fringe issues that will need to be addressed, like the fact that
it's no longer a 1:1 mapping, which might be assumed in some places.

However I thought that 64K-pages were frowned upon nowadays for the
kernel - outside of HPC loads, most of the kernel memory becomes
pagecache, and files don't tend to be 64K-sized, so you have tons of
wasted memory (since you never cache multiple files in the same page).

But don't take that as me disapproving of such a project. It'd esp be
nice to do something like this outside of the PPC64 environment, where
BE concerns mix in with the 64K page concerns, and nothing works as a
result.

  -ilia

[PATCH] drm/atomic: Don't reject reflect-only rotations

2016-12-07 Thread Brian Starkey 
On Wed, Dec 07, 2016 at 04:12:07PM +0200, Ville Syrjälä wrote:
>On Wed, Dec 07, 2016 at 12:18:19PM +, Brian Starkey wrote:
>> The check to reject combinations of multiple rotation angles is overly
>> restrictive and has the side-effect of also failing any rotation value
>> which consists only of reflections.
>>
>> Fix this by relaxing the check to ignore values which contain no
>> rotation flags.
>>
>> Fixes: 6e0c7c3358d4 ("drm/atomic: Reject attempts to use multiple rotation 
>> angles at once")
>> Signed-off-by: Brian Starkey 
>> ---
>>  drivers/gpu/drm/drm_atomic.c |3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index 362e3ea..44f4030 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -846,7 +846,8 @@ int drm_atomic_plane_set_property(struct drm_plane 
>> *plane,
>>  } else if (property == config->prop_src_h) {
>>  state->src_h = val;
>>  } else if (property == plane->rotation_property) {
>> -if (!is_power_of_2(val & DRM_ROTATE_MASK))
>> +if ((val & DRM_ROTATE_MASK) &&
>> +!is_power_of_2(val & DRM_ROTATE_MASK))
>
>NAK. You must always set one and only one rotation bit.
>

How do you do (DRM_ROTATE_90 | DRM_REFLECT_X) then?

Could you suggest the correct fix? Because right now a commit which
sets rotation = "reflect-x" fails on this check

Thanks,
Brian

>>  return -EINVAL;
>>  state->rotation = val;
>>  } else if (property == plane->zpos_property) {
>> --
>> 1.7.9.5
>
>-- 
>Ville Syrjälä
>Intel OTC

[PATCH] etnaviv: Cannot render to rb-swapped formats

2016-12-07 Thread Wladimir J. van der Laan 
Exposing rb swapped (or other swizzled) formats for rendering would
involve swizzing in the pixel shader. This is not the case at the
moment, so reject requests for creating such surfaces.

(GPUs that need an extra resolve step anyway due to multiple pixel
pipes, such as gc2000, might also do this swap in the resolve operation.
But this would be tricky to keep track of)
---
 src/gallium/drivers/etnaviv/etnaviv_screen.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
b/src/gallium/drivers/etnaviv/etnaviv_screen.c
index c3f270d..06327b6 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
@@ -464,8 +464,11 @@ etna_screen_is_format_supported(struct pipe_screen 
*pscreen,
   return FALSE;

if (usage & PIPE_BIND_RENDER_TARGET) {
-  /* if render target, must be RS-supported format */
-  if (translate_rs_format(format) != ETNA_NO_MATCH) {
+  /* If render target, must be RS-supported format that is not rb swapped.
+   * Exposing rb swapped (or other swizzled) formats for rendering would
+   * involve swizzing in the pixel shader.
+   */
+  if (translate_rs_format(format) != ETNA_NO_MATCH && 
!translate_rs_format_rb_swap(format)) {
  /* Validate MSAA; number of samples must be allowed, and render target
   * must have MSAA'able format. */
  if (sample_count > 1) {
-- 
2.7.4

[PATCH] drm: Allow CAP_PRIME on !MODESET

2016-12-07 Thread Daniel Vetter 
vgem (and our igt tests using vgem) need this. I suspect etnaviv will
fare similarly.

Fixes: d5264ed3823a ("drm: Return -ENOTSUPP when called for KMS cap with a 
non-KMS driver")
Cc: Michel Dänzer 
Cc: Alex Deucher 
Cc: Chris Wilson 
Signed-off-by: Daniel Vetter 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_ioctl.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 0a900bd4575d..60bf95644739 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -234,10 +234,15 @@ static int drm_getcap(struct drm_device *dev, void *data, 
struct drm_file *file_

req->value = 0;

-   /* Only one cap makes sense with a UMS driver: */
-   if (req->capability == DRM_CAP_TIMESTAMP_MONOTONIC) {
+   /* Only some caps make sense with UMS/render-only drivers. */
+   switch (req->capability) ) {
+   case DRM_CAP_TIMESTAMP_MONOTONIC:
req->value = drm_timestamp_monotonic;
return 0;
+   case DRM_CAP_PRIME:
+   req->value |= dev->driver->prime_fd_to_handle ? 
DRM_PRIME_CAP_IMPORT : 0;
+   req->value |= dev->driver->prime_handle_to_fd ? 
DRM_PRIME_CAP_EXPORT : 0;
+   return 0;
}

/* Other caps only work with KMS drivers */
@@ -258,10 +263,6 @@ static int drm_getcap(struct drm_device *dev, void *data, 
struct drm_file *file_
case DRM_CAP_DUMB_PREFER_SHADOW:
req->value = dev->mode_config.prefer_shadow;
break;
-   case DRM_CAP_PRIME:
-   req->value |= dev->driver->prime_fd_to_handle ? 
DRM_PRIME_CAP_IMPORT : 0;
-   req->value |= dev->driver->prime_handle_to_fd ? 
DRM_PRIME_CAP_EXPORT : 0;
-   break;
case DRM_CAP_ASYNC_PAGE_FLIP:
req->value = dev->mode_config.async_page_flip;
break;
-- 
2.10.2

[PATCH 10/10] virtio: enable endian checks for sparse builds

2016-12-07 Thread Stefan Hajnoczi 
On Tue, Dec 06, 2016 at 05:41:05PM +0200, Michael S. Tsirkin wrote:
> __CHECK_ENDIAN__ isn't on by default presumably because
> it triggers too many sparse warnings for correct code.
> But virtio is now clean of these warnings, and
> we want to keep it this way - enable this for
> sparse builds.
> 
> Signed-off-by: Michael S. Tsirkin 
> ---
> 
> It seems that there should be a better way to do it,
> but this works too.
> 
>  drivers/block/Makefile  | 1 +
>  drivers/char/Makefile   | 1 +
>  drivers/char/hw_random/Makefile | 2 ++
>  drivers/gpu/drm/virtio/Makefile | 1 +
>  drivers/net/Makefile| 3 +++
>  drivers/net/caif/Makefile   | 1 +
>  drivers/rpmsg/Makefile  | 1 +
>  drivers/s390/virtio/Makefile| 2 ++
>  drivers/scsi/Makefile   | 1 +
>  drivers/vhost/Makefile  | 1 +
>  drivers/virtio/Makefile | 3 +++
>  net/9p/Makefile | 1 +
>  net/packet/Makefile | 1 +
>  net/vmw_vsock/Makefile  | 2 ++
>  14 files changed, 21 insertions(+)

Reviewed-by: Stefan Hajnoczi 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/d7e15474/attachment.sig>

[PATCH 3/8] drm/tegra: Add falcon helper library

2016-12-07 Thread Mikko Perttunen 


On 05.12.2016 21:13, Thierry Reding wrote:
> On Thu, Nov 10, 2016 at 08:23:40PM +0200, Mikko Perttunen wrote:
>> From: Arto Merilainen 
>>
>> Add a set of falcon helper routines for use by the tegradrm client drivers
>> of the various falcon-based engines.
>>
>> The falcon is a microcontroller that acts as a frontend for the rest of a
>> particular Tegra engine.  In order to properly utilize these engines, the
>> frontend must be booted before pushing any commands.
>>
>> Based on work by Andrew Chew 
>>
>> Signed-off-by: Andrew Chew 
>> Signed-off-by: Arto Merilainen 
>> Signed-off-by: Mikko Perttunen 
>> ---
>>  drivers/gpu/drm/tegra/Makefile |   3 +-
>>  drivers/gpu/drm/tegra/falcon.c | 256 
>> +
>>  drivers/gpu/drm/tegra/falcon.h | 130 +
>>  3 files changed, 388 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/gpu/drm/tegra/falcon.c
>>  create mode 100644 drivers/gpu/drm/tegra/falcon.h
>>
>> diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
>> index 2c66a8d..93e9a4a 100644
>> --- a/drivers/gpu/drm/tegra/Makefile
>> +++ b/drivers/gpu/drm/tegra/Makefile
>> @@ -13,6 +13,7 @@ tegra-drm-y := \
>>  sor.o \
>>  dpaux.o \
>>  gr2d.o \
>> -gr3d.o
>> +gr3d.o \
>> +falcon.o
>>
>>  obj-$(CONFIG_DRM_TEGRA) += tegra-drm.o
>> diff --git a/drivers/gpu/drm/tegra/falcon.c b/drivers/gpu/drm/tegra/falcon.c
>> new file mode 100644
>> index 000..180b2fd
>> --- /dev/null
>> +++ b/drivers/gpu/drm/tegra/falcon.c
>> @@ -0,0 +1,256 @@
>> +/*
>> + * Copyright (c) 2015, NVIDIA Corporation.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "falcon.h"
>> +#include "drm.h"
>> +
>> +#define FALCON_IDLE_TIMEOUT_US  10
>> +#define FALCON_IDLE_CHECK_PERIOD_US 10
>
> Seems a little overkill to have these here, given that their only used
> twice. They're also used in two cases where we may end up using
> different periods and timeouts eventually, so I'd just stick them into
> falcon_wait_idle() and falcon_dma_wait_idle() directly and omit these
> definitions. That's kind of a nitpick, so feel free to keep it as-is.

Fixed.

>
>> +
>> +enum falcon_memory {
>> +FALCON_MEMORY_IMEM,
>> +FALCON_MEMORY_DATA,
>> +};
>> +
>> +static void falcon_writel(struct falcon *falcon, u32 value, u32 offset)
>> +{
>> +writel(value, falcon->regs + offset);
>> +}
>> +
>> +int falcon_wait_idle(struct falcon *falcon)
>> +{
>> +u32 idlestate;
>> +
>> +return readl_poll_timeout(falcon->regs + FALCON_IDLESTATE, idlestate,
>> +  (!idlestate),
>
> That's an odd way to write this. Why not just "idlestate == 0"? That's
> much easier to read and more explicit.

Fixed.

>
>> +  FALCON_IDLE_CHECK_PERIOD_US,
>> +  FALCON_IDLE_TIMEOUT_US);
>> +}
>> +
>> +static int falcon_dma_wait_idle(struct falcon *falcon)
>> +{
>> +u32 dmatrfcmd;
>
> u32 value? Naming it after a register suggests that it may be an offset
> rather than the register value.

Fixed.

>
>> +
>> +return readl_poll_timeout(falcon->regs + FALCON_DMATRFCMD, dmatrfcmd,
>> +  (dmatrfcmd & FALCON_DMATRFCMD_IDLE),
>> +  FALCON_IDLE_CHECK_PERIOD_US,
>> +  FALCON_IDLE_TIMEOUT_US);
>> +}
>> +
>> +static int falcon_copy_chunk(struct falcon *falcon,
>> + phys_addr_t base,
>> + unsigned long offset,
>> + enum falcon_memory target)
>> +{
>> +u32 cmd = FALCON_DMATRFCMD_SIZE_256B;
>> +
>> +if (target == FALCON_MEMORY_IMEM)
>> +cmd |= FALCON_DMATRFCMD_IMEM;
>> +
>> +falcon_writel(falcon, offset, FALCON_DMATRFMOFFS);
>> +falcon_writel(falcon, base, FALCON_DMATRFFBOFFS);
>> +falcon_writel(falcon, cmd, FALCON_DMATRFCMD);
>> +
>> +return falcon_dma_wait_idle(falcon);
>> +}
>> +
>> +static void falcon_copy_firmware_image(struct falcon *falcon,
>> +   const struct firmware *firmware)
>> +{
>> +u32 *firmware_vaddr = falcon->firmware.vaddr;
>> +size_t i;
>> +
>> +/* copy the whole thing taking into account endianness */
>> +for (i = 0; i < firmware->size / sizeof(u32); i++)
>> +firmware_vaddr[i] = le32_to_cpu(((u32 *)firmware->data)[i]);
>> +
>> +/* ensure that caches are flushed and falcon can see the firmware */
>> +dma_sync_single_for_device(falcon->dev, virt_to_phys(firmware_vaddr),
>> +   falcon->firmware.size, DMA_TO_DEVICE);
>
> My understanding is that this is an error and the DMA API will complain
> about it if debugging is enabled. I think y

[PATCH] drm/atomic: Don't reject reflect-only rotations

2016-12-07 Thread Chris Wilson 
On Wed, Dec 07, 2016 at 12:18:19PM +, Brian Starkey wrote:
> The check to reject combinations of multiple rotation angles is overly
> restrictive and has the side-effect of also failing any rotation value
> which consists only of reflections.
> 
> Fix this by relaxing the check to ignore values which contain no
> rotation flags.
> 
> Fixes: 6e0c7c3358d4 ("drm/atomic: Reject attempts to use multiple rotation 
> angles at once")
> Signed-off-by: Brian Starkey 

>  drivers/gpu/drm/drm_atomic.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 362e3ea..44f4030 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -846,7 +846,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
>   } else if (property == config->prop_src_h) {
>   state->src_h = val;
>   } else if (property == plane->rotation_property) {
> - if (!is_power_of_2(val & DRM_ROTATE_MASK))
> + if ((val & DRM_ROTATE_MASK) &&

If val & DRM_ROTATE_MASK is zero, val must be REFLECT_X | REFLECT_Y.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 10/10] virtio: enable endian checks for sparse builds

2016-12-07 Thread Jason Wang 


On 2016年12月06日 23:41, Michael S. Tsirkin wrote:
> __CHECK_ENDIAN__ isn't on by default presumably because
> it triggers too many sparse warnings for correct code.
> But virtio is now clean of these warnings, and
> we want to keep it this way - enable this for
> sparse builds.
>
> Signed-off-by: Michael S. Tsirkin 
> ---
>
> It seems that there should be a better way to do it,
> but this works too.

Reviewed-by: Jason Wang 

>
>   drivers/block/Makefile  | 1 +
>   drivers/char/Makefile   | 1 +
>   drivers/char/hw_random/Makefile | 2 ++
>   drivers/gpu/drm/virtio/Makefile | 1 +
>   drivers/net/Makefile| 3 +++
>   drivers/net/caif/Makefile   | 1 +
>   drivers/rpmsg/Makefile  | 1 +
>   drivers/s390/virtio/Makefile| 2 ++
>   drivers/scsi/Makefile   | 1 +
>   drivers/vhost/Makefile  | 1 +
>   drivers/virtio/Makefile | 3 +++
>   net/9p/Makefile | 1 +
>   net/packet/Makefile | 1 +
>   net/vmw_vsock/Makefile  | 2 ++
>   14 files changed, 21 insertions(+)
>
> diff --git a/drivers/block/Makefile b/drivers/block/Makefile
> index 1e9661e..597481c 100644
> --- a/drivers/block/Makefile
> +++ b/drivers/block/Makefile
> @@ -27,6 +27,7 @@ obj-$(CONFIG_BLK_DEV_OSD)   += osdblk.o
>   obj-$(CONFIG_BLK_DEV_UMEM)  += umem.o
>   obj-$(CONFIG_BLK_DEV_NBD)   += nbd.o
>   obj-$(CONFIG_BLK_DEV_CRYPTOLOOP) += cryptoloop.o
> +CFLAGS_virtio_blk.o += -D__CHECK_ENDIAN__
>   obj-$(CONFIG_VIRTIO_BLK)+= virtio_blk.o
>   
>   obj-$(CONFIG_BLK_DEV_SX8)   += sx8.o
> diff --git a/drivers/char/Makefile b/drivers/char/Makefile
> index 6e6c244..a99467d 100644
> --- a/drivers/char/Makefile
> +++ b/drivers/char/Makefile
> @@ -6,6 +6,7 @@ obj-y += mem.o random.o
>   obj-$(CONFIG_TTY_PRINTK)+= ttyprintk.o
>   obj-y   += misc.o
>   obj-$(CONFIG_ATARI_DSP56K)  += dsp56k.o
> +CFLAGS_virtio_console.o += -D__CHECK_ENDIAN__
>   obj-$(CONFIG_VIRTIO_CONSOLE)+= virtio_console.o
>   obj-$(CONFIG_RAW_DRIVER)+= raw.o
>   obj-$(CONFIG_SGI_SNSC)  += snsc.o snsc_event.o
> diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
> index 5f52b1e..a2b0931 100644
> --- a/drivers/char/hw_random/Makefile
> +++ b/drivers/char/hw_random/Makefile
> @@ -17,6 +17,8 @@ obj-$(CONFIG_HW_RANDOM_IXP4XX) += ixp4xx-rng.o
>   obj-$(CONFIG_HW_RANDOM_OMAP) += omap-rng.o
>   obj-$(CONFIG_HW_RANDOM_OMAP3_ROM) += omap3-rom-rng.o
>   obj-$(CONFIG_HW_RANDOM_PASEMI) += pasemi-rng.o
> +CFLAGS_virtio_transport.o += -D__CHECK_ENDIAN__
> +CFLAGS_virtio-rng.o += -D__CHECK_ENDIAN__
>   obj-$(CONFIG_HW_RANDOM_VIRTIO) += virtio-rng.o
>   obj-$(CONFIG_HW_RANDOM_TX4939) += tx4939-rng.o
>   obj-$(CONFIG_HW_RANDOM_MXC_RNGA) += mxc-rnga.o
> diff --git a/drivers/gpu/drm/virtio/Makefile b/drivers/gpu/drm/virtio/Makefile
> index 3fb8eac..1162366 100644
> --- a/drivers/gpu/drm/virtio/Makefile
> +++ b/drivers/gpu/drm/virtio/Makefile
> @@ -3,6 +3,7 @@
>   # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>   
>   ccflags-y := -Iinclude/drm
> +ccflags-y += -D__CHECK_ENDIAN__
>   
>   virtio-gpu-y := virtgpu_drv.o virtgpu_kms.o virtgpu_drm_bus.o virtgpu_gem.o 
> \
>   virtgpu_fb.o virtgpu_display.o virtgpu_vq.o virtgpu_ttm.o \
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 7336cbd..3f587de 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_EQUALIZER) += eql.o
>   obj-$(CONFIG_IFB) += ifb.o
>   obj-$(CONFIG_MACSEC) += macsec.o
>   obj-$(CONFIG_MACVLAN) += macvlan.o
> +CFLAGS_macvtap.o += -D__CHECK_ENDIAN__
>   obj-$(CONFIG_MACVTAP) += macvtap.o
>   obj-$(CONFIG_MII) += mii.o
>   obj-$(CONFIG_MDIO) += mdio.o
> @@ -20,8 +21,10 @@ obj-$(CONFIG_NETCONSOLE) += netconsole.o
>   obj-$(CONFIG_PHYLIB) += phy/
>   obj-$(CONFIG_RIONET) += rionet.o
>   obj-$(CONFIG_NET_TEAM) += team/
> +CFLAGS_tun.o += -D__CHECK_ENDIAN__
>   obj-$(CONFIG_TUN) += tun.o
>   obj-$(CONFIG_VETH) += veth.o
> +CFLAGS_virtio_net.o += -D__CHECK_ENDIAN__
>   obj-$(CONFIG_VIRTIO_NET) += virtio_net.o
>   obj-$(CONFIG_VXLAN) += vxlan.o
>   obj-$(CONFIG_GENEVE) += geneve.o
> diff --git a/drivers/net/caif/Makefile b/drivers/net/caif/Makefile
> index 9bbd453..d1a922c 100644
> --- a/drivers/net/caif/Makefile
> +++ b/drivers/net/caif/Makefile
> @@ -12,3 +12,4 @@ obj-$(CONFIG_CAIF_HSI) += caif_hsi.o
>   
>   # Virtio interface
>   obj-$(CONFIG_CAIF_VIRTIO) += caif_virtio.o
> +CFLAGS_caif_virtio.o += -D__CHECK_ENDIAN__
> diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile
> index ae9c913..23c8b66 100644
> --- a/drivers/rpmsg/Makefile
> +++ b/drivers/rpmsg/Makefile
> @@ -1,3 +1,4 @@
>   obj-$(CONFIG_RPMSG) += rpmsg_core.o
>   obj-$(CONFIG_RPMSG_QCOM_SMD)+= qcom_smd.o
>   obj-$(CONFIG_RPMSG_VIRTIO)  += virtio_rpmsg_bus.o
> +CFLAGS_virtio_rpmsg_bus.o+= -D__CHECK_ENDIAN__
> diff --git a/drivers/s390/virtio/Makefile b/drivers/s390/virtio

[PATCH] drm: Allow CAP_PRIME on !MODESET

2016-12-07 Thread Chris Wilson 
On Wed, Dec 07, 2016 at 02:13:23PM +0100, Daniel Vetter wrote:
> vgem (and our igt tests using vgem) need this. I suspect etnaviv will
> fare similarly.
> 
> Fixes: d5264ed3823a ("drm: Return -ENOTSUPP when called for KMS cap with a 
> non-KMS driver")
> Cc: Michel Dänzer 
> Cc: Alex Deucher 
> Cc: Chris Wilson 
> Signed-off-by: Daniel Vetter 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_ioctl.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 0a900bd4575d..60bf95644739 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -234,10 +234,15 @@ static int drm_getcap(struct drm_device *dev, void 
> *data, struct drm_file *file_
>  
>   req->value = 0;
>  
> - /* Only one cap makes sense with a UMS driver: */
> - if (req->capability == DRM_CAP_TIMESTAMP_MONOTONIC) {
> + /* Only some caps make sense with UMS/render-only drivers. */
> + switch (req->capability) ) {
> + case DRM_CAP_TIMESTAMP_MONOTONIC:
>   req->value = drm_timestamp_monotonic;
>   return 0;
> + case DRM_CAP_PRIME:
> + req->value |= dev->driver->prime_fd_to_handle ? 
> DRM_PRIME_CAP_IMPORT : 0;
> + req->value |= dev->driver->prime_handle_to_fd ? 
> DRM_PRIME_CAP_EXPORT : 0;
> + return 0;

Slightly changes old behaviour but shouldn't we also be checking
driver->features?

if (drm_core_check_feature(dev, DRIVER_PRIME)) {
req->value |= dev->driver->prime_fd_to_handle ? DRM_PRIME_CAP_IMPORT : 
0;
req->value |= dev->driver->prime_handle_to_fd ? DRM_PRIME_CAP_EXPORT : 
0;
}

Paranoia says second patch as a potential change of abi. So,

Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 189451] UVD not responding with Mobility Radeon HD 5650

2016-12-07 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=189451

--- Comment #4 from Raffaele  ---
Created attachment 247081
  --> https://bugzilla.kernel.org/attachment.cgi?id=247081&action=edit
Second error message with 4.8.10

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 189451] UVD not responding with Mobility Radeon HD 5650

2016-12-07 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=189451

--- Comment #3 from Raffaele  ---
I have a new kernel and a new error message

Kernel 4.8.10-300.fc25.x86_64

New error message. This time UVD seems to be initialized fine, but there is
another error afterwards

[   20.447459] [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding, trying
to reset the VCPU!!!
[   20.468164] [drm] ring test on 5 succeeded in 2 usecs
[   20.468174] [drm] UVD initialized successfully.
[   20.468806] [drm] ib test on ring 0 succeeded in 0 usecs
[   20.468866] [drm] ib test on ring 3 succeeded in 0 usecs
[   20.796813] audit: type=1130 audit(1481115873.389:65): pid=1 uid=0
auid=4294967295 ses=4294967295
msg='unit=systemd-fsck at 
dev-disk-by\x2duuid-061555a1\x2d22db\x2d41c0\x2d8dcf\x2dc05c26473ceb
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'
[   20.956774] audit: type=1130 audit(1481115873.549:66): pid=1 uid=0
auid=4294967295 ses=4294967295 msg='unit=systemd-fsck at 
dev-mapper-fedora\x2dhome
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'
[   21.124357] Adding 2097148k swap on /dev/mapper/fedora-swap.  Priority:-1
extents:1 across:2097148k FS
[   21.350043] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts:
(null)
[   21.643288] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts:
(null)
[   21.684650] [drm:uvd_v1_0_ib_test [radeon]] *ERROR* radeon: fence wait timed
out.
[   21.685106] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed
testing IB on ring 5 (-110).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[GIT PULL] drm/fsl-dcu: fixes and cleanup around fbdev for v4.10

2016-12-07 Thread Dave Airlie 
On 7 December 2016 at 11:51, Stefan Agner  wrote:
> Hi Dave,
>
> On 2016-11-28 18:55, Stefan Agner wrote:
>> Hi Dave,
>>
>> Some fixes and cleanup, mainly around fbdev emulation. It also adds a
>> new module parameter which allows to specify the color depth/bpp for
>> the fbdev emulation (like the IMX DRM driver).
>>
>> There have been some fixes in that driver which are not yet in
>> drm-next, but it seems to merge cleanly...
>
> Friendly reminder... Or any specific reason you did not merge that yet?

There was a reason this failed to work when I tried but I can't
remember why now,

however in future can you use tags as it makes the merge nicer to
read, instead of having
just a git SHA in the pull request.

Dave.

[PATCH] drm/atomic: Don't reject reflect-only rotations

2016-12-07 Thread Brian Starkey 
The check to reject combinations of multiple rotation angles is overly
restrictive and has the side-effect of also failing any rotation value
which consists only of reflections.

Fix this by relaxing the check to ignore values which contain no
rotation flags.

Fixes: 6e0c7c3358d4 ("drm/atomic: Reject attempts to use multiple rotation 
angles at once")
Signed-off-by: Brian Starkey 
---
 drivers/gpu/drm/drm_atomic.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 362e3ea..44f4030 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -846,7 +846,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
} else if (property == config->prop_src_h) {
state->src_h = val;
} else if (property == plane->rotation_property) {
-   if (!is_power_of_2(val & DRM_ROTATE_MASK))
+   if ((val & DRM_ROTATE_MASK) &&
+   !is_power_of_2(val & DRM_ROTATE_MASK))
return -EINVAL;
state->rotation = val;
} else if (property == plane->zpos_property) {
-- 
1.7.9.5

[PATCH 04/10] drm/virtio: annotate virtio_gpu_queue_ctrl_buffer_locked

2016-12-07 Thread Jason Wang 


On 2016年12月06日 23:40, Michael S. Tsirkin wrote:
> virtio_gpu_queue_ctrl_buffer_locked is called with ctrlq.qlock taken, it
> releases and acquires this lock.  This causes a sparse warning.  Add
> appropriate annotations for sparse context checking.
>
> Signed-off-by: Michael S. Tsirkin 
> ---
>   drivers/gpu/drm/virtio/virtgpu_vq.c | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
> b/drivers/gpu/drm/virtio/virtgpu_vq.c
> index 2f0c2f9..a6e2ce4 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_vq.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
> @@ -297,6 +297,8 @@ void virtio_gpu_dequeue_cursor_func(struct work_struct 
> *work)
>   
>   static int virtio_gpu_queue_ctrl_buffer_locked(struct virtio_gpu_device 
> *vgdev,
>  struct virtio_gpu_vbuffer *vbuf)
> + __releases(&vgdev->ctrlq.qlock)
> + __acquires(&vgdev->ctrlq.qlock)
>   {
>   struct virtqueue *vq = vgdev->ctrlq.vq;
>   struct scatterlist *sgs[3], vcmd, vout, vresp;

Reviewed-by: Jason Wang

[PATCH 03/10] drm/virtio: fix lock context imbalance

2016-12-07 Thread Jason Wang 


On 2016年12月06日 23:40, Michael S. Tsirkin wrote:
> When virtio_gpu_free_vbufs exits due to list empty, it does not
> drop the free_vbufs lock that it took.
> list empty is not expected to happen anyway, but it can't hurt to fix
> this and drop the lock.
>
> Signed-off-by: Michael S. Tsirkin 
> ---
>   drivers/gpu/drm/virtio/virtgpu_vq.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)

Reviewed-by: Jason Wang 

>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
> b/drivers/gpu/drm/virtio/virtgpu_vq.c
> index 5a0f8a7..2f0c2f9 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_vq.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
> @@ -109,8 +109,10 @@ void virtio_gpu_free_vbufs(struct virtio_gpu_device 
> *vgdev)
>   
>   spin_lock(&vgdev->free_vbufs_lock);
>   for (i = 0; i < count; i++) {
> - if (WARN_ON(list_empty(&vgdev->free_vbufs)))
> + if (WARN_ON(list_empty(&vgdev->free_vbufs))) {
> + spin_unlock(&vgdev->free_vbufs_lock);
>   return;
> + }
>   vbuf = list_first_entry(&vgdev->free_vbufs,
>   struct virtio_gpu_vbuffer, list);
>   list_del(&vbuf->list);

[PATCH 02/10] drm/virtio: fix endianness in primary_plane_update

2016-12-07 Thread Jason Wang 


On 2016年12月06日 23:40, Michael S. Tsirkin wrote:
> virtio_gpu_cmd_transfer_to_host_2d expects x and y
> parameters in LE, but virtio_gpu_primary_plane_update
> passes in the CPU format instead.
>
> Signed-off-by: Michael S. Tsirkin 
> ---
>   drivers/gpu/drm/virtio/virtgpu_plane.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Jason Wang 

>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c 
> b/drivers/gpu/drm/virtio/virtgpu_plane.c
> index ba28c0f..1fda965 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_plane.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
> @@ -88,8 +88,8 @@ static void virtio_gpu_primary_plane_update(struct 
> drm_plane *plane,
>   (vgdev, handle, 0,
>cpu_to_le32(plane->state->src_w >> 16),
>cpu_to_le32(plane->state->src_h >> 16),
> -  plane->state->src_x >> 16,
> -  plane->state->src_y >> 16, NULL);
> +  cpu_to_le32(plane->state->src_x >> 16),
> +  cpu_to_le32(plane->state->src_y >> 16), NULL);
>   }
>   } else {
>   handle = 0;

[PATCH 2/2] drm/sti: do not post HQVDP command if no update

2016-12-07 Thread Benjamin Gaignard 
Acked-by: Benjamin Gaignard 

2016-12-05 16:09 GMT+01:00 Fabien Dessenne :
> Do not process update requests with unmodified parameters.
>
> Since the HQVDP command queue is limited to 2, we shall take care of
> not posting unneeded commands, which would abusively fill the command
> queue leading to frame update skip.
> This typically happens when the driver is called with legacy
> (non-atomic) IOCTL : in that case atomic_update() is called multiple
> times with the same parameters.
>
> Signed-off-by: Fabien Dessenne 
> ---
>  drivers/gpu/drm/sti/sti_hqvdp.c | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
> index a547723..55cbaea 100644
> --- a/drivers/gpu/drm/sti/sti_hqvdp.c
> +++ b/drivers/gpu/drm/sti/sti_hqvdp.c
> @@ -1117,6 +1117,21 @@ static void sti_hqvdp_atomic_update(struct drm_plane 
> *drm_plane,
> if (!crtc || !fb)
> return;
>
> +   if ((oldstate->fb == state->fb) &&
> +   (oldstate->crtc_x == state->crtc_x) &&
> +   (oldstate->crtc_y == state->crtc_y) &&
> +   (oldstate->crtc_w == state->crtc_w) &&
> +   (oldstate->crtc_h == state->crtc_h) &&
> +   (oldstate->src_x == state->src_x) &&
> +   (oldstate->src_y == state->src_y) &&
> +   (oldstate->src_w == state->src_w) &&
> +   (oldstate->src_h == state->src_h)) {
> +   /* No change since last update, do not post cmd */
> +   DRM_DEBUG_DRIVER("No change, not posting cmd\n");
> +   plane->status = STI_PLANE_UPDATED;
> +   return;
> +   }
> +
> mode = &crtc->mode;
> dst_x = state->crtc_x;
> dst_y = state->crtc_y;
> --
> 2.7.4
>



-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

[PATCH 1/2] drm/sti: load XP70 firmware only once

2016-12-07 Thread Benjamin Gaignard 
Acked-by: Benjamin Gaignard 

2016-12-05 16:09 GMT+01:00 Fabien Dessenne :
> When a plane is enabled, after having been disabled, do not reload XP70
> firmware again, but only register VTG again
>
> Signed-off-by: Fabien Dessenne 
> ---
>  drivers/gpu/drm/sti/sti_hqvdp.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
> index f88130f..a547723 100644
> --- a/drivers/gpu/drm/sti/sti_hqvdp.c
> +++ b/drivers/gpu/drm/sti/sti_hqvdp.c
> @@ -332,6 +332,7 @@ struct sti_hqvdp_cmd {
>   * @hqvdp_cmd_paddr:   physical address of hqvdp_cmd
>   * @vtg:   vtg for main data path
>   * @xp70_initialized:  true if xp70 is already initialized
> + * @vtg_registered:true if registered to VTG
>   */
>  struct sti_hqvdp {
> struct device *dev;
> @@ -347,6 +348,7 @@ struct sti_hqvdp {
> u32 hqvdp_cmd_paddr;
> struct sti_vtg *vtg;
> bool xp70_initialized;
> +   bool vtg_registered;
>  };
>
>  #define to_sti_hqvdp(x) container_of(x, struct sti_hqvdp, plane)
> @@ -771,7 +773,7 @@ static void sti_hqvdp_disable(struct sti_hqvdp *hqvdp)
> DRM_ERROR("XP70 could not revert to idle\n");
>
> hqvdp->plane.status = STI_PLANE_DISABLED;
> -   hqvdp->xp70_initialized = false;
> +   hqvdp->vtg_registered = false;
>  }
>
>  /**
> @@ -1064,10 +1066,11 @@ static int sti_hqvdp_atomic_check(struct drm_plane 
> *drm_plane,
> return -EINVAL;
> }
>
> -   if (!hqvdp->xp70_initialized) {
> +   if (!hqvdp->xp70_initialized)
> /* Start HQVDP XP70 coprocessor */
> sti_hqvdp_start_xp70(hqvdp);
>
> +   if (!hqvdp->vtg_registered) {
> /* Prevent VTG shutdown */
> if (clk_prepare_enable(hqvdp->clk_pix_main)) {
> DRM_ERROR("Failed to prepare/enable pix main clk\n");
> @@ -1081,6 +1084,7 @@ static int sti_hqvdp_atomic_check(struct drm_plane 
> *drm_plane,
> DRM_ERROR("Cannot register VTG notifier\n");
> return -EINVAL;
> }
> +   hqvdp->vtg_registered = true;
> }
>
> DRM_DEBUG_KMS("CRTC:%d (%s) drm plane:%d (%s)\n",
> --
> 2.7.4
>



-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

[PATCH] drm/fence: add drm_crtc_create_fence()

2016-12-07 Thread Gustavo Padovan 
2016-12-07 Daniel Vetter :

> On Tue, Dec 06, 2016 at 03:47:17PM -0200, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > Instead of dealing with crtc details inside drm_atomic.c we should
> > just export a function that creates a new crtc fence for us and
> > use that.
> > 
> > Suggested-by: Chris Wilson 
> > Signed-off-by: Gustavo Padovan 
> 
> Yeah, seems reasonable.
> 
> Reviewed-by: Daniel Vetter 

Applied to drm-misc. Thanks for reviewing.

Gustavo

[pull] amdgpu drm-fixes-4.9

2016-12-07 Thread Alex Deucher 
Hi Dave,

If it's not too late, one last regression fix for amdgpu.

The following changes since commit ab7cd8d83e5dba13027de66f1b008b08b30b71a4:

  Merge tag 'drm-intel-fixes-2016-12-01' of 
git://anongit.freedesktop.org/git/drm-intel into drm-fixes (2016-12-04 06:31:26 
+1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.9

for you to fetch changes up to faefba95c9e8ca3a523831c2ec2150f5ea054dae:

  drm/amdgpu: just suspend the hw on pci shutdown (2016-12-07 11:17:21 -0500)


Alex Deucher (1):
  drm/amdgpu: just suspend the hw on pci shutdown

 drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 5 -
 3 files changed, 6 insertions(+), 2 deletions(-)

[PATCH 14/22] dt-bindings: display: dw-hdmi: Clean up DT bindings documentation

2016-12-07 Thread Laurent Pinchart 
Hi Rob,

On Tuesday 06 Dec 2016 15:15:50 Rob Herring wrote:
> On Fri, Dec 02, 2016 at 01:43:29AM +0200, Laurent Pinchart wrote:
> > Make it clear that the core bridge/dw_hdmi.txt document isn't a device
> > tree binding by itself but is meant to be referenced by platform device
> > tree bindings, and update the Rockchip and Freescale DWC HDMI TX
> > bindings to reference it.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  .../devicetree/bindings/display/bridge/dw_hdmi.txt | 85 +++--
> >  .../devicetree/bindings/display/imx/hdmi.txt   | 51 +++--
> >  .../bindings/display/rockchip/dw_hdmi-rockchip.txt | 43 +++
> >  3 files changed, 91 insertions(+), 88 deletions(-)
> 
> Acked-by: Rob Herring 
> 
> Really, the ddc-i2c-bus prop needs to move to a connector node, but
> that's a separate problem.

I fully agree. One step at a time though :-)

> We might also want to drop the 'ddc-' part and have a generic way to refer
> to an i2c bus. There's a couple of other cases.

Right, but a DT node might need to refer to multiple I2C buses (probably not 
for connectors though). The ddc- prefix serves a similar purpose than the 
power supply or GPIO name in the *-supply or *-gpios properties.

-- 
Regards,

Laurent Pinchart

[PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check

2016-12-07 Thread Laurent Pinchart 
Hello,

On Wednesday 07 Dec 2016 10:26:25 Chen-Yu Tsai wrote:
> On Wed, Dec 7, 2016 at 1:29 AM, Maxime Ripard wrote:
> > On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu Tsai wrote:
> >> The panels shipped with Allwinner devices are very "generic", i.e.
> >> they do not have model numbers or reliable sources of information
> >> for the timings (that we know of) other than the fex files shipped
> >> on them. The dot clock frequency provided in the fex files have all
> >> been rounded to the nearest MHz, as that is the unit used in them.
> >> 
> >> We were using the simple panel "urt,umsh-8596md-t" as a substitute
> >> for the A13 Q8 tablets in the absence of a specific model for what
> >> may be many different but otherwise timing compatible panels. This
> >> was usable without any visual artifacts or side effects, until the
> >> dot clock rate check was added in commit bb43d40d7c83 ("drm/sun4i:
> >> rgb: Validate the clock rate").
> >> 
> >> The reason this check fails is because the dotclock frequency for
> >> this model is 33.26 MHz, which is not achievable with our dot clock
> >> hardware, and the rate returned by clk_round_rate deviates slightly,
> >> causing the driver to reject the display mode.
> >> 
> >> The LCD panels have some tolerance on the dot clock frequency, even
> >> if it's not specified in their datasheets.
> >> 
> >> This patch adds a 5% tolerence to the dot clock check.
> > 
> > As we discussed already, I really believe this is just as arbitrary as
> > the current behaviour.
> 
> Yes. I agree. This patch is mainly to give something that works for
> people who don't care about the details, and to get some feedback
> from people that do.
> 
> > Some panels require an exact frequency,

There's no such thing as an exact frequency, there will always be some 
tolerance (and if your display controller can really generate an exact 
frequency I'd be very interested in that hardware :-)).

This is something that has been bugging me for some time now. The problem has 
been mostly ignored, or worked around in different ways by different drivers. 
I'm afraid I have no generic solution available, but I think we should try to 
agree on a common behaviour.

I don't believe it would be reasonable to request each panel to report a 
tolerance, as the value is most of the time not available from the 
documentation (when documentation is available). Worse, I'm pretty sure that 
most panels documented as fixed timing can actually accept a wide range of 
timings. The timings reported in the datasheet are just the nominal values.

Panels that don't support multiple resolutions obviously require fixed active 
h/v values. Even if they can tolerate some departure from the nominal timings 
for the sync and porches lengths, it might not be very useful to support that 
as I don't expect the display controllers and encoders to be a limiting factor 
by not supporting the particular timings that a panel considers as nominal. On 
the other hand, departing from the nominal pixel clock frequency is needed as 
we can't achieve an exact match, and even possibly to have some control over 
the frame rate (although that might also require changing the sync and porches 
timings). Without specific information about panel tolerance, do we have any 
option other than picking an arbitrary value ?

> > some have a minimal frequency
> > but no maximum, some have a maximum frequency but no minimal, and I
> > guess most of them deviates by how much exactly they can take (and
> > possibly can take more easily a higher frequency, but are less
> > tolerant if you take a frequency lower than the nominal.
> > 
> > And we cannot remove that check entirely, since some bridges will
> > report out of range frequencies for higher modes that we know we
> > cannot reach.
> 
> I believe this should be handled by the bridge driver in the check
> callback? The callback I'm changing is attached to the connector,
> which I think doesn't get used if you have a bridge instead.
> And this only checks the pre-registered display modes, such as
> those specified in simple-panel or EDID.
> 
> > We could just try to see if the screen pixel clock frequency is out of
> > the pixel clock range we can generate, but then we will loop back on
> > how much out of range is it exactly, and is it within the screen
> > tolerancy.
> > 
> > We have an API to deal with the panel tolerancies in the DRM panel
> > framework, we can (and should) use it.
> 
> If you mean the get_timings callback, it's not very useful. Most of
> the panels in simple-panel do not use the display_timings structure,
> so they don't return anything. And I get that. The few datasheets
> I found don't list min/max tolerances for the dotclock.
> 
> The ones that do have the min/max the same as the recommended value.
> This may or may not be accurate. IIRC the one panel that had this
> that I did check didn't list min/max values in its datasheet.
> 
> > I'm not sure how others usually deal with this th

[PATCH v5 2/4] drm: bridge: add support for TI ths8135

2016-12-07 Thread Bartosz Golaszewski 
2016-12-07 11:42 GMT+01:00 Bartosz Golaszewski :
> THS8135 is a configurable video DAC. Add DT bindings for this chip and
> use the dumb-vga-dac driver for now as no configuration is required to
> make it work.
>
> Signed-off-by: Bartosz Golaszewski 
> ---
>  .../bindings/display/bridge/ti,ths8135.txt | 52 
> ++
>  drivers/gpu/drm/bridge/dumb-vga-dac.c  |  1 +
>  2 files changed, 53 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt 
> b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> new file mode 100644
> index 000..23cd8ee
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> @@ -0,0 +1,52 @@
> +THS8135 Video DAC
> +-
> +
> +This is the binding for Texas Instruments THS8135 Video DAC bridge.
> +
> +Required properties:
> +
> +- compatible: Must be "ti,ths8135"
> +
> +Required nodes:
> +
> +This device has two video ports. Their connections are modelled using the OF
> +graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> +
> +- Video port 0 for RGB input
> +- Video port 1 for VGA output
> +
> +Example
> +---
> +
> +vga-bridge {
> +   compatible = "ti,ths8135";
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   port at 0 {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   reg = <0>;
> +
> +   vga_bridge_in: endpoint at 0 {
> +   reg = <0>;
> +   remote-endpoint = <&lcdc_out_vga>;
> +   };
> +   };
> +
> +   port at 1 {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   reg = <1>;
> +
> +   vga_bridge_out: endpoint at 0 {
> +   reg = <0>;
> +   remote-endpoint = <&vga_con_in>;
> +   };
> +   };
> +   };
> +};
> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c 
> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> index afec232..498fa75 100644
> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> @@ -204,6 +204,7 @@ static int dumb_vga_remove(struct platform_device *pdev)
>
>  static const struct of_device_id dumb_vga_match[] = {
> { .compatible = "dumb-vga-dac" },
> +   { .compatible = "ti,ths8135" },
> {},
>  };
>  MODULE_DEVICE_TABLE(of, dumb_vga_match);
> --
> 2.9.3
>

+ Maxime

Sorry, I forgot to include your e-mail.

Bartosz

[PATCH v5 4/4] ARM: dts: da850: specify the maximum pixel clock rate for tilcdc

2016-12-07 Thread Bartosz Golaszewski 
At maximum CPU frequency of 300 MHz the maximum pixel clock frequency
is 37.5 MHz[1]. We must filter out any mode for which the calculated
pixel clock rate would exceed this value.

Specify the max-pixelclock property for the display node for
da850-lcdk.

[1] 
http://processors.wiki.ti.com/index.php/OMAP-L1x/C674x/AM1x_LCD_Controller_(LCDC)_Throughput_and_Optimization_Techniques

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/boot/dts/da850.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 3f51e59..ba5bf80 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -452,6 +452,7 @@
compatible = "ti,da850-tilcdc";
reg = <0x213000 0x1000>;
interrupts = <52>;
+   max-pixelclock = <37500>;
status = "disabled";
};
};
-- 
2.9.3

[PATCH v5 3/4] ARM: dts: da850-lcdk: add the vga-bridge node

2016-12-07 Thread Bartosz Golaszewski 
Add the vga-bridge node to the board DT together with corresponding
ports and vga connector. This allows to retrieve the edid info from
the display automatically.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/boot/dts/da850-lcdk.dts | 67 
 1 file changed, 67 insertions(+)

diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index afcb482..39602eb 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -51,6 +51,51 @@
system-clock-frequency = <24576000>;
};
};
+
+   vga-bridge {
+   compatible = "ti,ths8135";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   vga_bridge_in: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <&lcdc_out_vga>;
+   };
+   };
+
+   port at 1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   vga_bridge_out: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <&vga_con_in>;
+   };
+   };
+   };
+   };
+
+   vga {
+   compatible = "vga-connector";
+
+   ddc-i2c-bus = <&i2c0>;
+
+   port {
+   vga_con_in: endpoint {
+   remote-endpoint = <&vga_bridge_out>;
+   };
+   };
+   };
 };

 &pmx_core {
@@ -236,3 +281,25 @@
 &memctrl {
status = "okay";
 };
+
+&lcdc {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <&lcd_pins>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   lcdc_out: port at 1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   lcdc_out_vga: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <&vga_bridge_in>;
+   };
+   };
+   };
+};
-- 
2.9.3

  1   2   >