Re: [PATCH 4/4] dt-bindings: Add missing 'additionalProperties: false'

[Masahiro Yamada]

On Thu, Mar 26, 2020 at 7:06 AM Rob Herring  wrote:
>
> Setting 'additionalProperties: false' is frequently omitted, but is
> important in order to check that there aren't extra undocumented
> properties in a binding.
>
> Ideally, we'd just add this automatically and make this the default, but
> there's some cases where it doesn't work. For example, if a common
> schema is referenced, then properties in the common schema aren't part
> of what's considered for 'additionalProperties'. Also, sometimes there
> are bus specific properties such as 'spi-max-frequency' that go into
> bus child nodes, but aren't defined in the child node's schema.
>
> So let's stick with the json-schema defined default and add
> 'additionalProperties: false' where needed. This will be a continual
> review comment and game of wack-a-mole.
>
> Signed-off-by: Rob Herring 
> ---


>  .../devicetree/bindings/gpio/socionext,uniphier-gpio.yaml  | 2 ++


You may have already queue this up, but just in case.

Acked-by: Masahiro Yamada 

-- 
Best Regards
Masahiro Yamada
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vc4: Fix HDMI mode validation

[Nicolas Saenz Julienne]

On Fri, 2020-03-27 at 13:40 +0100, Maxime Ripard wrote:
> On Fri, Mar 27, 2020 at 12:46:52PM +0100, Nicolas Saenz Julienne wrote:
> > Hi Daniel,
> > 
> > On Thu, 2020-03-26 at 13:20 +0100, Nicolas Saenz Julienne wrote:
> > > Current mode validation impedes setting up some video modes which should
> > > be supported otherwise. Namely 1920x1200@60Hz.
> > > 
> > > Fix this by lowering the minimum HDMI state machine clock to pixel clock
> > > ratio allowed.
> > > 
> > > Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks")
> > > Reported-by: Stefan Wahren 
> > > Suggested-by: Dave Stevenson 
> > > Signed-off-by: Nicolas Saenz Julienne 
> > 
> > Would it be possible for you to take this in for v5.7 (or as a fix for v5.6,
> > but it seems a little late)?
> > 
> > A device-tree patch I have to channel trough the SoC tree depends on this to
> > avoid regressions.
> 
> I've applied it for 5.7-rc1

Thanks!



signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/4] dt-bindings: Clean-up schema errors due to missing 'addtionalProperties: false'

[Masahiro Yamada]

On Thu, Mar 26, 2020 at 7:06 AM Rob Herring  wrote:
>
> Numerous schemas are missing 'additionalProperties: false' statements which
> ensures a binding doesn't have any extra undocumented properties or child
> nodes. Fixing this reveals various missing properties, so let's fix all
> those occurrences.
>
> Cc: Stephen Boyd 
> Cc: Linus Walleij 
> Cc: Bartosz Golaszewski 
> Cc: Masahiro Yamada 
> Cc: Jonathan Cameron 
> Cc: Hartmut Knaack 
> Cc: Lars-Peter Clausen 
> Cc: Peter Meerwald-Stadler 
> Cc: Neil Armstrong 
> Cc: Mauro Carvalho Chehab 
> Cc: Kevin Hilman 
> Cc: Lee Jones 
> Cc: "David S. Miller" 
> Cc: Liam Girdwood 
> Cc: Mark Brown 
> Cc: Guillaume La Roque 
> Cc: Zhang Rui 
> Cc: Daniel Lezcano 
> Cc: Thomas Gleixner 
> Cc: linux-...@vger.kernel.org
> Cc: linux-g...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: linux-amlo...@lists.infradead.org
> Cc: net...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---



>  .../gpio/socionext,uniphier-gpio.yaml |  2 ++


You may have already queue this up, but just in case.

Acked-by: Masahiro Yamada 


-- 
Best Regards
Masahiro Yamada
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 5/8] ARM: DTS: omap36xx: add sgx gpu child node

[H. Nikolaus Schaller]

and add interrupt.

Tested-by: H. Nikolaus Schaller  # GTA04, BeagleBoard XM
Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap36xx.dtsi | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 71f3c8f1f924..b308dbb3b1bb 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -211,10 +211,11 @@ sgx_module: target-module@5000 {
#size-cells = <1>;
ranges = <0 0x5000 0x200>;
 
-   /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+   gpu: gpu@0 {
+   compatible = "ti,omap3-sgx530-125", 
"img,sgx530-125", "img,sgx530";
+   reg = <0x0 0x1>;/* 64kB */
+   interrupts = <21>;
+   };
};
};
 
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 hmm 4/9] mm/hmm: remove HMM_FAULT_SNAPSHOT

[Jason Gunthorpe]

From: Jason Gunthorpe 

Now that flags are handled on a fine-grained per-page basis this global
flag is redundant and has a confusing overlap with the pfn_flags_mask and
default_flags.

Normalize the HMM_FAULT_SNAPSHOT behavior into one place. Callers needing
the SNAPSHOT behavior should set a pfn_flags_mask and default_flags that
always results in a cleared HMM_PFN_VALID. Then no pages will be faulted,
and HMM_FAULT_SNAPSHOT is not a special flow that overrides the masking
mechanism.

As this is the last flag, also remove the flags argument. If future flags
are needed they can be part of the struct hmm_range function arguments.

Signed-off-by: Jason Gunthorpe 
---
 Documentation/vm/hmm.rst| 12 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  2 +-
 drivers/gpu/drm/nouveau/nouveau_svm.c   |  2 +-
 include/linux/hmm.h |  5 +
 mm/hmm.c| 17 +
 5 files changed, 17 insertions(+), 21 deletions(-)

diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst
index 95fec596836262..4e3e9362afeb10 100644
--- a/Documentation/vm/hmm.rst
+++ b/Documentation/vm/hmm.rst
@@ -161,13 +161,11 @@ device must complete the update before the driver 
callback returns.
 When the device driver wants to populate a range of virtual addresses, it can
 use::
 
-  long hmm_range_fault(struct hmm_range *range, unsigned int flags);
+  long hmm_range_fault(struct hmm_range *range);
 
-With the HMM_RANGE_SNAPSHOT flag, it will only fetch present CPU page table
-entries and will not trigger a page fault on missing or non-present entries.
-Without that flag, it does trigger a page fault on missing or read-only entries
-if write access is requested (see below). Page faults use the generic mm page
-fault code path just like a CPU page fault.
+It will trigger a page fault on missing or read-only entries if write access is
+requested (see below). Page faults use the generic mm page fault code path just
+like a CPU page fault.
 
 Both functions copy CPU page table entries into their pfns array argument. Each
 entry in that array corresponds to an address in the virtual range. HMM
@@ -197,7 +195,7 @@ The usage pattern is::
  again:
   range.notifier_seq = mmu_interval_read_begin(&interval_sub);
   down_read(&mm->mmap_sem);
-  ret = hmm_range_fault(&range, HMM_RANGE_SNAPSHOT);
+  ret = hmm_range_fault(&range);
   if (ret) {
   up_read(&mm->mmap_sem);
   if (ret == -EBUSY)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 90821ce5e6cad0..c520290709371b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -856,7 +856,7 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo *bo, 
struct page **pages)
range->notifier_seq = mmu_interval_read_begin(&bo->notifier);
 
down_read(&mm->mmap_sem);
-   r = hmm_range_fault(range, 0);
+   r = hmm_range_fault(range);
up_read(&mm->mmap_sem);
if (unlikely(r <= 0)) {
/*
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c 
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index 39c731a99937c6..e3797b2d4d1759 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -540,7 +540,7 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
range.default_flags = 0;
range.pfn_flags_mask = -1UL;
down_read(&mm->mmap_sem);
-   ret = hmm_range_fault(&range, 0);
+   ret = hmm_range_fault(&range);
up_read(&mm->mmap_sem);
if (ret <= 0) {
if (ret == 0 || ret == -EBUSY)
diff --git a/include/linux/hmm.h b/include/linux/hmm.h
index daee6508a3f609..7475051100c782 100644
--- a/include/linux/hmm.h
+++ b/include/linux/hmm.h
@@ -117,13 +117,10 @@ static inline struct page *hmm_device_entry_to_page(const 
struct hmm_range *rang
return pfn_to_page(entry >> range->pfn_shift);
 }
 
-/* Don't fault in missing PTEs, just snapshot the current state. */
-#define HMM_FAULT_SNAPSHOT (1 << 1)
-
 /*
  * Please see Documentation/vm/hmm.rst for how to use the range API.
  */
-long hmm_range_fault(struct hmm_range *range, unsigned int flags);
+long hmm_range_fault(struct hmm_range *range);
 
 /*
  * HMM_RANGE_DEFAULT_TIMEOUT - default timeout (ms) when waiting for a range
diff --git a/mm/hmm.c b/mm/hmm.c
index 136de474221d77..8dbd9e1d0308b4 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -29,7 +29,6 @@
 struct hmm_vma_walk {
struct hmm_range*range;
unsigned long   last;
-   unsigned intflags;
 };
 
 enum {
@@ -112,9 +111,6 @@ static unsigned int hmm_pte_need_fault(const struct 
hmm_vma_walk *hmm_vma_walk,
 {
struct hmm_range *range = hmm_vma_walk->range;
 
-   if (hmm_vma_walk->flags & HMM_FAULT_SNAPSHOT)
-   return 0;
-
/*

[PATCH v2 10/22] interconnect: Relax requirement in of_icc_get_from_provider()

[Dmitry Osipenko]

From: Artur Świgoń 

This patch relaxes the condition in of_icc_get_from_provider() so that it
is no longer required to set #interconnect-cells = <1> in the DT. In case
of the devfreq driver for exynos-bus, #interconnect-cells is always zero.

Signed-off-by: Artur Świgoń 
[dig...@gmail.com: added cells_num checking for of_icc_xlate_onecell()]
Signed-off-by: Dmitry Osipenko 
---
 drivers/interconnect/core.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index 2c6515e3ecf1..7d09656734c1 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -335,7 +335,7 @@ static struct icc_node *of_icc_get_from_provider(struct 
of_phandle_args *spec)
struct icc_node *node = ERR_PTR(-EPROBE_DEFER);
struct icc_provider *provider;
 
-   if (!spec || spec->args_count != 1)
+   if (!spec)
return ERR_PTR(-EINVAL);
 
mutex_lock(&icc_lock);
@@ -851,6 +851,15 @@ EXPORT_SYMBOL_GPL(icc_nodes_remove);
  */
 int icc_provider_add(struct icc_provider *provider)
 {
+   struct device_node *np = provider->dev->of_node;
+   u32 cells_num;
+   int err;
+
+   err = of_property_read_u32(np, "#interconnect-cells", &cells_num);
+   if (WARN_ON(err))
+   return err;
+   if (WARN_ON(provider->xlate == of_icc_xlate_onecell && cells_num != 1))
+   return -EINVAL;
if (WARN_ON(!provider->set))
return -EINVAL;
if (WARN_ON(!provider->xlate))
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH] staging: fbtft: Replace udelay with preferred usleep_range

[Sam Muhammed]

On Sun, 2020-03-29 at 12:37 +0200, Julia Lawall wrote:
> 
> On Sun, 29 Mar 2020, Soumyajit Deb wrote:
> 
> > I had the same doubt the other day about the replacement of udelay() with
> > usleep_range(). The corresponding range for the single argument value of
> > udelay() is quite confusing as I couldn't decide the range. But as much as I
> > noticed checkpatch.pl gives warning for replacing udelay() with
> > usleep_range() by checking the argument value of udelay(). In the
> > documentation, it is written udelay() should be used for a sleep time of at
> > most 10 microseconds but between 10 microseconds and 20 milliseconds,
> > usleep_range() should be used. 
> > I think the range is code specific and will depend on what range is
> > acceptable and doesn't break the code.
> >  Please correct me if I am wrong.
> 
> The range depends on the associated hardware.  Just because checkpatch
> suggests something doesn't mean that it is easy to address the problem.
> 
> julia
> 

Hi all, i think when it comes to a significant change in the code, we
should at least be familiar with the driver or be able to test the
change.

In the very beginning of the Documentation/timers/timers-howto.rst
there is the question:
"Is my code in an atomic context?"
It's not just about the range, it's more of at which context this code
runs, for atomic-context -> udelay must be used.
for non-atomic context -> usleep-range is better for power-management.

unless we are familiar with the driver we wouldn't really know in what
context this code is run at.

This thread though had the same conversation about this change, for the
same driver.
https://patchwork.kernel.org/patch/11137125/

Sam

> >
> > More clarification on this issue will be helpful.
> >
> > On Sun, 29 Mar 2020, 15:17 Julia Lawall,  wrote:
> >
> >
> >   On Sun, 29 Mar 2020, John Wyatt wrote:
> >
> >   > On Sun, 2020-03-29 at 11:28 +0200, Julia Lawall wrote:
> >   > >
> >   > > On Sun, 29 Mar 2020, John B. Wyatt IV wrote:
> >   > >
> >   > > > Fix style issue with usleep_range being reported as
> >   preferred over
> >   > > > udelay.
> >   > > >
> >   > > > Issue reported by checkpatch.
> >   > > >
> >   > > > Please review.
> >   > > >
> >   > > > As written in Documentation/timers/timers-howto.rst udelay
> >   is the
> >   > > > generally preferred API. hrtimers, as noted in the docs,
> >   may be too
> >   > > > expensive for this short timer.
> >   > > >
> >   > > > Are the docs out of date, or, is this a checkpatch issue?
> >   > > >
> >   > > > Signed-off-by: John B. Wyatt IV 
> >   > > > ---
> >   > > >  drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +-
> >   > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> >   > > >
> >   > > > diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c
> >   > > > b/drivers/staging/fbtft/fb_agm1264k-fl.c
> >   > > > index ec97ad27..019c8cce6bab 100644
> >   > > > --- a/drivers/staging/fbtft/fb_agm1264k-fl.c
> >   > > > +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
> >   > > > @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par)
> >   > > >   dev_dbg(par->info->device, "%s()\n", __func__);
> >   > > >
> >   > > >   gpiod_set_value(par->gpio.reset, 0);
> >   > > > - udelay(20);
> >   > > > + usleep_range(20, 20);
> >   > >
> >   > > usleep_range should have a range, eg usleep_range(50,
> >   100);.  But it
> >   > > is
> >   > > hard to know a priori what the range should be.  So it is
> >   probably
> >   > > better
> >   > > to leave the code alone.
> >   >
> >   > Understood.
> >   >
> >   > With the question I wrote in the commit message:
> >   >
> >   > "As written in Documentation/timers/timers-howto.rst udelay is
> >   the
> >   > generally preferred API. hrtimers, as noted in the docs, may
> >   be too
> >   > expensive for this short timer.
> >   >
> >   > Are the docs out of date, or, is this a checkpatch issue?"
> >   >
> >   > Is usleep_range too expensive for this operation?
> >   >
> >   > Why does checkpatch favor usleep_range while the docs favor
> >   udelay?
> >
> >   I don't know the answer in detail, but it is quite possible that
> >   checkpatch doesn't pay any attention to the delay argument. 
> >   Checkpatch is
> >   a perl script that highlights things that may be of concern.  It
> >   is not a
> >   precise static analsis tool.
> >
> >   As a matter of form, all of your Please review comments should
> >   have been
> >   put below the ---.  Currently, if someone had wanted to apply
> >   the patch,
> >   you would make them do extra work to remove this information.
> >
> >   julia
> >
> >   >
> >   > >
> >   > > julia
> >   > >
> >   > > >   gpiod_set_value(par->gpio.reset, 1);
> >   > > >   

Re: [DPU PATCH v4 1/5] dt-bindings: msm/dp: add bindings of DP/DP-PLL driver for Snapdragon

[varar]

Hi Stephen Boyd,

Thanks for reviewing the change.
I have updated my comments inline for some comments, please check and 
let us know your views.
Rest of the comments are addressed, will try to post a new patchset in 
couple of days.


Thanks,
--Vara

On 2020-03-18 17:48, Stephen Boyd wrote:

Quoting Vara Reddy (2020-03-04 16:10:24)

From: Chandan Uddaraju 

Add bindings for Snapdragon DisplayPort and
display-port PLL driver.

Changes in V2:
Provide details about sel-gpio

Changes in V4:
Provide details about max dp lanes
Change the commit text

Signed-off-by: Chandan Uddaraju 
Signed-off-by: Vara Reddy 
---
 .../devicetree/bindings/display/msm/dp.txt | 252 
+

 .../devicetree/bindings/display/msm/dpu.txt|  16 +-
 2 files changed, 264 insertions(+), 4 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dp.txt


Having this in YAML will certainly make it easier to review. Please do
that as Rob H has asked.



diff --git a/Documentation/devicetree/bindings/display/msm/dp.txt 
b/Documentation/devicetree/bindings/display/msm/dp.txt

new file mode 100644
index 000..1a4e17f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/dp.txt
@@ -0,0 +1,252 @@
+Qualcomm Technologies, Inc.
+DP is the master Display Port device which supports DP host 
controllers that are compatible with VESA Display Port interface 
specification.

+DP Controller: Required properties:
+- compatible:   Should be "qcom,dp-display".
+- reg:  Base address and length of DP hardware's 
memory mapped regions.

+- cell-index:   Specifies the controller instance.
+- reg-names:A list of strings that name the list of regs.
+   "dp_ahb" - DP controller memory region.
+   "dp_aux" - DP AUX memory region.
+   "dp_link" - DP link layer memory region.
+   "dp_p0" - DP pixel clock domain memory region.
+   "dp_phy" - DP PHY memory region.
+   "dp_ln_tx0" - USB3 DP PHY combo TX-0 lane 
memory region.
+   "dp_ln_tx1" - USB3 DP PHY combo TX-1 lane 
memory region.
+   "dp_mmss_cc" - Display Clock Control memory 
region.

+   "qfprom_physical" - QFPROM Phys memory region.
+   "dp_pll" - USB3 DP combo PLL memory region.
+   "usb3_dp_com" - USB3 DP PHY combo memory 
region.

+   "hdcp_physical" - DP HDCP memory region.


A handful of these register properties overlap with the USB PHY region.
I suspect the existing qcom,sc7180-qmp-usb3-phy USB PHY binding that we
have is wrong. It should describe both the USB part and the DP part of
the combo PHY. Probably the DP part can be a subnode like how the
superspeed PHY is a child node of the wrapper node. Then we'll have to
figure out how to coordinate the access to usb3_dp_com (which I presume
corresponds to the dp_com region in the usb3-phy binding) so that the
USB and DP PHY drivers can figure out how to configure the "type-c" 
pins
on the SoC to be 2 lanes DP and 2 lanes USB or 4 lanes USB or 4 lanes 
DP.


msm usb3_dp_com region has two separate software interface to combo phy 
used by DP and USB.

We are trying to map DP specific address space for configuration.
I am not sure if USB can figure out dynamically a 2 lane DP and 2 lane 
USB case
as i think we need to feed this information based on our hardware design 
through dtsi.





+- interrupt-parent phandle to the interrupt parent device node.
+- interrupts:  The interrupt signal from the DP block.
+- clocks:   Clocks required for Display Port operation. 
See [1] for details on clock bindings.
+- clock-names:  Names of the clocks corresponding to handles. 
Following clocks are required:
+   "core_aux_clk", 
"core_usb_ref_clk_src","core_usb_ref_clk", "core_usb_cfg_ahb_clk",
+   "core_usb_pipe_clk", "ctrl_link_clk", 
"ctrl_link_iface_clk", "ctrl_crypto_clk",
+   "ctrl_pixel_clk", "pixel_clk_rcg", 
"pixel_parent".


Please remove _clk suffix on all clock names. It's redundant.


+- pll-node:phandle to DP PLL node.
+- vdda-1p2-supply: phandle to vdda 1.2V regulator node.
+- vdda-0p9-supply: phandle to vdda 0.9V regulator node.
+- qcom,aux-cfg0-settings:  Specifies the DP AUX 
configuration 0 settings. The first
+   entry in this array 
corresponds to the register offset
+   within DP AUX, while the 
remaining entries indicate the

+   programmable values.
+- qcom,aux-cfg1-settings:  Specifies the DP AUX 
configuration 1 settings. The first
+   entry in this array 
corresponds to the register offset
+  

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Christophe Leroy]

Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :

On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:

On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
 wrote:

On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:

On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:

On Fri, Mar 27, 2020 at 1:12 PM Michal Simek  wrote:


...


It does raise a follow-up question about ppc40x though: is it time to
retire all of it?


Who knows?

I have in possession nice WD My Book Live, based on this architecture, and I
won't it gone from modern kernel support. OTOH I understand that amount of real
users not too big.


+Cc: Christian Lamparter, whom I owe for that WD box.


According to https://openwrt.org/toh/wd/mybooklive, that one is based on
APM82181/ppc464, so it is about several generations newer than what I
asked about (ppc40x).


Ah, and I have Amiga board, but that one is being used only for testing, so,
I don't care much.


I think there are a couple of ppc440 based Amiga boards, but again, not 405
to my knowledge.


Ah, you are right. No objections from ppc40x removal!



Removing 40x would help cleaning things a bit. For instance 40x is the 
last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x 
we can get rid of PTE_ATOMIC_UPDATES completely.



If no one objects, I can prepare a series to drop support for 40x 
completely.


Michael, any thought ?

Christophe
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Michal Simek]

Hi,

recently we wanted to update xilinx intc driver and we found that function
which we wanted to remove is still wired by ancient Xilinx PowerPC
platforms. Here is the thread about it.
https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa...@xilinx.com/

I have been talking about it internally and there is no interest in these
platforms and it is also orphan for quite a long time. None is really
running/testing these platforms regularly that's why I think it makes sense
to remove them also with drivers which are specific to this platform.

U-Boot support was removed in 2017 without anybody complain about it
https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed

Based on current ppc/next.

If anyone has any objection about it, please let me know.

Thanks,
Michal


Michal Simek (2):
  sound: ac97: Remove sound driver for ancient platform
  powerpc: Remove Xilinx PPC405/PPC440 support

 Documentation/devicetree/bindings/xilinx.txt |  143 --
 Documentation/powerpc/bootwrapper.rst|   28 +-
 MAINTAINERS  |6 -
 arch/powerpc/Kconfig.debug   |2 +-
 arch/powerpc/boot/Makefile   |7 +-
 arch/powerpc/boot/dts/Makefile   |1 -
 arch/powerpc/boot/dts/virtex440-ml507.dts|  406 --
 arch/powerpc/boot/dts/virtex440-ml510.dts|  466 ---
 arch/powerpc/boot/ops.h  |1 -
 arch/powerpc/boot/serial.c   |5 -
 arch/powerpc/boot/uartlite.c |   79 --
 arch/powerpc/boot/virtex.c   |   97 --
 arch/powerpc/boot/virtex405-head.S   |   31 -
 arch/powerpc/boot/wrapper|8 -
 arch/powerpc/configs/40x/virtex_defconfig|   75 -
 arch/powerpc/configs/44x/virtex5_defconfig   |   74 -
 arch/powerpc/configs/ppc40x_defconfig|8 -
 arch/powerpc/configs/ppc44x_defconfig|8 -
 arch/powerpc/include/asm/xilinx_intc.h   |   16 -
 arch/powerpc/include/asm/xilinx_pci.h|   21 -
 arch/powerpc/kernel/cputable.c   |   39 -
 arch/powerpc/platforms/40x/Kconfig   |   31 -
 arch/powerpc/platforms/40x/Makefile  |1 -
 arch/powerpc/platforms/40x/virtex.c  |   54 -
 arch/powerpc/platforms/44x/Kconfig   |   37 -
 arch/powerpc/platforms/44x/Makefile  |2 -
 arch/powerpc/platforms/44x/virtex.c  |   60 -
 arch/powerpc/platforms/44x/virtex_ml510.c|   30 -
 arch/powerpc/platforms/Kconfig   |4 -
 arch/powerpc/sysdev/Makefile |2 -
 arch/powerpc/sysdev/xilinx_intc.c|   88 --
 arch/powerpc/sysdev/xilinx_pci.c |  132 --
 arch/powerpc/xmon/ppc-dis.c  |6 -
 arch/powerpc/xmon/ppc-opc.c  |   23 -
 arch/powerpc/xmon/ppc.h  |5 -
 drivers/char/Kconfig |2 +-
 drivers/video/fbdev/Kconfig  |2 +-
 sound/drivers/Kconfig|   12 -
 sound/drivers/Makefile   |2 -
 sound/drivers/ml403-ac97cr.c | 1298 --
 40 files changed, 7 insertions(+), 3305 deletions(-)
 delete mode 100644 arch/powerpc/boot/dts/virtex440-ml507.dts
 delete mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
 delete mode 100644 arch/powerpc/boot/uartlite.c
 delete mode 100644 arch/powerpc/boot/virtex.c
 delete mode 100644 arch/powerpc/boot/virtex405-head.S
 delete mode 100644 arch/powerpc/configs/40x/virtex_defconfig
 delete mode 100644 arch/powerpc/configs/44x/virtex5_defconfig
 delete mode 100644 arch/powerpc/include/asm/xilinx_intc.h
 delete mode 100644 arch/powerpc/include/asm/xilinx_pci.h
 delete mode 100644 arch/powerpc/platforms/40x/virtex.c
 delete mode 100644 arch/powerpc/platforms/44x/virtex.c
 delete mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
 delete mode 100644 arch/powerpc/sysdev/xilinx_intc.c
 delete mode 100644 arch/powerpc/sysdev/xilinx_pci.c
 delete mode 100644 sound/drivers/ml403-ac97cr.c

-- 
2.26.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 6/8] ARM: DTS: omap4: add sgx gpu child node

[H. Nikolaus Schaller]

and add interrupt.

Since omap4420/30/60 and omap4470 come with different SGX variants
we need to introduce a new omap4470.dtsi. If an omap4470 board
does not want to use SGX it is no problem to still include
omap4460.dtsi.

Tested-by: H. Nikolaus Schaller  # PandaBoard ES
Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap4.dtsi   | 11 ++-
 arch/arm/boot/dts/omap4470.dts | 15 +++
 2 files changed, 21 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap4470.dts

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 9a87440d0b9d..939061f96523 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -390,7 +390,7 @@ abb_iva: regulator-abb-iva {
status = "disabled";
};
 
-   target-module@5600 {
+   sgx_module: target-module@5600 {
compatible = "ti,sysc-omap4", "ti,sysc";
reg = <0x5600fe00 0x4>,
  <0x5600fe10 0x4>;
@@ -409,10 +409,11 @@ target-module@5600 {
#size-cells = <1>;
ranges = <0 0x5600 0x200>;
 
-   /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+   gpu: gpu@0 {
+   compatible = "ti,omap4-sgx540-120", 
"img,sgx540-120", "img,sgx540";
+   reg = <0x0 0x200>;  /* 32MB */
+   interrupts = ;
+   };
};
 
dss: dss@5800 {
diff --git a/arch/arm/boot/dts/omap4470.dts b/arch/arm/boot/dts/omap4470.dts
new file mode 100644
index ..19b554612401
--- /dev/null
+++ b/arch/arm/boot/dts/omap4470.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Device Tree Source for OMAP4470 SoC
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+#include "omap4460.dtsi"
+
+&sgx {
+   compatible = "img,sgx544-112", "img,sgx544", "ti,omap-omap4-sgx544-112";
+};
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH] staging: fbtft: Replace udelay with preferred usleep_range

[Soumyajit Deb]

I had the same doubt the other day about the replacement of udelay() with
usleep_range(). The corresponding range for the single argument value of
udelay() is quite confusing as I couldn't decide the range.
But as much as I noticed checkpatch.pl gives warning for replacing udelay()
with usleep_range() by checking the argument value of udelay(). In the
documentation, it is written udelay() should be used for a sleep time of at
most 10 microseconds but between 10 microseconds and 20 milliseconds,
usleep_range() should be used.
I think the range is code specific and will depend on what range is
acceptable and doesn't break the code.
 Please correct me if I am wrong.

More clarification on this issue will be helpful.

On Sun, 29 Mar 2020, 15:17 Julia Lawall,  wrote:

>
>
> On Sun, 29 Mar 2020, John Wyatt wrote:
>
> > On Sun, 2020-03-29 at 11:28 +0200, Julia Lawall wrote:
> > >
> > > On Sun, 29 Mar 2020, John B. Wyatt IV wrote:
> > >
> > > > Fix style issue with usleep_range being reported as preferred over
> > > > udelay.
> > > >
> > > > Issue reported by checkpatch.
> > > >
> > > > Please review.
> > > >
> > > > As written in Documentation/timers/timers-howto.rst udelay is the
> > > > generally preferred API. hrtimers, as noted in the docs, may be too
> > > > expensive for this short timer.
> > > >
> > > > Are the docs out of date, or, is this a checkpatch issue?
> > > >
> > > > Signed-off-by: John B. Wyatt IV 
> > > > ---
> > > >  drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c
> > > > b/drivers/staging/fbtft/fb_agm1264k-fl.c
> > > > index ec97ad27..019c8cce6bab 100644
> > > > --- a/drivers/staging/fbtft/fb_agm1264k-fl.c
> > > > +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
> > > > @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par)
> > > >   dev_dbg(par->info->device, "%s()\n", __func__);
> > > >
> > > >   gpiod_set_value(par->gpio.reset, 0);
> > > > - udelay(20);
> > > > + usleep_range(20, 20);
> > >
> > > usleep_range should have a range, eg usleep_range(50, 100);.  But it
> > > is
> > > hard to know a priori what the range should be.  So it is probably
> > > better
> > > to leave the code alone.
> >
> > Understood.
> >
> > With the question I wrote in the commit message:
> >
> > "As written in Documentation/timers/timers-howto.rst udelay is the
> > generally preferred API. hrtimers, as noted in the docs, may be too
> > expensive for this short timer.
> >
> > Are the docs out of date, or, is this a checkpatch issue?"
> >
> > Is usleep_range too expensive for this operation?
> >
> > Why does checkpatch favor usleep_range while the docs favor udelay?
>
> I don't know the answer in detail, but it is quite possible that
> checkpatch doesn't pay any attention to the delay argument.  Checkpatch is
> a perl script that highlights things that may be of concern.  It is not a
> precise static analsis tool.
>
> As a matter of form, all of your Please review comments should have been
> put below the ---.  Currently, if someone had wanted to apply the patch,
> you would make them do extra work to remove this information.
>
> julia
>
> >
> > >
> > > julia
> > >
> > > >   gpiod_set_value(par->gpio.reset, 1);
> > > >   mdelay(120);
> > > >  }
> > > > --
> > > > 2.25.1
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "outreachy-kernel" group.
> > > > To unsubscribe from this group and stop receiving emails from it,
> > > > send an email to outreachy-kernel+unsubscr...@googlegroups.com.
> > > > To view this discussion on the web visit
> > > >
> https://groups.google.com/d/msgid/outreachy-kernel/20200329092204.770405-1-jbwyatt4%40gmail.com
> > > > .
> > > >
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/alpine.DEB.2.21.2003291144460.2990%40hadrien
> .
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: anx6345: set correct BPC for display_info of connector

[Jernej Škrabec]

Hi!

Dne ponedeljek, 30. marec 2020 ob 00:22:53 CEST je Vasily Khoruzhick 
napisal(a):
> Some drivers (e.g. sun4i-drm) need this info to decide whether they
> need to enable dithering. Currently driver reports what panel supports
> and if panel supports 8 we don't get dithering enabled.
> 
> Hardcode BPC to 6 for now since that's the only BPC
> that driver supports.

Acked-by: Jernej Skrabec 

Best regards,
Jernej

> 
> Fixes: 6aa192698089 ("drm/bridge: Add Analogix anx6345 support")
> Signed-off-by: Vasily Khoruzhick 
> ---
>  drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c index
> d7cb10c599a3..ea5de9395662 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -494,6 +494,9 @@ static int anx6345_get_modes(struct drm_connector
> *connector)
> 
>   num_modes += drm_add_edid_modes(connector, anx6345->edid);
> 
> + /* Driver currently supports only 6bpc */
> + connector->display_info.bpc = 6;
> +
>  unlock:
>   if (power_off)
>   anx6345_poweroff(anx6345);




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 00/22] Introduce memory interconnect for NVIDIA Tegra SoCs

[Dmitry Osipenko]

Hello,

This series brings initial support for memory interconnect to Tegra20 and
Tegra30 SoCs. The interconnect provides are quite generic and should be
suitable for all Tegra SoCs, but currently support is added only for these
two generations of Tegra SoCs.

For the starter only display controllers are getting interconnect API
support, others could be supported later on. The display controllers
have the biggest demand for interconnect API right now because dynamic
memory frequency scaling can't be done safely without taking into account
bandwidth requirement from the displays.

(!) Please note that the EMC patches are made on top of the other EMC
patches [1][2] that I was sending out recently.

[1] https://patchwork.ozlabs.org/project/linux-tegra/list/?series=164165
[2] https://patchwork.ozlabs.org/project/linux-tegra/list/?series=165451

Changelog:

v2: - Instead of a single dma-mem interconnect path, the paths are now
  defined per memory client.

- The EMC provider now uses #interconnect-cells=<0>.

- Dropped Tegra124 because there is no enough information about how to
  properly calculate required EMC clock rate for it and I don't have
  hardware for testing. Somebody else will have to work on it.

- Moved interconnect providers code into drivers/memory/tegra/*.

- Added "Create tegra20-devfreq device" patch because interconnect
  is not very usable without the devfreq memory auto-scaling since
  memory freq will be fixed to the display's requirement.

Artur Świgoń (1):
  interconnect: Relax requirement in of_icc_get_from_provider()

Dmitry Osipenko (21):
  dt-bindings: memory: tegra20: mc: Document new interconnect property
  dt-bindings: memory: tegra20: emc: Document new interconnect property
  dt-bindings: memory: tegra30: mc: Document new interconnect property
  dt-bindings: memory: tegra30: emc: Document new interconnect property
  dt-bindings: host1x: Document new interconnect properties
  dt-bindings: memory: tegra20: Add memory client IDs
  dt-bindings: memory: tegra30: Add memory client IDs
  ARM: tegra: Add interconnect properties to Tegra20 device-tree
  ARM: tegra: Add interconnect properties to Tegra30 device-tree
  memory: tegra: Register as interconnect provider
  memory: tegra20-emc: Use devm_platform_ioremap_resource
  memory: tegra20-emc: Continue probing if timings are missing in
device-tree
  memory: tegra20-emc: Register as interconnect provider
  memory: tegra20-emc: Create tegra20-devfreq device
  memory: tegra30-emc: Continue probing if timings are missing in
device-tree
  memory: tegra30-emc: Register as interconnect provider
  drm/tegra: dc: Support memory bandwidth management
  drm/tegra: dc: Tune up high priority request controls for Tegra20
  drm/tegra: dc: Extend debug stats with total number of events
  ARM: tegra: Enable interconnect API in tegra_defconfig
  ARM: multi_v7_defconfig: Enable interconnect API

 .../display/tegra/nvidia,tegra20-host1x.txt   |  68 +
 .../memory-controllers/nvidia,tegra20-emc.txt |   2 +
 .../memory-controllers/nvidia,tegra20-mc.txt  |   3 +
 .../nvidia,tegra30-emc.yaml   |   6 +
 .../memory-controllers/nvidia,tegra30-mc.yaml |   5 +
 arch/arm/boot/dts/tegra20.dtsi|  22 +-
 arch/arm/boot/dts/tegra30.dtsi|  23 +-
 arch/arm/configs/multi_v7_defconfig   |   1 +
 arch/arm/configs/tegra_defconfig  |   1 +
 drivers/gpu/drm/tegra/dc.c| 289 +-
 drivers/gpu/drm/tegra/dc.h|  13 +
 drivers/gpu/drm/tegra/drm.c   |  19 ++
 drivers/gpu/drm/tegra/plane.c |   1 +
 drivers/gpu/drm/tegra/plane.h |   4 +-
 drivers/interconnect/core.c   |  11 +-
 drivers/memory/tegra/mc.c | 118 +++
 drivers/memory/tegra/mc.h |   8 +
 drivers/memory/tegra/tegra20-emc.c| 161 --
 drivers/memory/tegra/tegra30-emc.c| 144 -
 include/dt-bindings/memory/tegra20-mc.h   |  53 
 include/dt-bindings/memory/tegra30-mc.h   |  67 
 include/soc/tegra/mc.h|   3 +
 22 files changed, 975 insertions(+), 47 deletions(-)

-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 hmm 9/9] mm/hmm: return error for non-vma snapshots

[Jason Gunthorpe]

From: Jason Gunthorpe 

The pagewalker does not call most ops with NULL vma, those are all routed
to hmm_vma_walk_hole() via ops->pte_hole instead.

Thus hmm_vma_fault() is only called with a NULL vma from
hmm_vma_walk_hole(), so hoist the NULL vma check to there.

Now it is clear that snapshotting with no vma is a HMM_PFN_ERROR as
without a vma we have no path to call hmm_vma_fault().

Reviewed-by: Christoph Hellwig 
Signed-off-by: Jason Gunthorpe 
---
 mm/hmm.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/mm/hmm.c b/mm/hmm.c
index e875d9ef0968fd..31d0f68689c32b 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -83,9 +83,6 @@ static int hmm_vma_fault(unsigned long addr, unsigned long 
end,
WARN_ON_ONCE(!required_fault);
hmm_vma_walk->last = addr;
 
-   if (!vma)
-   return -EFAULT;
-
if (required_fault & HMM_NEED_WRITE_FAULT) {
if (!(vma->vm_flags & VM_WRITE))
return -EPERM;
@@ -170,6 +167,11 @@ static int hmm_vma_walk_hole(unsigned long addr, unsigned 
long end,
npages = (end - addr) >> PAGE_SHIFT;
pfns = &range->pfns[i];
required_fault = hmm_range_need_fault(hmm_vma_walk, pfns, npages, 0);
+   if (!walk->vma) {
+   if (required_fault)
+   return -EFAULT;
+   return hmm_pfns_fill(addr, end, range, HMM_PFN_ERROR);
+   }
if (required_fault)
return hmm_vma_fault(addr, end, required_fault, walk);
hmm_vma_walk->last = addr;
-- 
2.25.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH] staging: fbtft: Replace udelay with preferred usleep_range

[John Wyatt]

On Sun, 2020-03-29 at 11:28 +0200, Julia Lawall wrote:
> 
> On Sun, 29 Mar 2020, John B. Wyatt IV wrote:
> 
> > Fix style issue with usleep_range being reported as preferred over
> > udelay.
> > 
> > Issue reported by checkpatch.
> > 
> > Please review.
> > 
> > As written in Documentation/timers/timers-howto.rst udelay is the
> > generally preferred API. hrtimers, as noted in the docs, may be too
> > expensive for this short timer.
> > 
> > Are the docs out of date, or, is this a checkpatch issue?
> > 
> > Signed-off-by: John B. Wyatt IV 
> > ---
> >  drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c
> > b/drivers/staging/fbtft/fb_agm1264k-fl.c
> > index ec97ad27..019c8cce6bab 100644
> > --- a/drivers/staging/fbtft/fb_agm1264k-fl.c
> > +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
> > @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par)
> > dev_dbg(par->info->device, "%s()\n", __func__);
> > 
> > gpiod_set_value(par->gpio.reset, 0);
> > -   udelay(20);
> > +   usleep_range(20, 20);
> 
> usleep_range should have a range, eg usleep_range(50, 100);.  But it
> is
> hard to know a priori what the range should be.  So it is probably
> better
> to leave the code alone.

Understood.

With the question I wrote in the commit message:

"As written in Documentation/timers/timers-howto.rst udelay is the
generally preferred API. hrtimers, as noted in the docs, may be too
expensive for this short timer.

Are the docs out of date, or, is this a checkpatch issue?"

Is usleep_range too expensive for this operation?

Why does checkpatch favor usleep_range while the docs favor udelay?

> 
> julia
> 
> > gpiod_set_value(par->gpio.reset, 1);
> > mdelay(120);
> >  }
> > --
> > 2.25.1
> > 
> > --
> > You received this message because you are subscribed to the Google
> > Groups "outreachy-kernel" group.
> > To unsubscribe from this group and stop receiving emails from it,
> > send an email to outreachy-kernel+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/outreachy-kernel/20200329092204.770405-1-jbwyatt4%40gmail.com
> > .
> > 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v3 4/8] dt-bindings: display: add ingenic-jz4780-hdmi DT Schema

[H. Nikolaus Schaller]

From: Sam Ravnborg 

Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
Based on .txt binding from Zubair Lutfullah Kakakhel

Signed-off-by: Sam Ravnborg 
Signed-off-by: H. Nikolaus Schaller 
Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
---
 .../bindings/display/ingenic-jz4780-hdmi.yaml | 82 +++
 1 file changed, 82 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml

diff --git a/Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml 
b/Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml
new file mode 100644
index ..a545ff8704eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/ingenic-jz4780-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bindings for Ingenic JZ4780 HDMI Transmitter
+
+maintainers:
+  - H. Nikolaus Schaller 
+
+description: |
+  The HDMI Transmitter in the Ingenic JZ4780 is a Synopsys DesignWare HDMI 1.4
+  TX controller IP with accompanying PHY IP.
+
+allOf:
+  - $ref: panel/panel-common.yaml#
+
+properties:
+  compatible:
+items:
+  - const: ingenic,jz4780-hdmi
+
+  reg:
+maxItems: 1
+description: the address & size of the LCD controller registers
+
+  reg-io-width:
+const: 4
+
+  interrupts:
+maxItems: 1
+description: Specifies the interrupt provided by parent
+
+  clocks:
+maxItems: 2
+description: Clock specifiers for isrf and iahb clocks
+
+  clock-names:
+items:
+  - const: isfr
+  - const: iahb
+
+  ddc-i2c-bus: true
+  ports: true
+
+required:
+- compatible
+- clocks
+- clock-names
+- ports
+- reg-io-width
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+hdmi: hdmi@1018 {
+compatible = "ingenic,jz4780-hdmi";
+reg = <0x1018 0x8000>;
+reg-io-width = <4>;
+ddc-i2c-bus = <&i2c4>;
+interrupt-parent = <&intc>;
+interrupts = <3>;
+clocks = <&cgu JZ4780_CLK_HDMI>, <&cgu JZ4780_CLK_AHB0>;
+clock-names = "isfr", "iahb";
+
+ports {
+hdmi_in: port {
+#address-cells = <1>;
+#size-cells = <0>;
+hdmi_in_lcd: endpoint@0 {
+reg = <0>;
+remote-endpoint = <&jz4780_out_hdmi>;
+};
+};
+};
+};
+
+...
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 hmm 6/9] mm/hmm: use device_private_entry_to_pfn()

[Jason Gunthorpe]

From: Jason Gunthorpe 

swp_offset() should not be called directly, the wrappers are supposed to
abstract away the encoding of the device_private specific information in
the swap entry.

Reviewed-by: Ralph Campbell 
Reviewed-by: Christoph Hellwig 
Tested-by: Ralph Campbell 
Signed-off-by: Jason Gunthorpe 
---
 mm/hmm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/hmm.c b/mm/hmm.c
index 3a71ec72b0a42f..3303686bf16d24 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -261,7 +261,7 @@ static int hmm_vma_handle_pte(struct mm_walk *walk, 
unsigned long addr,
 */
if (hmm_is_device_private_entry(range, entry)) {
*pfn = hmm_device_entry_from_pfn(range,
-   swp_offset(entry));
+   device_private_entry_to_pfn(entry));
*pfn |= range->flags[HMM_PFN_VALID];
if (is_write_device_private_entry(entry))
*pfn |= range->flags[HMM_PFN_WRITE];
-- 
2.25.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vc4: Fix HDMI mode validation

[Maxime Ripard]

On Fri, Mar 27, 2020 at 12:46:52PM +0100, Nicolas Saenz Julienne wrote:
> Hi Daniel,
>
> On Thu, 2020-03-26 at 13:20 +0100, Nicolas Saenz Julienne wrote:
> > Current mode validation impedes setting up some video modes which should
> > be supported otherwise. Namely 1920x1200@60Hz.
> >
> > Fix this by lowering the minimum HDMI state machine clock to pixel clock
> > ratio allowed.
> >
> > Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks")
> > Reported-by: Stefan Wahren 
> > Suggested-by: Dave Stevenson 
> > Signed-off-by: Nicolas Saenz Julienne 
>
> Would it be possible for you to take this in for v5.7 (or as a fix for v5.6,
> but it seems a little late)?
>
> A device-tree patch I have to channel trough the SoC tree depends on this to
> avoid regressions.

I've applied it for 5.7-rc1

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/3] AMDGPU / RADEON / DRM Fix mapping of user pages

[Quoc Kien Ly]

Sent from Mail for Windows 10

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 0/8] ARM/MIPS: DTS: add child nodes describing the PVRSGX GPU present in some OMAP SoC and JZ4780 (and many more)

[H. Nikolaus Schaller]

* reworked YAML bindings to pass dt_binding_check and be better grouped
* rename all nodes to "gpu: gpu@"
* removed "img,sgx5" from example - suggested by Rob Herring 


PATCH V4 2019-12-17 19:02:11:
* MIPS: DTS: jz4780: removed "img,sgx5" from bindings
* YAML bindings: updated according to suggestions by Rob Herring
* MIPS: DTS: jz4780: insert-sorted gpu node by register address - suggested by 
Paul Cercueil

PATCH V3 2019-11-24 12:40:33:
* reworked YAML format with help by Rob Herring
* removed .txt binding document
* change compatible "ti,am335x-sgx" to "ti,am3352-sgx" - suggested by Tony 
Lindgren

PATCH V2 2019-11-07 12:06:17:
* tried to convert bindings to YAML format - suggested by Rob Herring
* added JZ4780 DTS node (proven to load the driver)
* removed timer and img,cores properties until we know we really need them - 
suggested by Rob Herring

PATCH V1 2019-10-18 20:46:35:

This patch series defines child nodes for the SGX5xx interface inside
different SoC so that a driver can be found and probed by the
compatible strings and can retrieve information about the SGX revision
that is included in a specific SoC. It also defines the interrupt number
to be used by the SGX driver.

There is currently no mainline driver for these GPUs, but a project [1]
is ongoing with the goal to get the open-source part as provided by TI/IMG
and others into drivers/gpu/drm/pvrsgx.

The kernel modules built from this project have successfully demonstrated
to work with the DTS definitions from this patch set on AM335x BeagleBone
Black, DM3730 and OMAP5 Pyra and Droid 4. They partially work on OMAP3530 and
PandaBoard ES but that is likely a problem in the kernel driver or the
(non-free) user-space libraries and binaries.

Wotk for JZ4780 (CI20 board) is in progress and there is potential to extend
this work to e.g. BananaPi-M3 (A83) and  some Intel Poulsbo and CedarView
devices.

[1]: https://github.com/openpvrsgx-devgroup


H. Nikolaus Schaller (8):
  dt-bindings: add img,pvrsgx.yaml for Imagination GPUs
  ARM: DTS: am33xx: add sgx gpu child node
  ARM: DTS: am3517: add sgx gpu child node
  ARM: DTS: omap34xx: add sgx gpu child node
  ARM: DTS: omap36xx: add sgx gpu child node
  ARM: DTS: omap4: add sgx gpu child node
  ARM: DTS: omap5: add sgx gpu child node
  MIPS: DTS: jz4780: add sgx gpu node

 .../devicetree/bindings/gpu/img,pvrsgx.yaml   | 109 ++
 arch/arm/boot/dts/am33xx.dtsi |  11 +-
 arch/arm/boot/dts/am3517.dtsi |   9 +-
 arch/arm/boot/dts/omap34xx.dtsi   |  11 +-
 arch/arm/boot/dts/omap36xx.dtsi   |   9 +-
 arch/arm/boot/dts/omap4.dtsi  |  11 +-
 arch/arm/boot/dts/omap4470.dts|  15 +++
 arch/arm/boot/dts/omap5.dtsi  |  11 +-
 arch/mips/boot/dts/ingenic/jz4780.dtsi|  11 ++
 9 files changed, 169 insertions(+), 28 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml
 create mode 100644 arch/arm/boot/dts/omap4470.dts

-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 12/22] memory: tegra20-emc: Use devm_platform_ioremap_resource

[Dmitry Osipenko]

Utilize that relatively new helper which makes code a bit cleaner.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/tegra20-emc.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/memory/tegra/tegra20-emc.c 
b/drivers/memory/tegra/tegra20-emc.c
index 60b048ae9982..ef3abc18a3f4 100644
--- a/drivers/memory/tegra/tegra20-emc.c
+++ b/drivers/memory/tegra/tegra20-emc.c
@@ -654,7 +654,6 @@ static int tegra_emc_probe(struct platform_device *pdev)
 {
struct device_node *np;
struct tegra_emc *emc;
-   struct resource *res;
int irq, err;
 
/* driver has nothing to do in a case of memory timing absence */
@@ -689,8 +688,7 @@ static int tegra_emc_probe(struct platform_device *pdev)
if (err)
return err;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   emc->regs = devm_ioremap_resource(&pdev->dev, res);
+   emc->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(emc->regs))
return PTR_ERR(emc->regs);
 
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: fix ifnullfree.cocci warnings

[Julia Lawall]

NULL check before kfree is not needed.

Generated by: scripts/coccinelle/free/ifnullfree.cocci

Fixes: c6603c740e0e ("drm: add managed resources tied to drm_device")
Signed-off-by: kbuild test robot 
Signed-off-by: Julia Lawall 
---

tree:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head:   9e1ed9fb1eb0a4bc43a26365c592d3095286038b
commit: c6603c740e0e3492c9c95fdab833375bf7117b6b [1587/1636] drm: add managed 
resources tied to drm_device
:: branch date: 8 hours ago
:: commit date: 9 hours ago

Up to you, if you tihnk it is useful...

 drm_drv.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -837,8 +837,9 @@ static void drm_dev_release(struct kref
if (!dev->driver->release && !dev->managed.final_kfree) {
WARN_ON(!list_empty(&dev->managed.resources));
kfree(dev);
-   } else if (dev->managed.final_kfree)
+   } else {
kfree(dev->managed.final_kfree);
+   }
 }

 /**
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v3 1/8] dt-bindings: display: convert ingenic, lcd.txt to ingenic, lcd.yaml

[H. Nikolaus Schaller]

and add compatible: jz4780-lcd, including an example how to
configure both lcd controllers.

Also fix the clock names and examples.

Based on work by Paul Cercueil  and
Sam Ravnborg 

Signed-off-by: H. Nikolaus Schaller 
Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
---
 .../bindings/display/ingenic,lcd.txt  |  45 --
 .../bindings/display/ingenic,lcd.yaml | 128 ++
 2 files changed, 128 insertions(+), 45 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/ingenic,lcd.txt
 create mode 100644 Documentation/devicetree/bindings/display/ingenic,lcd.yaml

diff --git a/Documentation/devicetree/bindings/display/ingenic,lcd.txt 
b/Documentation/devicetree/bindings/display/ingenic,lcd.txt
deleted file mode 100644
index 01e3261defb6..
--- a/Documentation/devicetree/bindings/display/ingenic,lcd.txt
+++ /dev/null
@@ -1,45 +0,0 @@
-Ingenic JZ47xx LCD driver
-
-Required properties:
-- compatible: one of:
-  * ingenic,jz4740-lcd
-  * ingenic,jz4725b-lcd
-  * ingenic,jz4770-lcd
-- reg: LCD registers location and length
-- clocks: LCD pixclock and device clock specifiers.
-  The device clock is only required on the JZ4740.
-- clock-names: "lcd_pclk" and "lcd"
-- interrupts: Specifies the interrupt line the LCD controller is connected to.
-
-Example:
-
-panel {
-   compatible = "sharp,ls020b1dd01d";
-
-   backlight = <&backlight>;
-   power-supply = <&vcc>;
-
-   port {
-   panel_input: endpoint {
-   remote-endpoint = <&panel_output>;
-   };
-   };
-};
-
-
-lcd: lcd-controller@1305 {
-   compatible = "ingenic,jz4725b-lcd";
-   reg = <0x1305 0x1000>;
-
-   interrupt-parent = <&intc>;
-   interrupts = <31>;
-
-   clocks = <&cgu JZ4725B_CLK_LCD>;
-   clock-names = "lcd";
-
-   port {
-   panel_output: endpoint {
-   remote-endpoint = <&panel_input>;
-   };
-   };
-};
diff --git a/Documentation/devicetree/bindings/display/ingenic,lcd.yaml 
b/Documentation/devicetree/bindings/display/ingenic,lcd.yaml
new file mode 100644
index ..8b6467cfc191
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ingenic,lcd.yaml
@@ -0,0 +1,128 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/ingenic,lcd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bindings for Ingenic JZ4780 LCD Controller
+
+maintainers:
+  - Paul Cercueil 
+
+description: |
+  LCD Controller is the Display Controller for the Ingenic JZ47xx SoC
+
+properties:
+  compatible:
+oneOf:
+ - const: ingenic,jz4725b-lcd
+ - const: ingenic,jz4740-lcd
+ - const: ingenic,jz4770-lcd
+ - const: ingenic,jz4780-lcd
+
+  reg:
+maxItems: 1
+description: LCD registers location and length
+
+  interrupts:
+maxItems: 1
+description: Specifies the interrupt provided by parent
+
+  clocks:
+maxItems: 2
+description: Clock specifiers for LCD pixclock and device clock.
+  The device clock is only required on the JZ4740 and JZ4780
+
+  clock-names:
+items:
+  - const: lcd
+  - const: lcd_pclk
+
+  port:
+type: object
+description: |
+  A port node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt
+
+required:
+- compatible
+- reg
+- interrupts
+- clocks
+- clock-names
+- port
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+panel {
+  compatible = "sharp,ls020b1dd01d";
+
+  backlight = <&backlight>;
+  power-supply = <&vcc>;
+
+  port {
+panel_input: endpoint {
+  remote-endpoint = <&panel_output>;
+  };
+};
+  };
+
+lcd: lcd-controller@1305 {
+  compatible = "ingenic,jz4725b-lcd";
+  reg = <0x1305 0x1000>;
+
+  interrupt-parent = <&intc>;
+  interrupts = <31>;
+
+  clocks = <&cgu JZ4725B_CLK_LCD>;
+  clock-names = "lcd", "lcd_pclk";
+
+  port {
+panel_output: endpoint {
+  remote-endpoint = <&panel_input>;
+  };
+};
+  };
+
+  - |
+#include 
+
+lcdc0: lcdc0@1305 {
+compatible = "ingenic,jz4780-lcd";
+reg = <0x1305 0x1800>;
+
+clocks = <&cgu JZ4780_CLK_TVE>, <&cgu JZ4780_CLK_LCD0PIXCLK>;
+clock-names = "lcd", "lcd_pclk";
+
+interrupt-parent = <&intc>;
+interrupts = <31>;
+
+jz4780_lcd_out: port {
+#address-cells = <1>;
+#size-cells = <0>;
+
+jz4780_out_hdmi: endpoint@0 {
+reg = <0>;
+remote-endpoint = <&hdmi_in_lcd>;
+};
+};
+};
+
+lcdc1: lcdc1@130a {
+compatible = "ingenic,jz4780-lcd";
+reg = <0x130a 0x1800>;
+
+clocks = <&cgu JZ4780_CLK_TVE>, <&cgu JZ4780_CLK_LCD1PIXCL

[PATCH v4] video: fbdev: vesafb: add missed release_region

[Chuhong Yuan]

The driver forgets to free the I/O region in remove and probe
failure.
Add the missed calls to fix it.

Since the success of request_region() is optional, add the "region" field
in vesafb_par to represent whether request_region() succeeds.
Then only call release_region() when "region" is not null.

Signed-off-by: Chuhong Yuan 
---
Changes in v4:
  - Add a field in vesafb_par to represent whether request_region() succeeds.
  - Only call release_region() when request_region() succeeds.
  - Adjust the order in the error handler of probe.
  - Modify commit message.

 drivers/video/fbdev/vesafb.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
index a1fe24ea869b..df6de5a9dd4c 100644
--- a/drivers/video/fbdev/vesafb.c
+++ b/drivers/video/fbdev/vesafb.c
@@ -32,6 +32,7 @@
 struct vesafb_par {
u32 pseudo_palette[256];
int wc_cookie;
+   struct resource *region;
 };
 
 static struct fb_var_screeninfo vesafb_defined = {
@@ -411,7 +412,7 @@ static int vesafb_probe(struct platform_device *dev)
 
/* request failure does not faze us, as vgacon probably has this
 * region already (FIXME) */
-   request_region(0x3c0, 32, "vesafb");
+   par->region = request_region(0x3c0, 32, "vesafb");
 
if (mtrr == 3) {
unsigned int temp_size = size_total;
@@ -439,7 +440,7 @@ static int vesafb_probe(struct platform_device *dev)
   "vesafb: abort, cannot ioremap video memory 0x%x @ 
0x%lx\n",
vesafb_fix.smem_len, vesafb_fix.smem_start);
err = -EIO;
-   goto err;
+   goto err_release_region;
}
 
printk(KERN_INFO "vesafb: framebuffer at 0x%lx, mapped to 0x%p, "
@@ -458,19 +459,22 @@ static int vesafb_probe(struct platform_device *dev)
 
if (fb_alloc_cmap(&info->cmap, 256, 0) < 0) {
err = -ENOMEM;
-   goto err;
+   goto err_release_region;
}
if (register_framebuffer(info)<0) {
err = -EINVAL;
fb_dealloc_cmap(&info->cmap);
-   goto err;
+   goto err_release_region;
}
fb_info(info, "%s frame buffer device\n", info->fix.id);
return 0;
-err:
+err_release_region:
arch_phys_wc_del(par->wc_cookie);
if (info->screen_base)
iounmap(info->screen_base);
+   if (par->region)
+   release_region(0x3c0, 32);
+err:
framebuffer_release(info);
release_mem_region(vesafb_fix.smem_start, size_total);
return err;
@@ -481,6 +485,8 @@ static int vesafb_remove(struct platform_device *pdev)
struct fb_info *info = platform_get_drvdata(pdev);
 
unregister_framebuffer(info);
+   if (((struct vesafb_par *)(info->par))->region)
+   release_region(0x3c0, 32);
framebuffer_release(info);
 
return 0;
-- 
2.26.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 01/22] dt-bindings: memory: tegra20: mc: Document new interconnect property

[Dmitry Osipenko]

Memory controller is interconnected with memory clients and with the
external memory controller. Document new interconnect property which
turns memory controller into interconnect provider.

Signed-off-by: Dmitry Osipenko 
---
 .../bindings/memory-controllers/nvidia,tegra20-mc.txt  | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt
index e55328237df4..739b7c6f2e26 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt
@@ -16,6 +16,8 @@ Required properties:
   IOMMU specifier needed to encode an address. GART supports only a single
   address space that is shared by all devices, therefore no additional
   information needed for the address encoding.
+- #interconnect-cells : Should be 1. This cell represents memory client.
+  The assignments may be found in header file 
.
 
 Example:
mc: memory-controller@7000f000 {
@@ -27,6 +29,7 @@ Example:
interrupts = ;
#reset-cells = <1>;
#iommu-cells = <0>;
+   #interconnect-cells = <1>;
};
 
video-codec@6001a000 {
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 03/22] dt-bindings: memory: tegra30: mc: Document new interconnect property

[Dmitry Osipenko]

Memory controller is interconnected with memory clients and with the
external memory controller. Document new interconnect property which
turns memory controller into interconnect provider.

Signed-off-by: Dmitry Osipenko 
---
 .../bindings/memory-controllers/nvidia,tegra30-mc.yaml   | 5 +
 1 file changed, 5 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml
index 4b9196c83291..083676676d0d 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml
+++ 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml
@@ -57,6 +57,9 @@ properties:
   "#iommu-cells":
 const: 1
 
+  "#interconnect-cells":
+const: 1
+
 patternProperties:
   "^emc-timings-[0-9]+$":
 type: object
@@ -121,6 +124,7 @@ required:
   - clock-names
   - "#reset-cells"
   - "#iommu-cells"
+  - "#interconnect-cells"
 
 additionalProperties: false
 
@@ -136,6 +140,7 @@ examples:
 
 #iommu-cells = <1>;
 #reset-cells = <1>;
+#interconnect-cells = <1>;
 
 emc-timings-1 {
 nvidia,ram-code = <1>;
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v3 3/8] drm: ingenic-drm: add support for ingenic,jz4780-lcd

[H. Nikolaus Schaller]

This adds jz_soc_info and a compatible string for the jz4780
lcd controller.

Note that the jz4780 lcdc is a superset of the jz4740 lcdc
and the additional functions are not used if they stay
uninitialized.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index bcba2f024842..82c28ef1ac02 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -837,10 +837,17 @@ static const struct jz_soc_info jz4770_soc_info = {
.max_height = 720,
 };
 
+static const struct jz_soc_info jz4780_soc_info = {
+   .needs_dev_clk = true,
+   .max_width = 4096,
+   .max_height = 2048,
+};
+
 static const struct of_device_id ingenic_drm_of_match[] = {
{ .compatible = "ingenic,jz4740-lcd", .data = &jz4740_soc_info },
{ .compatible = "ingenic,jz4725b-lcd", .data = &jz4725b_soc_info },
{ .compatible = "ingenic,jz4770-lcd", .data = &jz4770_soc_info },
+   { .compatible = "ingenic,jz4780-lcd", .data = &jz4780_soc_info },
{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, ingenic_drm_of_match);
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 04/22] dt-bindings: memory: tegra30: emc: Document new interconnect property

[Dmitry Osipenko]

External memory controller is interconnected with memory controller and
with external memory. Document new interconnect property which turns
external memory controller into interconnect provider.

Signed-off-by: Dmitry Osipenko 
---
 .../bindings/memory-controllers/nvidia,tegra30-emc.yaml | 6 ++
 1 file changed, 6 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml
index e4135bac6957..2d7aed245552 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml
+++ 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml
@@ -31,6 +31,9 @@ properties:
   interrupts:
 maxItems: 1
 
+  "#interconnect-cells":
+const: 0
+
   nvidia,memory-controller:
 $ref: /schemas/types.yaml#/definitions/phandle
 description:
@@ -217,6 +220,7 @@ required:
   - interrupts
   - clocks
   - nvidia,memory-controller
+  - "#interconnect-cells"
 
 additionalProperties: false
 
@@ -230,6 +234,8 @@ examples:
 
 nvidia,memory-controller = <&mc>;
 
+#interconnect-cells = <0>;
+
 emc-timings-1 {
 nvidia,ram-code = <1>;
 
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 hmm 8/9] mm/hmm: do not set pfns when returning an error code

[Jason Gunthorpe]

From: Jason Gunthorpe 

Most places that return an error code, like -EFAULT, do not set
HMM_PFN_ERROR, only two places do this.

Resolve this inconsistency by never setting the pfns on an error
exit. This doesn't seem like a worthwhile thing to do anyhow.

If for some reason it becomes important, it makes more sense to directly
return the address of the failing page rather than have the caller scan
for the HMM_PFN_ERROR.

No caller inspects the pnfs output array if hmm_range_fault() fails.

Reviewed-by: Christoph Hellwig 
Signed-off-by: Jason Gunthorpe 
---
 mm/hmm.c | 18 +++---
 1 file changed, 3 insertions(+), 15 deletions(-)

diff --git a/mm/hmm.c b/mm/hmm.c
index dc826898979bc5..e875d9ef0968fd 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -77,17 +77,14 @@ static int hmm_vma_fault(unsigned long addr, unsigned long 
end,
 unsigned int required_fault, struct mm_walk *walk)
 {
struct hmm_vma_walk *hmm_vma_walk = walk->private;
-   struct hmm_range *range = hmm_vma_walk->range;
struct vm_area_struct *vma = walk->vma;
-   uint64_t *pfns = range->pfns;
-   unsigned long i = (addr - range->start) >> PAGE_SHIFT;
unsigned int fault_flags = FAULT_FLAG_REMOTE;
 
WARN_ON_ONCE(!required_fault);
hmm_vma_walk->last = addr;
 
if (!vma)
-   goto out_error;
+   return -EFAULT;
 
if (required_fault & HMM_NEED_WRITE_FAULT) {
if (!(vma->vm_flags & VM_WRITE))
@@ -95,15 +92,10 @@ static int hmm_vma_fault(unsigned long addr, unsigned long 
end,
fault_flags |= FAULT_FLAG_WRITE;
}
 
-   for (; addr < end; addr += PAGE_SIZE, i++)
+   for (; addr < end; addr += PAGE_SIZE)
if (handle_mm_fault(vma, addr, fault_flags) & VM_FAULT_ERROR)
-   goto out_error;
-
+   return -EFAULT;
return -EBUSY;
-
-out_error:
-   pfns[i] = range->values[HMM_PFN_ERROR];
-   return -EFAULT;
 }
 
 static unsigned int hmm_pte_need_fault(const struct hmm_vma_walk *hmm_vma_walk,
@@ -286,7 +278,6 @@ static int hmm_vma_handle_pte(struct mm_walk *walk, 
unsigned long addr,
 
/* Report error for everything else */
pte_unmap(ptep);
-   *pfn = range->values[HMM_PFN_ERROR];
return -EFAULT;
}
 
@@ -572,9 +563,6 @@ static const struct mm_walk_ops hmm_walk_ops = {
  *
  * This is similar to get_user_pages(), except that it can read the page tables
  * without mutating them (ie causing faults).
- *
- * On error, for one virtual address in the range, the function will mark the
- * corresponding HMM pfn entry with an error flag.
  */
 long hmm_range_fault(struct hmm_range *range)
 {
-- 
2.25.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 06/22] dt-bindings: memory: tegra20: Add memory client IDs

[Dmitry Osipenko]

Each memory client have a unique hardware ID, this patch adds these IDs.

Signed-off-by: Dmitry Osipenko 
---
 include/dt-bindings/memory/tegra20-mc.h | 53 +
 1 file changed, 53 insertions(+)

diff --git a/include/dt-bindings/memory/tegra20-mc.h 
b/include/dt-bindings/memory/tegra20-mc.h
index 35e131eee198..6f8829508ad0 100644
--- a/include/dt-bindings/memory/tegra20-mc.h
+++ b/include/dt-bindings/memory/tegra20-mc.h
@@ -18,4 +18,57 @@
 #define TEGRA20_MC_RESET_VDE   13
 #define TEGRA20_MC_RESET_VI14
 
+#define TEGRA20_MC_DISPLAY0A   0
+#define TEGRA20_MC_DISPLAY0AB  1
+#define TEGRA20_MC_DISPLAY0B   2
+#define TEGRA20_MC_DISPLAY0BB  3
+#define TEGRA20_MC_DISPLAY0C   4
+#define TEGRA20_MC_DISPLAY0CB  5
+#define TEGRA20_MC_DISPLAY1B   6
+#define TEGRA20_MC_DISPLAY1BB  7
+#define TEGRA20_MC_EPPUP   8
+#define TEGRA20_MC_G2PR9
+#define TEGRA20_MC_G2SR10
+#define TEGRA20_MC_MPEUNIFBR   11
+#define TEGRA20_MC_VIRUV   12
+#define TEGRA20_MC_AVPCARM7R   13
+#define TEGRA20_MC_DISPLAYHC   14
+#define TEGRA20_MC_DISPLAYHCB  15
+#define TEGRA20_MC_FDCDRD  16
+#define TEGRA20_MC_G2DR17
+#define TEGRA20_MC_HOST1XDMAR  18
+#define TEGRA20_MC_HOST1XR 19
+#define TEGRA20_MC_IDXSRD  20
+#define TEGRA20_MC_MPCORER 21
+#define TEGRA20_MC_MPE_IPRED   22
+#define TEGRA20_MC_MPEAMEMRD   23
+#define TEGRA20_MC_MPECSRD 24
+#define TEGRA20_MC_PPCSAHBDMAR 25
+#define TEGRA20_MC_PPCSAHBSLVR 26
+#define TEGRA20_MC_TEXSRD  27
+#define TEGRA20_MC_VDEBSEVR28
+#define TEGRA20_MC_VDEMBER 29
+#define TEGRA20_MC_VDEMCER 30
+#define TEGRA20_MC_VDETPER 31
+#define TEGRA20_MC_EPPU32
+#define TEGRA20_MC_EPPV33
+#define TEGRA20_MC_EPPY34
+#define TEGRA20_MC_MPEUNIFBW   35
+#define TEGRA20_MC_VIWSB   36
+#define TEGRA20_MC_VIWU37
+#define TEGRA20_MC_VIWV38
+#define TEGRA20_MC_VIWY39
+#define TEGRA20_MC_G2DW40
+#define TEGRA20_MC_AVPCARM7W   41
+#define TEGRA20_MC_FDCDWR  42
+#define TEGRA20_MC_HOST1XW 43
+#define TEGRA20_MC_ISPW44
+#define TEGRA20_MC_MPCOREW 45
+#define TEGRA20_MC_MPECSWR 46
+#define TEGRA20_MC_PPCSAHBDMAW 47
+#define TEGRA20_MC_PPCSAHBSLVW 48
+#define TEGRA20_MC_VDEBSEVW49
+#define TEGRA20_MC_VDEMBEW 50
+#define TEGRA20_MC_VDETPMW 51
+
 #endif
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 14/22] memory: tegra20-emc: Register as interconnect provider

[Dmitry Osipenko]

Now memory controller is a memory interconnection provider. This allows us
to use interconnect API in order to change memory configuration.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/tegra20-emc.c | 117 +
 1 file changed, 117 insertions(+)

diff --git a/drivers/memory/tegra/tegra20-emc.c 
b/drivers/memory/tegra/tegra20-emc.c
index 3a6eb5cc5c29..a2fcff221659 100644
--- a/drivers/memory/tegra/tegra20-emc.c
+++ b/drivers/memory/tegra/tegra20-emc.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -21,6 +22,8 @@
 
 #include 
 
+#include "mc.h"
+
 #define EMC_INTSTATUS  0x000
 #define EMC_INTMASK0x004
 #define EMC_DBG0x008
@@ -145,6 +148,7 @@ struct emc_timing {
 struct tegra_emc {
struct device *dev;
struct notifier_block clk_nb;
+   struct icc_provider provider;
struct clk *clk;
void __iomem *regs;
 
@@ -658,6 +662,112 @@ static void tegra_emc_debugfs_init(struct tegra_emc *emc)
emc, &tegra_emc_debug_max_rate_fops);
 }
 
+static inline struct tegra_emc *
+to_tegra_emc_provider(struct icc_provider *provider)
+{
+   return container_of(provider, struct tegra_emc, provider);
+}
+
+static struct icc_node *
+emc_of_icc_xlate_onecell(struct of_phandle_args *spec, void *data)
+{
+   struct icc_provider *provider = data;
+   struct icc_node *node;
+
+   /* External Memory is the only possible ICC route */
+   list_for_each_entry(node, &provider->nodes, node_list) {
+   if (node->id == TEGRA_ICC_EMEM)
+   return node;
+   }
+
+   return ERR_PTR(-EINVAL);
+}
+
+static int emc_icc_set(struct icc_node *src, struct icc_node *dst)
+{
+   struct tegra_emc *emc = to_tegra_emc_provider(dst->provider);
+   unsigned long long rate = icc_units_to_bps(dst->avg_bw);
+   unsigned int dram_data_bus_width_bytes = 4;
+   unsigned int ddr = 2;
+   int err;
+
+   do_div(rate, ddr * dram_data_bus_width_bytes);
+   rate = min_t(u64, rate, U32_MAX);
+
+   err = clk_set_min_rate(emc->clk, rate);
+   if (err)
+   return err;
+
+   err = clk_set_rate(emc->clk, rate);
+   if (err)
+   return err;
+
+   return 0;
+}
+
+static int emc_icc_aggregate(struct icc_node *node,
+u32 tag, u32 avg_bw, u32 peak_bw,
+u32 *agg_avg, u32 *agg_peak)
+{
+   *agg_avg = min((u64)avg_bw + (*agg_avg), (u64)U32_MAX);
+   *agg_peak = max(*agg_peak, peak_bw);
+
+   return 0;
+}
+
+static int tegra_emc_interconnect_init(struct tegra_emc *emc)
+{
+   struct icc_node *node;
+   int err;
+
+   /* older device-trees don't have interconnect properties */
+   if (!of_find_property(emc->dev->of_node, "#interconnect-cells", NULL))
+   return 0;
+
+   emc->provider.dev = emc->dev;
+   emc->provider.set = emc_icc_set;
+   emc->provider.data = &emc->provider;
+   emc->provider.xlate = emc_of_icc_xlate_onecell;
+   emc->provider.aggregate = emc_icc_aggregate;
+
+   err = icc_provider_add(&emc->provider);
+   if (err)
+   return err;
+
+   /* create External Memory Controller node */
+   node = icc_node_create(TEGRA_ICC_EMC);
+   err = PTR_ERR_OR_ZERO(node);
+   if (err)
+   goto del_provider;
+
+   node->name = "External Memory Controller";
+   icc_node_add(node, &emc->provider);
+
+   /* link External Memory Controller to External Memory (DRAM) */
+   err = icc_link_create(node, TEGRA_ICC_EMEM);
+   if (err)
+   goto remove_nodes;
+
+   /* create External Memory node */
+   node = icc_node_create(TEGRA_ICC_EMEM);
+   err = PTR_ERR_OR_ZERO(node);
+   if (err)
+   goto remove_nodes;
+
+   node->name = "External Memory (DRAM)";
+   icc_node_add(node, &emc->provider);
+
+   return 0;
+
+remove_nodes:
+   icc_nodes_remove(&emc->provider);
+
+del_provider:
+   icc_provider_del(&emc->provider);
+
+   return err;
+}
+
 static int tegra_emc_probe(struct platform_device *pdev)
 {
struct device_node *np;
@@ -721,6 +831,13 @@ static int tegra_emc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, emc);
tegra_emc_debugfs_init(emc);
 
+   if (IS_ENABLED(CONFIG_INTERCONNECT)) {
+   err = tegra_emc_interconnect_init(emc);
+   if (err)
+   dev_err(&pdev->dev, "failed to initialize ICC: %d\n",
+   err);
+   }
+
return 0;
 
 unset_cb:
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm/lima: Add optional devfreq and cooling device support

[Martin Blumenstingl]

On Sat, Mar 28, 2020 at 9:40 AM Qiang Yu  wrote:
>
> Applied to drm-misc-next.
thank you!

regarding patch #1 - can you apply this as well?
patch #1 just takes this midgard change [0] and ports it to utgard


Thank you!
Martin


[0] 
https://cgit.freedesktop.org/drm/drm-misc/commit/Documentation/devicetree/bindings/gpu?id=982c0500fd1a8012c31d3c9dd8de285129904656
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 20/22] drm/tegra: dc: Extend debug stats with total number of events

[Dmitry Osipenko]

It's useful to know the total number of underflow events and currently
the debug stats are getting reset each time CRTC is being disabled. Let's
account the overall number of events that doesn't get reset.

Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/tegra/dc.c | 10 ++
 drivers/gpu/drm/tegra/dc.h |  5 +
 2 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 564af302a965..7112f80ff9e8 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1616,6 +1616,11 @@ static int tegra_dc_show_stats(struct seq_file *s, void 
*data)
seq_printf(s, "underflow: %lu\n", dc->stats.underflow);
seq_printf(s, "overflow: %lu\n", dc->stats.overflow);
 
+   seq_printf(s, "frames total: %lu\n", dc->stats.frames_total);
+   seq_printf(s, "vblank total: %lu\n", dc->stats.vblank_total);
+   seq_printf(s, "underflow total: %lu\n", dc->stats.underflow_total);
+   seq_printf(s, "overflow total: %lu\n", dc->stats.overflow_total);
+
return 0;
 }
 
@@ -2187,6 +2192,7 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
/*
dev_dbg(dc->dev, "%s(): frame end\n", __func__);
*/
+   dc->stats.frames_total++;
dc->stats.frames++;
}
 
@@ -2195,6 +2201,7 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
dev_dbg(dc->dev, "%s(): vertical blank\n", __func__);
*/
drm_crtc_handle_vblank(&dc->base);
+   dc->stats.vblank_total++;
dc->stats.vblank++;
}
 
@@ -2202,6 +2209,7 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
/*
dev_dbg(dc->dev, "%s(): underflow\n", __func__);
*/
+   dc->stats.underflow_total++;
dc->stats.underflow++;
}
 
@@ -2209,11 +2217,13 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
/*
dev_dbg(dc->dev, "%s(): overflow\n", __func__);
*/
+   dc->stats.overflow_total++;
dc->stats.overflow++;
}
 
if (status & HEAD_UF_INT) {
dev_dbg_ratelimited(dc->dev, "%s(): head underflow\n", 
__func__);
+   dc->stats.underflow_total++;
dc->stats.underflow++;
}
 
diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
index 3a0ff57c5169..3eb4eddc2288 100644
--- a/drivers/gpu/drm/tegra/dc.h
+++ b/drivers/gpu/drm/tegra/dc.h
@@ -41,6 +41,11 @@ struct tegra_dc_stats {
unsigned long vblank;
unsigned long underflow;
unsigned long overflow;
+
+   unsigned long frames_total;
+   unsigned long vblank_total;
+   unsigned long underflow_total;
+   unsigned long overflow_total;
 };
 
 struct tegra_windowgroup_soc {
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 2/8] ARM: DTS: am33xx: add sgx gpu child node

[H. Nikolaus Schaller]

and add interrupt.

Tested-by: H. Nikolaus Schaller  # BeagleBone Black
Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/am33xx.dtsi | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 41dcfb37155a..cbdd85a1e4b0 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -497,7 +497,7 @@ aes: aes@0 {
};
};
 
-   target-module@5600 {
+   sgx_module: target-module@5600 {
compatible = "ti,sysc-omap4", "ti,sysc";
reg = <0x5600fe00 0x4>,
  <0x5600fe10 0x4>;
@@ -516,10 +516,11 @@ target-module@5600 {
#size-cells = <1>;
ranges = <0 0x5600 0x100>;
 
-   /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+   gpu: gpu@0 {
+   compatible = "ti,am3352-sgx530-125", 
"img,sgx530-125", "img,sgx530";
+   reg = <0x00 0x100>; /* 16 MB */
+   interrupts = <37>;
+   };
};
};
 };
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Andy Shevchenko]

On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek  wrote:
> >
> > recently we wanted to update xilinx intc driver and we found that function
> > which we wanted to remove is still wired by ancient Xilinx PowerPC
> > platforms. Here is the thread about it.
> > https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa...@xilinx.com/
> >
> > I have been talking about it internally and there is no interest in these
> > platforms and it is also orphan for quite a long time. None is really
> > running/testing these platforms regularly that's why I think it makes sense
> > to remove them also with drivers which are specific to this platform.
> >
> > U-Boot support was removed in 2017 without anybody complain about it
> > https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed
> >
> > Based on current ppc/next.
> >
> > If anyone has any objection about it, please let me know.
> 
> Acked-by: Arnd Bergmann 
> 
> This looks reasonable to me as well, in particular as the code only
> supports the two
> ppc44x virtex developer boards and no commercial products.
> 
> It does raise a follow-up question about ppc40x though: is it time to
> retire all of it?

Who knows?

I have in possession nice WD My Book Live, based on this architecture, and I
won't it gone from modern kernel support. OTOH I understand that amount of real
users not too big.

Ah, and I have Amiga board, but that one is being used only for testing, so,
I don't care much.

> The other ppc405 machines appear to have seen even fewer updates after the
> OpenBlockS 600 got added in 2011, so it's possible nobody is using them any 
> more
> with modern kernels.
> 
> I see that OpenWRT removed both ppc40x and ppc44x exactly a year ago after
> they had not been maintained for years.
> 
> However, 44x (in its ppc476 incarnation) is clearly still is used
> through the fsp2 platform,
> and can not be deprecated at least until that is known to have stopped
> getting kernel
> updates.
> 
> Arnd

-- 
With Best Regards,
Andy Shevchenko


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 3/8] ARM: DTS: am3517: add sgx gpu child node

[H. Nikolaus Schaller]

and add interrupt.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/am3517.dtsi | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/am3517.dtsi b/arch/arm/boot/dts/am3517.dtsi
index e0b5a00e2078..3fce56a646d1 100644
--- a/arch/arm/boot/dts/am3517.dtsi
+++ b/arch/arm/boot/dts/am3517.dtsi
@@ -138,10 +138,11 @@ sgx_module: target-module@5000 {
#size-cells = <1>;
ranges = <0 0x5000 0x4000>;
 
-   /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+   gpu: gpu@0 {
+   compatible = "ti,am3517-sgx530-125", 
"img,sgx530-125", "img,sgx530";
+   reg = <0x0 0x4000>;
+   interrupts = <21>;
+   };
};
};
 };
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 hmm 0/9] Small hmm_range_fault() cleanups

[Jason Gunthorpe]

From: Jason Gunthorpe 

This is v3 with some minor adjustments made.

We are at the end of the dev cycle, and as nothing major has come up I'll push
this toward linux-next to get some coverage and decide next week what goes
this cycle.

v3 changes:
 - Keep NEED_WRITE_FAULT and NEED_FAULT separate (CH)
 - Use CH's vesion of hmm_can_fault and drop the inline
v2: https://lore.kernel.org/r/20200324011457.2817-1-...@ziepe.ca
v1: https://lore.kernel.org/r/20200320164905.21722-1-...@ziepe.ca

Thanks to everyone who looked on this,
Jason

Jason Gunthorpe (9):
  mm/hmm: remove pgmap checking for devmap pages
  mm/hmm: return the fault type from hmm_pte_need_fault()
  mm/hmm: remove unused code and tidy comments
  mm/hmm: remove HMM_FAULT_SNAPSHOT
  mm/hmm: remove the CONFIG_TRANSPARENT_HUGEPAGE #ifdef
  mm/hmm: use device_private_entry_to_pfn()
  mm/hmm: do not unconditionally set pfns when returning EBUSY
  mm/hmm: do not set pfns when returning an error code
  mm/hmm: return error for non-vma snapshots

 Documentation/vm/hmm.rst|  12 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |   2 +-
 drivers/gpu/drm/nouveau/nouveau_svm.c   |   2 +-
 include/linux/hmm.h | 109 +
 mm/hmm.c| 307 +---
 5 files changed, 128 insertions(+), 304 deletions(-)

-- 
2.25.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] powerpc: Remove Xilinx PPC405/PPC440 support

[Michal Simek]

The latest Xilinx design tools called ISE and EDK has been released in
October 2013. New tool doesn't support any PPC405/PPC440 new designs.
These platforms are no longer supported and tested.

PowerPC 405/440 port is orphan from 2013 by
commit cdeb89943bfc ("MAINTAINERS: Fix incorrect status tag") and
commit 19624236cce1 ("MAINTAINERS: Update Grant's email address and 
maintainership")
that's why it is time to remove the support fot these platforms.

Signed-off-by: Michal Simek 
---

 Documentation/devicetree/bindings/xilinx.txt | 143 --
 Documentation/powerpc/bootwrapper.rst|  28 +-
 MAINTAINERS  |   6 -
 arch/powerpc/Kconfig.debug   |   2 +-
 arch/powerpc/boot/Makefile   |   7 +-
 arch/powerpc/boot/dts/Makefile   |   1 -
 arch/powerpc/boot/dts/virtex440-ml507.dts| 406 
 arch/powerpc/boot/dts/virtex440-ml510.dts| 466 ---
 arch/powerpc/boot/ops.h  |   1 -
 arch/powerpc/boot/serial.c   |   5 -
 arch/powerpc/boot/uartlite.c |  79 
 arch/powerpc/boot/virtex.c   |  97 
 arch/powerpc/boot/virtex405-head.S   |  31 --
 arch/powerpc/boot/wrapper|   8 -
 arch/powerpc/configs/40x/virtex_defconfig|  75 ---
 arch/powerpc/configs/44x/virtex5_defconfig   |  74 ---
 arch/powerpc/configs/ppc40x_defconfig|   8 -
 arch/powerpc/configs/ppc44x_defconfig|   8 -
 arch/powerpc/include/asm/xilinx_intc.h   |  16 -
 arch/powerpc/include/asm/xilinx_pci.h|  21 -
 arch/powerpc/kernel/cputable.c   |  39 --
 arch/powerpc/platforms/40x/Kconfig   |  31 --
 arch/powerpc/platforms/40x/Makefile  |   1 -
 arch/powerpc/platforms/40x/virtex.c  |  54 ---
 arch/powerpc/platforms/44x/Kconfig   |  37 --
 arch/powerpc/platforms/44x/Makefile  |   2 -
 arch/powerpc/platforms/44x/virtex.c  |  60 ---
 arch/powerpc/platforms/44x/virtex_ml510.c|  30 --
 arch/powerpc/platforms/Kconfig   |   4 -
 arch/powerpc/sysdev/Makefile |   2 -
 arch/powerpc/sysdev/xilinx_intc.c|  88 
 arch/powerpc/sysdev/xilinx_pci.c | 132 --
 arch/powerpc/xmon/ppc-dis.c  |   6 -
 arch/powerpc/xmon/ppc-opc.c  |  23 -
 arch/powerpc/xmon/ppc.h  |   5 -
 drivers/char/Kconfig |   2 +-
 drivers/video/fbdev/Kconfig  |   2 +-
 37 files changed, 7 insertions(+), 1993 deletions(-)
 delete mode 100644 arch/powerpc/boot/dts/virtex440-ml507.dts
 delete mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
 delete mode 100644 arch/powerpc/boot/uartlite.c
 delete mode 100644 arch/powerpc/boot/virtex.c
 delete mode 100644 arch/powerpc/boot/virtex405-head.S
 delete mode 100644 arch/powerpc/configs/40x/virtex_defconfig
 delete mode 100644 arch/powerpc/configs/44x/virtex5_defconfig
 delete mode 100644 arch/powerpc/include/asm/xilinx_intc.h
 delete mode 100644 arch/powerpc/include/asm/xilinx_pci.h
 delete mode 100644 arch/powerpc/platforms/40x/virtex.c
 delete mode 100644 arch/powerpc/platforms/44x/virtex.c
 delete mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
 delete mode 100644 arch/powerpc/sysdev/xilinx_intc.c
 delete mode 100644 arch/powerpc/sysdev/xilinx_pci.c

diff --git a/Documentation/devicetree/bindings/xilinx.txt 
b/Documentation/devicetree/bindings/xilinx.txt
index d058ace29345..28199b31fe5e 100644
--- a/Documentation/devicetree/bindings/xilinx.txt
+++ b/Documentation/devicetree/bindings/xilinx.txt
@@ -86,149 +86,6 @@
xlnx,use-parity = <0>;
};
 
-   Some IP cores actually implement 2 or more logical devices.  In
-   this case, the device should still describe the whole IP core with
-   a single node and add a child node for each logical device.  The
-   ranges property can be used to translate from parent IP-core to the
-   registers of each device.  In addition, the parent node should be
-   compatible with the bus type 'xlnx,compound', and should contain
-   #address-cells and #size-cells, as with any other bus.  (Note: this
-   makes the assumption that both logical devices have the same bus
-   binding.  If this is not true, then separate nodes should be used
-   for each logical device).  The 'cell-index' property can be used to
-   enumerate logical devices within an IP core.  For example, the
-   following is the system.mhs entry for the dual ps2 controller found
-   on the ml403 reference design.
-
-   BEGIN opb_ps2_dual_ref
-   PARAMETER INSTANCE = opb_ps2_dual_ref_0
-   PARAMETER HW_VER = 1.00.a
-   PARAMETER C_BASEADDR = 0xA900
-   PARAMETER C_HIGHADDR = 0xA9001FFF
-   BUS_INTERFACE SOPB = opb_v20_0
-   PORT Sys_Intr1 = ps2_1_intr
-   PORT Sys_Intr2 = ps2_2_intr
-   PORT Clkin

How to handle disconnection of eDP panels due to dynamic display mux switches

[Daniel Dadap]

A number of hybrid GPU notebook computer designs with dual (integrated 
plus discrete) GPUs are equipped with multiplexers (muxes) that allow 
display panels to be driven by either the integrated GPU or the discrete 
GPU. Typically, this is a selection that can be made at boot time as a 
menu option in the system firmware's setup screen, and the mux selection 
stays fixed for as long as the system is running and persists across 
reboots until it is explicitly changed. However, some muxed hybrid GPU 
systems have dynamically switchable muxes which can be switched while 
the system is running.


NVIDIA is exploring the possibility of taking advantage of dynamically 
switchable muxes to enhance the experience of using a hybrid GPU system. 
For example, on a system configured for PRIME render offloading, it may 
be possible to keep the discrete GPU powered down and use the integrated 
GPU for rendering and displaying the desktop when no applications are 
using the discrete GPU, and dynamically switch the panel to be driven 
directly by the discrete GPU when render-offloading a fullscreen 
application.


We have been conducting some experiments on systems with dynamic muxes, 
and have found some limitations that would need to be addressed in order 
to support use cases like the one suggested above:


* In at least the i915 DRM-KMS driver, and likely in other DRM-KMS 
drivers as well, eDP panels are assumed to be always connected. This 
assumption is broken when the panel is muxed away, which can cause 
problems. A typical symptom is i915 repeatedly attempting to retrain the 
link, severely impacting system performance and printing messages like 
the following every five seconds or so:


[drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link 
training
[drm] Reducing the compressed framebuffer size. This may lead to less 
power savings than a non-reduced-size. Try to increase stolen memory 
size if available in BIOS.


This symptom might occur if something causes the DRM-KMS driver to probe 
the display while it's muxed away, for example a modeset or DPMS state 
change.


* When switching the mux back to a GPU that was previously driving a 
mode, it is necessary to at the very least retrain DP links to restore 
the previously displayed image. In a proof of concept I have been 
experimenting with, I am able to accomplish this from userspace by 
triggering DPMS off and then back on again; however, it would be good to 
have an in-kernel API to request that an output owned by a DRM-KMS 
driver be refreshed to resume driving a mode on a disconnected and 
reconnected display. This API would need to be accessible from outside 
of the DRM-KMS driver handling the output. One reason it would be good 
to do this within the kernel, rather than rely on e.g. DPMS operations 
in the xf86-video-modesetting driver, is that it would be useful for 
restoring the console if X crashes or is forcefully killed while the mux 
is switched to a GPU other than the one which drives the console.


Basically, we'd like to be able to do the following:

1) Communicate to a DRM-KMS driver that an output is disconnected and 
can't be used. Ideally, DRI clients such as X should still see the 
output as being connected, so user applications don't need to keep track 
of the change.
2) Request that a mode that was previously driven on a disconnected 
output be driven again upon reconnection.


If APIs to do the above are already available, I wasn't able to find 
information about them. These could be handled as separate APIs, e.g., 
one to set connected/disconnected state and another to restore an 
output, or as a single API, e.g., signal a disconnect or reconnect, 
leaving it up to the driver receiving the signal to set the appropriate 
internal state and restore the reconnected output. Another possibility 
would be an API to disable and enable individual outputs from outside of 
the DRM-KMS driver that owns them. I'm curious to hear the thoughts of 
the DRM subsystem maintainers and contributors on what the best approach 
to this would be.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v3 7/8] MIPS: DTS: CI20: add HDMI setup

[H. Nikolaus Schaller]

From: Paul Boddie 

We need to hook up
* HDMI power regulator
* HDMI connector
* DDC pinmux
* HDMI and LCD endpoint connections

Signed-off-by: Paul Boddie 
Signed-off-by: H. Nikolaus Schaller 
---
 arch/mips/boot/dts/ingenic/ci20.dts | 64 +
 1 file changed, 64 insertions(+)

diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
b/arch/mips/boot/dts/ingenic/ci20.dts
index c340f947baa0..97e09382ebd7 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -62,6 +62,28 @@ eth0_power: fixedregulator@0 {
enable-active-high;
};
 
+   hdmi_power: fixedregulator@2 {
+   compatible = "regulator-fixed";
+   regulator-name = "hdmi_power";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gpa 25 GPIO_ACTIVE_LOW>;
+   enable-active-high;
+   regulator-always-on;
+   };
+
+   hdmi_out: connector {
+   compatible = "hdmi-connector";
+   label = "HDMI OUT";
+   type = "a";
+
+   port {
+   hdmi_con: endpoint {
+   remote-endpoint = <&dw_hdmi_out>;
+   };
+   };
+   };
+
wlan0_power: fixedregulator@1 {
compatible = "regulator-fixed";
regulator-name = "wlan0_power";
@@ -435,6 +457,12 @@ pins_i2c4: i2c4 {
bias-disable;
};
 
+   pins_hdmi_ddc: hdmi_ddc {
+   function = "hdmi-ddc";
+   groups = "hdmi-ddc";
+   bias-disable;
+   };
+
pins_nemc: nemc {
function = "nemc";
groups = "nemc-data", "nemc-cle-ale", "nemc-rd-we", 
"nemc-frd-fwe";
@@ -471,3 +499,39 @@ &tcu {
assigned-clocks = <&tcu TCU_CLK_TIMER0>, <&tcu TCU_CLK_TIMER1>;
assigned-clock-rates = <300>, <300>;
 };
+
+&hdmi {
+   status = "okay";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&pins_hdmi_ddc>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   dw_hdmi_in: endpoint {
+   remote-endpoint = <&lcd_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   dw_hdmi_out: endpoint {
+   remote-endpoint = <&hdmi_con>;
+   };
+   };
+   };
+};
+
+&lcdc0 {
+   status = "okay";
+
+   port {
+   lcd_out: endpoint {
+   remote-endpoint = <&dw_hdmi_in>;
+   };
+   };
+};
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 hmm 7/9] mm/hmm: do not unconditionally set pfns when returning EBUSY

[Jason Gunthorpe]

From: Jason Gunthorpe 

In hmm_vma_handle_pte() and hmm_vma_walk_hugetlb_entry() if fault happens
then -EBUSY will be returned and the pfns input flags will have been
destroyed.

For hmm_vma_handle_pte() set HMM_PFN_NONE only on the success returns that
don't otherwise store to pfns.

For hmm_vma_walk_hugetlb_entry() all exit paths already set pfns, so
remove the redundant store.

Fixes: 2aee09d8c116 ("mm/hmm: change hmm_vma_fault() to allow write fault on 
page basis")
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jason Gunthorpe 
---
 mm/hmm.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/mm/hmm.c b/mm/hmm.c
index 3303686bf16d24..dc826898979bc5 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -244,11 +244,11 @@ static int hmm_vma_handle_pte(struct mm_walk *walk, 
unsigned long addr,
pte_t pte = *ptep;
uint64_t orig_pfn = *pfn;
 
-   *pfn = range->values[HMM_PFN_NONE];
if (pte_none(pte)) {
required_fault = hmm_pte_need_fault(hmm_vma_walk, orig_pfn, 0);
if (required_fault)
goto fault;
+   *pfn = range->values[HMM_PFN_NONE];
return 0;
}
 
@@ -269,8 +269,10 @@ static int hmm_vma_handle_pte(struct mm_walk *walk, 
unsigned long addr,
}
 
required_fault = hmm_pte_need_fault(hmm_vma_walk, orig_pfn, 0);
-   if (!required_fault)
+   if (!required_fault) {
+   *pfn = range->values[HMM_PFN_NONE];
return 0;
+   }
 
if (!non_swap_entry(entry))
goto fault;
@@ -488,7 +490,6 @@ static int hmm_vma_walk_hugetlb_entry(pte_t *pte, unsigned 
long hmask,
 
i = (start - range->start) >> PAGE_SHIFT;
orig_pfn = range->pfns[i];
-   range->pfns[i] = range->values[HMM_PFN_NONE];
cpu_flags = pte_to_hmm_pfn_flags(range, entry);
required_fault = hmm_pte_need_fault(hmm_vma_walk, orig_pfn, cpu_flags);
if (required_fault) {
-- 
2.25.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH] staging: fbtft: Replace udelay with preferred usleep_range

[Julia Lawall]

On Sun, 29 Mar 2020, John B. Wyatt IV wrote:

> Fix style issue with usleep_range being reported as preferred over
> udelay.
>
> Issue reported by checkpatch.
>
> Please review.
>
> As written in Documentation/timers/timers-howto.rst udelay is the
> generally preferred API. hrtimers, as noted in the docs, may be too
> expensive for this short timer.
>
> Are the docs out of date, or, is this a checkpatch issue?
>
> Signed-off-by: John B. Wyatt IV 
> ---
>  drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c 
> b/drivers/staging/fbtft/fb_agm1264k-fl.c
> index ec97ad27..019c8cce6bab 100644
> --- a/drivers/staging/fbtft/fb_agm1264k-fl.c
> +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
> @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par)
>   dev_dbg(par->info->device, "%s()\n", __func__);
>
>   gpiod_set_value(par->gpio.reset, 0);
> - udelay(20);
> + usleep_range(20, 20);

usleep_range should have a range, eg usleep_range(50, 100);.  But it is
hard to know a priori what the range should be.  So it is probably better
to leave the code alone.

julia

>   gpiod_set_value(par->gpio.reset, 1);
>   mdelay(120);
>  }
> --
> 2.25.1
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20200329092204.770405-1-jbwyatt4%40gmail.com.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] fbcon: fix null-ptr-deref in fbcon_switch

[Qiujun Huang]

On Sun, Mar 29, 2020 at 2:13 AM Sam Ravnborg  wrote:
>
> Hi Qiujun
>
> Thanks for looking into the sysbot bugs.
>
> On Sat, Mar 28, 2020 at 11:15:10PM +0800, Qiujun Huang wrote:
> > Add check for vc_cons[logo_shown].d, as it can be released by
> > vt_ioctl(VT_DISALLOCATE).
> >
> > Reported-by: syzbot+732528bae351682f1...@syzkaller.appspotmail.com
> > Signed-off-by: Qiujun Huang 
> > ---
> >  drivers/video/fbdev/core/fbcon.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c 
> > b/drivers/video/fbdev/core/fbcon.c
> > index bb6ae995c2e5..7ee0f7b55829 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -2254,7 +2254,7 @@ static int fbcon_switch(struct vc_data *vc)
> >   fbcon_update_softback(vc);
> >   }
> >
> > - if (logo_shown >= 0) {
> > + if (logo_shown >= 0 && vc_cons_allocated(logo_shown)) {
> >   struct vc_data *conp2 = vc_cons[logo_shown].d;
> >
> >   if (conp2->vc_top == logo_lines
> > @@ -2852,7 +2852,7 @@ static void fbcon_scrolldelta(struct vc_data *vc, int 
> > lines)
> >   return;
> >   if (vc->vc_mode != KD_TEXT || !lines)
> >   return;
> > - if (logo_shown >= 0) {
> > + if (logo_shown >= 0 && vc_cons_allocated(logo_shown)) {
> >   struct vc_data *conp2 = vc_cons[logo_shown].d;
> >
> >   if (conp2->vc_top == logo_lines
>
> I am not familiar with this code.
>
> But it looks like you try to avoid the sympton
> which is that logo_shown has a wrong value after a
> vc is deallocated, and do not fix the root cause.
>
> We have:
>
> vt_ioctl(VT_DISALLOCATE)
>  |
>  +- vc_deallocate()
>  |
>  +- visual_deinit()
>  |
>  +- vc->vc_sw->con_deinit(vc)
>  |
>  +- fbcon_deinit()
>
> Would it be better to update logo_shown
> in fbcon_deinit()?
> Then we will not try to do anything with
> the logo in fbcon_switch().
>
> fbcon_deinit() is called with console locked
> so there should not be any races.

Get that, thanks.

>
> I did not stare long enough on the code to come up with a patch,
> but this may be a better way to fix it.
>
> Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 15/22] memory: tegra20-emc: Create tegra20-devfreq device

[Dmitry Osipenko]

The tegra20-devfreq driver provides memory frequency scaling functionality
and it uses EMC clock for the scaling. Since tegra20-devfreq is a software
driver, the device for the driver needs to be created manually. Let's do
it from EMC driver since it provides the clk rate-change functionality.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/tegra20-emc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/memory/tegra/tegra20-emc.c 
b/drivers/memory/tegra/tegra20-emc.c
index a2fcff221659..867cd518b32e 100644
--- a/drivers/memory/tegra/tegra20-emc.c
+++ b/drivers/memory/tegra/tegra20-emc.c
@@ -838,6 +838,9 @@ static int tegra_emc_probe(struct platform_device *pdev)
err);
}
 
+   if (IS_ENABLED(CONFIG_ARM_TEGRA20_DEVFREQ))
+   platform_device_register_simple("tegra20-devfreq", -1, NULL, 0);
+
return 0;
 
 unset_cb:
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 02/22] dt-bindings: memory: tegra20: emc: Document new interconnect property

[Dmitry Osipenko]

External memory controller is interconnected with memory controller and
with external memory. Document new interconnect property which turns
external memory controller into interconnect provider.

Signed-off-by: Dmitry Osipenko 
---
 .../bindings/memory-controllers/nvidia,tegra20-emc.txt  | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
index add95367640b..f51da7662de4 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
+++ 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
@@ -12,6 +12,7 @@ Properties:
   irrespective of ram-code configuration.
 - interrupts : Should contain EMC General interrupt.
 - clocks : Should contain EMC clock.
+- #interconnect-cells : Should be 0.
 
 Child device nodes describe the memory settings for different configurations 
and clock rates.
 
@@ -20,6 +21,7 @@ Example:
memory-controller@7000f400 {
#address-cells = < 1 >;
#size-cells = < 0 >;
+   #interconnect-cells = < 0 >;
compatible = "nvidia,tegra20-emc";
reg = <0x7000f4000 0x200>;
interrupts = <0 78 0x04>;
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] fbcon: fix null-ptr-deref in fbcon_switch

[Qiujun Huang]

Set logo_shown to FBCON_LOGO_CANSHOW when the vc was deallocated.

syzkaller report: https://lkml.org/lkml/2020/3/27/403
general protection fault, probably for non-canonical address
0xdc6c:  [#1] SMP KASAN
KASAN: null-ptr-deref in range [0x0360-0x0367]
RIP: 0010:fbcon_switch+0x28f/0x1740
drivers/video/fbdev/core/fbcon.c:2260

Call Trace:
redraw_screen+0x2a8/0x770 drivers/tty/vt/vt.c:1008
vc_do_resize+0xfe7/0x1360 drivers/tty/vt/vt.c:1295
fbcon_init+0x1221/0x1ab0 drivers/video/fbdev/core/fbcon.c:1219
visual_init+0x305/0x5c0 drivers/tty/vt/vt.c:1062
do_bind_con_driver+0x536/0x890 drivers/tty/vt/vt.c:3542
do_take_over_console+0x453/0x5b0 drivers/tty/vt/vt.c:4122
do_fbcon_takeover+0x10b/0x210 drivers/video/fbdev/core/fbcon.c:588
fbcon_fb_registered+0x26b/0x340 drivers/video/fbdev/core/fbcon.c:3259
do_register_framebuffer drivers/video/fbdev/core/fbmem.c:1664 [inline]
register_framebuffer+0x56e/0x980 drivers/video/fbdev/core/fbmem.c:1832
dlfb_usb_probe.cold+0x1743/0x1ba3 drivers/video/fbdev/udlfb.c:1735
usb_probe_interface+0x310/0x800 drivers/usb/core/driver.c:374

accessing vc_cons[logo_shown].d->vc_top causes the bug.

Reported-by: syzbot+732528bae351682f1...@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang 
---
 drivers/video/fbdev/core/fbcon.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index bb6ae995c2e5..5eb3fc90f9f6 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1283,6 +1283,9 @@ static void fbcon_deinit(struct vc_data *vc)
if (!con_is_bound(&fb_con))
fbcon_exit();
 
+   if (vc->vc_num == logo_shown)
+   logo_shown = FBCON_LOGO_CANSHOW;
+
return;
 }
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Andy Shevchenko]

On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
> > On Fri, Mar 27, 2020 at 1:12 PM Michal Simek  
> > wrote:
> > >
> > > recently we wanted to update xilinx intc driver and we found that function
> > > which we wanted to remove is still wired by ancient Xilinx PowerPC
> > > platforms. Here is the thread about it.
> > > https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa...@xilinx.com/
> > >
> > > I have been talking about it internally and there is no interest in these
> > > platforms and it is also orphan for quite a long time. None is really
> > > running/testing these platforms regularly that's why I think it makes 
> > > sense
> > > to remove them also with drivers which are specific to this platform.
> > >
> > > U-Boot support was removed in 2017 without anybody complain about it
> > > https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed
> > >
> > > Based on current ppc/next.
> > >
> > > If anyone has any objection about it, please let me know.
> > 
> > Acked-by: Arnd Bergmann 
> > 
> > This looks reasonable to me as well, in particular as the code only
> > supports the two
> > ppc44x virtex developer boards and no commercial products.
> > 
> > It does raise a follow-up question about ppc40x though: is it time to
> > retire all of it?
> 
> Who knows?
> 
> I have in possession nice WD My Book Live, based on this architecture, and I
> won't it gone from modern kernel support. OTOH I understand that amount of 
> real
> users not too big.

+Cc: Christian Lamparter, whom I owe for that WD box.

> 
> Ah, and I have Amiga board, but that one is being used only for testing, so,
> I don't care much.
> 
> > The other ppc405 machines appear to have seen even fewer updates after the
> > OpenBlockS 600 got added in 2011, so it's possible nobody is using them any 
> > more
> > with modern kernels.
> > 
> > I see that OpenWRT removed both ppc40x and ppc44x exactly a year ago after
> > they had not been maintained for years.
> > 
> > However, 44x (in its ppc476 incarnation) is clearly still is used
> > through the fsp2 platform,
> > and can not be deprecated at least until that is known to have stopped
> > getting kernel
> > updates.
> > 
> > Arnd
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

-- 
With Best Regards,
Andy Shevchenko


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: check to see if the FPU is available before using it

[Jason A. Donenfeld]

It's not safe to just grab the FPU willy nilly without first checking to
see if it's available. This patch adds the usual call to may_use_simd()
and falls back to boring memcpy if it's not available.

Signed-off-by: Jason A. Donenfeld 
---
 drivers/gpu/drm/i915/i915_memcpy.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_memcpy.c 
b/drivers/gpu/drm/i915/i915_memcpy.c
index fdd550405fd3..7c0e022586bc 100644
--- a/drivers/gpu/drm/i915/i915_memcpy.c
+++ b/drivers/gpu/drm/i915/i915_memcpy.c
@@ -24,6 +24,7 @@
 
 #include 
 #include 
+#include 
 
 #include "i915_memcpy.h"
 
@@ -38,6 +39,12 @@ static DEFINE_STATIC_KEY_FALSE(has_movntdqa);
 #ifdef CONFIG_AS_MOVNTDQA
 static void __memcpy_ntdqa(void *dst, const void *src, unsigned long len)
 {
+   if (unlikely(!may_use_simd())) {
+   memcpy(dst, src, len);
+   return;
+   }
+
+
kernel_fpu_begin();
 
while (len >= 4) {
@@ -67,6 +74,11 @@ static void __memcpy_ntdqa(void *dst, const void *src, 
unsigned long len)
 
 static void __memcpy_ntdqu(void *dst, const void *src, unsigned long len)
 {
+   if (unlikely(!may_use_simd())) {
+   memcpy(dst, src, len);
+   return;
+   }
+
kernel_fpu_begin();
 
while (len >= 4) {
-- 
2.26.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v3 2/8] drm: ingenic-drm: add MODULE_DEVICE_TABLE

[H. Nikolaus Schaller]

so that the driver can load by matching the device tree
if compiled as module.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 6d47ef7b148c..bcba2f024842 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -843,6 +843,7 @@ static const struct of_device_id ingenic_drm_of_match[] = {
{ .compatible = "ingenic,jz4770-lcd", .data = &jz4770_soc_info },
{ /* sentinel */ },
 };
+MODULE_DEVICE_TABLE(of, ingenic_drm_of_match);
 
 static struct platform_driver ingenic_drm_driver = {
.driver = {
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Andy Shevchenko]

On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
>  wrote:
> > On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
> > > On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
> > > > On Fri, Mar 27, 2020 at 1:12 PM Michal Simek  
> > > > wrote:

...

> > > > It does raise a follow-up question about ppc40x though: is it time to
> > > > retire all of it?
> > >
> > > Who knows?
> > >
> > > I have in possession nice WD My Book Live, based on this architecture, 
> > > and I
> > > won't it gone from modern kernel support. OTOH I understand that amount 
> > > of real
> > > users not too big.
> >
> > +Cc: Christian Lamparter, whom I owe for that WD box.
> 
> According to https://openwrt.org/toh/wd/mybooklive, that one is based on
> APM82181/ppc464, so it is about several generations newer than what I
> asked about (ppc40x).
> 
> > > Ah, and I have Amiga board, but that one is being used only for testing, 
> > > so,
> > > I don't care much.
> 
> I think there are a couple of ppc440 based Amiga boards, but again, not 405
> to my knowledge.

Ah, you are right. No objections from ppc40x removal!

-- 
With Best Regards,
Andy Shevchenko


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 21/22] ARM: tegra: Enable interconnect API in tegra_defconfig

[Dmitry Osipenko]

Tegra now has interconnect providers that are used for memory bandwidth
allocation.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/configs/tegra_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index aa94369bdd0f..0029259a6bf5 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -268,6 +268,7 @@ CONFIG_AK8975=y
 CONFIG_PWM=y
 CONFIG_PWM_TEGRA=y
 CONFIG_PHY_TEGRA_XUSB=y
+CONFIG_INTERCONNECT=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT2_FS_XATTR=y
 CONFIG_EXT2_FS_POSIX_ACL=y
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dt-bindings: display: meson-vpu: fix indentation of reg-names' "items"

[Martin Blumenstingl]

Use two spaces for indentation instead of one to be consistent with the
rest of the file. No functional changes.

Fixes: 6b9ebf1e0e678b ("dt-bindings: display: amlogic, meson-vpu: convert to 
yaml")
Signed-off-by: Martin Blumenstingl 
---
 .../devicetree/bindings/display/amlogic,meson-vpu.yaml  | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml 
b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
index d1205a6697a0..cd8ad2af52c9 100644
--- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
@@ -71,9 +71,9 @@ properties:
 maxItems: 2
 
   reg-names:
-   items:
- - const: vpu
- - const: hhi
+items:
+  - const: vpu
+  - const: hhi
 
   interrupts:
 maxItems: 1
-- 
2.26.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 hmm 1/9] mm/hmm: remove pgmap checking for devmap pages

[Jason Gunthorpe]

From: Jason Gunthorpe 

The checking boils down to some racy check if the pagemap is still
available or not. Instead of checking this, rely entirely on the
notifiers, if a pagemap is destroyed then all pages that belong to it must
be removed from the tables and the notifiers triggered.

Reviewed-by: Ralph Campbell 
Reviewed-by: Christoph Hellwig 
Tested-by: Ralph Campbell 
Signed-off-by: Jason Gunthorpe 
---
 mm/hmm.c | 50 ++
 1 file changed, 2 insertions(+), 48 deletions(-)

diff --git a/mm/hmm.c b/mm/hmm.c
index a491d9aaafe45d..3a2610e0713329 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -28,7 +28,6 @@
 
 struct hmm_vma_walk {
struct hmm_range*range;
-   struct dev_pagemap  *pgmap;
unsigned long   last;
unsigned intflags;
 };
@@ -196,19 +195,8 @@ static int hmm_vma_handle_pmd(struct mm_walk *walk, 
unsigned long addr,
return hmm_vma_fault(addr, end, fault, write_fault, walk);
 
pfn = pmd_pfn(pmd) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
-   for (i = 0; addr < end; addr += PAGE_SIZE, i++, pfn++) {
-   if (pmd_devmap(pmd)) {
-   hmm_vma_walk->pgmap = get_dev_pagemap(pfn,
- hmm_vma_walk->pgmap);
-   if (unlikely(!hmm_vma_walk->pgmap))
-   return -EBUSY;
-   }
+   for (i = 0; addr < end; addr += PAGE_SIZE, i++, pfn++)
pfns[i] = hmm_device_entry_from_pfn(range, pfn) | cpu_flags;
-   }
-   if (hmm_vma_walk->pgmap) {
-   put_dev_pagemap(hmm_vma_walk->pgmap);
-   hmm_vma_walk->pgmap = NULL;
-   }
hmm_vma_walk->last = end;
return 0;
 }
@@ -300,15 +288,6 @@ static int hmm_vma_handle_pte(struct mm_walk *walk, 
unsigned long addr,
if (fault || write_fault)
goto fault;
 
-   if (pte_devmap(pte)) {
-   hmm_vma_walk->pgmap = get_dev_pagemap(pte_pfn(pte),
- hmm_vma_walk->pgmap);
-   if (unlikely(!hmm_vma_walk->pgmap)) {
-   pte_unmap(ptep);
-   return -EBUSY;
-   }
-   }
-
/*
 * Since each architecture defines a struct page for the zero page, just
 * fall through and treat it like a normal page.
@@ -328,10 +307,6 @@ static int hmm_vma_handle_pte(struct mm_walk *walk, 
unsigned long addr,
return 0;
 
 fault:
-   if (hmm_vma_walk->pgmap) {
-   put_dev_pagemap(hmm_vma_walk->pgmap);
-   hmm_vma_walk->pgmap = NULL;
-   }
pte_unmap(ptep);
/* Fault any virtual address we were asked to fault */
return hmm_vma_fault(addr, end, fault, write_fault, walk);
@@ -418,16 +393,6 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp,
return r;
}
}
-   if (hmm_vma_walk->pgmap) {
-   /*
-* We do put_dev_pagemap() here and not in hmm_vma_handle_pte()
-* so that we can leverage get_dev_pagemap() optimization which
-* will not re-take a reference on a pgmap if we already have
-* one.
-*/
-   put_dev_pagemap(hmm_vma_walk->pgmap);
-   hmm_vma_walk->pgmap = NULL;
-   }
pte_unmap(ptep - 1);
 
hmm_vma_walk->last = addr;
@@ -491,20 +456,9 @@ static int hmm_vma_walk_pud(pud_t *pudp, unsigned long 
start, unsigned long end,
}
 
pfn = pud_pfn(pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
-   for (i = 0; i < npages; ++i, ++pfn) {
-   hmm_vma_walk->pgmap = get_dev_pagemap(pfn,
- hmm_vma_walk->pgmap);
-   if (unlikely(!hmm_vma_walk->pgmap)) {
-   ret = -EBUSY;
-   goto out_unlock;
-   }
+   for (i = 0; i < npages; ++i, ++pfn)
pfns[i] = hmm_device_entry_from_pfn(range, pfn) |
  cpu_flags;
-   }
-   if (hmm_vma_walk->pgmap) {
-   put_dev_pagemap(hmm_vma_walk->pgmap);
-   hmm_vma_walk->pgmap = NULL;
-   }
hmm_vma_walk->last = end;
goto out_unlock;
}
-- 
2.25.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [DPU PATCH v4 4/5] drm/msm/dp: add support for DP PLL driver

[varar]

Hi Stephen Boyd,

I have updated our comments inline for the queries.
Could you please check and let know your views.
I have addressed most of the comments from Rob/Jordon and planning to 
update new patchset in couple of days.


Thanks,
--Vara

On 2020-03-27 13:28, va...@codeaurora.org wrote:

On 2020-03-19 15:17, Stephen Boyd wrote:

Quoting Vara Reddy (2020-03-04 16:10:27)

From: Chandan Uddaraju 

Add the needed DP PLL specific files to support
display port interface on msm targets.

The DP driver calls the DP PLL driver registration.
The DP driver sets the link and pixel clock sources.

Changes in v2:
-- Update copyright markings on all relevant files.
-- Use DRM_DEBUG_DP for debug msgs.

Changes in v4:
-- Update the DP link clock provider names

Signed-off-by: Chandan Uddaraju 
Signed-off-by: Vara Reddy 
---
 drivers/gpu/drm/msm/Kconfig   |  13 +
 drivers/gpu/drm/msm/Makefile  |   4 +
 drivers/gpu/drm/msm/dp/dp_display.c   |  51 +++
 drivers/gpu/drm/msm/dp/dp_display.h   |   3 +
 drivers/gpu/drm/msm/dp/dp_parser.h|   4 +
 drivers/gpu/drm/msm/dp/dp_power.h |   1 -
 drivers/gpu/drm/msm/dp/pll/dp_pll.c   | 136 +++
 drivers/gpu/drm/msm/dp/pll/dp_pll.h   |  57 +++
 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.c  | 406 


 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.h  |  86 +
 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm_util.c | 524 
++

 11 files changed, 1284 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll.c
 create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll.h
 create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.c
 create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.h
 create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm_util.c

diff --git a/drivers/gpu/drm/msm/Kconfig 
b/drivers/gpu/drm/msm/Kconfig

index 7946cb1..e73ad23 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -66,6 +66,19 @@ config DRM_MSM_DP
  display support is enabled through this config option. It 
can

  be primary or secondary display on device.

+config DRM_MSM_DP_PLL
+   bool "Enable DP PLL driver in MSM DRM"
+   depends on DRM_MSM_DP && COMMON_CLK
+   help
+ Choose this option to enable DP PLL driver which provides 
DP

+ source clocks under common clock framework.
+
+config DRM_MSM_DP_10NM_PLL
+   bool "Enable DP 10nm PLL driver in MSM DRM (used by SDM845)"
+   depends on DRM_MSM_DP_PLL
+   help
+ Choose this option if DP PLL on SDM845 is used on the 
platform.

+
 config DRM_MSM_DSI
bool "Enable DSI support in MSM DRM driver"
depends on DRM_MSM
diff --git a/drivers/gpu/drm/msm/Makefile 
b/drivers/gpu/drm/msm/Makefile

index c846599..1621f3f 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -140,4 +140,8 @@ msm-$(CONFIG_DRM_MSM_DSI_14NM_PHY) += 
dsi/pll/dsi_pll_14nm.o

 msm-$(CONFIG_DRM_MSM_DSI_10NM_PHY) += dsi/pll/dsi_pll_10nm.o
 endif

+msm-$(CONFIG_DRM_MSM_DP_PLL)+= dp/pll/dp_pll.o
+msm-$(CONFIG_DRM_MSM_DP_10NM_PLL)+= dp/pll/dp_pll_10nm.o \
+   dp/pll/dp_pll_10nm_util.o
+
 obj-$(CONFIG_DRM_MSM)  += msm.o
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c

index 5525405..ded8f5c 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -61,6 +61,51 @@ struct dp_display_private {
{}
 };

+static int dp_get_pll(struct dp_display_private *dp_priv)
+{
+   struct platform_device *pdev = NULL;
+   struct platform_device *pll_pdev;
+   struct device_node *pll_node;
+   struct dp_parser *dp_parser = NULL;
+
+   if (!dp_priv) {
+   DRM_ERROR("Invalid Arguments\n");


It's a static function. Is this even possible? The bad code would be 
in

the same file.


+   return -EINVAL;
+   }
+
+   pdev = dp_priv->pdev;
+   dp_parser = dp_priv->parser;
+
+   if (!dp_parser) {
+   DRM_DEV_ERROR(&pdev->dev, "%s: Parser not 
initialized\n",

+   __func__);
+   return -EINVAL;
+   }
+
+   pll_node = of_parse_phandle(pdev->dev.of_node, "pll-node", 
0);

+   if (!pll_node) {
+   DRM_DEV_ERROR(&pdev->dev, "%s: cannot find pll 
device\n",

+   __func__);
+   return -ENXIO;
+   }
+
+   pll_pdev = of_find_device_by_node(pll_node);
+   if (pll_pdev)
+   dp_parser->pll = platform_get_drvdata(pll_pdev);
+
+   of_node_put(pll_node);
+
+   if (!pll_pdev || !dp_parser->pll) {
+   DRM_DEV_ERROR(&pdev->dev, "%s: pll driver is not 
ready\n",

+   __func__);
+   return -EPROBE_DEFER;
+   }
+
+   dp_parser->pll_dev = get_device(&pll_pdev->dev);
+
+   return 0;
+}
+
 static irqreturn_t dp_display_irq

Re: [PATCH] fbcon: fix null-ptr-deref in fbcon_switch

[Qiujun Huang]

On Sun, Mar 29, 2020 at 12:31 AM Daniel Vetter  wrote:
>
> On Sat, Mar 28, 2020 at 4:15 PM Qiujun Huang  wrote:
> > Add check for vc_cons[logo_shown].d, as it can be released by
> > vt_ioctl(VT_DISALLOCATE).
>
> Can you pls link to the syzbot report and distill the essence of the
> crash/issue here in the commit message? As-is a bit unclear what's
> going on. Patch itself looks correct.

https://lkml.org/lkml/2020/3/27/403
Thanks.

>
> Thanks, Daniel
>
> > Reported-by: syzbot+732528bae351682f1...@syzkaller.appspotmail.com
> > Signed-off-by: Qiujun Huang 
> > ---
> >  drivers/video/fbdev/core/fbcon.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c 
> > b/drivers/video/fbdev/core/fbcon.c
> > index bb6ae995c2e5..7ee0f7b55829 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -2254,7 +2254,7 @@ static int fbcon_switch(struct vc_data *vc)
> > fbcon_update_softback(vc);
> > }
> >
> > -   if (logo_shown >= 0) {
> > +   if (logo_shown >= 0 && vc_cons_allocated(logo_shown)) {
> > struct vc_data *conp2 = vc_cons[logo_shown].d;
> >
> > if (conp2->vc_top == logo_lines
> > @@ -2852,7 +2852,7 @@ static void fbcon_scrolldelta(struct vc_data *vc, int 
> > lines)
> > return;
> > if (vc->vc_mode != KD_TEXT || !lines)
> > return;
> > -   if (logo_shown >= 0) {
> > +   if (logo_shown >= 0 && vc_cons_allocated(logo_shown)) {
> > struct vc_data *conp2 = vc_cons[logo_shown].d;
> >
> > if (conp2->vc_top == logo_lines
> > --
> > 2.17.1
> >
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 hmm 3/9] mm/hmm: remove unused code and tidy comments

[Jason Gunthorpe]

From: Jason Gunthorpe 

Delete several functions that are never called, fix some desync between
comments and structure content, toss the now out of date top of file
header, and move one function only used by hmm.c into hmm.c

Reviewed-by: Christoph Hellwig 
Signed-off-by: Jason Gunthorpe 
---
 include/linux/hmm.h | 104 +---
 mm/hmm.c|  24 +++---
 2 files changed, 19 insertions(+), 109 deletions(-)

diff --git a/include/linux/hmm.h b/include/linux/hmm.h
index bb6be4428633a8..daee6508a3f609 100644
--- a/include/linux/hmm.h
+++ b/include/linux/hmm.h
@@ -3,58 +3,8 @@
  * Copyright 2013 Red Hat Inc.
  *
  * Authors: Jérôme Glisse 
- */
-/*
- * Heterogeneous Memory Management (HMM)
- *
- * See Documentation/vm/hmm.rst for reasons and overview of what HMM is and it
- * is for. Here we focus on the HMM API description, with some explanation of
- * the underlying implementation.
- *
- * Short description: HMM provides a set of helpers to share a virtual address
- * space between CPU and a device, so that the device can access any valid
- * address of the process (while still obeying memory protection). HMM also
- * provides helpers to migrate process memory to device memory, and back. Each
- * set of functionality (address space mirroring, and migration to and from
- * device memory) can be used independently of the other.
- *
- *
- * HMM address space mirroring API:
- *
- * Use HMM address space mirroring if you want to mirror a range of the CPU
- * page tables of a process into a device page table. Here, "mirror" means 
"keep
- * synchronized". Prerequisites: the device must provide the ability to write-
- * protect its page tables (at PAGE_SIZE granularity), and must be able to
- * recover from the resulting potential page faults.
  *
- * HMM guarantees that at any point in time, a given virtual address points to
- * either the same memory in both CPU and device page tables (that is: CPU and
- * device page tables each point to the same pages), or that one page table 
(CPU
- * or device) points to no entry, while the other still points to the old page
- * for the address. The latter case happens when the CPU page table update
- * happens first, and then the update is mirrored over to the device page 
table.
- * This does not cause any issue, because the CPU page table cannot start
- * pointing to a new page until the device page table is invalidated.
- *
- * HMM uses mmu_notifiers to monitor the CPU page tables, and forwards any
- * updates to each device driver that has registered a mirror. It also provides
- * some API calls to help with taking a snapshot of the CPU page table, and to
- * synchronize with any updates that might happen concurrently.
- *
- *
- * HMM migration to and from device memory:
- *
- * HMM provides a set of helpers to hotplug device memory as ZONE_DEVICE, with
- * a new MEMORY_DEVICE_PRIVATE type. This provides a struct page for each page
- * of the device memory, and allows the device driver to manage its memory
- * using those struct pages. Having struct pages for device memory makes
- * migration easier. Because that memory is not addressable by the CPU it must
- * never be pinned to the device; in other words, any CPU page fault can always
- * cause the device memory to be migrated (copied/moved) back to regular 
memory.
- *
- * A new migrate helper (migrate_vma()) has been added (see mm/migrate.c) that
- * allows use of a device DMA engine to perform the copy operation between
- * regular system memory and device memory.
+ * See Documentation/vm/hmm.rst for reasons and overview of what HMM is.
  */
 #ifndef LINUX_HMM_H
 #define LINUX_HMM_H
@@ -120,9 +70,6 @@ enum hmm_pfn_value_e {
  *
  * @notifier: a mmu_interval_notifier that includes the start/end
  * @notifier_seq: result of mmu_interval_read_begin()
- * @hmm: the core HMM structure this range is active against
- * @vma: the vm area struct for the range
- * @list: all range lock are on a list
  * @start: range virtual start address (inclusive)
  * @end: range virtual end address (exclusive)
  * @pfns: array of pfns (big enough for the range)
@@ -130,8 +77,7 @@ enum hmm_pfn_value_e {
  * @values: pfn value for some special case (none, special, error, ...)
  * @default_flags: default flags for the range (write, read, ... see hmm doc)
  * @pfn_flags_mask: allows to mask pfn flags so that only default_flags matter
- * @pfn_shifts: pfn shift value (should be <= PAGE_SHIFT)
- * @valid: pfns array did not change since it has been fill by an HMM function
+ * @pfn_shift: pfn shift value (should be <= PAGE_SHIFT)
  * @dev_private_owner: owner of device private pages
  */
 struct hmm_range {
@@ -171,52 +117,6 @@ static inline struct page *hmm_device_entry_to_page(const 
struct hmm_range *rang
return pfn_to_page(entry >> range->pfn_shift);
 }
 
-/*
- * hmm_device_entry_to_pfn() - return pfn value store in a device entry
- * @range: range use to decode device entry value
- * @en

Re: [PATCH] drm/i915: Force DPCD backlight mode for HP Spectre x360 Convertible 13t-aw100

[Kai-Heng Feng]

Hi,

> On Mar 23, 2020, at 13:35, Kai-Heng Feng  wrote:
> 
> There's another OLED panel needs to use DPCD aux interface to control
> backlight.
> 
> BugLink: https://bugs.launchpad.net/bugs/1860303
> Signed-off-by: Kai-Heng Feng 

Would it be possible to review this?
I'd like to send a similar quirk for a new panel, and I want to avoid causing 
any merge conflict.

Kai-Heng

> ---
> drivers/gpu/drm/drm_dp_helper.c | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 8ba4531e808d..a0d4314663de 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1301,6 +1301,8 @@ static const struct edid_quirk edid_quirk_list[] = {
>* only supports DPCD backlight controls
>*/
>   { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41), 
> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> + /* HP Spectre x360 Convertible 13t-aw100 */
> + { MFG(0x4c, 0x83), PROD_ID(0x42, 0x41), 
> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
>   /*
>* Some Dell CML 2020 systems have panels support both AUX and PWM
>* backlight control, and some only support AUX backlight control. All
> -- 
> 2.17.1
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH] staging: fbtft: Replace udelay with preferred usleep_range

[Julia Lawall]

On Sun, 29 Mar 2020, John Wyatt wrote:

> On Sun, 2020-03-29 at 11:28 +0200, Julia Lawall wrote:
> >
> > On Sun, 29 Mar 2020, John B. Wyatt IV wrote:
> >
> > > Fix style issue with usleep_range being reported as preferred over
> > > udelay.
> > >
> > > Issue reported by checkpatch.
> > >
> > > Please review.
> > >
> > > As written in Documentation/timers/timers-howto.rst udelay is the
> > > generally preferred API. hrtimers, as noted in the docs, may be too
> > > expensive for this short timer.
> > >
> > > Are the docs out of date, or, is this a checkpatch issue?
> > >
> > > Signed-off-by: John B. Wyatt IV 
> > > ---
> > >  drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c
> > > b/drivers/staging/fbtft/fb_agm1264k-fl.c
> > > index ec97ad27..019c8cce6bab 100644
> > > --- a/drivers/staging/fbtft/fb_agm1264k-fl.c
> > > +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
> > > @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par)
> > >   dev_dbg(par->info->device, "%s()\n", __func__);
> > >
> > >   gpiod_set_value(par->gpio.reset, 0);
> > > - udelay(20);
> > > + usleep_range(20, 20);
> >
> > usleep_range should have a range, eg usleep_range(50, 100);.  But it
> > is
> > hard to know a priori what the range should be.  So it is probably
> > better
> > to leave the code alone.
>
> Understood.
>
> With the question I wrote in the commit message:
>
> "As written in Documentation/timers/timers-howto.rst udelay is the
> generally preferred API. hrtimers, as noted in the docs, may be too
> expensive for this short timer.
>
> Are the docs out of date, or, is this a checkpatch issue?"
>
> Is usleep_range too expensive for this operation?
>
> Why does checkpatch favor usleep_range while the docs favor udelay?

I don't know the answer in detail, but it is quite possible that
checkpatch doesn't pay any attention to the delay argument.  Checkpatch is
a perl script that highlights things that may be of concern.  It is not a
precise static analsis tool.

As a matter of form, all of your Please review comments should have been
put below the ---.  Currently, if someone had wanted to apply the patch,
you would make them do extra work to remove this information.

julia

>
> >
> > julia
> >
> > >   gpiod_set_value(par->gpio.reset, 1);
> > >   mdelay(120);
> > >  }
> > > --
> > > 2.25.1
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "outreachy-kernel" group.
> > > To unsubscribe from this group and stop receiving emails from it,
> > > send an email to outreachy-kernel+unsubscr...@googlegroups.com.
> > > To view this discussion on the web visit
> > > https://groups.google.com/d/msgid/outreachy-kernel/20200329092204.770405-1-jbwyatt4%40gmail.com
> > > .
> > >
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v3 8/8] MIPS: CI20: defconfig: configure for DRM_DW_HDMI_JZ4780

[H. Nikolaus Schaller]

We configure them as loadable modules by default.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/mips/configs/ci20_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index be41df2a81fb..3f733a555cb2 100644
--- a/arch/mips/configs/ci20_defconfig
+++ b/arch/mips/configs/ci20_defconfig
@@ -103,6 +103,9 @@ CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_JZ4740=y
 CONFIG_DMADEVICES=y
 CONFIG_DMA_JZ4780=y
+CONFIG_DRM=m
+CONFIG_DRM_DW_HDMI_JZ4780=m
+CONFIG_DRM_DW_HDMI=m
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_MEMORY=y
 CONFIG_EXT4_FS=y
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 hmm 2/9] mm/hmm: return the fault type from hmm_pte_need_fault()

[Jason Gunthorpe]

From: Jason Gunthorpe 

Using two bools instead of flags return is not necessary and leads to
bugs. Returning a value is easier for the compiler to check and easier to
pass around the code flow.

Convert the two bools into flags and push the change to all callers.

Signed-off-by: Jason Gunthorpe 
---
 mm/hmm.c | 183 ---
 1 file changed, 81 insertions(+), 102 deletions(-)

diff --git a/mm/hmm.c b/mm/hmm.c
index 3a2610e0713329..d208ddd351066f 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -32,6 +32,12 @@ struct hmm_vma_walk {
unsigned intflags;
 };
 
+enum {
+   HMM_NEED_FAULT = 1 << 0,
+   HMM_NEED_WRITE_FAULT = 1 << 1,
+   HMM_NEED_ALL_BITS = HMM_NEED_FAULT | HMM_NEED_WRITE_FAULT,
+};
+
 static int hmm_pfns_fill(unsigned long addr, unsigned long end,
struct hmm_range *range, enum hmm_pfn_value_e value)
 {
@@ -49,8 +55,7 @@ static int hmm_pfns_fill(unsigned long addr, unsigned long 
end,
  * hmm_vma_fault() - fault in a range lacking valid pmd or pte(s)
  * @addr: range virtual start address (inclusive)
  * @end: range virtual end address (exclusive)
- * @fault: should we fault or not ?
- * @write_fault: write fault ?
+ * @required_fault: HMM_NEED_* flags
  * @walk: mm_walk structure
  * Return: -EBUSY after page fault, or page fault error
  *
@@ -58,8 +63,7 @@ static int hmm_pfns_fill(unsigned long addr, unsigned long 
end,
  * or whenever there is no page directory covering the virtual address range.
  */
 static int hmm_vma_fault(unsigned long addr, unsigned long end,
- bool fault, bool write_fault,
- struct mm_walk *walk)
+unsigned int required_fault, struct mm_walk *walk)
 {
struct hmm_vma_walk *hmm_vma_walk = walk->private;
struct hmm_range *range = hmm_vma_walk->range;
@@ -68,13 +72,13 @@ static int hmm_vma_fault(unsigned long addr, unsigned long 
end,
unsigned long i = (addr - range->start) >> PAGE_SHIFT;
unsigned int fault_flags = FAULT_FLAG_REMOTE;
 
-   WARN_ON_ONCE(!fault && !write_fault);
+   WARN_ON_ONCE(!required_fault);
hmm_vma_walk->last = addr;
 
if (!vma)
goto out_error;
 
-   if (write_fault) {
+   if (required_fault & HMM_NEED_WRITE_FAULT) {
if (!(vma->vm_flags & VM_WRITE))
return -EPERM;
fault_flags |= FAULT_FLAG_WRITE;
@@ -91,14 +95,13 @@ static int hmm_vma_fault(unsigned long addr, unsigned long 
end,
return -EFAULT;
 }
 
-static inline void hmm_pte_need_fault(const struct hmm_vma_walk *hmm_vma_walk,
- uint64_t pfns, uint64_t cpu_flags,
- bool *fault, bool *write_fault)
+static unsigned int hmm_pte_need_fault(const struct hmm_vma_walk *hmm_vma_walk,
+  uint64_t pfns, uint64_t cpu_flags)
 {
struct hmm_range *range = hmm_vma_walk->range;
 
if (hmm_vma_walk->flags & HMM_FAULT_SNAPSHOT)
-   return;
+   return 0;
 
/*
 * So we not only consider the individual per page request we also
@@ -114,37 +117,37 @@ static inline void hmm_pte_need_fault(const struct 
hmm_vma_walk *hmm_vma_walk,
 
/* We aren't ask to do anything ... */
if (!(pfns & range->flags[HMM_PFN_VALID]))
-   return;
+   return 0;
 
-   /* If CPU page table is not valid then we need to fault */
-   *fault = !(cpu_flags & range->flags[HMM_PFN_VALID]);
/* Need to write fault ? */
if ((pfns & range->flags[HMM_PFN_WRITE]) &&
-   !(cpu_flags & range->flags[HMM_PFN_WRITE])) {
-   *write_fault = true;
-   *fault = true;
-   }
+   !(cpu_flags & range->flags[HMM_PFN_WRITE]))
+   return HMM_NEED_FAULT | HMM_NEED_WRITE_FAULT;
+
+   /* If CPU page table is not valid then we need to fault */
+   if (!(cpu_flags & range->flags[HMM_PFN_VALID]))
+   return HMM_NEED_FAULT;
+   return 0;
 }
 
-static void hmm_range_need_fault(const struct hmm_vma_walk *hmm_vma_walk,
-const uint64_t *pfns, unsigned long npages,
-uint64_t cpu_flags, bool *fault,
-bool *write_fault)
+static unsigned int
+hmm_range_need_fault(const struct hmm_vma_walk *hmm_vma_walk,
+const uint64_t *pfns, unsigned long npages,
+uint64_t cpu_flags)
 {
+   unsigned int required_fault = 0;
unsigned long i;
 
-   if (hmm_vma_walk->flags & HMM_FAULT_SNAPSHOT) {
-   *fault = *write_fault = false;
-   return;
-   }
+   if (hmm_vma_walk->flags & HMM_FAULT_SNAPSHOT)
+   return 0;
 
-   *fault = *write_fault = false;
for (i = 0; i < npages; ++i) {
-   hmm_pte_need

[PATCH v5 1/8] dt-bindings: add img,pvrsgx.yaml for Imagination GPUs

[H. Nikolaus Schaller]

The Imagination PVR/SGX GPU is part of several SoC from
multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo,
Allwinner A83 and others.

With this binding, we describe how the SGX processor is
interfaced to the SoC (registers, interrupt etc.).

In most cases, Clock, Reset and power management is handled
by a parent node or elsewhere (e.g. code in the driver).

Tested by make dt_binding_check dtbs_check

Signed-off-by: H. Nikolaus Schaller 
---
 .../devicetree/bindings/gpu/img,pvrsgx.yaml   | 109 ++
 1 file changed, 109 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml

diff --git a/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml 
b/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml
new file mode 100644
index ..aadfb2d9b012
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpu/img,pvrsgx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Imagination PVR/SGX GPU
+
+maintainers:
+  - H. Nikolaus Schaller 
+
+description: |+
+  This binding describes the Imagination SGX5 series of 3D accelerators which
+  are found in several different SoC like TI OMAP, Sitara, Ingenic JZ4780,
+  Allwinner A83, and Intel Poulsbo and CedarView and more.
+
+  For an extensive list see: 
https://en.wikipedia.org/wiki/PowerVR#Implementations
+
+  The SGX node is usually a child node of some DT node belonging to the SoC
+  which handles clocks, reset and general address space mapping of the SGX
+  register area.
+
+properties:
+  compatible:
+oneOf:
+  - description: SGX530-121 based SoC
+items:
+  - enum:
+- ti,omap3-sgx530-121 # BeagleBoard A/B/C, OpenPandora 600MHz and 
similar
+  - const: img,sgx530-121
+  - const: img,sgx530
+
+  - description: SGX530-125 based SoC
+items:
+  - enum:
+- ti,am3352-sgx530-125 # BeagleBone Black
+- ti,am3517-sgx530-125
+- ti,am4-sgx530-125
+- ti,omap3-sgx530-125 # BeagleBoard XM, GTA04, OpenPandora 1GHz 
and similar
+- ti,ti81xx-sgx530-125
+  - const: ti,omap3-sgx530-125
+  - const: img,sgx530-125
+  - const: img,sgx530
+
+  - description: SGX535-116 based SoC
+items:
+  - const: intel,poulsbo-gma500-sgx535 # Atom Z5xx
+  - const: img,sgx535-116
+  - const: img,sgx535
+
+  - description: SGX540-116 based SoC
+items:
+  - const: intel,medfield-gma-sgx540 # Atom Z24xx
+  - const: img,sgx540-116
+  - const: img,sgx540
+
+  - description: SGX540-120 based SoC
+items:
+  - enum:
+- ingenic,jz4780-sgx540-120 # CI20
+- ti,omap4-sgx540-120 # Pandaboard, Pandaboard ES and similar
+  - const: img,sgx540-120
+  - const: img,sgx540
+
+  - description: SGX544-112 based SoC
+items:
+  - const: ti,omap4-sgx544-112
+  - const: img,sgx544-112
+  - const: img,sgx544
+
+  - description: SGX544-116 based SoC
+items:
+  - enum:
+- allwinner,sun8i-a83t-sgx544-116 # Banana-Pi-M3 (Allwinner A83T) 
and similar
+- ti,dra7-sgx544-116 # DRA7
+- ti,omap5-sgx544-116 # OMAP5 UEVM, Pyra Handheld and similar
+  - const: img,sgx544-116
+  - const: img,sgx544
+
+  - description: SGX545-116 based SoC
+items:
+  - const: intel,cedarview-gma3600-sgx545 # Atom N2600, D2500
+  - const: img,sgx545-116
+  - const: img,sgx545
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+
+additionalProperties: false
+
+examples:
+  - |+
+#include 
+
+gpu: gpu@fe00 {
+  compatible = "ti,omap5-sgx544-116", "img,sgx544-116", "img,sgx544";
+  reg = <0xfe00 0x200>;
+  interrupts = ;
+};
+
+...
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [DPU PATCH v4 4/5] drm/msm/dp: add support for DP PLL driver

[varar]

On 2020-03-19 15:17, Stephen Boyd wrote:

Quoting Vara Reddy (2020-03-04 16:10:27)

From: Chandan Uddaraju 

Add the needed DP PLL specific files to support
display port interface on msm targets.

The DP driver calls the DP PLL driver registration.
The DP driver sets the link and pixel clock sources.

Changes in v2:
-- Update copyright markings on all relevant files.
-- Use DRM_DEBUG_DP for debug msgs.

Changes in v4:
-- Update the DP link clock provider names

Signed-off-by: Chandan Uddaraju 
Signed-off-by: Vara Reddy 
---
 drivers/gpu/drm/msm/Kconfig   |  13 +
 drivers/gpu/drm/msm/Makefile  |   4 +
 drivers/gpu/drm/msm/dp/dp_display.c   |  51 +++
 drivers/gpu/drm/msm/dp/dp_display.h   |   3 +
 drivers/gpu/drm/msm/dp/dp_parser.h|   4 +
 drivers/gpu/drm/msm/dp/dp_power.h |   1 -
 drivers/gpu/drm/msm/dp/pll/dp_pll.c   | 136 +++
 drivers/gpu/drm/msm/dp/pll/dp_pll.h   |  57 +++
 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.c  | 406 


 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.h  |  86 +
 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm_util.c | 524 
++

 11 files changed, 1284 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll.c
 create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll.h
 create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.c
 create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.h
 create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm_util.c

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 7946cb1..e73ad23 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -66,6 +66,19 @@ config DRM_MSM_DP
  display support is enabled through this config option. It 
can

  be primary or secondary display on device.

+config DRM_MSM_DP_PLL
+   bool "Enable DP PLL driver in MSM DRM"
+   depends on DRM_MSM_DP && COMMON_CLK
+   help
+ Choose this option to enable DP PLL driver which provides DP
+ source clocks under common clock framework.
+
+config DRM_MSM_DP_10NM_PLL
+   bool "Enable DP 10nm PLL driver in MSM DRM (used by SDM845)"
+   depends on DRM_MSM_DP_PLL
+   help
+ Choose this option if DP PLL on SDM845 is used on the 
platform.

+
 config DRM_MSM_DSI
bool "Enable DSI support in MSM DRM driver"
depends on DRM_MSM
diff --git a/drivers/gpu/drm/msm/Makefile 
b/drivers/gpu/drm/msm/Makefile

index c846599..1621f3f 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -140,4 +140,8 @@ msm-$(CONFIG_DRM_MSM_DSI_14NM_PHY) += 
dsi/pll/dsi_pll_14nm.o

 msm-$(CONFIG_DRM_MSM_DSI_10NM_PHY) += dsi/pll/dsi_pll_10nm.o
 endif

+msm-$(CONFIG_DRM_MSM_DP_PLL)+= dp/pll/dp_pll.o
+msm-$(CONFIG_DRM_MSM_DP_10NM_PLL)+= dp/pll/dp_pll_10nm.o \
+   dp/pll/dp_pll_10nm_util.o
+
 obj-$(CONFIG_DRM_MSM)  += msm.o
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c

index 5525405..ded8f5c 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -61,6 +61,51 @@ struct dp_display_private {
{}
 };

+static int dp_get_pll(struct dp_display_private *dp_priv)
+{
+   struct platform_device *pdev = NULL;
+   struct platform_device *pll_pdev;
+   struct device_node *pll_node;
+   struct dp_parser *dp_parser = NULL;
+
+   if (!dp_priv) {
+   DRM_ERROR("Invalid Arguments\n");


It's a static function. Is this even possible? The bad code would be in
the same file.


+   return -EINVAL;
+   }
+
+   pdev = dp_priv->pdev;
+   dp_parser = dp_priv->parser;
+
+   if (!dp_parser) {
+   DRM_DEV_ERROR(&pdev->dev, "%s: Parser not 
initialized\n",

+   __func__);
+   return -EINVAL;
+   }
+
+   pll_node = of_parse_phandle(pdev->dev.of_node, "pll-node", 0);
+   if (!pll_node) {
+   DRM_DEV_ERROR(&pdev->dev, "%s: cannot find pll 
device\n",

+   __func__);
+   return -ENXIO;
+   }
+
+   pll_pdev = of_find_device_by_node(pll_node);
+   if (pll_pdev)
+   dp_parser->pll = platform_get_drvdata(pll_pdev);
+
+   of_node_put(pll_node);
+
+   if (!pll_pdev || !dp_parser->pll) {
+   DRM_DEV_ERROR(&pdev->dev, "%s: pll driver is not 
ready\n",

+   __func__);
+   return -EPROBE_DEFER;
+   }
+
+   dp_parser->pll_dev = get_device(&pll_pdev->dev);
+
+   return 0;
+}
+
 static irqreturn_t dp_display_irq(int irq, void *dev_id)
 {
struct dp_display_private *dp = dev_id;
@@ -114,6 +159,10 @@ static int dp_display_bind(struct device *dev, 
struct device *master,

goto end;
}

+   rc = dp_get_pll(dp);
+   if (rc)
+   goto end;
+
rc = dp_aux_regist

[RFC v3 6/8] MIPS: DTS: jz4780: account for Synopsys HDMI driver and LCD controller

[H. Nikolaus Schaller]

From: Paul Boddie 

A specialisation of the generic Synopsys HDMI driver is employed for JZ4780
HDMI support. This requires a new driver, plus device tree and configuration
modifications.

Signed-off-by: Paul Boddie 
Signed-off-by: H. Nikolaus Schaller 
---
 arch/mips/boot/dts/ingenic/jz4780.dtsi | 46 ++
 1 file changed, 46 insertions(+)

diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi 
b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index bb89653d16a3..73776514bbe5 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -434,4 +434,50 @@ bch: bch@134d {
 
status = "disabled";
};
+
+   hdmi: hdmi@1018 {
+   compatible = "ingenic,jz4780-dw-hdmi";
+   reg = <0x1018 0x8000>;
+   reg-io-width = <4>;
+
+   clocks = <&cgu JZ4780_CLK_HDMI>, <&cgu JZ4780_CLK_AHB0>;
+   clock-names = "isfr" , "iahb";
+
+   assigned-clocks = <&cgu JZ4780_CLK_HDMI>;
+   assigned-clock-rates = <2700>;
+
+   interrupt-parent = <&intc>;
+   interrupts = <3>;
+
+   /* ddc-i2c-bus = <&i2c4>; */
+
+   status = "disabled";
+   };
+
+   lcdc0: lcdc0@1305 {
+   compatible = "ingenic,jz4780-lcd";
+   reg = <0x1305 0x1800>;
+
+   clocks = <&cgu JZ4780_CLK_TVE>, <&cgu JZ4780_CLK_LCD0PIXCLK>;
+   clock-names = "lcd", "lcd_pclk";
+
+   interrupt-parent = <&intc>;
+   interrupts = <31>;
+
+   status = "disabled";
+   };
+
+   lcdc1: lcdc1@130a {
+   compatible = "ingenic,jz4780-lcd";
+   reg = <0x130a 0x1800>;
+
+   clocks = <&cgu JZ4780_CLK_TVE>, <&cgu JZ4780_CLK_LCD1PIXCLK>;
+   clock-names = "lcd", "lcd_pclk";
+
+   interrupt-parent = <&intc>;
+   interrupts = <31>;
+
+   status = "disabled";
+   };
+
 };
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vc4: Fix HDMI mode validation

[Nicolas Saenz Julienne]

Hi Daniel,

On Thu, 2020-03-26 at 13:20 +0100, Nicolas Saenz Julienne wrote:
> Current mode validation impedes setting up some video modes which should
> be supported otherwise. Namely 1920x1200@60Hz.
> 
> Fix this by lowering the minimum HDMI state machine clock to pixel clock
> ratio allowed.
> 
> Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks")
> Reported-by: Stefan Wahren 
> Suggested-by: Dave Stevenson 
> Signed-off-by: Nicolas Saenz Julienne 

Would it be possible for you to take this in for v5.7 (or as a fix for v5.6,
but it seems a little late)?

A device-tree patch I have to channel trough the SoC tree depends on this to
avoid regressions.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 7/8] ARM: DTS: omap5: add sgx gpu child node

[H. Nikolaus Schaller]

and add interrupt.

Tested-by: H. Nikolaus Schaller  # Pyra-Handheld.
Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap5.dtsi | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index d0ecf54d5a23..4c7c4ca0bd87 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -269,7 +269,7 @@ sata: sata@4a141100 {
ports-implemented = <0x1>;
};
 
-   target-module@5600 {
+   sgx_module: target-module@5600 {
compatible = "ti,sysc-omap4", "ti,sysc";
reg = <0x5600fe00 0x4>,
  <0x5600fe10 0x4>;
@@ -286,10 +286,11 @@ target-module@5600 {
#size-cells = <1>;
ranges = <0 0x5600 0x200>;
 
-   /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+   gpu: gpu@0 {
+   compatible = "ti,omap5-sgx544-116", 
"img,sgx544-116", "img,sgx544";
+   reg = <0x0 0x1>;
+   interrupts = ;
+   };
};
 
dss: dss@5800 {
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v3 0/8] MIPS: CI20: add HDMI out support

[H. Nikolaus Schaller]

+++ help is needed: driver is not completely working and shows no output signal 
on the HDMI data and clock lanes
+++ HPD is working and /dev/fb0 does appear
+++ but there is no trigger to initialize the lcdc

* add definition for second jz4780-lcdc
* diverse fixes for yaml schema
* make ingenic-drm driver compatible to ingenic,jz4780-lcd
* converted existing ingenic,lcd.txt to ingenic,lcd.yaml - suggested by Paul 
Cercueil 
* removed blank line before MODULE_DEVICE_TABLE() macro - Paul Cercueil 

* added some missing Signed-off:
* removed Zubair Lutfullah Kakakhel  from the
  recipients list and Cc: since the address is no longer available.
* removed "pinctrl: ingenic: add hdmi-ddc pin control group" from this patch
  series since it is already applied elsewhere (by Linus Walleij 
)

RFC V2 2020-02-28 19:19:40:
* Converted .txt bindings to .yaml (by Sam Ravnborg  - big 
THANKS)

RFC V1 2020-02-26 20:13:06:
This patch series adds HDMI output to the jz4780/CI20 board.

It is based on taking the old 3.18 vendor kernel as well as
an earlier submission from 2015:
https://lore.kernel.org/patchwork/patch/547872/
and trying to achieve the same with modern DTS setup and new/modified
drivers.

Unfortunately, in this first RFC, only EDID and creation of
/dev/fb0 are working. Also, HDMI hot plugging is detected.

But there is no HDMI output signal. So some tiny piece seems
to be missing to enable/configure the Synposys HDMI controller.

We need help from the community to fix this.

Original authors of most patches are
* Paul Boddie 
* Zubair Lutfullah Kakakhel 


H. Nikolaus Schaller (4):
  dt-bindings: display: convert ingenic,lcd.txt to ingenic,lcd.yaml
  drm: ingenic-drm: add MODULE_DEVICE_TABLE
  drm: ingenic-drm: add support for ingenic,jz4780-lcd
  MIPS: CI20: defconfig: configure for DRM_DW_HDMI_JZ4780

Paul Boddie (3):
  drm: ingenic: add jz4780 Synopsys HDMI driver
  MIPS: DTS: jz4780: account for Synopsys HDMI driver and LCD controller
  MIPS: DTS: CI20: add HDMI setup

Sam Ravnborg (1):
  dt-bindings: display: add ingenic-jz4780-hdmi DT Schema

 .../bindings/display/ingenic,lcd.txt  |  45 --
 .../bindings/display/ingenic,lcd.yaml | 128 ++
 .../bindings/display/ingenic-jz4780-hdmi.yaml |  82 +++
 arch/mips/boot/dts/ingenic/ci20.dts   |  64 +
 arch/mips/boot/dts/ingenic/jz4780.dtsi|  46 +++
 arch/mips/configs/ci20_defconfig  |   3 +
 drivers/gpu/drm/ingenic/Kconfig   |   8 ++
 drivers/gpu/drm/ingenic/Makefile  |   1 +
 drivers/gpu/drm/ingenic/dw_hdmi-jz4780.c  | 120 
 drivers/gpu/drm/ingenic/ingenic-drm.c |   8 ++
 10 files changed, 460 insertions(+), 45 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/ingenic,lcd.txt
 create mode 100644 Documentation/devicetree/bindings/display/ingenic,lcd.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml
 create mode 100644 drivers/gpu/drm/ingenic/dw_hdmi-jz4780.c

-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

general protection fault in fbcon_switch

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:e17994d1 usb: core: kcov: collect coverage from usb comple..
git tree:   https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=1328834be0
kernel config:  https://syzkaller.appspot.com/x/.config?x=5d64370c438bc60
dashboard link: https://syzkaller.appspot.com/bug?extid=732528bae351682f1f27
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+732528bae351682f1...@syzkaller.appspotmail.com

general protection fault, probably for non-canonical address 
0xdc6c:  [#1] SMP KASAN
KASAN: null-ptr-deref in range [0x0360-0x0367]
CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.6.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Workqueue: usb_hub_wq hub_event
RIP: 0010:fbcon_switch+0x28f/0x1740 drivers/video/fbdev/core/fbcon.c:2260
Code: 0f 85 96 14 00 00 48 8d 04 db 48 8b 1c c5 00 91 ff 89 48 b8 00 00 00 00 
00 fc ff df 48 8d bb 60 03 00 00 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 
3c 03 0f 8e de 11 00 00 44 8b b3 60 03 00
RSP: 0018:8881da1dead8 EFLAGS: 00010206
RAX: dc00 RBX:  RCX: c9000d9eb000
RDX: 006c RSI: 81fe5b44 RDI: 0360
RBP: 8881ab4f R08: 8881da196200 R09: fbfff0fcc10e
R10: fbfff0fcc10d R11: 87e6086f R12: 8881d6616000
R13: 8881c6a4a000 R14: 00a3 R15: 85ff8520
FS:  () GS:8881db20() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f676c8e2740 CR3: 0001cfd06000 CR4: 001406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 redraw_screen+0x2a8/0x770 drivers/tty/vt/vt.c:1008
 vc_do_resize+0xfe7/0x1360 drivers/tty/vt/vt.c:1295
 fbcon_init+0x1221/0x1ab0 drivers/video/fbdev/core/fbcon.c:1219
 visual_init+0x305/0x5c0 drivers/tty/vt/vt.c:1062
 do_bind_con_driver+0x536/0x890 drivers/tty/vt/vt.c:3542
 do_take_over_console+0x453/0x5b0 drivers/tty/vt/vt.c:4122
 do_fbcon_takeover+0x10b/0x210 drivers/video/fbdev/core/fbcon.c:588
 fbcon_fb_registered+0x26b/0x340 drivers/video/fbdev/core/fbcon.c:3259
 do_register_framebuffer drivers/video/fbdev/core/fbmem.c:1664 [inline]
 register_framebuffer+0x56e/0x980 drivers/video/fbdev/core/fbmem.c:1832
 dlfb_usb_probe.cold+0x1743/0x1ba3 drivers/video/fbdev/udlfb.c:1735
 usb_probe_interface+0x310/0x800 drivers/usb/core/driver.c:374
 really_probe+0x290/0xac0 drivers/base/dd.c:551
 driver_probe_device+0x223/0x350 drivers/base/dd.c:724
 __device_attach_driver+0x1d1/0x290 drivers/base/dd.c:831
 bus_for_each_drv+0x162/0x1e0 drivers/base/bus.c:431
 __device_attach+0x217/0x390 drivers/base/dd.c:897
 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491
 device_add+0x1459/0x1bf0 drivers/base/core.c:2500
 usb_set_configuration+0xe47/0x17d0 drivers/usb/core/message.c:2023
 usb_generic_driver_probe+0x9d/0xe0 drivers/usb/core/generic.c:241
 usb_probe_device+0xd9/0x230 drivers/usb/core/driver.c:272
 really_probe+0x290/0xac0 drivers/base/dd.c:551
 driver_probe_device+0x223/0x350 drivers/base/dd.c:724
 __device_attach_driver+0x1d1/0x290 drivers/base/dd.c:831
 bus_for_each_drv+0x162/0x1e0 drivers/base/bus.c:431
 __device_attach+0x217/0x390 drivers/base/dd.c:897
 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491
 device_add+0x1459/0x1bf0 drivers/base/core.c:2500
 usb_new_device.cold+0x540/0xcd0 drivers/usb/core/hub.c:2548
 hub_port_connect drivers/usb/core/hub.c:5195 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5335 [inline]
 port_event drivers/usb/core/hub.c:5481 [inline]
 hub_event+0x21cb/0x4300 drivers/usb/core/hub.c:5563
 process_one_work+0x94b/0x1620 kernel/workqueue.c:2264
 process_scheduled_works kernel/workqueue.c:2326 [inline]
 worker_thread+0x7ab/0xe20 kernel/workqueue.c:2412
 kthread+0x318/0x420 kernel/kthread.c:255
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Modules linked in:
---[ end trace bae4913bb3cd6c7d ]---
RIP: 0010:fbcon_switch+0x28f/0x1740 drivers/video/fbdev/core/fbcon.c:2260
Code: 0f 85 96 14 00 00 48 8d 04 db 48 8b 1c c5 00 91 ff 89 48 b8 00 00 00 00 
00 fc ff df 48 8d bb 60 03 00 00 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 
3c 03 0f 8e de 11 00 00 44 8b b3 60 03 00
RSP: 0018:8881da1dead8 EFLAGS: 00010206
RAX: dc00 RBX:  RCX: c9000d9eb000
RDX: 006c RSI: 81fe5b44 RDI: 0360
RBP: 8881ab4f R08: 8881da196200 R09: fbfff0fcc10e
R10: fbfff0fcc10d R11: 87e6086f R12: 8881d6616000
R13: 8881c6a4a000 R14: 00a3 R15: 85ff8520
FS:  () GS:8881db20(

[PATCH] fbcon: fix null-ptr-deref in fbcon_switch

[Qiujun Huang]

Add check for vc_cons[logo_shown].d, as it can be released by
vt_ioctl(VT_DISALLOCATE).

Reported-by: syzbot+732528bae351682f1...@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang 
---
 drivers/video/fbdev/core/fbcon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index bb6ae995c2e5..7ee0f7b55829 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2254,7 +2254,7 @@ static int fbcon_switch(struct vc_data *vc)
fbcon_update_softback(vc);
}
 
-   if (logo_shown >= 0) {
+   if (logo_shown >= 0 && vc_cons_allocated(logo_shown)) {
struct vc_data *conp2 = vc_cons[logo_shown].d;
 
if (conp2->vc_top == logo_lines
@@ -2852,7 +2852,7 @@ static void fbcon_scrolldelta(struct vc_data *vc, int 
lines)
return;
if (vc->vc_mode != KD_TEXT || !lines)
return;
-   if (logo_shown >= 0) {
+   if (logo_shown >= 0 && vc_cons_allocated(logo_shown)) {
struct vc_data *conp2 = vc_cons[logo_shown].d;
 
if (conp2->vc_top == logo_lines
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 16/22] memory: tegra30-emc: Continue probing if timings are missing in device-tree

[Dmitry Osipenko]

EMC driver will become mandatory after turning it into interconnect
provider because interconnect users, like display controller driver, will
fail to probe using newer device-trees that have interconnect properties.
Thus make EMC driver to probe even if timings are missing in device-tree.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/tegra30-emc.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/memory/tegra/tegra30-emc.c 
b/drivers/memory/tegra/tegra30-emc.c
index 900a291803ca..69698665d431 100644
--- a/drivers/memory/tegra/tegra30-emc.c
+++ b/drivers/memory/tegra/tegra30-emc.c
@@ -988,6 +988,11 @@ static struct device_node 
*emc_find_node_by_ram_code(struct device *dev)
u32 value, ram_code;
int err;
 
+   if (of_get_child_count(dev->of_node) == 0) {
+   dev_info(dev, "device-tree doesn't have memory timings\n");
+   return NULL;
+   }
+
ram_code = tegra_read_ram_code();
 
for_each_child_of_node(dev->of_node, np) {
@@ -1057,6 +1062,9 @@ static long emc_round_rate(unsigned long rate,
struct tegra_emc *emc = arg;
unsigned int i;
 
+   if (!emc->num_timings)
+   return clk_get_rate(emc->clk);
+
min_rate = min(min_rate, emc->timings[emc->num_timings - 1].rate);
 
for (i = 0; i < emc->num_timings; i++) {
@@ -1263,12 +1271,6 @@ static int tegra_emc_probe(struct platform_device *pdev)
struct tegra_emc *emc;
int err;
 
-   if (of_get_child_count(pdev->dev.of_node) == 0) {
-   dev_info(&pdev->dev,
-"device-tree node doesn't have memory timings\n");
-   return -ENODEV;
-   }
-
np = of_parse_phandle(pdev->dev.of_node, "nvidia,memory-controller", 0);
if (!np) {
dev_err(&pdev->dev, "could not get memory controller node\n");
@@ -1280,10 +1282,6 @@ static int tegra_emc_probe(struct platform_device *pdev)
if (!mc)
return -ENOENT;
 
-   np = emc_find_node_by_ram_code(&pdev->dev);
-   if (!np)
-   return -EINVAL;
-
emc = devm_kzalloc(&pdev->dev, sizeof(*emc), GFP_KERNEL);
if (!emc) {
of_node_put(np);
@@ -1297,10 +1295,13 @@ static int tegra_emc_probe(struct platform_device *pdev)
emc->clk_nb.notifier_call = emc_clk_change_notify;
emc->dev = &pdev->dev;
 
-   err = emc_load_timings_from_dt(emc, np);
-   of_node_put(np);
-   if (err)
-   return err;
+   np = emc_find_node_by_ram_code(&pdev->dev);
+   if (np) {
+   err = emc_load_timings_from_dt(emc, np);
+   of_node_put(np);
+   if (err)
+   return err;
+   }
 
emc->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(emc->regs))
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 18/22] drm/tegra: dc: Support memory bandwidth management

[Dmitry Osipenko]

Display controller (DC) performs isochronous memory transfers, and thus,
has a requirement for a minimum memory bandwidth that shall be fulfilled,
otherwise framebuffer data can't be fetched fast enough and this results
in a DC's data-FIFO underflow that follows by a visual corruption.

The Memory Controller drivers provide facility for memory bandwidth
management via interconnect API. This patch wires up the interconnect
API support to the DC driver.

Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/tegra/dc.c| 271 +-
 drivers/gpu/drm/tegra/dc.h|   8 +
 drivers/gpu/drm/tegra/drm.c   |  19 +++
 drivers/gpu/drm/tegra/plane.c |   1 +
 drivers/gpu/drm/tegra/plane.h |   4 +-
 5 files changed, 299 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 1a7b08f35776..b540ac6ffdc4 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -519,6 +519,136 @@ static void tegra_dc_setup_window(struct tegra_plane 
*plane,
tegra_plane_setup_blending(plane, window);
 }
 
+static unsigned long
+tegra_plane_memory_bandwidth(struct drm_plane_state *state,
+struct tegra_dc_window *window,
+unsigned int num,
+unsigned int denum)
+{
+   struct tegra_plane_state *tegra_state;
+   struct drm_crtc_state *crtc_state;
+   const struct drm_format_info *fmt;
+   struct tegra_dc_window win;
+   unsigned long long bandwidth;
+   unsigned int bpp_plane;
+   unsigned int bpp;
+   unsigned int mul;
+   unsigned int i;
+
+   if (!state->fb || !state->visible)
+   return 0;
+
+   crtc_state = drm_atomic_get_new_crtc_state(state->state, state->crtc);
+   tegra_state = to_tegra_plane_state(state);
+
+   if (!window)
+   window = &win;
+
+   window->src.w = drm_rect_width(&state->src) >> 16;
+   window->src.h = drm_rect_height(&state->src) >> 16;
+   window->dst.w = drm_rect_width(&state->dst);
+   window->dst.h = drm_rect_height(&state->dst);
+   window->tiling = tegra_state->tiling;
+
+   fmt = state->fb->format;
+
+   /*
+* Note that real memory bandwidth vary depending on format and
+* memory layout, we are not taking that into account because small
+* estimation error isn't important since bandwidth is rounded up
+* anyway.
+*/
+   for (i = 0, bpp = 0; i < fmt->num_planes; i++) {
+   bpp_plane = fmt->cpp[i] * 8;
+
+   /*
+* Sub-sampling is relevant for chroma planes only and vertical
+* readouts are not cached, hence only horizontal sub-sampling
+* matters.
+*/
+   if (i > 0)
+   bpp_plane /= fmt->hsub;
+
+   bpp += bpp_plane;
+   }
+
+   /*
+* Horizontal downscale takes extra bandwidth which roughly depends
+* on the scaled width.
+*/
+   if (window->src.w > window->dst.w)
+   mul = (window->src.w - window->dst.w) * bpp / 2048 + 1;
+   else
+   mul = 1;
+
+   /*
+* Ignore cursor window if its width is small enough such that
+* data-prefetch FIFO will easily help to overcome temporal memory
+* pressure.
+*
+* Window A has a 128bit x 128 deep read FIFO, while windows B/C
+* have a 128bit x 64 deep read FIFO.
+*
+* This allows us to not overestimate memory frequency requirement.
+* Even if it will happen that cursor gets a temporal underflow, this
+* won't be fatal.
+*/
+   if (state->plane->type == DRM_PLANE_TYPE_CURSOR &&
+   mul == 1 && window->src.w * bpp <= 128 * 16)
+   return 0;
+
+   /* mode.clock in kHz, bandwidth in kbit/s */
+   bandwidth = kbps_to_icc(crtc_state->mode.clock * bpp * mul);
+
+   /* the requested bandwidth should be higher than required */
+   bandwidth *= num;
+   do_div(bandwidth, denum);
+
+   return min_t(u64, bandwidth, ULONG_MAX);
+}
+
+static unsigned long
+tegra20_plane_memory_bandwidth(struct drm_plane_state *state)
+{
+   return tegra_plane_memory_bandwidth(state, NULL, 29, 10);
+}
+
+static unsigned long
+tegra30_plane_memory_bandwidth(struct drm_plane_state *state)
+{
+   struct tegra_dc_window window;
+   unsigned long bandwidth;
+
+   bandwidth = tegra_plane_memory_bandwidth(state, &window, 29, 10);
+
+   /* x2: memory overfetch for tiled framebuffer and DDR3 */
+   if (window.tiling.mode == TEGRA_BO_TILING_MODE_TILED)
+   bandwidth *= 2;
+
+   return bandwidth;
+}
+
+static unsigned long
+tegra114_plane_memory_bandwidth(struct drm_plane_state *state)
+{
+   struct tegra_dc_window window;
+   unsigned long bandwidth;
+
+   bandwidth = tegra_plane_memory_bandwidth(sta

[PATCH v5 4/8] ARM: DTS: omap34xx: add sgx gpu child node

[H. Nikolaus Schaller]

and add interrupt.

According to omap3530 TRM the SGX register block is 64kB.
See: 13.4  SGX Register Mapping, Table 13-2

Reported-by: Andrew F. Davis   # register size
Tested-by: H. Nikolaus Schaller  # OpenPandora 600 MHz.
Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap34xx.dtsi | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index c4dd9801840d..51c60ee2b68d 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -167,12 +167,13 @@ sgx_module: target-module@5000 {
clock-names = "fck", "ick";
#address-cells = <1>;
#size-cells = <1>;
-   ranges = <0 0x5000 0x4000>;
+   ranges = <0 0x5000 0x1>;
 
-   /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+   gpu: gpu@0 {
+   compatible = "ti,omap3-sgx530-121", 
"img,sgx530-121", "img,sgx530";
+   reg = <0x0 0x1>;/* 64kB */
+   interrupts = <21>;
+   };
};
};
 
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] staging: fbtft: Replace udelay with preferred usleep_range

[John B. Wyatt IV]

Fix style issue with usleep_range being reported as preferred over
udelay.

Issue reported by checkpatch.

Please review.

As written in Documentation/timers/timers-howto.rst udelay is the
generally preferred API. hrtimers, as noted in the docs, may be too
expensive for this short timer.

Are the docs out of date, or, is this a checkpatch issue?

Signed-off-by: John B. Wyatt IV 
---
 drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c 
b/drivers/staging/fbtft/fb_agm1264k-fl.c
index ec97ad27..019c8cce6bab 100644
--- a/drivers/staging/fbtft/fb_agm1264k-fl.c
+++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
@@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par)
dev_dbg(par->info->device, "%s()\n", __func__);
 
gpiod_set_value(par->gpio.reset, 0);
-   udelay(20);
+   usleep_range(20, 20);
gpiod_set_value(par->gpio.reset, 1);
mdelay(120);
 }
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 11/22] memory: tegra: Register as interconnect provider

[Dmitry Osipenko]

Now memory controller is a memory interconnection provider. This allows us
to use interconnect API in order to change memory configuration.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/mc.c | 118 ++
 drivers/memory/tegra/mc.h |   8 +++
 include/soc/tegra/mc.h|   3 +
 3 files changed, 129 insertions(+)

diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index ec8403557ed4..bcf0478c5f5a 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -591,6 +591,117 @@ static __maybe_unused irqreturn_t tegra20_mc_irq(int irq, 
void *data)
return IRQ_HANDLED;
 }
 
+static int tegra_mc_icc_set(struct icc_node *src, struct icc_node *dst)
+{
+   return 0;
+}
+
+static int tegra_mc_icc_aggregate(struct icc_node *node,
+ u32 tag, u32 avg_bw, u32 peak_bw,
+ u32 *agg_avg, u32 *agg_peak)
+{
+   *agg_avg = min((u64)avg_bw + (*agg_avg), (u64)U32_MAX);
+   *agg_peak = max(*agg_peak, peak_bw);
+
+   return 0;
+}
+
+/*
+ * Memory Controller (MC) has few Memory Clients that are issuing memory
+ * bandwidth allocation requests to the MC interconnect provider. The MC
+ * provider aggregates the requests and then sends the aggregated request
+ * up to the External Memory Controller (EMC) interconnect provider which
+ * re-configures hardware interface to External Memory (EMEM) in accordance
+ * to the required bandwidth. Each MC interconnect node represents an
+ * individual Memory Client.
+ *
+ * Memory interconnect topology:
+ *
+ *   ++
+ * ++||
+ * | TEXSRD +--->+|
+ * ++||
+ *   ||+-++--+
+ *...| MC +--->+ EMC +--->+ EMEM |
+ *   ||+-++--+
+ * ++||
+ * | DISP.. +--->+|
+ * ++||
+ *   ++
+ */
+static int tegra_mc_interconnect_setup(struct tegra_mc *mc)
+{
+   struct icc_onecell_data *data;
+   struct icc_node *node;
+   unsigned int num_nodes;
+   unsigned int i;
+   int err;
+
+   /* older device-trees don't have interconnect properties */
+   if (!of_find_property(mc->dev->of_node, "#interconnect-cells", NULL))
+   return 0;
+
+   num_nodes = mc->soc->num_clients;
+
+   data = devm_kzalloc(mc->dev, struct_size(data, nodes, num_nodes),
+   GFP_KERNEL);
+   if (!data)
+   return -ENOMEM;
+
+   mc->provider.dev = mc->dev;
+   mc->provider.set = tegra_mc_icc_set;
+   mc->provider.data = data;
+   mc->provider.xlate = of_icc_xlate_onecell;
+   mc->provider.aggregate = tegra_mc_icc_aggregate;
+
+   err = icc_provider_add(&mc->provider);
+   if (err)
+   return err;
+
+   /* create Memory Controller node */
+   node = icc_node_create(TEGRA_ICC_MC);
+   err = PTR_ERR_OR_ZERO(node);
+   if (err)
+   goto del_provider;
+
+   node->name = "Memory Controller";
+   icc_node_add(node, &mc->provider);
+
+   /* link Memory Controller to External Memory Controller */
+   err = icc_link_create(node, TEGRA_ICC_EMC);
+   if (err)
+   goto remove_nodes;
+
+   for (i = 0; i < num_nodes; i++) {
+   /* create MC client node */
+   node = icc_node_create(mc->soc->clients[i].id);
+   err = PTR_ERR_OR_ZERO(node);
+   if (err)
+   goto remove_nodes;
+
+   node->name = mc->soc->clients[i].name;
+   icc_node_add(node, &mc->provider);
+
+   /* link Memory Client to Memory Controller */
+   err = icc_link_create(node, TEGRA_ICC_MC);
+   if (err)
+   goto remove_nodes;
+
+   data->nodes[i] = node;
+   }
+   data->num_nodes = num_nodes;
+
+   return 0;
+
+remove_nodes:
+   icc_nodes_remove(&mc->provider);
+
+del_provider:
+   icc_provider_del(&mc->provider);
+
+   return err;
+}
+
 static int tegra_mc_probe(struct platform_device *pdev)
 {
struct resource *res;
@@ -699,6 +810,13 @@ static int tegra_mc_probe(struct platform_device *pdev)
}
}
 
+   if (IS_ENABLED(CONFIG_INTERCONNECT)) {
+   err = tegra_mc_interconnect_setup(mc);
+   if (err)
+   dev_err(&pdev->dev, "failed to initialize ICC: %d\n",
+   err);
+   }
+
return 0;
 }
 
diff --git a/drivers/memory/tegra/mc.h b/drivers/memory/tegra/mc.h
index 957c6eb74ff9..bb13747cd96c 100644
--- a/drivers/memory/tegra/mc.h
+++ b/drivers/memory/tegra/mc.h
@@ -114,4 +114,12 @@ extern const struct tegra_mc_soc tegra132_mc_soc;
 extern const struct tegra_mc_soc tegra210_mc_soc;
 #endif
 
+/*
+ * These IDs are for internal use of Tegra's ICC, the values are chosen
+ * such that they don't 

[PATCH v2 17/22] memory: tegra30-emc: Register as interconnect provider

[Dmitry Osipenko]

Now external memory controller is a memory interconnection provider.
This allows us to use interconnect API to change memory configuration.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/tegra30-emc.c | 115 +
 1 file changed, 115 insertions(+)

diff --git a/drivers/memory/tegra/tegra30-emc.c 
b/drivers/memory/tegra/tegra30-emc.c
index 69698665d431..5a4106173a75 100644
--- a/drivers/memory/tegra/tegra30-emc.c
+++ b/drivers/memory/tegra/tegra30-emc.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -327,6 +328,7 @@ struct tegra_emc {
struct device *dev;
struct tegra_mc *mc;
struct notifier_block clk_nb;
+   struct icc_provider provider;
struct clk *clk;
void __iomem *regs;
unsigned int irq;
@@ -1264,6 +1266,112 @@ static void tegra_emc_debugfs_init(struct tegra_emc 
*emc)
emc, &tegra_emc_debug_max_rate_fops);
 }
 
+static inline struct tegra_emc *
+to_tegra_emc_provider(struct icc_provider *provider)
+{
+   return container_of(provider, struct tegra_emc, provider);
+}
+
+static struct icc_node *
+emc_of_icc_xlate_onecell(struct of_phandle_args *spec, void *data)
+{
+   struct icc_provider *provider = data;
+   struct icc_node *node;
+
+   /* External Memory is the only possible ICC route */
+   list_for_each_entry(node, &provider->nodes, node_list) {
+   if (node->id == TEGRA_ICC_EMEM)
+   return node;
+   }
+
+   return ERR_PTR(-EINVAL);
+}
+
+static int emc_icc_set(struct icc_node *src, struct icc_node *dst)
+{
+   struct tegra_emc *emc = to_tegra_emc_provider(dst->provider);
+   unsigned long long rate = icc_units_to_bps(dst->avg_bw);
+   unsigned int dram_data_bus_width_bytes = 4;
+   unsigned int ddr = 2;
+   int err;
+
+   do_div(rate, ddr * dram_data_bus_width_bytes);
+   rate = min_t(u64, rate, U32_MAX);
+
+   err = clk_set_min_rate(emc->clk, rate);
+   if (err)
+   return err;
+
+   err = clk_set_rate(emc->clk, rate);
+   if (err)
+   return err;
+
+   return 0;
+}
+
+static int emc_icc_aggregate(struct icc_node *node,
+u32 tag, u32 avg_bw, u32 peak_bw,
+u32 *agg_avg, u32 *agg_peak)
+{
+   *agg_avg = min((u64)avg_bw + (*agg_avg), (u64)U32_MAX);
+   *agg_peak = max(*agg_peak, peak_bw);
+
+   return 0;
+}
+
+static int tegra_emc_interconnect_init(struct tegra_emc *emc)
+{
+   struct icc_node *node;
+   int err;
+
+   /* older device-trees don't have interconnect properties */
+   if (!of_find_property(emc->dev->of_node, "#interconnect-cells", NULL))
+   return 0;
+
+   emc->provider.dev = emc->dev;
+   emc->provider.set = emc_icc_set;
+   emc->provider.data = &emc->provider;
+   emc->provider.xlate = emc_of_icc_xlate_onecell;
+   emc->provider.aggregate = emc_icc_aggregate;
+
+   err = icc_provider_add(&emc->provider);
+   if (err)
+   return err;
+
+   /* create External Memory Controller node */
+   node = icc_node_create(TEGRA_ICC_EMC);
+   err = PTR_ERR_OR_ZERO(node);
+   if (err)
+   goto del_provider;
+
+   node->name = "External Memory Controller";
+   icc_node_add(node, &emc->provider);
+
+   /* link External Memory Controller to External Memory (DRAM) */
+   err = icc_link_create(node, TEGRA_ICC_EMEM);
+   if (err)
+   goto remove_nodes;
+
+   /* create External Memory node */
+   node = icc_node_create(TEGRA_ICC_EMEM);
+   err = PTR_ERR_OR_ZERO(node);
+   if (err)
+   goto remove_nodes;
+
+   node->name = "External Memory (DRAM)";
+   icc_node_add(node, &emc->provider);
+
+   return 0;
+
+remove_nodes:
+   icc_nodes_remove(&emc->provider);
+
+del_provider:
+   icc_provider_del(&emc->provider);
+
+   return err;
+}
+
 static int tegra_emc_probe(struct platform_device *pdev)
 {
struct platform_device *mc;
@@ -1344,6 +1452,13 @@ static int tegra_emc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, emc);
tegra_emc_debugfs_init(emc);
 
+   if (IS_ENABLED(CONFIG_INTERCONNECT)) {
+   err = tegra_emc_interconnect_init(emc);
+   if (err)
+   dev_err(&pdev->dev, "failed to initialize ICC: %d\n",
+   err);
+   }
+
return 0;
 
 unset_cb:
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 05/22] dt-bindings: host1x: Document new interconnect properties

[Dmitry Osipenko]

Most of Host1x devices have at least one memory client. These clients
are directly connected to the memory controller. The new interconnect
properties represent the memory client's connection to the memory
controller.

Signed-off-by: Dmitry Osipenko 
---
 .../display/tegra/nvidia,tegra20-host1x.txt   | 68 +++
 1 file changed, 68 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt 
b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
index 255ac5b6..d92d4e814d77 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
@@ -20,6 +20,10 @@ Required properties:
 - reset-names: Must include the following entries:
   - host1x
 
+Each host1x client module having to perform DMA through the Memory Controller
+should have the interconnect endpoints set to the Memory Client and External
+Memory respectively.
+
 The host1x top-level node defines a number of children, each representing one
 of the following host1x client modules:
 
@@ -36,6 +40,12 @@ of the following host1x client modules:
   - reset-names: Must include the following entries:
 - mpe
 
+  Optional properties:
+  - interconnects: Must contain entry for the MPE memory clients.
+  - interconnect-names: Must include name of the interconnect path for each
+interconnect entry. Consult TRM documentation for information about
+available memory clients.
+
 - vi: video input
 
   Required properties:
@@ -49,6 +59,12 @@ of the following host1x client modules:
   - reset-names: Must include the following entries:
 - vi
 
+  Optional properties:
+  - interconnects: Must contain entry for the VI memory clients.
+  - interconnect-names: Must include name of the interconnect path for each
+interconnect entry. Consult TRM documentation for information about
+available memory clients.
+
 - epp: encoder pre-processor
 
   Required properties:
@@ -62,6 +78,12 @@ of the following host1x client modules:
   - reset-names: Must include the following entries:
 - epp
 
+  Optional properties:
+  - interconnects: Must contain entry for the EPP memory clients.
+  - interconnect-names: Must include name of the interconnect path for each
+interconnect entry. Consult TRM documentation for information about
+available memory clients.
+
 - isp: image signal processor
 
   Required properties:
@@ -75,6 +97,12 @@ of the following host1x client modules:
   - reset-names: Must include the following entries:
 - isp
 
+  Optional properties:
+  - interconnects: Must contain entry for the ISP memory clients.
+  - interconnect-names: Must include name of the interconnect path for each
+interconnect entry. Consult TRM documentation for information about
+available memory clients.
+
 - gr2d: 2D graphics engine
 
   Required properties:
@@ -88,6 +116,12 @@ of the following host1x client modules:
   - reset-names: Must include the following entries:
 - 2d
 
+  Optional properties:
+  - interconnects: Must contain entry for the GR2D memory clients.
+  - interconnect-names: Must include name of the interconnect path for each
+interconnect entry. Consult TRM documentation for information about
+available memory clients.
+
 - gr3d: 3D graphics engine
 
   Required properties:
@@ -106,6 +140,12 @@ of the following host1x client modules:
 - 3d
 - 3d2 (Only required on SoCs with two 3D clocks)
 
+  Optional properties:
+  - interconnects: Must contain entry for the GR3D memory clients.
+  - interconnect-names: Must include name of the interconnect path for each
+interconnect entry. Consult TRM documentation for information about
+available memory clients.
+
 - dc: display controller
 
   Required properties:
@@ -133,6 +173,10 @@ of the following host1x client modules:
   - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
   - nvidia,edid: supplies a binary EDID blob
   - nvidia,panel: phandle of a display panel
+  - interconnects: Must contain entry for the DC memory clients.
+  - interconnect-names: Must include name of the interconnect path for each
+interconnect entry. Consult TRM documentation for information about
+available memory clients.
 
 - hdmi: High Definition Multimedia Interface
 
@@ -281,6 +325,12 @@ of the following host1x client modules:
   - reset-names: Must include the following entries:
 - vic
 
+  Optional properties:
+  - interconnects: Must contain entry for the VIC memory clients.
+  - interconnect-names: Must include name of the interconnect path for each
+interconnect entry. Consult TRM documentation for information about
+available memory clients.
+
 Example:
 
 / {
@@ -363,6 +413,15 @@ Example:
resets = <&tegra_car 27>;
reset-names = "dc";
 
+   interconnects = <&mc TEGRA20_MC_DISPLAY0A &emc>,
+ 

[PATCH v2 08/22] ARM: tegra: Add interconnect properties to Tegra20 device-tree

[Dmitry Osipenko]

Add interconnect properties to the memory controller, external memory
controller and the display controller nodes in order to describe hardware
interconnection.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20.dtsi | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index c3b8ad53b967..974048e83541 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -109,6 +109,15 @@ dc@5420 {
 
nvidia,head = <0>;
 
+   interconnects = <&mc TEGRA20_MC_DISPLAY0A &emc>,
+   <&mc TEGRA20_MC_DISPLAY0B &emc>,
+   <&mc TEGRA20_MC_DISPLAY0C &emc>,
+   <&mc TEGRA20_MC_DISPLAY1B &emc>;
+   interconnect-names = "display0a",
+"display0b",
+"display0c",
+"display1b";
+
rgb {
status = "disabled";
};
@@ -126,6 +135,15 @@ dc@5424 {
 
nvidia,head = <1>;
 
+   interconnects = <&mc TEGRA20_MC_DISPLAY0AB &emc>,
+   <&mc TEGRA20_MC_DISPLAY0BB &emc>,
+   <&mc TEGRA20_MC_DISPLAY0CB &emc>,
+   <&mc TEGRA20_MC_DISPLAY1BB &emc>;
+   interconnect-names = "display0a",
+"display0b",
+"display0c",
+"display1b";
+
rgb {
status = "disabled";
};
@@ -626,15 +644,17 @@ mc: memory-controller@7000f000 {
interrupts = ;
#reset-cells = <1>;
#iommu-cells = <0>;
+   #interconnect-cells = <1>;
};
 
-   memory-controller@7000f400 {
+   emc: memory-controller@7000f400 {
compatible = "nvidia,tegra20-emc";
reg = <0x7000f400 0x200>;
interrupts = ;
clocks = <&tegra_car TEGRA20_CLK_EMC>;
#address-cells = <1>;
#size-cells = <0>;
+   #interconnect-cells = <0>;
};
 
fuse@7000f800 {
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 07/22] dt-bindings: memory: tegra30: Add memory client IDs

[Dmitry Osipenko]

Each memory client have a unique hardware ID, this patch adds these IDs.

Signed-off-by: Dmitry Osipenko 
---
 include/dt-bindings/memory/tegra30-mc.h | 67 +
 1 file changed, 67 insertions(+)

diff --git a/include/dt-bindings/memory/tegra30-mc.h 
b/include/dt-bindings/memory/tegra30-mc.h
index 169f005fbc78..930f708aca17 100644
--- a/include/dt-bindings/memory/tegra30-mc.h
+++ b/include/dt-bindings/memory/tegra30-mc.h
@@ -41,4 +41,71 @@
 #define TEGRA30_MC_RESET_VDE   16
 #define TEGRA30_MC_RESET_VI17
 
+#define TEGRA30_MC_PTCR0
+#define TEGRA30_MC_DISPLAY0A   1
+#define TEGRA30_MC_DISPLAY0AB  2
+#define TEGRA30_MC_DISPLAY0B   3
+#define TEGRA30_MC_DISPLAY0BB  4
+#define TEGRA30_MC_DISPLAY0C   5
+#define TEGRA30_MC_DISPLAY0CB  6
+#define TEGRA30_MC_DISPLAY1B   7
+#define TEGRA30_MC_DISPLAY1BB  8
+#define TEGRA30_MC_EPPUP   9
+#define TEGRA30_MC_G2PR10
+#define TEGRA30_MC_G2SR11
+#define TEGRA30_MC_MPEUNIFBR   12
+#define TEGRA30_MC_VIRUV   13
+#define TEGRA30_MC_AFIR14
+#define TEGRA30_MC_AVPCARM7R   15
+#define TEGRA30_MC_DISPLAYHC   16
+#define TEGRA30_MC_DISPLAYHCB  17
+#define TEGRA30_MC_FDCDRD  18
+#define TEGRA30_MC_FDCDRD2 19
+#define TEGRA30_MC_G2DR20
+#define TEGRA30_MC_HDAR21
+#define TEGRA30_MC_HOST1XDMAR  22
+#define TEGRA30_MC_HOST1XR 23
+#define TEGRA30_MC_IDXSRD  24
+#define TEGRA30_MC_IDXSRD2 25
+#define TEGRA30_MC_MPE_IPRED   26
+#define TEGRA30_MC_MPEAMEMRD   27
+#define TEGRA30_MC_MPECSRD 28
+#define TEGRA30_MC_PPCSAHBDMAR 29
+#define TEGRA30_MC_PPCSAHBSLVR 30
+#define TEGRA30_MC_SATAR   31
+#define TEGRA30_MC_TEXSRD  32
+#define TEGRA30_MC_TEXSRD2 33
+#define TEGRA30_MC_VDEBSEVR34
+#define TEGRA30_MC_VDEMBER 35
+#define TEGRA30_MC_VDEMCER 36
+#define TEGRA30_MC_VDETPER 37
+#define TEGRA30_MC_MPCORELPR   38
+#define TEGRA30_MC_MPCORER 39
+#define TEGRA30_MC_EPPU40
+#define TEGRA30_MC_EPPV41
+#define TEGRA30_MC_EPPY42
+#define TEGRA30_MC_MPEUNIFBW   43
+#define TEGRA30_MC_VIWSB   44
+#define TEGRA30_MC_VIWU45
+#define TEGRA30_MC_VIWV46
+#define TEGRA30_MC_VIWY47
+#define TEGRA30_MC_G2DW48
+#define TEGRA30_MC_AFIW49
+#define TEGRA30_MC_AVPCARM7W   50
+#define TEGRA30_MC_FDCDWR  51
+#define TEGRA30_MC_FDCDWR2 52
+#define TEGRA30_MC_HDAW53
+#define TEGRA30_MC_HOST1XW 54
+#define TEGRA30_MC_ISPW55
+#define TEGRA30_MC_MPCORELPW   56
+#define TEGRA30_MC_MPCOREW 57
+#define TEGRA30_MC_MPECSWR 58
+#define TEGRA30_MC_PPCSAHBDMAW 59
+#define TEGRA30_MC_PPCSAHBSLVW 60
+#define TEGRA30_MC_SATAW   61
+#define TEGRA30_MC_VDEBSEVW62
+#define TEGRA30_MC_VDEDBGW 63
+#define TEGRA30_MC_VDEMBEW 64
+#define TEGRA30_MC_VDETPMW 65
+
 #endif
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 8/8] MIPS: DTS: jz4780: add sgx gpu node

[H. Nikolaus Schaller]

and add interrupt and clocks.

Tested to build for CI20 board and load a driver.
Setup can not yet be tested since there is no working
HDMI driver for jz4780.

Suggested-by: Paul Boddie 
Tested-by: H. Nikolaus Schaller  # CI20.
Signed-off-by: H. Nikolaus Schaller 
---
 arch/mips/boot/dts/ingenic/jz4780.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi 
b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index bb89653d16a3..618e48c78a87 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -357,6 +357,17 @@ i2c4: i2c@10054000 {
status = "disabled";
};
 
+   gpu: gpu@1304 {
+   compatible = "ingenic,jz4780-sgx540-120", "img,sgx540-120", 
"img,sgx540";
+   reg = <0x1304 0x4000>;
+
+   clocks = <&cgu JZ4780_CLK_GPU>;
+   clock-names = "gpu";
+
+   interrupt-parent = <&intc>;
+   interrupts = <63>;
+   };
+
nemc: nemc@1341 {
compatible = "ingenic,jz4780-nemc";
reg = <0x1341 0x1>;
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 19/22] drm/tegra: dc: Tune up high priority request controls for Tegra20

[Dmitry Osipenko]

Tegra20 has a high-priority-request control that allows to configure
when display's memory client should perform read requests with a higher
priority (Tegra30+ uses other means like Latency Allowance).

This patch changes the controls configuration in order to get a more
aggressive memory prefetching, which allows to reliably avoid FIFO
underflow when running on a lower memory frequency. This allow us
safely drop the memory bandwidth requirement by about two times in a
most popular use-cases (only one display active, video overlay inactive,
no scaling is done).

Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/tegra/dc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index b540ac6ffdc4..564af302a965 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1980,12 +1980,12 @@ static void tegra_crtc_atomic_enable(struct drm_crtc 
*crtc,
tegra_dc_writel(dc, value, DC_CMD_INT_POLARITY);
 
/* initialize timer */
-   value = CURSOR_THRESHOLD(0) | WINDOW_A_THRESHOLD(0x20) |
-   WINDOW_B_THRESHOLD(0x20) | WINDOW_C_THRESHOLD(0x20);
+   value = CURSOR_THRESHOLD(0) | WINDOW_A_THRESHOLD(0x70) |
+   WINDOW_B_THRESHOLD(0x30) | WINDOW_C_THRESHOLD(0x70);
tegra_dc_writel(dc, value, DC_DISP_DISP_MEM_HIGH_PRIORITY);
 
-   value = CURSOR_THRESHOLD(0) | WINDOW_A_THRESHOLD(1) |
-   WINDOW_B_THRESHOLD(1) | WINDOW_C_THRESHOLD(1);
+   value = CURSOR_THRESHOLD(0) | WINDOW_A_THRESHOLD(0) |
+   WINDOW_B_THRESHOLD(0) | WINDOW_C_THRESHOLD(0);
tegra_dc_writel(dc, value, 
DC_DISP_DISP_MEM_HIGH_PRIORITY_TIMER);
 
value = VBLANK_INT | WIN_A_UF_INT | WIN_B_UF_INT | WIN_C_UF_INT 
|
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 hmm 5/9] mm/hmm: remove the CONFIG_TRANSPARENT_HUGEPAGE #ifdef

[Jason Gunthorpe]

From: Jason Gunthorpe 

This code can be compiled when CONFIG_TRANSPARENT_HUGEPAGE is off, so
remove the ifdef.

The function is only ever called under

   if (pmd_devmap(pmd) || pmd_trans_huge(pmd))

Which is statically false if !CONFIG_TRANSPARENT_HUGEPAGE, so the compiler
reliably eliminates all of this code.

Reviewed-by: Ralph Campbell 
Reviewed-by: Christoph Hellwig 
Tested-by: Ralph Campbell 
Signed-off-by: Jason Gunthorpe 
---
 mm/hmm.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/mm/hmm.c b/mm/hmm.c
index 8dbd9e1d0308b4..3a71ec72b0a42f 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -193,7 +193,6 @@ static inline uint64_t pmd_to_hmm_pfn_flags(struct 
hmm_range *range, pmd_t pmd)
range->flags[HMM_PFN_VALID];
 }
 
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 static int hmm_vma_handle_pmd(struct mm_walk *walk, unsigned long addr,
unsigned long end, uint64_t *pfns, pmd_t pmd)
 {
@@ -216,11 +215,6 @@ static int hmm_vma_handle_pmd(struct mm_walk *walk, 
unsigned long addr,
hmm_vma_walk->last = end;
return 0;
 }
-#else /* CONFIG_TRANSPARENT_HUGEPAGE */
-/* stub to allow the code below to compile */
-int hmm_vma_handle_pmd(struct mm_walk *walk, unsigned long addr,
-   unsigned long end, uint64_t *pfns, pmd_t pmd);
-#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 
 static inline bool hmm_is_device_private_entry(struct hmm_range *range,
swp_entry_t entry)
-- 
2.25.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 09/22] ARM: tegra: Add interconnect properties to Tegra30 device-tree

[Dmitry Osipenko]

Add interconnect properties to the memory controller, external memory
controller and the display controller nodes in order to describe hardware
interconnection.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra30.dtsi | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index d2d05f1da274..2b183025629f 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -208,6 +208,15 @@ dc@5420 {
 
nvidia,head = <0>;
 
+   interconnects = <&mc TEGRA30_MC_DISPLAY0A &emc>,
+   <&mc TEGRA30_MC_DISPLAY0B &emc>,
+   <&mc TEGRA30_MC_DISPLAY0C &emc>,
+   <&mc TEGRA30_MC_DISPLAY1B &emc>;
+   interconnect-names = "display0a",
+"display0b",
+"display0c",
+"display1b";
+
rgb {
status = "disabled";
};
@@ -227,6 +236,15 @@ dc@5424 {
 
nvidia,head = <1>;
 
+   interconnects = <&mc TEGRA30_MC_DISPLAY0AB &emc>,
+   <&mc TEGRA30_MC_DISPLAY0BB &emc>,
+   <&mc TEGRA30_MC_DISPLAY0CB &emc>,
+   <&mc TEGRA30_MC_DISPLAY1BB &emc>;
+   interconnect-names = "display0a",
+"display0b",
+"display0c",
+"display1b";
+
rgb {
status = "disabled";
};
@@ -733,15 +751,18 @@ mc: memory-controller@7000f000 {
 
#iommu-cells = <1>;
#reset-cells = <1>;
+   #interconnect-cells = <1>;
};
 
-   memory-controller@7000f400 {
+   emc: memory-controller@7000f400 {
compatible = "nvidia,tegra30-emc";
reg = <0x7000f400 0x400>;
interrupts = ;
clocks = <&tegra_car TEGRA30_CLK_EMC>;
 
nvidia,memory-controller = <&mc>;
+
+   #interconnect-cells = <0>;
};
 
fuse@7000f800 {
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH] staging: fbtft: Replace udelay with preferred usleep_range

[Julia Lawall]

On Sun, 29 Mar 2020, Soumyajit Deb wrote:

> I had the same doubt the other day about the replacement of udelay() with
> usleep_range(). The corresponding range for the single argument value of
> udelay() is quite confusing as I couldn't decide the range. But as much as I
> noticed checkpatch.pl gives warning for replacing udelay() with
> usleep_range() by checking the argument value of udelay(). In the
> documentation, it is written udelay() should be used for a sleep time of at
> most 10 microseconds but between 10 microseconds and 20 milliseconds,
> usleep_range() should be used. 
> I think the range is code specific and will depend on what range is
> acceptable and doesn't break the code.
>  Please correct me if I am wrong.

The range depends on the associated hardware.  Just because checkpatch
suggests something doesn't mean that it is easy to address the problem.

julia

>
> More clarification on this issue will be helpful.
>
> On Sun, 29 Mar 2020, 15:17 Julia Lawall,  wrote:
>
>
>   On Sun, 29 Mar 2020, John Wyatt wrote:
>
>   > On Sun, 2020-03-29 at 11:28 +0200, Julia Lawall wrote:
>   > >
>   > > On Sun, 29 Mar 2020, John B. Wyatt IV wrote:
>   > >
>   > > > Fix style issue with usleep_range being reported as
>   preferred over
>   > > > udelay.
>   > > >
>   > > > Issue reported by checkpatch.
>   > > >
>   > > > Please review.
>   > > >
>   > > > As written in Documentation/timers/timers-howto.rst udelay
>   is the
>   > > > generally preferred API. hrtimers, as noted in the docs,
>   may be too
>   > > > expensive for this short timer.
>   > > >
>   > > > Are the docs out of date, or, is this a checkpatch issue?
>   > > >
>   > > > Signed-off-by: John B. Wyatt IV 
>   > > > ---
>   > > >  drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +-
>   > > >  1 file changed, 1 insertion(+), 1 deletion(-)
>   > > >
>   > > > diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c
>   > > > b/drivers/staging/fbtft/fb_agm1264k-fl.c
>   > > > index ec97ad27..019c8cce6bab 100644
>   > > > --- a/drivers/staging/fbtft/fb_agm1264k-fl.c
>   > > > +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
>   > > > @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par)
>   > > >   dev_dbg(par->info->device, "%s()\n", __func__);
>   > > >
>   > > >   gpiod_set_value(par->gpio.reset, 0);
>   > > > - udelay(20);
>   > > > + usleep_range(20, 20);
>   > >
>   > > usleep_range should have a range, eg usleep_range(50,
>   100);.  But it
>   > > is
>   > > hard to know a priori what the range should be.  So it is
>   probably
>   > > better
>   > > to leave the code alone.
>   >
>   > Understood.
>   >
>   > With the question I wrote in the commit message:
>   >
>   > "As written in Documentation/timers/timers-howto.rst udelay is
>   the
>   > generally preferred API. hrtimers, as noted in the docs, may
>   be too
>   > expensive for this short timer.
>   >
>   > Are the docs out of date, or, is this a checkpatch issue?"
>   >
>   > Is usleep_range too expensive for this operation?
>   >
>   > Why does checkpatch favor usleep_range while the docs favor
>   udelay?
>
>   I don't know the answer in detail, but it is quite possible that
>   checkpatch doesn't pay any attention to the delay argument. 
>   Checkpatch is
>   a perl script that highlights things that may be of concern.  It
>   is not a
>   precise static analsis tool.
>
>   As a matter of form, all of your Please review comments should
>   have been
>   put below the ---.  Currently, if someone had wanted to apply
>   the patch,
>   you would make them do extra work to remove this information.
>
>   julia
>
>   >
>   > >
>   > > julia
>   > >
>   > > >   gpiod_set_value(par->gpio.reset, 1);
>   > > >   mdelay(120);
>   > > >  }
>   > > > --
>   > > > 2.25.1
>   > > >
>   > > > --
>   > > > You received this message because you are subscribed to
>   the Google
>   > > > Groups "outreachy-kernel" group.
>   > > > To unsubscribe from this group and stop receiving emails
>   from it,
>   > > > send an email to
>   outreachy-kernel+unsubscr...@googlegroups.com.
>   > > > To view this discussion on the web visit
>   > > 
> >https://groups.google.com/d/msgid/outreachy-kernel/20200329092204.770405-1-
>   jbwyatt4%40gmail.com
>   > > > .
>   > > >
>   >
>   >
>
>   --
>   You received this message because you are subscribed to the
>   Google Groups "outreachy-kernel" group.
>   To unsubscribe from this group and stop receiving emails from
>   it, send an email to
>   outreachy-kernel+unsubscr...@googlegroups.com.
>   To view this discussion on the web 
> visithttps://

[PATCH v2 22/22] ARM: multi_v7_defconfig: Enable interconnect API

[Dmitry Osipenko]

NVIDIA Tegra now has interconnect providers that are used for memory
bandwidth allocation.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index f8e45351c3f9..658b5c1892eb 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -1085,6 +1085,7 @@ CONFIG_FSI_MASTER_ASPEED=m
 CONFIG_FSI_SCOM=m
 CONFIG_FSI_SBEFIFO=m
 CONFIG_FSI_OCC=m
+CONFIG_INTERCONNECT=y
 CONFIG_EXT4_FS=y
 CONFIG_AUTOFS4_FS=y
 CONFIG_MSDOS_FS=y
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v3 5/8] drm: ingenic: add jz4780 Synopsys HDMI driver

[H. Nikolaus Schaller]

From: Paul Boddie 

A specialisation of the generic Synopsys HDMI driver is employed for JZ4780
HDMI support. This requires a new driver, plus device tree and configuration
modifications.

Signed-off-by: Paul Boddie 
Signed-off-by: H. Nikolaus Schaller 
---
 drivers/gpu/drm/ingenic/Kconfig  |   8 ++
 drivers/gpu/drm/ingenic/Makefile |   1 +
 drivers/gpu/drm/ingenic/dw_hdmi-jz4780.c | 120 +++
 3 files changed, 129 insertions(+)
 create mode 100644 drivers/gpu/drm/ingenic/dw_hdmi-jz4780.c

diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
index d82c3d37ec9c..44bfd0d35af1 100644
--- a/drivers/gpu/drm/ingenic/Kconfig
+++ b/drivers/gpu/drm/ingenic/Kconfig
@@ -14,3 +14,11 @@ config DRM_INGENIC
  Choose this option for DRM support for the Ingenic SoCs.
 
  If M is selected the module will be called ingenic-drm.
+
+config DRM_DW_HDMI_JZ4780
+   tristate "HDMI Support for Ingenic JZ4780"
+   depends on DRM_INGENIC
+   depends on OF
+   select DRM_DW_HDMI
+   help
+ Choose this option for HDMI output from the Ingenic JZ4780.
diff --git a/drivers/gpu/drm/ingenic/Makefile b/drivers/gpu/drm/ingenic/Makefile
index 11cac42ce0bb..238383de63c7 100644
--- a/drivers/gpu/drm/ingenic/Makefile
+++ b/drivers/gpu/drm/ingenic/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o
+obj-$(CONFIG_DRM_DW_HDMI_JZ4780) += dw_hdmi-jz4780.o
diff --git a/drivers/gpu/drm/ingenic/dw_hdmi-jz4780.c 
b/drivers/gpu/drm/ingenic/dw_hdmi-jz4780.c
new file mode 100644
index ..fa379e337263
--- /dev/null
+++ b/drivers/gpu/drm/ingenic/dw_hdmi-jz4780.c
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2019 Paul Boddie 
+ *
+ * Derived from dw_hdmi-imx.c with i.MX portions removed.
+ * Probe and remove operations derived from rcar_dw_hdmi.c.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static const struct dw_hdmi_mpll_config jz4780_mpll_cfg[] = {
+   { 4525,  { { 0x01e0, 0x },
+  { 0x21e1, 0x },
+  { 0x41e2, 0x } } },
+   { 9250,  { { 0x0140, 0x0005 },
+  { 0x2141, 0x0005 },
+  { 0x4142, 0x0005 } } },
+   { 14850, { { 0x00a0, 0x000a },
+  { 0x20a1, 0x000a },
+  { 0x40a2, 0x000a } } },
+   { 21600, { { 0x00a0, 0x000a },
+  { 0x2001, 0x000f },
+  { 0x4002, 0x000f } } },
+   { ~0UL,  { { 0x, 0x },
+  { 0x, 0x },
+  { 0x, 0x } } }
+};
+
+static const struct dw_hdmi_curr_ctrl jz4780_cur_ctr[] = {
+   /*pixelclk bpp8bpp10   bpp12 */
+   { 5400,  { 0x091c, 0x091c, 0x06dc } },
+   { 5840,  { 0x091c, 0x06dc, 0x06dc } },
+   { 7200,  { 0x06dc, 0x06dc, 0x091c } },
+   { 7425,  { 0x06dc, 0x0b5c, 0x091c } },
+   { 11880, { 0x091c, 0x091c, 0x06dc } },
+   { 21600, { 0x06dc, 0x0b5c, 0x091c } },
+   { ~0UL,  { 0x, 0x, 0x } },
+};
+
+/*
+ * Resistance term 133Ohm Cfg
+ * PREEMP config 0.00
+ * TX/CK level 10
+ */
+static const struct dw_hdmi_phy_config jz4780_phy_config[] = {
+   /*pixelclk   symbol   term   vlev */
+   { 21600, 0x800d, 0x0005, 0x01ad},
+   { ~0UL,  0x, 0x, 0x}
+};
+
+static enum drm_mode_status
+jz4780_hdmi_mode_valid(struct drm_connector *con,
+  const struct drm_display_mode *mode)
+{
+   if (mode->clock < 13500)
+   return MODE_CLOCK_LOW;
+   /* FIXME: Hardware is capable of 270MHz, but setup data is missing. */
+   if (mode->clock > 216000)
+   return MODE_CLOCK_HIGH;
+
+   return MODE_OK;
+}
+
+static struct dw_hdmi_plat_data jz4780_dw_hdmi_plat_data = {
+   .mpll_cfg   = jz4780_mpll_cfg,
+   .cur_ctr= jz4780_cur_ctr,
+   .phy_config = jz4780_phy_config,
+   .mode_valid = jz4780_hdmi_mode_valid,
+};
+
+static const struct of_device_id jz4780_dw_hdmi_dt_ids[] = {
+   { .compatible = "ingenic,jz4780-dw-hdmi" },
+   { /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, jz4780_dw_hdmi_dt_ids);
+
+static int jz4780_dw_hdmi_probe(struct platform_device *pdev)
+{
+   struct dw_hdmi *hdmi;
+
+   hdmi = dw_hdmi_probe(pdev, &jz4780_dw_hdmi_plat_data);
+   if (IS_ERR(hdmi))
+   return PTR_ERR(hdmi);
+
+   platform_set_drvdata(pdev, hdmi);
+
+   return 0;
+}
+
+static int jz4780_dw_hdmi_remove(struct platform_device *pdev)
+{
+   struct dw_hdmi *hdmi = platform_get_drvdata(pdev);
+
+   dw_hdmi_remove(hdmi);
+
+   return 0;
+}
+
+static struct platform_driver jz4780_dw_hdmi_platform_driver = {
+   .probe  = jz4780_dw_hdmi_probe,
+   .remove = jz4780_dw_hdmi_remove,
+   .driver = {
+   .name = "dw-hdmi

[PATCH v2 13/22] memory: tegra20-emc: Continue probing if timings are missing in device-tree

[Dmitry Osipenko]

EMC driver will become mandatory after turning it into interconnect
provider because interconnect users, like display controller driver, will
fail to probe using newer device-trees that have interconnect properties.
Thus make EMC driver to probe even if timings are missing in device-tree.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/tegra20-emc.c | 37 +++---
 1 file changed, 18 insertions(+), 19 deletions(-)

diff --git a/drivers/memory/tegra/tegra20-emc.c 
b/drivers/memory/tegra/tegra20-emc.c
index ef3abc18a3f4..3a6eb5cc5c29 100644
--- a/drivers/memory/tegra/tegra20-emc.c
+++ b/drivers/memory/tegra/tegra20-emc.c
@@ -383,6 +383,11 @@ tegra_emc_find_node_by_ram_code(struct device *dev)
u32 value, ram_code;
int err;
 
+   if (of_get_child_count(dev->of_node) == 0) {
+   dev_info(dev, "device-tree doesn't have memory timings\n");
+   return NULL;
+   }
+
if (!of_property_read_bool(dev->of_node, "nvidia,use-ram-code"))
return of_node_get(dev->of_node);
 
@@ -451,6 +456,9 @@ static long emc_round_rate(unsigned long rate,
struct tegra_emc *emc = arg;
unsigned int i;
 
+   if (!emc->num_timings)
+   return clk_get_rate(emc->clk);
+
min_rate = min(min_rate, emc->timings[emc->num_timings - 1].rate);
 
for (i = 0; i < emc->num_timings; i++) {
@@ -656,13 +664,6 @@ static int tegra_emc_probe(struct platform_device *pdev)
struct tegra_emc *emc;
int irq, err;
 
-   /* driver has nothing to do in a case of memory timing absence */
-   if (of_get_child_count(pdev->dev.of_node) == 0) {
-   dev_info(&pdev->dev,
-"EMC device tree node doesn't have memory timings\n");
-   return 0;
-   }
-
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(&pdev->dev, "interrupt not specified\n");
@@ -670,23 +671,20 @@ static int tegra_emc_probe(struct platform_device *pdev)
return irq;
}
 
-   np = tegra_emc_find_node_by_ram_code(&pdev->dev);
-   if (!np)
-   return -EINVAL;
-
emc = devm_kzalloc(&pdev->dev, sizeof(*emc), GFP_KERNEL);
-   if (!emc) {
-   of_node_put(np);
+   if (!emc)
return -ENOMEM;
-   }
 
emc->clk_nb.notifier_call = tegra_emc_clk_change_notify;
emc->dev = &pdev->dev;
 
-   err = tegra_emc_load_timings_from_dt(emc, np);
-   of_node_put(np);
-   if (err)
-   return err;
+   np = tegra_emc_find_node_by_ram_code(&pdev->dev);
+   if (np) {
+   err = tegra_emc_load_timings_from_dt(emc, np);
+   of_node_put(np);
+   if (err)
+   return err;
+   }
 
emc->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(emc->regs))
@@ -699,7 +697,8 @@ static int tegra_emc_probe(struct platform_device *pdev)
err = devm_request_irq(&pdev->dev, irq, tegra_emc_isr, 0,
   dev_name(&pdev->dev), emc);
if (err) {
-   dev_err(&pdev->dev, "failed to request IRQ#%u: %d\n", irq, err);
+   dev_err(&pdev->dev, "failed to request IRQ#%u: %d\n",
+   irq, err);
return err;
}
 
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] Update my email address in various drivers

[Russell King]

Globally update my email address in six files scattered through the
tree.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_drv.c | 2 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 2 +-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c   | 2 +-
 drivers/media/cec/cec-notifier.c| 2 +-
 drivers/net/phy/swphy.c | 2 +-
 include/media/cec-notifier.h| 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index 3df2dacf4c94..5a82a12cd105 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -389,7 +389,7 @@ static void __exit armada_drm_exit(void)
 }
 module_exit(armada_drm_exit);
 
-MODULE_AUTHOR("Russell King ");
+MODULE_AUTHOR("Russell King ");
 MODULE_DESCRIPTION("Armada DRM Driver");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:armada-drm");
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
index e8e3e9339ff9..f6f55776e43e 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
@@ -698,7 +698,7 @@ static struct platform_driver snd_dw_hdmi_driver = {
 
 module_platform_driver(snd_dw_hdmi_driver);
 
-MODULE_AUTHOR("Russell King ");
+MODULE_AUTHOR("Russell King ");
 MODULE_DESCRIPTION("Synopsis Designware HDMI AHB ALSA interface");
 MODULE_LICENSE("GPL v2");
 MODULE_ALIAS("platform:" DRIVER_NAME);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 1f9c01be40d7..d6798f716b77 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -739,7 +739,7 @@ static void __exit etnaviv_exit(void)
 module_exit(etnaviv_exit);
 
 MODULE_AUTHOR("Christian Gmeiner ");
-MODULE_AUTHOR("Russell King ");
+MODULE_AUTHOR("Russell King ");
 MODULE_AUTHOR("Lucas Stach ");
 MODULE_DESCRIPTION("etnaviv DRM Driver");
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/media/cec/cec-notifier.c b/drivers/media/cec/cec-notifier.c
index 7cf42b133dbc..2d4f7dd7cef7 100644
--- a/drivers/media/cec/cec-notifier.c
+++ b/drivers/media/cec/cec-notifier.c
@@ -2,7 +2,7 @@
 /*
  * cec-notifier.c - notify CEC drivers of physical address changes
  *
- * Copyright 2016 Russell King 
+ * Copyright 2016 Russell King.
  * Copyright 2016-2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
  */
 
diff --git a/drivers/net/phy/swphy.c b/drivers/net/phy/swphy.c
index 53c214a22b95..774814714c82 100644
--- a/drivers/net/phy/swphy.c
+++ b/drivers/net/phy/swphy.c
@@ -2,7 +2,7 @@
 /*
  * Software PHY emulation
  *
- * Code taken from fixed_phy.c by Russell King 
+ * Code taken from fixed_phy.c by Russell King.
  *
  * Author: Vitaly Bordug 
  * Anton Vorontsov 
diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
index 985afea1ee36..e2b1b894aae7 100644
--- a/include/media/cec-notifier.h
+++ b/include/media/cec-notifier.h
@@ -2,7 +2,7 @@
 /*
  * cec-notifier.h - notify CEC drivers of physical address changes
  *
- * Copyright 2016 Russell King 
+ * Copyright 2016 Russell King.
  * Copyright 2016-2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
  */
 
-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v4,1/3] drm/prime: use dma length macro when mapping sg

[Marek Szyprowski]

Hi

On 2020-03-27 10:10, Marek Szyprowski wrote:
> Hi Christian,
>
> On 2020-03-27 09:11, Christian König wrote:
>> Am 27.03.20 um 08:54 schrieb Marek Szyprowski:
>>> On 2020-03-25 10:07, Shane Francis wrote:
 As dma_map_sg can reorganize scatter-gather lists in a
 way that can cause some later segments to be empty we should
 always use the sg_dma_len macro to fetch the actual length.

 This could now be 0 and not need to be mapped to a page or
 address array

 Signed-off-by: Shane Francis 
 Reviewed-by: Michael J. Ruhl 
>>> This patch landed in linux-next 20200326 and it causes a kernel 
>>> panic on
>>> various Exynos SoC based boards.
 ---
    drivers/gpu/drm/drm_prime.c | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
 index 86d9b0e45c8c..1de2cde2277c 100644
 --- a/drivers/gpu/drm/drm_prime.c
 +++ b/drivers/gpu/drm/drm_prime.c
 @@ -967,7 +967,7 @@ int drm_prime_sg_to_page_addr_arrays(struct 
 sg_table *sgt, struct page **pages,
       index = 0;
    for_each_sg(sgt->sgl, sg, sgt->nents, count) {
 -    len = sg->length;
 +    len = sg_dma_len(sg);
    page = sg_page(sg);
    addr = sg_dma_address(sg);
>>> Sorry, but this code is wrong :(
>>
>> Well it is at least better than before because it makes most drivers 
>> work correctly again.
>
> Well, I'm not sure that a half-broken fix should be considered as a 
> fix ;)
>
> Anyway, I just got the comment from Shane, that my patch is fixing the 
> issues with amdgpu and radeon, while still working fine for exynos, so 
> it is indeed a proper fix.

Today I've noticed that this patch went to final v5.6 without even a day 
of testing in linux-next, so v5.6 is broken on Exynos and probably a few 
other ARM archs, which rely on the drm_prime_sg_to_page_addr_arrays 
function.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/4] dt-bindings: Add missing 'additionalProperties: false'

[Masahiro Yamada]

Hi Rob,

On Mon, Mar 30, 2020 at 4:09 PM Masahiro Yamada  wrote:
>
> On Thu, Mar 26, 2020 at 7:06 AM Rob Herring  wrote:
> >
> > Setting 'additionalProperties: false' is frequently omitted, but is
> > important in order to check that there aren't extra undocumented
> > properties in a binding.
> >
> > Ideally, we'd just add this automatically and make this the default, but
> > there's some cases where it doesn't work. For example, if a common
> > schema is referenced, then properties in the common schema aren't part
> > of what's considered for 'additionalProperties'. Also, sometimes there
> > are bus specific properties such as 'spi-max-frequency' that go into
> > bus child nodes, but aren't defined in the child node's schema.
> >
> > So let's stick with the json-schema defined default and add
> > 'additionalProperties: false' where needed. This will be a continual
> > review comment and game of wack-a-mole.
> >
> > Signed-off-by: Rob Herring 
> > ---
>
>
> >  .../devicetree/bindings/gpio/socionext,uniphier-gpio.yaml  | 2 ++
>
>
> You may have already queue this up, but just in case.
>
> Acked-by: Masahiro Yamada 



I take back Ack for socionext,uniphier-gpio.yaml



Now "make dt_binding_check" produces a new warning.

gpio@5500: 'interrupt-parent' does not match any of the regexes:
'pinctrl-[0-9]+'


This binding uses 'interrupt-parent'
without 'interrupts'.

Instead, the mapping of the interrupt numbers
is specified by the vendor-specific property
socionext,interrupt-ranges



I cannot add   "interrupt-parent: true" because
dt-schema/meta-schemas/interrupts.yaml
has "interrupt-parent: false".


Is there any solution?



-- 
Best Regards
Masahiro Yamada
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/managed: Fix off-by-one in warning

[Daniel Vetter]

Ok 0day people uploaded the tree they tested (from patches) now, I
confirmed it's indeed this line that's blowing up.
-Daniel

On Sat, Mar 28, 2020 at 5:24 PM Daniel Vetter  wrote:
>
> I'm thinking this is the warning that fired in the 0day report, but I
> can't double-check yet since 0day didn't upload its source tree
> anywhere I can check. And all the drivers I can easily test don't use
> drm_dev_alloc anymore ...
>
> Also if I'm correct supreme amounts of bad luck because usually kslap
> (for bigger structures) gives us something quite a bit bigger than
> what we asked for.
>
> Reported-by: kernel test robot 
> Fixes: c6603c740e0e ("drm: add managed resources tied to drm_device")
> Cc: Sam Ravnborg 
> Cc: Thomas Zimmermann 
> Cc: Dan Carpenter 
> Cc: Laurent Pinchart 
> Cc: Neil Armstrong  Cc: Greg Kroah-Hartman 
> Cc: "Rafael J. Wysocki" 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_managed.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
> index 4955241ceb4c..9cebfe370a65 100644
> --- a/drivers/gpu/drm/drm_managed.c
> +++ b/drivers/gpu/drm/drm_managed.c
> @@ -139,8 +139,7 @@ void drmm_add_final_kfree(struct drm_device *dev, void 
> *container)
>  {
> WARN_ON(dev->managed.final_kfree);
> WARN_ON(dev < (struct drm_device *) container);
> -   WARN_ON(dev + 1 >=
> -   (struct drm_device *) (container + ksize(container)));
> +   WARN_ON(dev + 1 > (struct drm_device *) (container + 
> ksize(container)));
> dev->managed.final_kfree = container;
>  }
>  EXPORT_SYMBOL(drmm_add_final_kfree);
> --
> 2.25.1
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v4,1/3] drm/prime: use dma length macro when mapping sg

[Shane Francis]

On Mon, Mar 30, 2020 at 9:18 AM Marek Szyprowski
 wrote:
> Today I've noticed that this patch went to final v5.6 without even a day
> of testing in linux-next, so v5.6 is broken on Exynos and probably a few
> other ARM archs, which rely on the drm_prime_sg_to_page_addr_arrays
> function.
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>

Not sure what the full merge pipeline is here, but my original patch
was not sent to the stable mailing list. So I would assume that it
went through the normal release gates / checks ? If there was a fault
on the way I uploaded the patches I do apologise however I did follow
the normal guidelines as far as I understood them.

Personally I did validate this patch on systems with Intel and AMD GFX,
unfortunately I do not have any ARM based dev kits that are able to run
mainline (was never able to get an Nvidia TK1 to boot outside of L4T)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/managed: Fix off-by-one in warning

[Sam Ravnborg]

On Sat, Mar 28, 2020 at 11:02:26PM +0100, Daniel Vetter wrote:
> On Sat, Mar 28, 2020 at 7:49 PM Sam Ravnborg  wrote:
> >
> > Hi Daniel.
> >
> > On Sat, Mar 28, 2020 at 05:23:58PM +0100, Daniel Vetter wrote:
> > > I'm thinking this is the warning that fired in the 0day report, but I
> > > can't double-check yet since 0day didn't upload its source tree
> > > anywhere I can check. And all the drivers I can easily test don't use
> > > drm_dev_alloc anymore ...
> > >
> > > Also if I'm correct supreme amounts of bad luck because usually kslap
> > > (for bigger structures) gives us something quite a bit bigger than
> > > what we asked for.
> > >
> > > Reported-by: kernel test robot 
> > > Fixes: c6603c740e0e ("drm: add managed resources tied to drm_device")
> > > Cc: Sam Ravnborg 
> > > Cc: Thomas Zimmermann 
> > > Cc: Dan Carpenter 
> > > Cc: Laurent Pinchart 
> > > Cc: Neil Armstrong  > > Cc: Greg Kroah-Hartman 
> > > Cc: "Rafael J. Wysocki" 
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/drm_managed.c | 3 +--
> > >  1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
> > > index 4955241ceb4c..9cebfe370a65 100644
> > > --- a/drivers/gpu/drm/drm_managed.c
> > > +++ b/drivers/gpu/drm/drm_managed.c
> > > @@ -139,8 +139,7 @@ void drmm_add_final_kfree(struct drm_device *dev, 
> > > void *container)
> > >  {
> > >   WARN_ON(dev->managed.final_kfree);
> > >   WARN_ON(dev < (struct drm_device *) container);
> > > - WARN_ON(dev + 1 >=
> > > - (struct drm_device *) (container + ksize(container)));
> > > + WARN_ON(dev + 1 > (struct drm_device *) (container + 
> > > ksize(container)));
> >
> > I do not think this is the right fix...
> > The original code would trigger if
> > 1) the container only had a drm_device - and nothing else
> > 2) and the allocated size was the same
> 
> Yup, which apparently happens for all the drivers calling
> drm_dev_alloc(). At least on the unlucky architecture that 0day tested
> on (or build settings, or whatever). The issue was hit with drm/bochs,
> which is still using drm_dev_alloc (like most older-ish drivers).

That explains it and then the checks makes sense.

Reviewed-by: Sam Ravnborg 


Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/managed: Fix off-by-one in warning

[Daniel Vetter]

On Mon, Mar 30, 2020 at 12:29:44PM +0200, Sam Ravnborg wrote:
> On Sat, Mar 28, 2020 at 11:02:26PM +0100, Daniel Vetter wrote:
> > On Sat, Mar 28, 2020 at 7:49 PM Sam Ravnborg  wrote:
> > >
> > > Hi Daniel.
> > >
> > > On Sat, Mar 28, 2020 at 05:23:58PM +0100, Daniel Vetter wrote:
> > > > I'm thinking this is the warning that fired in the 0day report, but I
> > > > can't double-check yet since 0day didn't upload its source tree
> > > > anywhere I can check. And all the drivers I can easily test don't use
> > > > drm_dev_alloc anymore ...
> > > >
> > > > Also if I'm correct supreme amounts of bad luck because usually kslap
> > > > (for bigger structures) gives us something quite a bit bigger than
> > > > what we asked for.
> > > >
> > > > Reported-by: kernel test robot 
> > > > Fixes: c6603c740e0e ("drm: add managed resources tied to drm_device")
> > > > Cc: Sam Ravnborg 
> > > > Cc: Thomas Zimmermann 
> > > > Cc: Dan Carpenter 
> > > > Cc: Laurent Pinchart 
> > > > Cc: Neil Armstrong  > > > Cc: Greg Kroah-Hartman 
> > > > Cc: "Rafael J. Wysocki" 
> > > > Signed-off-by: Daniel Vetter 
> > > > ---
> > > >  drivers/gpu/drm/drm_managed.c | 3 +--
> > > >  1 file changed, 1 insertion(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_managed.c 
> > > > b/drivers/gpu/drm/drm_managed.c
> > > > index 4955241ceb4c..9cebfe370a65 100644
> > > > --- a/drivers/gpu/drm/drm_managed.c
> > > > +++ b/drivers/gpu/drm/drm_managed.c
> > > > @@ -139,8 +139,7 @@ void drmm_add_final_kfree(struct drm_device *dev, 
> > > > void *container)
> > > >  {
> > > >   WARN_ON(dev->managed.final_kfree);
> > > >   WARN_ON(dev < (struct drm_device *) container);
> > > > - WARN_ON(dev + 1 >=
> > > > - (struct drm_device *) (container + ksize(container)));
> > > > + WARN_ON(dev + 1 > (struct drm_device *) (container + 
> > > > ksize(container)));
> > >
> > > I do not think this is the right fix...
> > > The original code would trigger if
> > > 1) the container only had a drm_device - and nothing else
> > > 2) and the allocated size was the same
> > 
> > Yup, which apparently happens for all the drivers calling
> > drm_dev_alloc(). At least on the unlucky architecture that 0day tested
> > on (or build settings, or whatever). The issue was hit with drm/bochs,
> > which is still using drm_dev_alloc (like most older-ish drivers).
> 
> That explains it and then the checks makes sense.
> 
> Reviewed-by: Sam Ravnborg 

Thanks for your review, patch applied and a note to the commit message
added that 0day confirmed that it's indeed this WARN_ON that they've hit.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/6] drm/vblank: Add intro to documentation

[Thomas Zimmermann]

Hi Sam and Lyude,

thanks for improving the documentation. Below are a few points that I'd
found more understandable. I'm no native speaker, though.

Am 28.03.20 um 14:20 schrieb Sam Ravnborg:
> Lyude Paul wrote a very good intro to vblank here:
> https://lore.kernel.org/dri-devel/faf63d8a9ed23c16af69762f59d0dca6b2bf085f.ca...@redhat.com/T/#mce6480be738160e9d07c5d023e88fd78d7a06d27
> 
> Add this to the intro chapter in drm_vblank.c so others
> can benefit from it too.
> 
> Signed-off-by: Sam Ravnborg 
> Co-developed-by: Lyude Paul 
> Cc: Lyude Paul 
> Cc: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> ---
>  drivers/gpu/drm/drm_vblank.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index bcf346b3e486..95cac22d59d1 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -41,6 +41,21 @@
>  /**
>   * DOC: vblank handling
>   *
> + * From the perspective of a computer, every time a computer monitor displays

Possibly change from dative case to genitive:

"From the computer's perspective," ...

> + * a new frame it's done by "scanning out" the display image from top to
> + * bottom, one row of pixels at a time. which row of pixels we're on is

s/which/Which

The text changes from third person (the computer) to first person
(we're). Makes it harder to read. I'd remove both, "we" and "computer",
and speak of display hardware or scanout engine.

> + * referred to as the scanline.

I'd say a scanline is any of them. Maybe say "current scanline"?

> + * Additionally, there's usually a couple of extra scanlines which we

"In addition to the display's visible area, there's usually a couple of
extra scanlines that" ...

> + * scan out, but aren't actually displayed on the screen (these sometimes
> + * get used by HDMI audio and friends, but that's another story).
> + * The period where we're on these scanlines is referred to as the vblank.

I'd replace vblank with "vertical blanking period." That term is
required in the next paragraph.

The time when the hardware operates on these invisible scanlines is
referred to as vertical blanking period, or simply vblank.

> + *
> + * On a lot of display hardware, programming needs to take effect during the
> + * vertical blanking period so that settings like gamma, what frame we're

"we" again

> + * scanning out, etc. can be safely changed without showing visual tearing
> + * on the screen. In some unforgiving hardware, some of this programming has
> + * to both start and end in the same vblank - vertical blanking.
> + *
>   * Vertical blanking plays a major role in graphics rendering. To achieve
>   * tear-free display, users must synchronize page flips and/or rendering to
>   * vertical blanking. The DRM API offers ioctls to perform page flips
> 

In any case

Acked-by: Thomas Zimmermann 

Best regards
Thomas

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 1/5] drm: bridge: dw_mipi_dsi: add initial regmap infrastructure

[Adrian Ratiu]

In order to support multiple versions of the Synopsis MIPI DSI host
controller, which have different register layouts but almost identical
HW protocols, we add a regmap infrastructure which can abstract away
register accesses for platform drivers using the bridge.

The controller HW revision is detected during bridge probe which will
be used in future commits to load the relevant register layout which
the bridge will use transparently to the platform drivers.

Signed-off-by: Adrian Ratiu 
---
New in v5.
---
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 208 ++
 1 file changed, 117 insertions(+), 91 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 5ef0f154aa7b..6d9e2f21c9cc 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -227,6 +228,7 @@ struct dw_mipi_dsi {
struct drm_bridge *panel_bridge;
struct device *dev;
void __iomem *base;
+   struct regmap *regs;
 
struct clk *pclk;
 
@@ -235,6 +237,7 @@ struct dw_mipi_dsi {
u32 lanes;
u32 format;
unsigned long mode_flags;
+   u32 hw_version;
 
 #ifdef CONFIG_DEBUG_FS
struct dentry *debugfs;
@@ -249,6 +252,13 @@ struct dw_mipi_dsi {
const struct dw_mipi_dsi_plat_data *plat_data;
 };
 
+static const struct regmap_config dw_mipi_dsi_regmap_cfg = {
+   .reg_bits = 32,
+   .val_bits = 32,
+   .reg_stride = 4,
+   .name = "dw-mipi-dsi",
+};
+
 /*
  * Check if either a link to a master or slave is present
  */
@@ -280,16 +290,6 @@ static inline struct dw_mipi_dsi *bridge_to_dsi(struct 
drm_bridge *bridge)
return container_of(bridge, struct dw_mipi_dsi, bridge);
 }
 
-static inline void dsi_write(struct dw_mipi_dsi *dsi, u32 reg, u32 val)
-{
-   writel(val, dsi->base + reg);
-}
-
-static inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 reg)
-{
-   return readl(dsi->base + reg);
-}
-
 static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
   struct mipi_dsi_device *device)
 {
@@ -366,29 +366,29 @@ static void dw_mipi_message_config(struct dw_mipi_dsi 
*dsi,
if (lpm)
val |= CMD_MODE_ALL_LP;
 
-   dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
-   dsi_write(dsi, DSI_CMD_MODE_CFG, val);
+   regmap_write(dsi->regs, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
+   regmap_write(dsi->regs, DSI_CMD_MODE_CFG, val);
 }
 
 static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 hdr_val)
 {
int ret;
-   u32 val, mask;
+   u32 val = 0, mask;
 
-   ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
-val, !(val & GEN_CMD_FULL), 1000,
-CMD_PKT_STATUS_TIMEOUT_US);
+   ret = regmap_read_poll_timeout(dsi->regs, DSI_CMD_PKT_STATUS,
+  val, !(val & GEN_CMD_FULL), 1000,
+  CMD_PKT_STATUS_TIMEOUT_US);
if (ret) {
dev_err(dsi->dev, "failed to get available command FIFO\n");
return ret;
}
 
-   dsi_write(dsi, DSI_GEN_HDR, hdr_val);
+   regmap_write(dsi->regs, DSI_GEN_HDR, hdr_val);
 
mask = GEN_CMD_EMPTY | GEN_PLD_W_EMPTY;
-   ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
-val, (val & mask) == mask,
-1000, CMD_PKT_STATUS_TIMEOUT_US);
+   ret = regmap_read_poll_timeout(dsi->regs, DSI_CMD_PKT_STATUS,
+  val, (val & mask) == mask,
+  1000, CMD_PKT_STATUS_TIMEOUT_US);
if (ret) {
dev_err(dsi->dev, "failed to write command FIFO\n");
return ret;
@@ -403,24 +403,26 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
const u8 *tx_buf = packet->payload;
int len = packet->payload_length, pld_data_bytes = sizeof(u32), ret;
__le32 word;
-   u32 val;
+   u32 val = 0;
 
while (len) {
if (len < pld_data_bytes) {
word = 0;
memcpy(&word, tx_buf, len);
-   dsi_write(dsi, DSI_GEN_PLD_DATA, le32_to_cpu(word));
+   regmap_write(dsi->regs, DSI_GEN_PLD_DATA,
+le32_to_cpu(word));
len = 0;
} else {
memcpy(&word, tx_buf, pld_data_bytes);
-   dsi_write(dsi, DSI_GEN_PLD_DATA, le32_to_cpu(word));
+   regmap_write(dsi->regs, DSI_GEN_PLD_DATA,
+le32_to_cpu(word));
tx_buf += pld_data_bytes;
   

[PATCH v5 3/5] drm: bridge: synopsis: add dsi v1.01 support

[Adrian Ratiu]

The Synopsis MIPI DSI v1.01 host controller is quite widely used
on platforms like i.mx6 and is not very different from the other
versions like the 1.31/1.30 used on rockchip/stm. The protocols
appear to be the same, only the register layout is different and
the newer versions have new features symbolized by new registers
so adding support for it is just a matter of defining the new
layout and adding a couple of dsi version checks.

Signed-off-by: Adrian Ratiu 
---
New in v5.
---
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 125 +-
 1 file changed, 119 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 5b78ff925af0..fb9dbc4fd0f5 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -32,6 +32,7 @@
 
 #define HWVER_131  0x31333100  /* IP version 1.31 */
 #define HWVER_130  0x31333000  /* IP version 1.30 */
+#define HWVER_101  0x31303000  /* IP version 1.01 */
 
 #define DSI_VERSION0x00
 #define VERSIONGENMASK(31, 8)
@@ -100,6 +101,25 @@
 #define DSI_EDPI_CMD_SIZE  0x64
 
 #define DSI_CMD_MODE_CFG   0x68
+
+#define DSI_DPI_CFG0x0c
+#define DSI_TMR_LINE_CFG   0x28
+#define DSI_VTIMING_CFG0x2c
+#define DSI_PHY_TMR_CFG_V101   0x30
+#define DSI_PHY_IF_CFG_V1010x58
+#define DSI_PHY_IF_CTRL0x5c
+#define DSI_PHY_RSTZ_V101  0x54
+#define DSI_PHY_STATUS_V1010x60
+#define DSI_PHY_TST_CTRL0_V101 0x64
+#define DSI_GEN_HDR_V101   0x34
+#define DSI_GEN_PLD_DATA_V101  0x38
+#define DSI_CMD_MODE_CFG_V101  0x24
+#define DSI_CMD_PKT_STATUS_V1010x3c
+#define DSI_VID_PKT_CFG0x20
+#define DSI_VID_MODE_CFG_V101  0x1c
+#define DSI_TO_CNT_CFG_V1010x40
+#define DSI_PCKHDL_CFG_V1010x18
+
 #define MAX_RD_PKT_SIZE_LP BIT(24)
 #define DCS_LW_TX_LP   BIT(19)
 #define DCS_SR_0P_TX_LPBIT(18)
@@ -127,6 +147,33 @@
 GEN_SW_1P_TX_LP | \
 GEN_SW_0P_TX_LP)
 
+#define EN_TEAR_FX_V101BIT(14)
+#define DCS_LW_TX_LP_V101  BIT(12)
+#define GEN_LW_TX_LP_V101  BIT(11)
+#define MAX_RD_PKT_SIZE_LP_V101BIT(10)
+#define DCS_SW_2P_TX_LP_V101   BIT(9)
+#define DCS_SW_1P_TX_LP_V101   BIT(8)
+#define DCS_SW_0P_TX_LP_V101   BIT(7)
+#define GEN_SR_2P_TX_LP_V101   BIT(6)
+#define GEN_SR_1P_TX_LP_V101   BIT(5)
+#define GEN_SR_0P_TX_LP_V101   BIT(4)
+#define GEN_SW_2P_TX_LP_V101   BIT(3)
+#define GEN_SW_1P_TX_LP_V101   BIT(2)
+#define GEN_SW_0P_TX_LP_V101   BIT(1)
+
+#define CMD_MODE_ALL_LP_V101   (DCS_LW_TX_LP_V101 | \
+GEN_LW_TX_LP_V101 | \
+MAX_RD_PKT_SIZE_LP_V101 | \
+DCS_SW_2P_TX_LP_V101 | \
+DCS_SW_1P_TX_LP_V101 | \
+DCS_SW_0P_TX_LP_V101 | \
+GEN_SR_2P_TX_LP_V101 | \
+GEN_SR_1P_TX_LP_V101 | \
+GEN_SR_0P_TX_LP_V101 | \
+GEN_SW_2P_TX_LP_V101 | \
+GEN_SW_1P_TX_LP_V101 | \
+GEN_SW_0P_TX_LP_V101)
+
 #define DSI_GEN_HDR0x6c
 #define DSI_GEN_PLD_DATA   0x70
 
@@ -165,6 +212,11 @@
 #define DSI_INT_MSK0   0xc4
 #define DSI_INT_MSK1   0xc8
 
+#define DSI_ERROR_ST0_V101 0x44
+#define DSI_ERROR_ST1_V101 0x48
+#define DSI_ERROR_MSK0_V1010x4c
+#define DSI_ERROR_MSK1_V1010x50
+
 #define DSI_PHY_TMR_RD_CFG 0xf4
 
 #define PHY_STATUS_TIMEOUT_US  1
@@ -359,6 +411,49 @@ static const struct dw_mipi_dsi_variant 
dw_mipi_dsi_v130_v131_layout = {
.cfg_gen_payload =  REG_FIELD(DSI_GEN_PLD_DATA, 0, 31),
 };
 
+static const struct dw_mipi_dsi_variant dw_mipi_dsi_v101_layout = {
+   .cfg_dpi_vid =  REG_FIELD(DSI_DPI_CFG, 0, 1),
+   .cfg_dpi_color_coding = REG_FIELD(DSI_DPI_CFG, 2, 4),
+   .cfg_dpi_18loosely_en = REG_FIELD(DSI_DPI_CFG, 10, 10),
+   .cfg_dpi_vsync_active_low = REG_FIELD(DSI_DPI_CFG, 6, 6),
+   .cfg_dpi_hsync_active_low = REG_FIELD(DSI_DPI_CFG, 7, 7),
+   .cfg_cmd_mode_en =  REG_FIELD(DSI_CMD_MODE_CFG_

[PATCH v5 0/5] Genericize DW MIPI DSI bridge and add i.MX 6 driver

[Adrian Ratiu]

Hello everyone,

The v5 series is a significantly cleaned up version from v4,
started by Ezequiel Garcia's suggestion of splitting out the
regmap infrastructure from the drivers (thank you!).

Turns out no changes are required to the existing drivers and
the bridge can transparently take care of the layout logic,
so there's no need to expose the regmap via plat_data anymore.

Starting from this version I also opted to add per-patch
changelogs. All review comments up to now have been addressed.

Tested on IMX6DL.

Adrian Ratiu (5):
  drm: bridge: dw_mipi_dsi: add initial regmap infrastructure
  drm: bridge: dw_mipi_dsi: abstract register access using reg_fields
  drm: bridge: synopsis: add dsi v1.01 support
  drm: imx: Add i.MX 6 MIPI DSI host platform driver
  dt-bindings: display: add i.MX6 MIPI DSI host controller doc

 .../display/imx/fsl,mipi-dsi-imx6.yaml| 134 
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 683 +-
 drivers/gpu/drm/imx/Kconfig   |   7 +
 drivers/gpu/drm/imx/Makefile  |   1 +
 drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c| 399 ++
 5 files changed, 1049 insertions(+), 175 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
 create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c

-- 
2.26.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 2/5] drm: bridge: dw_mipi_dsi: abstract register access using reg_fields

[Adrian Ratiu]

Register existence, address/offsets, field layouts, reserved bits and
so on differ between MIPI-DSI versions and between SoC vendor boards.
Despite these differences the hw IP and protocols are mostly the same
so the generic bridge can be made to compensate these differences.

The current Rockchip and STM drivers hardcoded a lot of their common
definitions in the bridge code because they're based on DSI v1.30 and
1.31 which are relatively close, but in order to support older/future
versions with more diverging layouts like the v1.01 present on imx6,
we abstract some of the register accesses via the regmap field APIs.

The bridge detects the DSI core version and initializes the required
regmap register layout. Other DSI versions / register layouts can
easily be added in the future by only changing the bridge code.

The platform drivers don't require any changes, DSI register layout
versioning will be handled transparently by the bridge, but if in
the future the regmap or layouts needs to be exposed to the drivres,
it could easily be done via plat_data or a new API in dw_mipi_dsi.h.

Suggested-by: Boris Brezillon 
Reviewed-by: Emil Velikov 
Signed-off-by: Adrian Ratiu 
---
Changes since v4:
  - Move regmap infrastructure logic to a separate commit (Ezequiel)
  - Consolidate field infrastructure in this commit (Ezequiel)
  - Move the dsi v1.01 layout logic to a separate commit (Ezequiel)

Changes since v2:
  - Added const declarations to dw_mipi_dsi structs (Emil)
  - Fixed commit tags (Emil)

Changes since v1:
  - Moved register definitions & regmap initialization into bridge
  module. Platform drivers get the regmap via plat_data after calling
  the bridge probe (Emil).
---
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 510 --
 1 file changed, 352 insertions(+), 158 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 6d9e2f21c9cc..5b78ff925af0 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -31,6 +31,7 @@
 #include 
 
 #define HWVER_131  0x31333100  /* IP version 1.31 */
+#define HWVER_130  0x31333000  /* IP version 1.30 */
 
 #define DSI_VERSION0x00
 #define VERSIONGENMASK(31, 8)
@@ -47,7 +48,6 @@
 #define DPI_VCID(vcid) ((vcid) & 0x3)
 
 #define DSI_DPI_COLOR_CODING   0x10
-#define LOOSELY18_EN   BIT(8)
 #define DPI_COLOR_CODING_16BIT_1   0x0
 #define DPI_COLOR_CODING_16BIT_2   0x1
 #define DPI_COLOR_CODING_16BIT_3   0x2
@@ -56,11 +56,6 @@
 #define DPI_COLOR_CODING_24BIT 0x5
 
 #define DSI_DPI_CFG_POL0x14
-#define COLORM_ACTIVE_LOW  BIT(4)
-#define SHUTD_ACTIVE_LOW   BIT(3)
-#define HSYNC_ACTIVE_LOW   BIT(2)
-#define VSYNC_ACTIVE_LOW   BIT(1)
-#define DATAEN_ACTIVE_LOW  BIT(0)
 
 #define DSI_DPI_LP_CMD_TIM 0x18
 #define OUTVACT_LPCMD_TIME(p)  (((p) & 0xff) << 16)
@@ -81,27 +76,19 @@
 #define DSI_GEN_VCID   0x30
 
 #define DSI_MODE_CFG   0x34
-#define ENABLE_VIDEO_MODE  0
-#define ENABLE_CMD_MODEBIT(0)
 
 #define DSI_VID_MODE_CFG   0x38
-#define ENABLE_LOW_POWER   (0x3f << 8)
-#define ENABLE_LOW_POWER_MASK  (0x3f << 8)
+#define ENABLE_LOW_POWER   0x3f
+
 #define VID_MODE_TYPE_NON_BURST_SYNC_PULSES0x0
 #define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS0x1
 #define VID_MODE_TYPE_BURST0x2
-#define VID_MODE_TYPE_MASK 0x3
-#define VID_MODE_VPG_ENABLEBIT(16)
-#define VID_MODE_VPG_HORIZONTALBIT(24)
 
 #define DSI_VID_PKT_SIZE   0x3c
-#define VID_PKT_SIZE(p)((p) & 0x3fff)
 
 #define DSI_VID_NUM_CHUNKS 0x40
-#define VID_NUM_CHUNKS(c)  ((c) & 0x1fff)
 
 #define DSI_VID_NULL_SIZE  0x44
-#define VID_NULL_SIZE(b)   ((b) & 0x1fff)
 
 #define DSI_VID_HSA_TIME   0x48
 #define DSI_VID_HBP_TIME   0x4c
@@ -125,7 +112,6 @@
 #define GEN_SW_2P_TX_LPBIT(10)
 #define GEN_SW_1P_TX_LPBIT(9)
 #define GEN_SW_0P_TX_LPBIT(8)
-#define ACK_RQST_ENBIT(1)
 #define TEAR_FX_EN BIT(0)
 
 #define CMD_MODE_ALL_LP(MAX_RD_PKT_SIZE_LP | \
@@ -154,8 +140,6 @@
 #define GEN_CMD_EMPTY  BIT(0)
 
 #define DSI_TO_CNT_CFG 0x78
-#define HSTX_TO_CNT(p) (((p) & 0x) << 16)
-#define LPRX_TO_CNT(p) ((p) & 0x)
 
 #define DSI_HS_RD_TO_CNT   0x7c
 #define DSI_LP_RD_TO_CNT   0x80
@@ -164,52 +148,17 @@
 #define DSI_BTA_TO_CNT  

[PATCH v5 4/5] drm: imx: Add i.MX 6 MIPI DSI host platform driver

[Adrian Ratiu]

This adds support for the Synopsis DesignWare MIPI DSI v1.01 host
controller which is embedded in i.MX 6 SoCs.

Based on following patches, but updated/extended to work with existing
support found in the kernel:

- drm: imx: Support Synopsys DesignWare MIPI DSI host controller
  Signed-off-by: Liu Ying 

- ARM: dtsi: imx6qdl: Add support for MIPI DSI host controller
  Signed-off-by: Liu Ying 

Cc: Fabio Estevam 
Reviewed-by: Emil Velikov 
Signed-off-by: Sjoerd Simons 
Signed-off-by: Martyn Welch 
Signed-off-by: Adrian Ratiu 
---
Changes since v4:
  - Split off driver-specific configuration of phy timings due
  to new upstream API.
  - Move regmap infrastructure logic to separate commit (Ezequiel)
  - Move dsi v1.01 layout addition to a separate commit (Ezequiel)
  - Minor warnings and driver name fixes

Changes since v3:
  - Renamed platform driver to reflect it's i.MX6 only. (Fabio)

Changes since v2:
  - Fixed commit tags. (Emil)

Changes since v1:
  - Moved register definitions & regmap initialization into bridge
  module. Platform drivers get the regmap via plat_data after
  calling the bridge probe. (Emil)
---
 drivers/gpu/drm/imx/Kconfig|   7 +
 drivers/gpu/drm/imx/Makefile   |   1 +
 drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c | 399 +
 3 files changed, 407 insertions(+)
 create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c

diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
index 207bf7409dfb..b49e70e7f0fd 100644
--- a/drivers/gpu/drm/imx/Kconfig
+++ b/drivers/gpu/drm/imx/Kconfig
@@ -39,3 +39,10 @@ config DRM_IMX_HDMI
depends on DRM_IMX
help
  Choose this if you want to use HDMI on i.MX6.
+
+config DRM_IMX6_MIPI_DSI
+   tristate "Freescale i.MX6 DRM MIPI DSI"
+   select DRM_DW_MIPI_DSI
+   depends on DRM_IMX
+   help
+ Choose this if you want to use MIPI DSI on i.MX6.
diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
index 21cdcc2faabc..9a7843c59347 100644
--- a/drivers/gpu/drm/imx/Makefile
+++ b/drivers/gpu/drm/imx/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
 obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
 
 obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
+obj-$(CONFIG_DRM_IMX6_MIPI_DSI) += dw_mipi_dsi-imx6.o
diff --git a/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c 
b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
new file mode 100644
index ..56b17d8670a2
--- /dev/null
+++ b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
@@ -0,0 +1,399 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * i.MX6 drm driver - MIPI DSI Host Controller
+ *
+ * Copyright (C) 2011-2015 Freescale Semiconductor, Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "imx-drm.h"
+
+#define DSI_PWR_UP 0x04
+#define RESET  0
+#define POWERUPBIT(0)
+
+#define DSI_PHY_IF_CTRL0x5c
+#define PHY_IF_CTRL_RESET  0x0
+
+#define DSI_PHY_TST_CTRL0  0x64
+#define PHY_TESTCLKBIT(1)
+#define PHY_UNTESTCLK  0
+#define PHY_TESTCLRBIT(0)
+#define PHY_UNTESTCLR  0
+
+#define DSI_PHY_TST_CTRL1  0x68
+#define PHY_TESTEN BIT(16)
+#define PHY_UNTESTEN   0
+#define PHY_TESTDOUT(n)(((n) & 0xff) << 8)
+#define PHY_TESTDIN(n) (((n) & 0xff) << 0)
+
+struct imx_mipi_dsi {
+   struct drm_encoder encoder;
+   struct device *dev;
+   struct regmap *mux_sel;
+   struct dw_mipi_dsi *mipi_dsi;
+   struct clk *pllref_clk;
+
+   void __iomem *base;
+   unsigned int lane_mbps;
+};
+
+struct dphy_pll_testdin_map {
+   unsigned int max_mbps;
+   u8 testdin;
+};
+
+/* The table is based on 27MHz DPHY pll reference clock. */
+static const struct dphy_pll_testdin_map dptdin_map[] = {
+   {160, 0x04}, {180, 0x24}, {200, 0x44}, {210, 0x06},
+   {240, 0x26}, {250, 0x46}, {270, 0x08}, {300, 0x28},
+   {330, 0x48}, {360, 0x2a}, {400, 0x4a}, {450, 0x0c},
+   {500, 0x2c}, {550, 0x0e}, {600, 0x2e}, {650, 0x10},
+   {700, 0x30}, {750, 0x12}, {800, 0x32}, {850, 0x14},
+   {900, 0x34}, {950, 0x54}, {1000, 0x74}
+};
+
+static inline struct imx_mipi_dsi *enc_to_dsi(struct drm_encoder *enc)
+{
+   return container_of(enc, struct imx_mipi_dsi, encoder);
+}
+
+static void imx_mipi_dsi_set_ipu_di_mux(struct imx_mipi_dsi *dsi, int ipu_di)
+{
+   regmap_update_bits(dsi->mux_sel, IOMUXC_GPR3,
+  IMX6Q_GPR3_MIPI_MUX_CTL_MASK,
+  ipu_di << IMX6Q_GPR3_MIPI_MUX_CTL_SHIFT);
+}
+
+static const struct drm_encoder_funcs imx_mipi_dsi_encoder_funcs = {
+   .destroy = imx_drm_encoder_destroy,
+};
+
+static bool imx_mipi_dsi_encoder_mode_fixup(struct drm_encoder *e

[PATCH v5 5/5] dt-bindings: display: add i.MX6 MIPI DSI host controller doc

[Adrian Ratiu]

This provides an example DT binding for the MIPI DSI host controller
present on the i.MX6 SoC based on Synopsis DesignWare v1.01 IP.

Cc: Rob Herring 
Cc: Neil Armstrong 
Cc: devicet...@vger.kernel.org
Signed-off-by: Sjoerd Simons 
Signed-off-by: Martyn Welch 
Signed-off-by: Adrian Ratiu 
---
Changes since v4:
  - Fixed yaml binding to pass `make dt_binding_check dtbs_check`
  and addressed received binding feedback (Rob)

Changes since v3:
  - Added commit message (Neil)
  - Converted to yaml format (Neil)
  - Minor dt node + driver fixes (Rob)
  - Added small panel example to the host controller binding

Changes since v2:
  - Fixed commit tags (Emil)
---
 .../display/imx/fsl,mipi-dsi-imx6.yaml| 134 ++
 1 file changed, 134 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml

diff --git 
a/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml 
b/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
new file mode 100644
index ..59146df11510
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
@@ -0,0 +1,134 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,mipi-dsi-imx6.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX6 DW MIPI DSI Host Controller
+
+maintainers:
+  - Adrian Ratiu 
+
+description: |
+  The i.MX6 DSI host controller is a Synopsys DesignWare MIPI DSI v1.01
+  IP block with a companion PHY IP.
+
+  These DT bindings follow the Synopsys DW MIPI DSI bindings defined in
+  Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt with
+  the following device-specific properties.
+
+properties:
+  compatible:
+items:
+  - const: fsl,imx6q-mipi-dsi
+  - const: snps,dw-mipi-dsi
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: Module Clock
+  - description: DSI bus clock
+
+  clock-names:
+items:
+  - const: ref
+  - const: pclk
+
+  fsl,gpr:
+description: Phandle to the iomuxc-gpr region containing the multiplexer 
control register.
+$ref: /schemas/types.yaml#/definitions/phandle
+
+  ports:
+type: object
+description: |
+  A node containing DSI input & output port nodes with endpoint
+  definitions as documented in
+  Documentation/devicetree/bindings/media/video-interfaces.txt
+  Documentation/devicetree/bindings/graph.txt
+properties:
+  port@0:
+type: object
+description:
+  DSI input port node, connected to the ltdc rgb output port.
+
+  port@1:
+type: object
+description:
+  DSI output port node, connected to a panel or a bridge input port"
+
+patternProperties:
+  "^panel@[0-3]$":
+type: object
+description: |
+  A node containing the panel or bridge description as documented in
+  Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+properties:
+  port:
+type: object
+description:
+  Panel or bridge port node, connected to the DSI output port (port@1)
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |+
+#include 
+#include 
+#include 
+
+dsi: dsi@21e {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "fsl,imx6q-mipi-dsi", "snps,dw-mipi-dsi";
+reg = <0x021e 0x4000>;
+interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+fsl,gpr = <&gpr>;
+clocks = <&clks IMX6QDL_CLK_MIPI_CORE_CFG>,
+ <&clks IMX6QDL_CLK_MIPI_IPG>;
+clock-names = "ref", "pclk";
+
+ports {
+port@1 {
+reg = <1>;
+dsi_out: endpoint {
+remote-endpoint = <&panel_in>;
+};
+};
+};
+
+panel@0 {
+compatible = "sharp,ls032b3sx01";
+reg = <0>;
+reset-gpios = <&gpio6 8 GPIO_ACTIVE_LOW>;
+ports {
+port@0 {
+panel_in: endpoint {
+remote-endpoint = <&dsi_out>;
+};
+};
+};
+};
+};
+
+...
-- 
2.26.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel