Re: [RFC 4/6] drm/bridge/sii8620: fix extcon dependency

2020-04-14 Thread Jani Nikula
On Tue, 14 Apr 2020, Daniel Vetter  wrote:
> On Tue, Apr 14, 2020 at 5:05 PM Arnd Bergmann  wrote:
>>
>> On Fri, Apr 10, 2020 at 8:56 AM Andrzej Hajda  wrote:
>> >
>> >
>> > On 08.04.2020 22:27, Arnd Bergmann wrote:
>> > > Using 'imply' does not work here, it still cause the same build
>> > > failure:
>> > >
>> > > arm-linux-gnueabi-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function 
>> > > `sii8620_remove':
>> > > sil-sii8620.c:(.text+0x1b8): undefined reference to 
>> > > `extcon_unregister_notifier'
>> > > arm-linux-gnueabi-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function 
>> > > `sii8620_probe':
>> > > sil-sii8620.c:(.text+0x27e8): undefined reference to 
>> > > `extcon_find_edev_by_node'
>> > > arm-linux-gnueabi-ld: sil-sii8620.c:(.text+0x2870): undefined reference 
>> > > to `extcon_register_notifier'
>> > > arm-linux-gnueabi-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function 
>> > > `sii8620_extcon_work':
>> > > sil-sii8620.c:(.text+0x2908): undefined reference to `extcon_get_state'
>> > >
>> > > I tried the usual 'depends on EXTCON || !EXTCON' logic, but that caused
>> > > a circular Kconfig dependency. Using IS_REACHABLE() is ugly but works.
>> >
>> > 'depends on EXTCON || !EXTCON' seems to be proper solution, maybe would be 
>> > better to try to solve circular dependencies issue.
>>
>> I agree that would be nice, but I failed to come to a proper solution
>> here. FWIW, there
>> is one circular dependency that I managed to avoid by changing all
>> drivers that select FB_DDC
>> to depend on I2C rather than selecting it:
>>
>> drivers/i2c/Kconfig:8:error: recursive dependency detected!
>> drivers/i2c/Kconfig:8: symbol I2C is selected by FB_DDC
>> drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB
>> drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER
>> drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on 
>> DRM_KMS_HELPER
>> drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by 
>> DRM_SIL_SII8620
>> drivers/gpu/drm/bridge/Kconfig:89: symbol DRM_SIL_SII8620 depends on EXTCON
>> drivers/extcon/Kconfig:2: symbol EXTCON is selected by CHARGER_MANAGER
>> drivers/power/supply/Kconfig:482: symbol CHARGER_MANAGER depends on 
>> POWER_SUPPLY
>> drivers/power/supply/Kconfig:2: symbol POWER_SUPPLY is selected by
>> HID_BATTERY_STRENGTH
>> drivers/hid/Kconfig:29: symbol HID_BATTERY_STRENGTH depends on HID
>> drivers/hid/Kconfig:8: symbol HID is selected by I2C_HID
>> drivers/hid/i2c-hid/Kconfig:5: symbol I2C_HID depends on I2C
>>
>> After that, Kconfig crashes with a segfault:
>>
>> drivers/video/fbdev/Kconfig:12:error: recursive dependency detected!
>> drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER
>> drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on 
>> DRM_KMS_HELPER
>> drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by 
>> DRM_SIL_SII8620
>> drivers/gpu/drm/bridge/Kconfig:89: symbol DRM_SIL_SII8620 depends on EXTCON
>> drivers/extcon/Kconfig:2: symbol EXTCON is selected by CHARGER_MANAGER
>> drivers/power/supply/Kconfig:482: symbol CHARGER_MANAGER depends on 
>> POWER_SUPPLY
>> drivers/power/supply/Kconfig:2: symbol POWER_SUPPLY is selected by HID_ASUS
>> drivers/hid/Kconfig:150: symbol HID_ASUS depends on LEDS_CLASS
>> drivers/leds/Kconfig:17: symbol LEDS_CLASS depends on NEW_LEDS
>> drivers/leds/Kconfig:9: symbol NEW_LEDS is selected by SENSORS_APPLESMC
>> drivers/hwmon/Kconfig:327: symbol SENSORS_APPLESMC depends on HWMON
>> drivers/hwmon/Kconfig:6: symbol HWMON is selected by EEEPC_LAPTOP
>> drivers/platform/x86/Kconfig:260: symbol EEEPC_LAPTOP depends on ACPI_VIDEO
>> make[3]: *** [/git/arm-soc/scripts/kconfig/Makefile:71: randconfig]
>> Segmentation fault (core dumped)
>>
>> After changing EEEPC_LAPTOP and THINKPAD_ACPI to 'depends on HWMON' instead 
>> of
>> 'select HWMON', I get this one:
>>
>> drivers/video/fbdev/Kconfig:12:error: recursive dependency detected!
>> drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER
>> drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on 
>> DRM_KMS_HELPER
>> drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by 
>> DRM_SIL_SII8620
>> drivers/gpu/drm/bridge/Kconfig:89: symbol DRM_SIL_SII8620 depends on EXTCON
>> drivers/extcon/Kconfig:2: symbol EXTCON is selected by CHARGER_MANAGER
>> drivers/power/supply/Kconfig:482: symbol CHARGER_MANAGER depends on 
>> POWER_SUPPLY
>> drivers/power/supply/Kconfig:2: symbol POWER_SUPPLY is selected by HID_ASUS
>> drivers/hid/Kconfig:150: symbol HID_ASUS depends on LEDS_CLASS
>> drivers/leds/Kconfig:17: symbol LEDS_CLASS depends on NEW_LEDS
>> drivers/leds/Kconfig:9: symbol NEW_LEDS is selected by BACKLIGHT_ADP8860
>> drivers/video/backlight/Kconfig:316: symbol BACKLIGHT_ADP8860 depends
>> on BACKLIGHT_CLASS_DEVICE
>> drivers/video/backlight/Kconfig:143: symbol BACKLIGHT_CLASS_DEVICE is
>> selected by FB_BACKLIGHT
>> drivers/video/fbdev/Kconfig:187: symbol FB_BACKL

Re: [PULL] topic/phy-compliance

2020-04-14 Thread Jani Nikula
On Wed, 08 Apr 2020, Maarten Lankhorst  
wrote:
> Hey,
>
> Here's a pull request to pull in the DP PHY Compliance series.
> It's based on top of drm/drm-next, and contains all patches for core, amd and 
> i915. :)

Ping, I don't see this merged in any tree yet.

BR,
Jani.


>
> Cheers,
> Maarten
>
> topic/phy-compliance-2020-04-08:
> Topic pull request for topic/phy-compliance:
> - Standardize DP_PHY_TEST_PATTERN name.
> - Add support for setting/getting test pattern from sink.
> - Implement DP PHY compliance to i915.
> The following changes since commit 12ab316ced2c5f32ced0e6300a054db644b5444a:
>
>   Merge tag 'amd-drm-next-5.7-2020-04-01' of 
> git://people.freedesktop.org/~agd5f/linux into drm-next (2020-04-08 09:34:27 
> +1000)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-misc 
> tags/topic/phy-compliance-2020-04-08
>
> for you to fetch changes up to 8cdf727119289db3a98835662eb28e1c5ad835f1:
>
>   drm/i915/dp: Program vswing, pre-emphasis, test-pattern (2020-04-08 
> 14:41:09 +0200)
>
> 
> Topic pull request for topic/phy-compliance:
> - Standardize DP_PHY_TEST_PATTERN name.
> - Add support for setting/getting test pattern from sink.
> - Implement DP PHY compliance to i915.
>
> 
> Animesh Manna (7):
>   drm/amd/display: Align macro name as per DP spec
>   drm/dp: get/set phy compliance pattern
>   drm/i915/dp: Made intel_dp_adjust_train() non-static
>   drm/i915/dp: Preparation for DP phy compliance auto test
>   drm/i915/dp: Add debugfs entry for DP phy compliance
>   drm/i915/dp: Register definition for DP compliance register
>   drm/i915/dp: Program vswing, pre-emphasis, test-pattern
>
>  drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   |   2 +-
>  drivers/gpu/drm/drm_dp_helper.c|  94 +++
>  .../gpu/drm/i915/display/intel_display_debugfs.c   |  12 +-
>  drivers/gpu/drm/i915/display/intel_display_types.h |   1 +
>  drivers/gpu/drm/i915/display/intel_dp.c| 171 
> +
>  drivers/gpu/drm/i915/display/intel_dp.h|   1 +
>  .../gpu/drm/i915/display/intel_dp_link_training.c  |   9 +-
>  .../gpu/drm/i915/display/intel_dp_link_training.h  |   4 +
>  drivers/gpu/drm/i915/i915_reg.h|  18 +++
>  include/drm/drm_dp_helper.h|  33 +++-
>  10 files changed, 337 insertions(+), 8 deletions(-)

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] staging: android: ion: Skip sync if not mapped

2020-04-14 Thread John Stultz
On Tue, Apr 14, 2020 at 9:11 AM Ørjan Eide  wrote:
>
> On Tue, Apr 14, 2020 at 04:28:10PM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Apr 14, 2020 at 04:18:47PM +0200, �rjan Eide wrote:
> > > Only sync the sg-list of an Ion dma-buf attachment when the attachment
> > > is actually mapped on the device.
> > >
> > > dma-bufs may be synced at any time. It can be reached from user space
> > > via DMA_BUF_IOCTL_SYNC, so there are no guarantees from callers on when
> > > syncs may be attempted, and dma_buf_end_cpu_access() and
> > > dma_buf_begin_cpu_access() may not be paired.
> > >
> > > Since the sg_list's dma_address isn't set up until the buffer is used
> > > on the device, and dma_map_sg() is called on it, the dma_address will be
> > > NULL if sync is attempted on the dma-buf before it's mapped on a device.
> > >
> > > Before v5.0 (commit 55897af63091 ("dma-direct: merge swiotlb_dma_ops
> > > into the dma_direct code")) this was a problem as the dma-api (at least
> > > the swiotlb_dma_ops on arm64) would use the potentially invalid
> > > dma_address. How that failed depended on how the device handled physical
> > > address 0. If 0 was a valid address to physical ram, that page would get
> > > flushed a lot, while the actual pages in the buffer would not get synced
> > > correctly. While if 0 is an invalid physical address it may cause a
> > > fault and trigger a crash.
> > >
> > > In v5.0 this was incidentally fixed by commit 55897af63091 ("dma-direct:
> > > merge swiotlb_dma_ops into the dma_direct code"), as this moved the
> > > dma-api to use the page pointer in the sg_list, and (for Ion buffers at
> > > least) this will always be valid if the sg_list exists at all.
> > >
> > > But, this issue is re-introduced in v5.3 with
> > > commit 449fa54d6815 ("dma-direct: correct the physical addr in
> > > dma_direct_sync_sg_for_cpu/device") moves the dma-api back to the old
> > > behaviour and picks the dma_address that may be invalid.
> > >
> > > dma-buf core doesn't ensure that the buffer is mapped on the device, and
> > > thus have a valid sg_list, before calling the exporter's
> > > begin_cpu_access.
> > >
> > > Signed-off-by: �rjan Eide 
> > > ---
> > >  drivers/staging/android/ion/ion.c | 12 
> > >  1 file changed, 12 insertions(+)
> > >
> > > Resubmit without disclaimer, sorry about that.
> > >
> > > This seems to be part of a bigger issue where dma-buf exporters assume
> > > that their dma-buf begin_cpu_access and end_cpu_access callbacks have a
> > > certain guaranteed behavior, which isn't ensured by dma-buf core.
> > >
> > > This patch fixes this in ion only, but it also needs to be fixed for
> > > other exporters, either handled like this in each exporter, or in
> > > dma-buf core before calling into the exporters.
> > >
> > > diff --git a/drivers/staging/android/ion/ion.c 
> > > b/drivers/staging/android/ion/ion.c
> > > index 38b51eace4f9..7b752ba0cb6d 100644
> > > --- a/drivers/staging/android/ion/ion.c
> > > +++ b/drivers/staging/android/ion/ion.c
> >
> > Now that we have the dma-buff stuff in the tree, do we even need the
> > ion code in the kernel anymore?  Can't we delete it now?
>
> It looks like the new dma-heaps have the same issue as ion. The
> heap-helpers also do dma_sync_sg_for_device() unconditionally on
> end_cpu_access which may happen before dma_map_sg(), leading to use of
> the 0 dma_address in the sg list of a, yet unmapped, attachment.

Yea, the dma-buf heaps code came from the ION logic, so it likely has
the same faults.

> It could be fixed in dma-heaps just like this patch does for ion. Is
> patch a valid way to fix this problem? Or, should this rather be handled
> in dma-buf core by tracking the mapped state of attachments there?

In the short-term, I'd definitely prefer to have a fix to dmabuf heaps
rather then ION, but I also agree that long term it probably shouldn't
just be up to the dma-buf exporter (as there are other dmabuf
exporters that may have it wrong too), and that we need to address
some DMA API expectations/limitations to better handle multiple device
pipelines. (I actually gave a talk last fall on some of the issues I
see around it: https://youtu.be/UsEVoWD_o0c )

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


Re: [PATCH] staging: android: ion: Skip sync if not mapped

2020-04-14 Thread John Stultz
On Tue, Apr 14, 2020 at 7:28 AM Greg Kroah-Hartman
 wrote:
>
> On Tue, Apr 14, 2020 at 04:18:47PM +0200, Ørjan Eide wrote:
> > Only sync the sg-list of an Ion dma-buf attachment when the attachment
> > is actually mapped on the device.
> >
> > dma-bufs may be synced at any time. It can be reached from user space
> > via DMA_BUF_IOCTL_SYNC, so there are no guarantees from callers on when
> > syncs may be attempted, and dma_buf_end_cpu_access() and
> > dma_buf_begin_cpu_access() may not be paired.
> >
> > Since the sg_list's dma_address isn't set up until the buffer is used
> > on the device, and dma_map_sg() is called on it, the dma_address will be
> > NULL if sync is attempted on the dma-buf before it's mapped on a device.
> >
> > Before v5.0 (commit 55897af63091 ("dma-direct: merge swiotlb_dma_ops
> > into the dma_direct code")) this was a problem as the dma-api (at least
> > the swiotlb_dma_ops on arm64) would use the potentially invalid
> > dma_address. How that failed depended on how the device handled physical
> > address 0. If 0 was a valid address to physical ram, that page would get
> > flushed a lot, while the actual pages in the buffer would not get synced
> > correctly. While if 0 is an invalid physical address it may cause a
> > fault and trigger a crash.
> >
> > In v5.0 this was incidentally fixed by commit 55897af63091 ("dma-direct:
> > merge swiotlb_dma_ops into the dma_direct code"), as this moved the
> > dma-api to use the page pointer in the sg_list, and (for Ion buffers at
> > least) this will always be valid if the sg_list exists at all.
> >
> > But, this issue is re-introduced in v5.3 with
> > commit 449fa54d6815 ("dma-direct: correct the physical addr in
> > dma_direct_sync_sg_for_cpu/device") moves the dma-api back to the old
> > behaviour and picks the dma_address that may be invalid.
> >
> > dma-buf core doesn't ensure that the buffer is mapped on the device, and
> > thus have a valid sg_list, before calling the exporter's
> > begin_cpu_access.
> >
> > Signed-off-by: Ørjan Eide 
> > ---
> >  drivers/staging/android/ion/ion.c | 12 
> >  1 file changed, 12 insertions(+)
> >
> > Resubmit without disclaimer, sorry about that.
> >
> > This seems to be part of a bigger issue where dma-buf exporters assume
> > that their dma-buf begin_cpu_access and end_cpu_access callbacks have a
> > certain guaranteed behavior, which isn't ensured by dma-buf core.
> >
> > This patch fixes this in ion only, but it also needs to be fixed for
> > other exporters, either handled like this in each exporter, or in
> > dma-buf core before calling into the exporters.
> >
> > diff --git a/drivers/staging/android/ion/ion.c 
> > b/drivers/staging/android/ion/ion.c
> > index 38b51eace4f9..7b752ba0cb6d 100644
> > --- a/drivers/staging/android/ion/ion.c
> > +++ b/drivers/staging/android/ion/ion.c
>
> Now that we have the dma-buff stuff in the tree, do we even need the
> ion code in the kernel anymore?  Can't we delete it now?
>

I agree that we shouldn't be taking further (non-security/cleanup)
patches to the ION code.

I'd like to give developers a little bit of a transition period (I was
thinking a year, but really just one LTS release that has both would
do) where they can move their ION heaps over to dmabuf heaps and test
both against the same tree.

But I do think we can mark it as deprecated and let folks know that
around the end of the year it will be deleted.

That sound ok?

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


Re: [PATCH v11 1/2] dt-bindings: display/bridge: Add binding for NWL mipi dsi host controller

2020-04-14 Thread Laurent Pinchart
Hi Guido,

On Sun, Apr 12, 2020 at 06:38:35PM +0200, Guido Günther wrote:
> On Fri, Apr 10, 2020 at 03:57:32PM +0300, Laurent Pinchart wrote:
> > On Fri, Apr 10, 2020 at 02:45:16PM +0200, Guido Günther wrote:
> >> On Fri, Apr 10, 2020 at 02:23:42PM +0300, Laurent Pinchart wrote:
> >>> On Thu, Apr 09, 2020 at 12:42:01PM +0200, Guido Günther wrote:
>  The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
>  
>  Signed-off-by: Guido Günther 
>  Tested-by: Robert Chiras 
>  Reviewed-by: Rob Herring 
>  Acked-by: Sam Ravnborg 
>  Reviewed-by: Fabio Estevam 
>  ---
>   .../bindings/display/bridge/nwl-dsi.yaml  | 226 ++
>   1 file changed, 226 insertions(+)
>   create mode 100644 
>  Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
>  
>  diff --git 
>  a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml 
>  b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
>  new file mode 100644
>  index ..8aff2d68fc33
>  --- /dev/null
>  +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
>  @@ -0,0 +1,226 @@
>  +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>  +%YAML 1.2
>  +---
>  +$id: http://devicetree.org/schemas/display/bridge/nwl-dsi.yaml#
>  +$schema: http://devicetree.org/meta-schemas/core.yaml#
>  +
>  +title: Northwest Logic MIPI-DSI controller on i.MX SoCs
>  +
>  +maintainers:
>  +  - Guido Gúnther 
>  +  - Robert Chiras 
>  +
>  +description: |
>  +  NWL MIPI-DSI host controller found on i.MX8 platforms. This is a dsi 
>  bridge for
>  +  the SOCs NWL MIPI-DSI host controller.
>  +
>  +properties:
>  +  compatible:
>  +const: fsl,imx8mq-nwl-dsi
>  +
>  +  reg:
>  +maxItems: 1
>  +
>  +  interrupts:
>  +maxItems: 1
>  +
>  +  '#address-cells':
>  +const: 1
>  +
>  +  '#size-cells':
>  +const: 0
>  +
>  +  clocks:
>  +items:
>  +  - description: DSI core clock
>  +  - description: RX_ESC clock (used in escape mode)
>  +  - description: TX_ESC clock (used in escape mode)
>  +  - description: PHY_REF clock
>  +  - description: LCDIF clock
>  +
>  +  clock-names:
>  +items:
>  +  - const: core
>  +  - const: rx_esc
>  +  - const: tx_esc
>  +  - const: phy_ref
>  +  - const: lcdif
>  +
>  +  mux-controls:
>  +description:
>  +  mux controller node to use for operating the input mux
>  +
>  +  phys:
>  +maxItems: 1
>  +description:
>  +  A phandle to the phy module representing the DPHY
>  +
>  +  phy-names:
>  +items:
>  +  - const: dphy
>  +
>  +  power-domains:
>  +maxItems: 1
>  +
>  +  resets:
>  +items:
>  +  - description: dsi byte reset line
>  +  - description: dsi dpi reset line
>  +  - description: dsi esc reset line
>  +  - description: dsi pclk reset line
>  +
>  +  reset-names:
>  +items:
>  +  - const: byte
>  +  - const: dpi
>  +  - const: esc
>  +  - const: pclk
>  +
>  +  ports:
>  +type: object
>  +description:
>  +  A node containing DSI input & output port nodes with endpoint
>  +  definitions as documented in
>  +  Documentation/devicetree/bindings/graph.txt.
>  +properties:
>  +  port@0:
>  +type: object
>  +description:
>  +  Input port node to receive pixel data from the
>  +  display controller. Exactly one endpoint must be
>  +  specified.
>  +properties:
>  +  '#address-cells':
>  +const: 1
>  +
>  +  '#size-cells':
>  +const: 0
>  +
>  +  endpoint@0:
>  +description: sub-node describing the input from LCDIF
>  +type: object
>  +
>  +  endpoint@1:
>  +description: sub-node describing the input from DCSS
>  +type: object
> >>> 
> >>> This models the two inputs to the IP core, that are connected to a mux
> >>> internally, controlled through mux-controls, right ? Why is a single
> >>> endpoint supported then, if there are two connections at the hardware
> >>> level, and why is this using endpoints instead of ports as there are
> >>> really two input ports ?
> >> 
> >> That came out of
> >> 
> >> https://lore.kernel.org/linux-arm-kernel/c86b7ca2-7799-eafd-c380-e4b551520...@samsung.com/
> >> 
> >> # If the ip has separate lines for DCSS and LCDIF you should distinguish
> >> # by port number. If they are shared
> >> # you can use endpoint number to specify DCSS or LCDIF, in

linux-next: manual merge of the drm-misc tree with the drm-intel tree

2020-04-14 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/i915/display/intel_dp_mst.c

between commit:

  743acd115070 ("drm/i915: Get rid of silly void* from MST code")

from the drm-intel tree and commit:

  20c22ad32957 ("drm/dp_mst: Remove drm_dp_mst_has_audio()")

from the drm-misc tree.

I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.



-- 
Cheers,
Stephen Rothwell


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


linux-next: manual merge of the drm-misc tree with Linus' tree

2020-04-14 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  MAINTAINERS

between commitis:

  4400b7d68f6e ("MAINTAINERS: sort entries by entry name")
  3b50142d8528 ("MAINTAINERS: sort field names for all entries")

from Linus' tree and commits:

  8edb69970739 ("MAINTAINERS: Better regex for dma_buf|fence|resv")
  7fd9681e8fd0 ("MAINTAINERS: Update feiyang,st7701 panel bindings converted as 
YAML")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc MAINTAINERS
index c3cd17dbcb88,50b068f3580a..
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -5037,14 -5019,32 +5037,14 @@@ M:   Sumit Semwal 
 -R:Andrew F. Davis 
 -R:Benjamin Gaignard 
 -R:Liam Mark 
 -R:Laura Abbott 
 -R:Brian Starkey 
 -R:John Stultz 
 -S:Maintained
 -L:linux-me...@vger.kernel.org
 -L:dri-devel@lists.freedesktop.org
 -L:linaro-mm-...@lists.linaro.org (moderated for non-subscribers)
 -F:include/uapi/linux/dma-heap.h
 -F:include/linux/dma-heap.h
 -F:drivers/dma-buf/dma-heap.c
 -F:drivers/dma-buf/heaps/*
 -T:git git://anongit.freedesktop.org/drm/drm-misc
  
  DMA GENERIC OFFLOAD ENGINE SUBSYSTEM
  M:Vinod Koul 
@@@ -5301,8 -5272,8 +5301,8 @@@ F:  drivers/gpu/drm/panel/panel-feixin-k
  DRM DRIVER FOR FEIYANG FY07024DI26A30-D MIPI-DSI LCD PANELS
  M:Jagan Teki 
  S:Maintained
- F:
Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
 -F:drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
+ F:
Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml
 +F:drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
  
  DRM DRIVER FOR GRAIN MEDIA GM12U320 PROJECTORS
  M:Hans de Goede 
@@@ -5441,18 -5412,18 +5441,18 @@@ S:   Orphan / Obsolet
  F:drivers/gpu/drm/sis/
  F:include/uapi/drm/sis_drm.h
  
 -DRM DRIVER FOR SITRONIX ST7701 PANELS
 -M:Jagan Teki 
 -S:Maintained
 -F:drivers/gpu/drm/panel/panel-sitronix-st7701.c
 -F:Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
 -
  DRM DRIVER FOR SITRONIX ST7586 PANELS
  M:David Lechner 
 -T:git git://anongit.freedesktop.org/drm/drm-misc
  S:Maintained
 -F:drivers/gpu/drm/tiny/st7586.c
 +T:git git://anongit.freedesktop.org/drm/drm-misc
  F:Documentation/devicetree/bindings/display/sitronix,st7586.txt
 +F:drivers/gpu/drm/tiny/st7586.c
 +
 +DRM DRIVER FOR SITRONIX ST7701 PANELS
 +M:Jagan Teki 
 +S:Maintained
- F:Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt
++F:Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
 +F:drivers/gpu/drm/panel/panel-sitronix-st7701.c
  
  DRM DRIVER FOR SITRONIX ST7735R PANELS
  M:David Lechner 


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


[PATCH v15 0/3] mt8183 dpi support pin mode swap

2020-04-14 Thread Jitao Shi
Changes since v14:
 - add "Acked-by" and "Reviewed-by"
 - change port@0 to port in yaml

Changes since v13:
 - move dpi dual edge patches to another series because it will have long time
   to implement the dual edge change base boris patches.
   https://patchwork.kernel.org/cover/11354279/

Changes since v12:
 - fix mediatek,dpi.yaml make_dt_binding_check errors.

Change since v11:
 - fine tune mediatek,dpi.yaml.
 - add Acked-by: Rob Herring .

Change since v10:
 - convert the 
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
   to yaml format.
 - read the pclk-sample in endpoint.

Changes since v9:
 - rename pinctrl-names = "gpiomode", "dpimode" to "active", "idle".
 - fix some typo.

Changes since v8:
 - drop pclk-sample redefine in mediatek,dpi.txt
 - only get the gpiomode and dpimode when dpi->pinctrl is successful.

Changes since v7:
 - separate dt-bindings to independent patches.
 - move dpi dual edge to one patch.

Changes since v6:
 - change dual_edge to pclk-sample
 - remove dpi_pin_mode_swap and

Changes since v5:
 - fine tune the dt-bindings commit message.

Changes since v4:
 - move pin mode control and dual edge control to deveice tree.
 - update dt-bindings document for pin mode swap and dual edge control.

Changes since v3:
 - add dpi pin mode control when dpi on or off.
 - update dpi dual edge comment.

Changes since v2:
 - update dt-bindings document for mt8183 dpi.
 - separate dual edge modfication as independent patch.

Jitao Shi (3):
  dt-bindings: display: mediatek: control dpi pins mode to avoid leakage
  dt-bindings: display: mediatek: convert the document format from txt
to yaml
  drm/mediatek: set dpi pin mode to gpio low to avoid leakage current

 .../bindings/display/mediatek/mediatek,dpi.txt | 36 
 .../bindings/display/mediatek/mediatek,dpi.yaml| 97 ++
 drivers/gpu/drm/mediatek/mtk_dpi.c | 31 +++
 3 files changed, 128 insertions(+), 36 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml

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


[PATCH v15 2/3] dt-bindings: display: mediatek: convert the document format from txt to yaml

2020-04-14 Thread Jitao Shi
Signed-off-by: Jitao Shi 
---
 .../bindings/display/mediatek/mediatek,dpi.txt | 42 --
 .../bindings/display/mediatek/mediatek,dpi.yaml| 97 ++
 2 files changed, 97 insertions(+), 42 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
deleted file mode 100644
index 77def4456706..
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-Mediatek DPI Device
-===
-
-The Mediatek DPI function block is a sink of the display subsystem and
-provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a parallel
-output bus.
-
-Required properties:
-- compatible: "mediatek,-dpi"
-  the supported chips are mt2701 , mt8173 and mt8183.
-- reg: Physical base address and length of the controller's registers
-- interrupts: The interrupt signal from the function block.
-- clocks: device clocks
-  See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
-- clock-names: must contain "pixel", "engine", and "pll"
-- port: Output port node with endpoint definitions as described in
-  Documentation/devicetree/bindings/graph.txt. This port should be connected
-  to the input port of an attached HDMI or LVDS encoder chip.
-
-Optional properties:
-- pinctrl-names: Contain "default" and "sleep".
-
-Example:
-
-dpi0: dpi@1401d000 {
-   compatible = "mediatek,mt8173-dpi";
-   reg = <0 0x1401d000 0 0x1000>;
-   interrupts = ;
-   clocks = <&mmsys CLK_MM_DPI_PIXEL>,
-<&mmsys CLK_MM_DPI_ENGINE>,
-<&apmixedsys CLK_APMIXED_TVDPLL>;
-   clock-names = "pixel", "engine", "pll";
-   pinctrl-names = "default", "sleep";
-   pinctrl-0 = <&dpi_pin_func>;
-   pinctrl-1 = <&dpi_pin_idle>;
-
-   port {
-   dpi0_out: endpoint {
-   remote-endpoint = <&hdmi0_in>;
-   };
-   };
-};
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
new file mode 100644
index ..2c2d6a71cb8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
@@ -0,0 +1,97 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: mediatek DPI Controller Device Tree Bindings
+
+maintainers:
+  - CK Hu 
+  - Jitao shi 
+
+description: |
+  The Mediatek DPI function block is a sink of the display subsystem and
+  provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a parallel
+  output bus.
+
+properties:
+  compatible:
+enum:
+  - mediatek,mt2701-dpi
+  - mediatek,mt8173-dpi
+  - mediatek,mt8183-dpi
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: Pixel Clock
+  - description: Engine Clock
+  - description: DPI PLL
+
+  clock-names:
+items:
+  - const: pixel
+  - const: engine
+  - const: pll
+
+  pinctrl-0: true
+  pinctrl-1: true
+
+  pinctrl-names:
+items:
+  - const: default
+  - const: sleep
+
+  port:
+type: object
+description:
+  Output port node with endpoint definitions as described in
+  Documentation/devicetree/bindings/graph.txt. This port should be 
connected
+  to the input port of an attached HDMI or LVDS encoder chip.
+
+properties:
+  endpoint:
+type: object
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+#include 
+dpi0: dpi@1401d000 {
+compatible = "mediatek,mt8173-dpi";
+reg = <0 0x1401d000 0 0x1000>;
+interrupts = ;
+clocks = <&mmsys CLK_MM_DPI_PIXEL>,
+ <&mmsys CLK_MM_DPI_ENGINE>,
+ <&apmixedsys CLK_APMIXED_TVDPLL>;
+clock-names = "pixel", "engine", "pll";
+pinctrl-names = "default", "sleep";
+pinctrl-0 = <&dpi_pin_func>;
+pinctrl-1 = <&dpi_pin_idle>;
+
+port {
+dpi0_out: endpoint {
+remote-endpoint = <&hdmi0_in>;
+};
+};
+};
+
+...
-- 
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v15 1/3] dt-bindings: display: mediatek: control dpi pins mode to avoid leakage

2020-04-14 Thread Jitao Shi
Add property "pinctrl-names" to swap pin mode between gpio and dpi mode. Set
the dpi pins to gpio mode and output-low to avoid leakage current when dpi
disabled.

Acked-by: Rob Herring 
Reviewed-by: Chun-Kuang Hu 
Signed-off-by: Jitao Shi 
---
 Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
index 58914cf681b8..77def4456706 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
@@ -17,6 +17,9 @@ Required properties:
   Documentation/devicetree/bindings/graph.txt. This port should be connected
   to the input port of an attached HDMI or LVDS encoder chip.
 
+Optional properties:
+- pinctrl-names: Contain "default" and "sleep".
+
 Example:
 
 dpi0: dpi@1401d000 {
@@ -27,6 +30,9 @@ dpi0: dpi@1401d000 {
 <&mmsys CLK_MM_DPI_ENGINE>,
 <&apmixedsys CLK_APMIXED_TVDPLL>;
clock-names = "pixel", "engine", "pll";
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <&dpi_pin_func>;
+   pinctrl-1 = <&dpi_pin_idle>;
 
port {
dpi0_out: endpoint {
-- 
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v15 3/3] drm/mediatek: set dpi pin mode to gpio low to avoid leakage current

2020-04-14 Thread Jitao Shi
Config dpi pins mode to output and pull low when dpi is disabled.
Aovid leakage current from some dpi pins (Hsync Vsync DE ... ).

Reviewed-by: Chun-Kuang Hu 
Signed-off-by: Jitao Shi 
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 087f5ce732e1..1e01254788d9 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -10,7 +10,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 
@@ -74,6 +76,9 @@ struct mtk_dpi {
enum mtk_dpi_out_yc_map yc_map;
enum mtk_dpi_out_bit_num bit_num;
enum mtk_dpi_out_channel_swap channel_swap;
+   struct pinctrl *pinctrl;
+   struct pinctrl_state *pins_gpio;
+   struct pinctrl_state *pins_dpi;
int refcount;
 };
 
@@ -379,6 +384,9 @@ static void mtk_dpi_power_off(struct mtk_dpi *dpi)
if (--dpi->refcount != 0)
return;
 
+   if (dpi->pinctrl && dpi->pins_gpio)
+   pinctrl_select_state(dpi->pinctrl, dpi->pins_gpio);
+
mtk_dpi_disable(dpi);
clk_disable_unprepare(dpi->pixel_clk);
clk_disable_unprepare(dpi->engine_clk);
@@ -403,6 +411,9 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi)
goto err_pixel;
}
 
+   if (dpi->pinctrl && dpi->pins_dpi)
+   pinctrl_select_state(dpi->pinctrl, dpi->pins_dpi);
+
mtk_dpi_enable(dpi);
return 0;
 
@@ -705,6 +716,26 @@ static int mtk_dpi_probe(struct platform_device *pdev)
dpi->dev = dev;
dpi->conf = (struct mtk_dpi_conf *)of_device_get_match_data(dev);
 
+   dpi->pinctrl = devm_pinctrl_get(&pdev->dev);
+   if (IS_ERR(dpi->pinctrl)) {
+   dpi->pinctrl = NULL;
+   dev_dbg(&pdev->dev, "Cannot find pinctrl!\n");
+   }
+   if (dpi->pinctrl) {
+   dpi->pins_gpio = pinctrl_lookup_state(dpi->pinctrl, "sleep");
+   if (IS_ERR(dpi->pins_gpio)) {
+   dpi->pins_gpio = NULL;
+   dev_dbg(&pdev->dev, "Cannot find pinctrl idle!\n");
+   }
+   if (dpi->pins_gpio)
+   pinctrl_select_state(dpi->pinctrl, dpi->pins_gpio);
+
+   dpi->pins_dpi = pinctrl_lookup_state(dpi->pinctrl, "default");
+   if (IS_ERR(dpi->pins_dpi)) {
+   dpi->pins_dpi = NULL;
+   dev_dbg(&pdev->dev, "Cannot find pinctrl active!\n");
+   }
+   }
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dpi->regs = devm_ioremap_resource(dev, mem);
if (IS_ERR(dpi->regs)) {
-- 
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH/RFC 4/6] dt-bindings: display: rockchip: dw-hdmi: Convert binding to YAML

2020-04-14 Thread Laurent Pinchart
Hi Rob,

On Tue, Apr 14, 2020 at 06:10:05PM -0500, Rob Herring wrote:
> On Wed, Apr 08, 2020 at 02:45:52PM +0300, Laurent Pinchart wrote:
> > On Tue, Apr 07, 2020 at 09:12:51AM +0200, Maxime Ripard wrote:
> >> On Mon, Apr 06, 2020 at 08:50:28PM +0300, Laurent Pinchart wrote:
> >>> On Mon, Apr 06, 2020 at 07:09:15PM +0200, Maxime Ripard wrote:
>  On Mon, Apr 06, 2020 at 02:19:27PM +0300, Laurent Pinchart wrote:
> > On Mon, Apr 06, 2020 at 10:00:32AM +0200, Maxime Ripard wrote:
> >> On Mon, Apr 06, 2020 at 02:39:33AM +0300, Laurent Pinchart wrote:
> >>> Convert the Rockchip HDMI TX text binding to YAML.
> >>>
> >>> Signed-off-by: Laurent Pinchart 
> >>> 
> >>> ---
> >>>  .../display/rockchip/dw_hdmi-rockchip.txt |  74 
> >>>  .../display/rockchip/rockchip,dw-hdmi.yaml| 178 
> >>> ++
> >>>  2 files changed, 178 insertions(+), 74 deletions(-)
> >>>  delete mode 100644 
> >>> Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> >>>  create mode 100644 
> >>> Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> >>>
> >>> diff --git 
> >>> a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> >>>  
> >>> b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> >>> deleted file mode 100644
> >>> index 3d32ce137e7f..
> >>> --- 
> >>> a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> >>> +++ /dev/null
> >>> @@ -1,74 +0,0 @@
> >>> -Rockchip DWC HDMI TX Encoder
> >>> -
> >>> -
> >>> -The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller 
> >>> IP
> >>> -with a companion PHY IP.
> >>> -
> >>> -These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
> >>> -Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
> >>> -following device-specific properties.
> >>> -
> >>> -
> >>> -Required properties:
> >>> -
> >>> -- compatible: should be one of the following:
> >>> - "rockchip,rk3228-dw-hdmi"
> >>> - "rockchip,rk3288-dw-hdmi"
> >>> - "rockchip,rk3328-dw-hdmi"
> >>> - "rockchip,rk3399-dw-hdmi"
> >>> -- reg: See dw_hdmi.txt.
> >>> -- reg-io-width: See dw_hdmi.txt. Shall be 4.
> >>> -- interrupts: HDMI interrupt number
> >>> -- clocks: See dw_hdmi.txt.
> >>> -- clock-names: Shall contain "iahb" and "isfr" as defined in 
> >>> dw_hdmi.txt.
> >>> -- ports: See dw_hdmi.txt. The DWC HDMI shall have a single port 
> >>> numbered 0
> >>> -  corresponding to the video input of the controller. The port shall 
> >>> have two
> >>> -  endpoints, numbered 0 and 1, connected respectively to the vopb 
> >>> and vopl.
> >>> -- rockchip,grf: Shall reference the GRF to mux vopl/vopb.
> >>> -
> >>> -Optional properties
> >>> -
> >>> -- ddc-i2c-bus: The HDMI DDC bus can be connected to either a system 
> >>> I2C master
> >>> -  or the functionally-reduced I2C master contained in the DWC HDMI. 
> >>> When
> >>> -  connected to a system I2C master this property contains a phandle 
> >>> to that
> >>> -  I2C master controller.
> >>> -- clock-names: See dw_hdmi.txt. The "cec" clock is optional.
> >>> -- clock-names: May contain "cec" as defined in dw_hdmi.txt.
> >>> -- clock-names: May contain "grf", power for grf io.
> >>> -- clock-names: May contain "vpll", external clock for some hdmi phy.
> >>> -- phys: from general PHY binding: the phandle for the PHY device.
> >>> -- phy-names: Should be "hdmi" if phys references an external phy.
> >>> -
> >>> -Optional pinctrl entry:
> >>> -- If you have both a "unwedge" and "default" pinctrl entry, dw_hdmi
> >>> -  will switch to the unwedge pinctrl state for 10ms if it ever gets 
> >>> an
> >>> -  i2c timeout.  It's intended that this unwedge pinctrl entry will
> >>> -  cause the SDA line to be driven low to work around a hardware
> >>> -  errata.
> >>> -
> >>> -Example:
> >>> -
> >>> -hdmi: hdmi@ff98 {
> >>> - compatible = "rockchip,rk3288-dw-hdmi";
> >>> - reg = <0xff98 0x2>;
> >>> - reg-io-width = <4>;
> >>> - ddc-i2c-bus = <&i2c5>;
> >>> - rockchip,grf = <&grf>;
> >>> - interrupts = ;
> >>> - clocks = <&cru  PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>;
> >>> - clock-names = "iahb", "isfr";
> >>> - ports {
> >>> - hdmi_in: port {
> >>> - #address-cells = <1>;
> >>> - #size-cells = <0>;
> >>> - hdmi_in_vopb: endpoint@0 {
> >>> - reg = <0>;
> >>> - remote-endpoint = 

[PATCH v1.1 2/4] dt-bindings: display: bridge: Convert simple-bridge bindings to YAML

2020-04-14 Thread Laurent Pinchart
The simple-bridge driver supports multiple simple or dumb bridges,
covered by different compatible strings but otherwise identical DT
bindings. Some of those bridges have undocumented bindings, while others
are documented in text form in separate files. Group them all in a
single binding and convert it to YAML.

The psave-gpios property of the adi,adv7123 is dropped, as it isn't
supported by the driver and isn't specified in any DT file upstream.
Support for power saving is available through the enable-gpios property
that should cover all the needs of the ADV7123 (as the device only has a
/PSAVE pin and no enable pin).

Signed-off-by: Laurent Pinchart 
Acked-by: Maxime Ripard 
---
Changes since v1:

- Mention dropping psave-gpios in the commit message.
---
 .../bindings/display/bridge/adi,adv7123.txt   | 50 --
 .../bindings/display/bridge/dumb-vga-dac.txt  | 50 --
 .../display/bridge/simple-bridge.yaml | 99 +++
 .../bindings/display/bridge/ti,ths813x.txt| 51 --
 4 files changed, 99 insertions(+), 151 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt
 delete mode 100644 
Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
 delete mode 100644 
Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt
deleted file mode 100644
index a6b2b2b8f3d9..
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Analog Device ADV7123 Video DAC

-
-The ADV7123 is a digital-to-analog converter that outputs VGA signals from a
-parallel video input.
-
-Required properties:
-
-- compatible: Should be "adi,adv7123"
-
-Optional properties:
-
-- psave-gpios: Power save control GPIO
-
-Required nodes:
-
-The ADV7123 has two video ports. Their connections are modeled using the OF
-graph bindings specified in Documentation/devicetree/bindings/graph.txt.
-
-- Video port 0 for DPI input
-- Video port 1 for VGA output
-
-
-Example

-
-   adv7123: encoder@0 {
-   compatible = "adi,adv7123";
-
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   port@0 {
-   reg = <0>;
-
-   adv7123_in: endpoint@0 {
-   remote-endpoint = <&dpi_out>;
-   };
-   };
-
-   port@1 {
-   reg = <1>;
-
-   adv7123_out: endpoint@0 {
-   remote-endpoint = <&vga_connector_in>;
-   };
-   };
-   };
-   };
diff --git a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt 
b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
deleted file mode 100644
index 164cbb15f04c..
--- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Dumb RGB to VGA DAC bridge

-
-This binding is aimed for dumb RGB to VGA DAC based bridges that do not require
-any configuration.
-
-Required properties:
-
-- compatible: Must be "dumb-vga-dac"
-
-Required nodes:
-
-This device has two video ports. Their connections are modelled using the OF
-graph bindings specified in Documentation/devicetree/bindings/graph.txt.
-
-- Video port 0 for RGB input
-- Video port 1 for VGA output
-
-Optional properties:
-- vdd-supply: Power supply for DAC
-
-Example

-
-bridge {
-   compatible = "dumb-vga-dac";
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   port@0 {
-   reg = <0>;
-
-   vga_bridge_in: endpoint {
-   remote-endpoint = <&tcon0_out_vga>;
-   };
-   };
-
-   port@1 {
-   reg = <1>;
-
-   vga_bridge_out: endpoint {
-   remote-endpoint = <&vga_con_in>;
-   };
-   };
-   };
-};
diff --git 
a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml 
b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
new file mode 100644
index ..0880cbf217d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/d

Re: [PATCH 2/8] fs: extract simple_pin/release_fs to separate files

2020-04-14 Thread kbuild test robot
Hi Emanuele,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on char-misc/char-misc-testing]
[also build test ERROR on driver-core/driver-core-testing linus/master v5.7-rc1 
next-20200414]
[cannot apply to security/next-testing]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Emanuele-Giuseppe-Esposito/Simplefs-group-and-simplify-linux-fs-code/20200415-030834
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git 
885a64715fd81e6af6d94a038556e0b2e6deb19c
config: arm-mvebu_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=9.3.0 make.cross ARCH=arm 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   arm-linux-gnueabi-ld: fs/tracefs/inode.o: in function `remove_one':
>> inode.c:(.text+0x1c): undefined reference to `simple_release_fs'
   arm-linux-gnueabi-ld: fs/tracefs/inode.o: in function 
`start_creating.part.0':
   inode.c:(.text+0x454): undefined reference to `simple_release_fs'
   arm-linux-gnueabi-ld: fs/tracefs/inode.o: in function `__create_dir':
>> inode.c:(.text+0x55c): undefined reference to `simple_pin_fs'
>> arm-linux-gnueabi-ld: inode.c:(.text+0x640): undefined reference to 
>> `simple_release_fs'
   arm-linux-gnueabi-ld: fs/tracefs/inode.o: in function `tracefs_create_file':
   inode.c:(.text+0x690): undefined reference to `simple_pin_fs'
   arm-linux-gnueabi-ld: inode.c:(.text+0x75c): undefined reference to 
`simple_release_fs'
   arm-linux-gnueabi-ld: fs/tracefs/inode.o: in function `tracefs_remove':
   inode.c:(.text+0x79c): undefined reference to `simple_pin_fs'
   arm-linux-gnueabi-ld: inode.c:(.text+0x7c0): undefined reference to 
`simple_release_fs'

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/4] dt-bindings: display: bridge: Convert simple-bridge bindings to YAML

2020-04-14 Thread Laurent Pinchart
Hi Rob,

On Tue, Apr 14, 2020 at 05:00:00PM -0500, Rob Herring wrote:
> On Mon, Apr 06, 2020 at 02:23:16AM +0300, Laurent Pinchart wrote:
> > The simple-bridge driver supports multiple simple or dumb bridges,
> > covered by different compatible strings but otherwise identical DT
> > bindings. Some of those bridges have undocumented bindings, while others
> > are documented in text form in separate files. Group them all in a
> > single binding and convert it to YAML.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> >  .../bindings/display/bridge/adi,adv7123.txt   | 50 --
> >  .../bindings/display/bridge/dumb-vga-dac.txt  | 50 --
> >  .../display/bridge/simple-bridge.yaml | 99 +++
> >  .../bindings/display/bridge/ti,ths813x.txt| 51 --
> >  4 files changed, 99 insertions(+), 151 deletions(-)
> >  delete mode 100644 
> > Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt
> >  delete mode 100644 
> > Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
> >  delete mode 100644 
> > Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt 
> > b/Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt
> > deleted file mode 100644
> > index a6b2b2b8f3d9..
> > --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt
> > +++ /dev/null
> > @@ -1,50 +0,0 @@
> > -Analog Device ADV7123 Video DAC
> > 
> > -
> > -The ADV7123 is a digital-to-analog converter that outputs VGA signals from 
> > a
> > -parallel video input.
> > -
> > -Required properties:
> > -
> > -- compatible: Should be "adi,adv7123"
> > -
> > -Optional properties:
> > -
> > -- psave-gpios: Power save control GPIO
> 
> Not documented in the new schema. Did you intend to change to 
> 'enable-gpios'?

Oops, I forgot to mention that, my bad. The psave GPIO isn't supported
by the driver, and isn't used in any upstream DT files, so I thought it
would be safe to drop it, and add support it later (possibly through the
enable GPIO) if/when needed. I'll mention it in the commit message.

-- 
Regards,

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


Re: [PATCH] component: Silence bind error on -EPROBE_DEFER

2020-04-14 Thread James Hilliard
On Tue, Apr 14, 2020 at 5:07 AM Jani Nikula  wrote:
>
> On Fri, 10 Apr 2020, James Hilliard  wrote:
> > If a component fails to bind due to -EPROBE_DEFER we should not log an
> > error as this is not a real failure.
> >
> > Fixes:
> > vc4-drm soc:gpu: failed to bind 3f902000.hdmi (ops vc4_hdmi_ops): -517
> > vc4-drm soc:gpu: master bind failed: -517
>
> I'd think the probe defer is useful information anyway. Maybe just tone
> down the severity and/or the message?
That's probably not needed as there's dev_dbg logging for -EPROBE_DEFER
elsewhere from what it looks like.

For example:
https://github.com/torvalds/linux/blob/v5.6/drivers/base/dd.c#L621
>
> BR,
> Jani.
>
> >
> > Signed-off-by: James Hilliard 
> > ---
> >  drivers/base/component.c | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/base/component.c b/drivers/base/component.c
> > index e97704104784..157c6c790578 100644
> > --- a/drivers/base/component.c
> > +++ b/drivers/base/component.c
> > @@ -256,7 +256,8 @@ static int try_to_bring_up_master(struct master *master,
> >   ret = master->ops->bind(master->dev);
> >   if (ret < 0) {
> >   devres_release_group(master->dev, NULL);
> > - dev_info(master->dev, "master bind failed: %d\n", ret);
> > + if (ret != -EPROBE_DEFER)
> > + dev_info(master->dev, "master bind failed: %d\n", 
> > ret);
> >   return ret;
> >   }
> >
> > @@ -611,8 +612,10 @@ static int component_bind(struct component *component, 
> > struct master *master,
> >   devres_release_group(component->dev, NULL);
> >   devres_release_group(master->dev, NULL);
> >
> > - dev_err(master->dev, "failed to bind %s (ops %ps): %d\n",
> > - dev_name(component->dev), component->ops, ret);
> > + if (ret != -EPROBE_DEFER) {
> > + dev_err(master->dev, "failed to bind %s (ops %ps): 
> > %d\n",
> > + dev_name(component->dev), component->ops, 
> > ret);
> > + }
> >   }
> >
> >   return ret;
>
> --
> Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 1/2] DRM: ARC: add HDMI 2.0 TX encoder support

2020-04-14 Thread Eugeniy Paltsev
The Synopsys ARC SoCs (like HSDK4xD) include on-chip DesignWare HDMI
encoders. Support them with a platform driver to provide platform glue
data to the dw-hdmi driver.

Acked-by: Sam Ravnborg 
Signed-off-by: Eugeniy Paltsev 
---
 MAINTAINERS   |   6 ++
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/arc/Kconfig   |   7 ++
 drivers/gpu/drm/arc/Makefile  |   1 +
 drivers/gpu/drm/arc/arc-dw-hdmi.c | 116 ++
 5 files changed, 131 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/arc/arc-dw-hdmi.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a6fbdf354d34..2aaed1190370 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1258,6 +1258,12 @@ S:   Supported
 F: drivers/gpu/drm/arc/
 F: Documentation/devicetree/bindings/display/snps,arcpgu.txt
 
+ARC DW HDMI DRIVER
+M: Eugeniy Paltsev 
+S: Supported
+F: drivers/gpu/drm/arc/arc-dw-hdmi.c
+F: Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
+
 ARCNET NETWORK LAYER
 M: Michael Grzeschik 
 L: net...@vger.kernel.org
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 6493088a0fdd..5b0bcf7f45cd 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -109,7 +109,7 @@ obj-y   += panel/
 obj-y  += bridge/
 obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
 obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
-obj-$(CONFIG_DRM_ARCPGU)+= arc/
+obj-y  += arc/
 obj-y  += hisilicon/
 obj-$(CONFIG_DRM_ZTE)  += zte/
 obj-$(CONFIG_DRM_MXSFB)+= mxsfb/
diff --git a/drivers/gpu/drm/arc/Kconfig b/drivers/gpu/drm/arc/Kconfig
index e8f3d63e0b91..baec9d2a4fba 100644
--- a/drivers/gpu/drm/arc/Kconfig
+++ b/drivers/gpu/drm/arc/Kconfig
@@ -8,3 +8,10 @@ config DRM_ARCPGU
  Choose this option if you have an ARC PGU controller.
 
  If M is selected the module will be called arcpgu.
+
+config DRM_ARC_DW_HDMI
+   tristate "ARC DW HDMI"
+   depends on DRM && OF
+   select DRM_DW_HDMI
+   help
+ Synopsys DW HDMI driver for various ARC development boards
diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
index c7028b7427b3..7a156d8c2c3c 100644
--- a/drivers/gpu/drm/arc/Makefile
+++ b/drivers/gpu/drm/arc/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0-only
 arcpgu-y := arcpgu_crtc.o arcpgu_hdmi.o arcpgu_sim.o arcpgu_drv.o
 obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
+obj-$(CONFIG_DRM_ARC_DW_HDMI) += arc-dw-hdmi.o
diff --git a/drivers/gpu/drm/arc/arc-dw-hdmi.c 
b/drivers/gpu/drm/arc/arc-dw-hdmi.c
new file mode 100644
index ..46a6ee09b302
--- /dev/null
+++ b/drivers/gpu/drm/arc/arc-dw-hdmi.c
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Synopsys DW HDMI driver for various ARC development boards
+//
+// Copyright (C) 2020 Synopsys
+// Author: Eugeniy Paltsev 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct dw_hdmi_mpll_config snps_hdmi_mpll_cfg[] = {
+   {
+   2700, {
+   { 0x00B3, 0x },
+   { 0x00B3, 0x },
+   { 0x00B3, 0x }
+   },
+   }, {
+   7425, {
+   { 0x0072, 0x0001},
+   { 0x0072, 0x0001},
+   { 0x0072, 0x0001}
+   },
+   }, {
+   14850, {
+   { 0x0051, 0x0002},
+   { 0x0051, 0x0002},
+   { 0x0051, 0x0002}
+   },
+   }, {
+   ~0UL, {
+   { 0x00B3, 0x },
+   { 0x00B3, 0x },
+   { 0x00B3, 0x },
+   },
+   }
+};
+
+static const struct dw_hdmi_curr_ctrl snps_hdmi_cur_ctr[] = {
+   /* pixelclkbpp8bpp10   bpp12 */
+   { 2700,  { 0x, 0x, 0x }, },
+   { 7425,  { 0x0008, 0x0008, 0x0008 }, },
+   { 14850, { 0x001b, 0x001b, 0x001b }, },
+   { ~0UL,  { 0x, 0x, 0x }, }
+};
+
+
+static const struct dw_hdmi_phy_config snps_hdmi_phy_config[] = {
+   /* pixelclk   symbol  termvlev */
+   { 2700,   0x8009, 0x0004, 0x0232},
+   { 7425,   0x8009, 0x0004, 0x0232},
+   { 14850,  0x8009, 0x0004, 0x0232},
+   { ~0UL,   0x8009, 0x0004, 0x0232}
+};
+
+static struct dw_hdmi_plat_data snps_dw_hdmi_drv_data = {
+   .mpll_cfg   = snps_hdmi_mpll_cfg,
+   .cur_ctr= snps_hdmi_cur_ctr,
+   .phy_config = snps_hdmi_phy_config,
+};
+
+static const struct of_device_id snps_dw_hdmi_dt_ids[] = {
+   { .compatible = "snps,arc-dw-hdmi-hsdk", .data = &snps_dw_hdmi_drv_data 
},
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, snps_dw_hdmi_dt_ids);
+
+static int snps_dw_hdmi_probe(struct platform_device *pdev)
+{
+   const struct dw_hdmi_plat_

[PATCH v3 2/2] dt-bindings: Document the Synopsys ARC HDMI TX bindings

2020-04-14 Thread Eugeniy Paltsev
This patch adds documentation of device tree bindings for the Synopsys
HDMI 2.0 TX encoder driver for ARC SoCs.

Acked-by: Sam Ravnborg 
Signed-off-by: Eugeniy Paltsev 
---
 .../display/bridge/snps,arc-dw-hdmi.yaml  | 136 ++
 1 file changed, 136 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml 
b/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
new file mode 100644
index ..9b2fdfecd5b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/snps,arc-dw-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DesignWare HDMI 2.0 TX encoder driver
+
+maintainers:
+  - Eugeniy Paltsev 
+
+description: |
+  The HDMI transmitter is a Synopsys DesignWare HDMI 2.0 TX controller IP
+  with a companion of Synopsys DesignWare HDMI 2.0 TX PHY IP.
+
+  These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
+  Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
+  with the following device-specific properties.
+
+properties:
+  compatible:
+const: snps,arc-dw-hdmi-hsdk
+
+  reg:
+maxItems: 1
+description: |
+  Memory mapped base address and length of the DWC HDMI TX registers.
+
+  clocks:
+items:
+  - description: The bus clock for AHB / APB
+  - description: The internal register configuration clock
+
+  clock-names:
+items:
+  - const: iahb
+  - const: isfr
+
+  interrupts:
+maxItems: 1
+description: Reference to the DWC HDMI TX interrupt
+
+  reg-io-width:
+allOf:
+  - $ref: /schemas/types.yaml#/definitions/uint32
+  - enum: [1, 4]
+description: |
+  Width of the registers specified by the reg property. The
+  value is expressed in bytes and must be equal to 1 or 4 if specified.
+  The register width defaults to 1 if the property is not present.
+
+  ports:
+type: object
+description: |
+  A ports node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt
+
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  port@0:
+type: object
+description: |
+  Video input endpoints of the controller.
+  Usually it is associated with ARC PGU.
+
+  port@1:
+type: object
+description: |
+  Output endpoints of the controller. HDMI connector.
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - port@0
+  - port@1
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - interrupts
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+hdmi@1 {
+compatible = "snps,arc-dw-hdmi-hsdk";
+reg = <0x1 0x1>;
+reg-io-width = <4>;
+interrupts = <14>;
+clocks = <&apbclk>, <&hdmi_pix_clk>;
+clock-names = "iahb", "isfr";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+hdmi_enc_input: endpoint {
+remote-endpoint = <&pgu_output>;
+};
+};
+
+port@1 {
+reg = <1>;
+hdmi_enc_out: endpoint {
+remote-endpoint = <&hdmi_con>;
+};
+};
+};
+};
+
+hdmi-out {
+port {
+hdmi_con: endpoint {
+remote-endpoint = <&hdmi_enc_out>;
+};
+};
+};
+
+pgu {
+port_o: port {
+pgu_output: endpoint {
+remote-endpoint = <&hdmi_enc_input>;
+};
+};
+};
-- 
2.21.1

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


[PATCH v3 0/2] DRM: ARC: add HDMI 2.0 TX encoder support

2020-04-14 Thread Eugeniy Paltsev
Changes v1->v2:
 * use DT Schema format please (.yaml files) for DT bindings

Changes v2->v3:
 * Add missing 'interrupts' property in DT bindings
 * Drop dummy 'dw_hdmi_bridge_mode_valid'
 * Change bracing format of 'of_device_id' structure
 * Change compatible string to "snps,arc-dw-hdmi-hsdk"
   Now DT binding file is snps,arc-dw-hdmi.yaml and compatible is
   "snps,arc-dw-hdmi-"
 * Minor fixes

Eugeniy Paltsev (2):
  DRM: ARC: add HDMI 2.0 TX encoder support
  dt-bindings: Document the Synopsys ARC HDMI TX bindings

 .../display/bridge/snps,arc-dw-hdmi.yaml  | 136 ++
 MAINTAINERS   |   6 +
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/arc/Kconfig   |   7 +
 drivers/gpu/drm/arc/Makefile  |   1 +
 drivers/gpu/drm/arc/arc-dw-hdmi.c | 116 +++
 6 files changed, 267 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
 create mode 100644 drivers/gpu/drm/arc/arc-dw-hdmi.c

-- 
2.21.1

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


Re: [PATCH] drm/amd/display: Fix pageflip event race condition for DCN. (v2)

2020-04-14 Thread Matt Coffin
Hey everyone,

This patch broke variable refresh rate in games (all that I've tried so
far... Project CARS 2, DiRT Rally 2.0, Assetto Corsa Competizione) as
well as a simple freesync tester application.

FreeSync tester I've been using: https://github.com/Nixola/VRRTest

I'm not at all familiar with the page flipping code, so it would take me
a long time to find the *right* way to fix it, but does someone else see
why it would do that?

The symptom is that the refresh rate of the display constantly bounces
between the two ends of the FreeSync range (for me 40 -> 144), and the
game stutters like a madman.

Any help on where to start, ideas on how to fix it (other than just
revert this commit, which I've done in the interim), or alternative
patches would be appreciated.

Thanks in advance for the work/help,
Matt

On 3/13/20 8:42 AM, Michel Dänzer wrote:
> On 2020-03-13 1:35 p.m., Kazlauskas, Nicholas wrote:
>> On 2020-03-12 10:32 a.m., Alex Deucher wrote:
>>> On Thu, Mar 5, 2020 at 4:21 PM Mario Kleiner
>>>  wrote:

 Commit '16f17eda8bad ("drm/amd/display: Send vblank and user
 events at vsartup for DCN")' introduces a new way of pageflip
 completion handling for DCN, and some trouble.

 The current implementation introduces a race condition, which
 can cause pageflip completion events to be sent out one vblank
 too early, thereby confusing userspace and causing flicker:

 prepare_flip_isr():

 1. Pageflip programming takes the ddev->event_lock.
 2. Sets acrtc->pflip_status == AMDGPU_FLIP_SUBMITTED
 3. Releases ddev->event_lock.

 --> Deadline for surface address regs double-buffering passes on
  target pipe.

 4. dc_commit_updates_for_stream() MMIO programs the new pageflip
     into hw, but too late for current vblank.

 => pflip_status == AMDGPU_FLIP_SUBMITTED, but flip won't complete
     in current vblank due to missing the double-buffering deadline
     by a tiny bit.

 5. VSTARTUP trigger point in vblank is reached, VSTARTUP irq fires,
     dm_dcn_crtc_high_irq() gets called.

 6. Detects pflip_status == AMDGPU_FLIP_SUBMITTED and assumes the
     pageflip has been completed/will complete in this vblank and
     sends out pageflip completion event to userspace and resets
     pflip_status = AMDGPU_FLIP_NONE.

 => Flip completion event sent out one vblank too early.

 This behaviour has been observed during my testing with measurement
 hardware a couple of time.

 The commit message says that the extra flip event code was added to
 dm_dcn_crtc_high_irq() to prevent missing to send out pageflip events
 in case the pflip irq doesn't fire, because the "DCH HUBP" component
 is clock gated and doesn't fire pflip irqs in that state. Also that
 this clock gating may happen if no planes are active. According to
 Nicholas, the clock gating can also happen if psr is active, and the
 gating is controlled independently by the hardware, so difficult to
 detect if and when the completion code in above commit is needed.

 This patch tries the following solution: It only executes the extra
 pflip
 completion code in dm_dcn_crtc_high_irq() iff the hardware reports
 that there aren't any surface updated pending in the double-buffered
 surface scanout address registers. Otherwise it leaves pflip completion
 to the pflip irq handler, for a more race-free experience.

 This would only guard against the order of events mentioned above.
 If Step 5 (VSTARTUP trigger) happens before step 4 then this won't help
 at all, because 1-3 + 5 might happen even without the hw being
 programmed
 at all, ie. no surface update pending because none yet programmed
 into hw.

 Therefore this patch also changes locking in amdgpu_dm_commit_planes(),
 so that prepare_flip_isr() and dc_commit_updates_for_stream() are done
 under event_lock protection within the same critical section.

 v2: Take Nicholas comments into account, try a different solution.

 Lightly tested on Polaris (locking) and Raven (the whole DCN stuff).
 Seems to work without causing obvious new trouble.
>>>
>>> Nick, any comments on this?  Can we get this committed or do you think
>>> it needs additional rework?
>>>
>>> Thanks,
>>>
>>> Alex
>>
>> Hi Alex, Mario,
>>
>> This might be a little strange, but if we want to get this in as a fix
>> for regressions caused by the original vblank and user events at
>> vstartup patch then I'm actually going to give my reviewed by on the
>> *v1* of this patch (but not this v2):
>>
>> Reviewed-by: Nicholas Kazlauskas 
>>
>> You can feel free to apply that one.
>>
>> Reason 1: After having thought about it some more I don't think we
>> enable anything today that has hubp powered down at the same time we
>> expect to be waiting for a flip - eg. DMCU powering down HUBP 

Re: [PATCH/RFC 6/6] dt-bindings: display: bridge: Remove deprecated dw_hdmi.txt

2020-04-14 Thread Rob Herring
On Mon,  6 Apr 2020 02:39:35 +0300, Laurent Pinchart wrote:
> dw_hdmi.txt has been replaced with synopsys,dw-hdmi.yaml, and all
> references to the old file have been converted. Remove it.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  .../bindings/display/bridge/dw_hdmi.txt   | 33 ---
>  1 file changed, 33 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
> 

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


Re: [PATCH/RFC 5/6] dt-bindings: display: sun8i-a83t-dw-hdmi: Reference dw-hdmi YAML schema

2020-04-14 Thread Rob Herring
On Mon,  6 Apr 2020 02:39:34 +0300, Laurent Pinchart wrote:
> Replace the reference to the DWC HDMI text DT binding with a reference
> to the YAML equivalent.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  .../bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml| 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

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


Re: [PATCH/RFC 4/6] dt-bindings: display: rockchip: dw-hdmi: Convert binding to YAML

2020-04-14 Thread Rob Herring
On Wed, Apr 08, 2020 at 02:45:52PM +0300, Laurent Pinchart wrote:
> Hi Maxime,
> 
> On Tue, Apr 07, 2020 at 09:12:51AM +0200, Maxime Ripard wrote:
> > On Mon, Apr 06, 2020 at 08:50:28PM +0300, Laurent Pinchart wrote:
> > > On Mon, Apr 06, 2020 at 07:09:15PM +0200, Maxime Ripard wrote:
> > > > On Mon, Apr 06, 2020 at 02:19:27PM +0300, Laurent Pinchart wrote:
> > > > > On Mon, Apr 06, 2020 at 10:00:32AM +0200, Maxime Ripard wrote:
> > > > > > On Mon, Apr 06, 2020 at 02:39:33AM +0300, Laurent Pinchart wrote:
> > > > > > > Convert the Rockchip HDMI TX text binding to YAML.
> > > > > > >
> > > > > > > Signed-off-by: Laurent Pinchart 
> > > > > > > 
> > > > > > > ---
> > > > > > >  .../display/rockchip/dw_hdmi-rockchip.txt |  74 
> > > > > > >  .../display/rockchip/rockchip,dw-hdmi.yaml| 178 
> > > > > > > ++
> > > > > > >  2 files changed, 178 insertions(+), 74 deletions(-)
> > > > > > >  delete mode 100644 
> > > > > > > Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> > > > > > >  create mode 100644 
> > > > > > > Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> > > > > > >
> > > > > > > diff --git 
> > > > > > > a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> > > > > > >  
> > > > > > > b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> > > > > > > deleted file mode 100644
> > > > > > > index 3d32ce137e7f..
> > > > > > > --- 
> > > > > > > a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> > > > > > > +++ /dev/null
> > > > > > > @@ -1,74 +0,0 @@
> > > > > > > -Rockchip DWC HDMI TX Encoder
> > > > > > > -
> > > > > > > -
> > > > > > > -The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX 
> > > > > > > controller IP
> > > > > > > -with a companion PHY IP.
> > > > > > > -
> > > > > > > -These DT bindings follow the Synopsys DWC HDMI TX bindings 
> > > > > > > defined in
> > > > > > > -Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt 
> > > > > > > with the
> > > > > > > -following device-specific properties.
> > > > > > > -
> > > > > > > -
> > > > > > > -Required properties:
> > > > > > > -
> > > > > > > -- compatible: should be one of the following:
> > > > > > > - "rockchip,rk3228-dw-hdmi"
> > > > > > > - "rockchip,rk3288-dw-hdmi"
> > > > > > > - "rockchip,rk3328-dw-hdmi"
> > > > > > > - "rockchip,rk3399-dw-hdmi"
> > > > > > > -- reg: See dw_hdmi.txt.
> > > > > > > -- reg-io-width: See dw_hdmi.txt. Shall be 4.
> > > > > > > -- interrupts: HDMI interrupt number
> > > > > > > -- clocks: See dw_hdmi.txt.
> > > > > > > -- clock-names: Shall contain "iahb" and "isfr" as defined in 
> > > > > > > dw_hdmi.txt.
> > > > > > > -- ports: See dw_hdmi.txt. The DWC HDMI shall have a single port 
> > > > > > > numbered 0
> > > > > > > -  corresponding to the video input of the controller. The port 
> > > > > > > shall have two
> > > > > > > -  endpoints, numbered 0 and 1, connected respectively to the 
> > > > > > > vopb and vopl.
> > > > > > > -- rockchip,grf: Shall reference the GRF to mux vopl/vopb.
> > > > > > > -
> > > > > > > -Optional properties
> > > > > > > -
> > > > > > > -- ddc-i2c-bus: The HDMI DDC bus can be connected to either a 
> > > > > > > system I2C master
> > > > > > > -  or the functionally-reduced I2C master contained in the DWC 
> > > > > > > HDMI. When
> > > > > > > -  connected to a system I2C master this property contains a 
> > > > > > > phandle to that
> > > > > > > -  I2C master controller.
> > > > > > > -- clock-names: See dw_hdmi.txt. The "cec" clock is optional.
> > > > > > > -- clock-names: May contain "cec" as defined in dw_hdmi.txt.
> > > > > > > -- clock-names: May contain "grf", power for grf io.
> > > > > > > -- clock-names: May contain "vpll", external clock for some hdmi 
> > > > > > > phy.
> > > > > > > -- phys: from general PHY binding: the phandle for the PHY device.
> > > > > > > -- phy-names: Should be "hdmi" if phys references an external phy.
> > > > > > > -
> > > > > > > -Optional pinctrl entry:
> > > > > > > -- If you have both a "unwedge" and "default" pinctrl entry, 
> > > > > > > dw_hdmi
> > > > > > > -  will switch to the unwedge pinctrl state for 10ms if it ever 
> > > > > > > gets an
> > > > > > > -  i2c timeout.  It's intended that this unwedge pinctrl entry 
> > > > > > > will
> > > > > > > -  cause the SDA line to be driven low to work around a hardware
> > > > > > > -  errata.
> > > > > > > -
> > > > > > > -Example:
> > > > > > > -
> > > > > > > -hdmi: hdmi@ff98 {
> > > > > > > - compatible = "rockchip,rk3288-dw-hdmi";
> > > > > > > - reg = <0xff98 0x2>;
> > > > > > > - reg-io-width = <4>;
> > > > > > > - ddc-i2c-bus = <&i2c5>;
> > > > > > > - rockchip,grf = <&grf>;
> > > > > > > - interrupts = ;
> > > > > > > - clocks = <&cru  PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>;
> > > > > > > - clock-names = "iahb", "is

Re: [PATCH 3/4] dt-bindings: display: bridge: thc63lvd1024: Convert binding to YAML

2020-04-14 Thread Rob Herring
On Mon,  6 Apr 2020 02:23:17 +0300, Laurent Pinchart wrote:
> Convert the Thine THC63LVD1024 text binding to YAML.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  .../display/bridge/thine,thc63lvd1024.txt |  66 --
>  .../display/bridge/thine,thc63lvd1024.yaml| 121 ++
>  2 files changed, 121 insertions(+), 66 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml
> 

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


Re: [PATCH 2/4] dt-bindings: display: bridge: Convert simple-bridge bindings to YAML

2020-04-14 Thread Rob Herring
On Mon, Apr 06, 2020 at 02:23:16AM +0300, Laurent Pinchart wrote:
> The simple-bridge driver supports multiple simple or dumb bridges,
> covered by different compatible strings but otherwise identical DT
> bindings. Some of those bridges have undocumented bindings, while others
> are documented in text form in separate files. Group them all in a
> single binding and convert it to YAML.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  .../bindings/display/bridge/adi,adv7123.txt   | 50 --
>  .../bindings/display/bridge/dumb-vga-dac.txt  | 50 --
>  .../display/bridge/simple-bridge.yaml | 99 +++
>  .../bindings/display/bridge/ti,ths813x.txt| 51 --
>  4 files changed, 99 insertions(+), 151 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt
>  delete mode 100644 
> Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
>  delete mode 100644 
> Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt 
> b/Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt
> deleted file mode 100644
> index a6b2b2b8f3d9..
> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt
> +++ /dev/null
> @@ -1,50 +0,0 @@
> -Analog Device ADV7123 Video DAC
> 
> -
> -The ADV7123 is a digital-to-analog converter that outputs VGA signals from a
> -parallel video input.
> -
> -Required properties:
> -
> -- compatible: Should be "adi,adv7123"
> -
> -Optional properties:
> -
> -- psave-gpios: Power save control GPIO

Not documented in the new schema. Did you intend to change to 
'enable-gpios'?

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


Re: [PATCH 1/4] dt-bindings: display: bridge: Reject additional properties in ports node

2020-04-14 Thread Rob Herring
On Mon,  6 Apr 2020 02:23:15 +0300, Laurent Pinchart wrote:
> Document the #address-cells and #size-cells properties of the ports node
> in the schemas of the bridge DT bindings, and set additionalProperties
> to false to reject additional properties.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  .../devicetree/bindings/display/bridge/anx6345.yaml   | 8 
>  .../devicetree/bindings/display/bridge/lvds-codec.yaml| 8 
>  .../devicetree/bindings/display/bridge/ps8640.yaml| 8 
>  3 files changed, 24 insertions(+)
> 

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


Re: [PATCH v2 2/2] dt-bindings: Document the Synopsys ARC HDMI TX bindings

2020-04-14 Thread Rob Herring
On Tue, 14 Apr 2020 17:44:02 +0300, Eugeniy Paltsev wrote:
> This patch adds documentation of device tree bindings for the Synopsys
> HDMI 2.0 TX encoder driver for ARC SoCs.
> 
> Signed-off-by: Eugeniy Paltsev 
> ---
>  .../display/bridge/snps,arc-dw-hdmi.yaml  | 131 ++
>  1 file changed, 131 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.example.dt.yaml:
 example-0: 'hdmi@0x1' does not match any of the regexes: '.*-names$', 
'.*-supply$', '^#.*-cells$', '^#[a-zA-Z0-9,+\\-._]{0,63}$', 
'^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}$', 
'^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-fA-F]+(,[0-9a-fA-F]+)*$', '^__.*__$', 
'pinctrl-[0-9]+'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.example.dt.yaml:
 hdmi@0x1: 'interrupts' does not match any of the regexes: 'pinctrl-[0-9]+'

See https://patchwork.ozlabs.org/patch/1270389

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master 
--upgrade

Please check and re-submit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 5/5] drm/i915: Replace "Broadcast RGB" with "RGB quantization range" property

2020-04-14 Thread Yussuf Khalil
On Tue, 2020-04-14 at 14:34 +0200, Daniel Vetter wrote:
> On Tue, Apr 14, 2020 at 02:21:06PM +0300, Jani Nikula wrote:
> > On Tue, 14 Apr 2020, Jani Nikula 
> > wrote:
> > > On Mon, 13 Apr 2020, Simon Ser  wrote:
> > > > On Monday, April 13, 2020 11:40 PM, Yussuf Khalil <
> > > > d...@pp3345.net> wrote:
> > > > 
> > > > > DRM now has a globally available "RGB quantization range"
> > > > > connector
> > > > > property. i915's "Broadcast RGB" that fulfils the same
> > > > > purpose is now
> > > > > considered deprecated, so drop it in favor of the DRM
> > > > > property.
> > > > 
> > > > For a UAPI point-of-view, I'm not sure this is fine. Some user-
> > > > space
> > > > might depend on this property, dropping it would break such
> > > > user-space.
> > > 
> > > Agreed.
> > > 
> > > > Can we make this property deprecated but still keep it for
> > > > backwards
> > > > compatibility?
> > > 
> > > Would be nice to make the i915 specific property an "alias" for
> > > the new
> > > property, however I'm not sure how you'd make that happen.
> > > Otherwise
> > > juggling between the two properties is going to be a nightmare.
> > 
> > Ah, the obvious easy choice is to use the property and enum names
> > already being used by i915 and gma500, and you have no problem.
> > Perhaps
> > they're not the names you'd like, but then looking at the total
> > lack of
> > consistency across property naming makes them fit right in. ;)
> 
> Yeah if we don't have contradictory usage across drivers when
> modernizing
> these properties, then let's just stick with the names already there.
> It's
> not pretty, but works better since more userspace/internet howtos
> know how
> to use this stuff.
> -Daniel

Note that i915's "Broadcast RGB" isn't the same as gma500's: i915 has an
"Automatic" option, whereas gma500 does not. Also, radeon has a property called
"output_csc" that fulfills a similar purpose. Looking at the code, though, it
seems that radeon does not adhere to the standard correctly (or I am missing
something).

An alternative would be to leave the existing driver-specific properties and
change them to be pseudo-aliases for the "RGB quantization range" property.
This can be done by letting the drivers read from and write to the new property
when user-space tries to read or modify the driver's property. This way we could
retain full backwards compatibility for all drivers equally.

What do you think?

Regards
Yussuf

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


Re: [RFC 5/6] drm/rcar-du: fix selection of CMM driver

2020-04-14 Thread Arnd Bergmann
On Tue, Apr 14, 2020 at 10:52 PM Laurent Pinchart
 wrote:
>
> Hi Arnd,
>
> On Tue, Apr 14, 2020 at 10:38:27PM +0200, Arnd Bergmann wrote:
> > On Tue, Apr 14, 2020 at 10:17 PM Laurent Pinchart wrote:
> > > On Wed, Apr 08, 2020 at 10:27:10PM +0200, Arnd Bergmann wrote:
> > > > The 'imply' statement does not seem to have an effect, as it's
> > > > still possible to turn the CMM code into a loadable module
> > > > in a randconfig build, leading to a link error:
> > > >
> > > > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in 
> > > > function `rcar_du_crtc_atomic_enable':
> > > > rcar_du_crtc.c:(.text+0xad4): undefined reference to 
> > > > `rcar_lvds_clk_enable'
> > > > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in 
> > > > function `rcar_du_crtc_atomic_disable':
> > > > rcar_du_crtc.c:(.text+0xd7c): undefined reference to 
> > > > `rcar_lvds_clk_disable'
> > > > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_drv.o: in 
> > > > function `rcar_du_init':
> > > > rcar_du_drv.c:(.init.text+0x4): undefined reference to `rcar_du_of_init'
> > > > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_encoder.o: in 
> > > > function `rcar_du_encoder_init':
> > > >
> > > > Remove the 'imply', and instead use a silent symbol that defaults
> > > > to the correct setting.
> > >
> > > This will result in the CMM always being selected when DU is, increasing
> > > the kernel size even for devices that don't need it. I believe we need a
> > > better construct in Kconfig to fix this.
> >
> > I had expected this to have the same meaning that we had before the
> > Kconfig change: whenever the dependencies are available, turn it on,
> > otherwise leave it disabled.
> >
> > Can you describe what behavior you actually want instead?
>
> Doesn't "imply" mean it gets selected by default but can be manually
> disabled ?

That may be what it means now (I still don't understand how it's defined
as of v5.7-rc1), but traditionally it was more like a 'select if all
dependencies
are met'.

> > > > --- a/drivers/gpu/drm/rcar-du/Kconfig
> > > > +++ b/drivers/gpu/drm/rcar-du/Kconfig
> > > > @@ -4,7 +4,6 @@ config DRM_RCAR_DU
> > > >   depends on DRM && OF
> > > >   depends on ARM || ARM64
> > > >   depends on ARCH_RENESAS || COMPILE_TEST
> > > > - imply DRM_RCAR_CMM
> > > >   imply DRM_RCAR_LVDS
> > > >   select DRM_KMS_HELPER
> > > >   select DRM_KMS_CMA_HELPER
> > > > @@ -15,9 +14,8 @@ config DRM_RCAR_DU
> > > > If M is selected the module will be called rcar-du-drm.
> > > >
> > > >  config DRM_RCAR_CMM
> > > > - tristate "R-Car DU Color Management Module (CMM) Support"
> > > > + def_tristate DRM_RCAR_DU
> > > >   depends on DRM && OF
> > > > - depends on DRM_RCAR_DU
> > > >   help
> >
> > It would be easy enough to make this a visible 'bool' symbol and
> > build it into the rcu-du-drm.ko module itself. Would that help you?
>
> That could indeed simplify a few things. I wonder if it could introduce
> a few small issues though (but likely nothing we can't fix). The two
> that come to mind are the fact that the module would have two
> MODULE_DESCRIPTION and MODULE_LICENSE entries (I have no idea if that
> could cause breakages), and that it could make module unloading more
> difficult as the CMM being used by the DU would increase the refcount on
> the module. I think the latter could be worked around by manually
> unbinding the DU device through sysfs before unloading the module (and I
> can't say for sure that unloading the DU module is not broken today
> *innocent and naive look* :-)).

In that case, a Makefile trick could also work, doing

ifdef CONFIG_DRM_RCAR_CMM
obj-$(CONFIG_DRM_RCAR_DU) += rcar-cmm.o
endif

Thereby making the cmm module have the same state (y or m) as
the du module whenever the option is enabled.

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


Re: [RFC 5/6] drm/rcar-du: fix selection of CMM driver

2020-04-14 Thread Laurent Pinchart
Hi Arnd,

On Tue, Apr 14, 2020 at 10:38:27PM +0200, Arnd Bergmann wrote:
> On Tue, Apr 14, 2020 at 10:17 PM Laurent Pinchart wrote:
> > On Wed, Apr 08, 2020 at 10:27:10PM +0200, Arnd Bergmann wrote:
> > > The 'imply' statement does not seem to have an effect, as it's
> > > still possible to turn the CMM code into a loadable module
> > > in a randconfig build, leading to a link error:
> > >
> > > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function 
> > > `rcar_du_crtc_atomic_enable':
> > > rcar_du_crtc.c:(.text+0xad4): undefined reference to 
> > > `rcar_lvds_clk_enable'
> > > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function 
> > > `rcar_du_crtc_atomic_disable':
> > > rcar_du_crtc.c:(.text+0xd7c): undefined reference to 
> > > `rcar_lvds_clk_disable'
> > > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_drv.o: in function 
> > > `rcar_du_init':
> > > rcar_du_drv.c:(.init.text+0x4): undefined reference to `rcar_du_of_init'
> > > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_encoder.o: in 
> > > function `rcar_du_encoder_init':
> > >
> > > Remove the 'imply', and instead use a silent symbol that defaults
> > > to the correct setting.
> >
> > This will result in the CMM always being selected when DU is, increasing
> > the kernel size even for devices that don't need it. I believe we need a
> > better construct in Kconfig to fix this.
> 
> I had expected this to have the same meaning that we had before the
> Kconfig change: whenever the dependencies are available, turn it on,
> otherwise leave it disabled.
> 
> Can you describe what behavior you actually want instead?

Doesn't "imply" mean it gets selected by default but can be manually
disabled ?

> > > --- a/drivers/gpu/drm/rcar-du/Kconfig
> > > +++ b/drivers/gpu/drm/rcar-du/Kconfig
> > > @@ -4,7 +4,6 @@ config DRM_RCAR_DU
> > >   depends on DRM && OF
> > >   depends on ARM || ARM64
> > >   depends on ARCH_RENESAS || COMPILE_TEST
> > > - imply DRM_RCAR_CMM
> > >   imply DRM_RCAR_LVDS
> > >   select DRM_KMS_HELPER
> > >   select DRM_KMS_CMA_HELPER
> > > @@ -15,9 +14,8 @@ config DRM_RCAR_DU
> > > If M is selected the module will be called rcar-du-drm.
> > >
> > >  config DRM_RCAR_CMM
> > > - tristate "R-Car DU Color Management Module (CMM) Support"
> > > + def_tristate DRM_RCAR_DU
> > >   depends on DRM && OF
> > > - depends on DRM_RCAR_DU
> > >   help
> 
> It would be easy enough to make this a visible 'bool' symbol and
> build it into the rcu-du-drm.ko module itself. Would that help you?

That could indeed simplify a few things. I wonder if it could introduce
a few small issues though (but likely nothing we can't fix). The two
that come to mind are the fact that the module would have two
MODULE_DESCRIPTION and MODULE_LICENSE entries (I have no idea if that
could cause breakages), and that it could make module unloading more
difficult as the CMM being used by the DU would increase the refcount on
the module. I think the latter could be worked around by manually
unbinding the DU device through sysfs before unloading the module (and I
can't say for sure that unloading the DU module is not broken today
*innocent and naive look* :-)).

-- 
Regards,

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


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

2020-04-14 Thread Laurent Pinchart
Hi Adrian,

Thank you for the patch.

On Tue, Apr 14, 2020 at 06:19:52PM +0300, Adrian Ratiu wrote:
> 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: Fabio Estevam 
> Cc: devicet...@vger.kernel.org
> Tested-by: Adrian Pop 
> Tested-by: Arnaud Ferraris 
> Signed-off-by: Sjoerd Simons 
> Signed-off-by: Martyn Welch 
> Signed-off-by: Adrian Ratiu 
> ---
> Changes since v5:
>   - Fixed missing reg warning (Fabio)
>   - Updated dt-schema and fixed warnings (Rob)
> 
> 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| 139 ++
>  1 file changed, 139 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 ..10e289ea219a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
> @@ -0,0 +1,139 @@
> +# 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.

Not necessarily a prerequisite for this patch, but it would be nice to
get that converted to yaml, and included here with

allOf:
  $ref: ../bridge/snps,dw-mipi-dsi.yaml#

(assuming that's how the file will be called).

> +
> +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.

Could you please wrap liens at a 80 columns boundary ?

> +$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:

You should add

   '#address-cells':
 const: 1

   '#size-cells':
 const: 0

> +  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"


Should this be "RGB output port node" ? And s/"/./

And here you should add

   additionalProperties: false

> +
> +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)

Does this belong here ? I think the port property for the panel needs to
be described in the panel's binding instead.

> +
> +  "#address-cells":
> +const: 1
> +
> +  "#size-cells":
> +const: 0

These two properties are not pattern properties, right ? Should they be
listed under the properties above ?

> +
> +required:
> +  - "#address-cells"
> +  - "#size-cells"
> +  - compatible
> +  - reg
> +  - interrupts
> +  - clocks
> +  - clock-names
> +  - ports
> +
> +additionalProperties: false
> +
> +examples:
> +  - |+
> +#include 
> +#include 
> +#include 

Alphabetical order ?

> +
> +dsi: dsi@21e {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +compatible = "fsl,imx6q-mipi-dsi", "snps,dw-mipi-dsi";
>

Re: [RFC 5/6] drm/rcar-du: fix selection of CMM driver

2020-04-14 Thread Arnd Bergmann
On Tue, Apr 14, 2020 at 10:17 PM Laurent Pinchart
 wrote:
>
> Hi Arnd,
>
> Thank you for the patch.
>
> On Wed, Apr 08, 2020 at 10:27:10PM +0200, Arnd Bergmann wrote:
> > The 'imply' statement does not seem to have an effect, as it's
> > still possible to turn the CMM code into a loadable module
> > in a randconfig build, leading to a link error:
> >
> > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function 
> > `rcar_du_crtc_atomic_enable':
> > rcar_du_crtc.c:(.text+0xad4): undefined reference to `rcar_lvds_clk_enable'
> > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function 
> > `rcar_du_crtc_atomic_disable':
> > rcar_du_crtc.c:(.text+0xd7c): undefined reference to `rcar_lvds_clk_disable'
> > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_drv.o: in function 
> > `rcar_du_init':
> > rcar_du_drv.c:(.init.text+0x4): undefined reference to `rcar_du_of_init'
> > arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_encoder.o: in 
> > function `rcar_du_encoder_init':
> >
> > Remove the 'imply', and instead use a silent symbol that defaults
> > to the correct setting.
>
> This will result in the CMM always being selected when DU is, increasing
> the kernel size even for devices that don't need it. I believe we need a
> better construct in Kconfig to fix this.

I had expected this to have the same meaning that we had before the
Kconfig change: whenever the dependencies are available, turn it on,
otherwise leave it disabled.

Can you describe what behavior you actually want instead?
> > --- a/drivers/gpu/drm/rcar-du/Kconfig
> > +++ b/drivers/gpu/drm/rcar-du/Kconfig
> > @@ -4,7 +4,6 @@ config DRM_RCAR_DU
> >   depends on DRM && OF
> >   depends on ARM || ARM64
> >   depends on ARCH_RENESAS || COMPILE_TEST
> > - imply DRM_RCAR_CMM
> >   imply DRM_RCAR_LVDS
> >   select DRM_KMS_HELPER
> >   select DRM_KMS_CMA_HELPER
> > @@ -15,9 +14,8 @@ config DRM_RCAR_DU
> > If M is selected the module will be called rcar-du-drm.
> >
> >  config DRM_RCAR_CMM
> > - tristate "R-Car DU Color Management Module (CMM) Support"
> > + def_tristate DRM_RCAR_DU
> >   depends on DRM && OF
> > - depends on DRM_RCAR_DU
> >   help

It would be easy enough to make this a visible 'bool' symbol and
build it into the rcu-du-drm.ko module itself. Would that help you?

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


Re: [RFC 5/6] drm/rcar-du: fix selection of CMM driver

2020-04-14 Thread Laurent Pinchart
Hi Arnd,

Thank you for the patch.

On Wed, Apr 08, 2020 at 10:27:10PM +0200, Arnd Bergmann wrote:
> The 'imply' statement does not seem to have an effect, as it's
> still possible to turn the CMM code into a loadable module
> in a randconfig build, leading to a link error:
> 
> arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function 
> `rcar_du_crtc_atomic_enable':
> rcar_du_crtc.c:(.text+0xad4): undefined reference to `rcar_lvds_clk_enable'
> arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function 
> `rcar_du_crtc_atomic_disable':
> rcar_du_crtc.c:(.text+0xd7c): undefined reference to `rcar_lvds_clk_disable'
> arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_drv.o: in function 
> `rcar_du_init':
> rcar_du_drv.c:(.init.text+0x4): undefined reference to `rcar_du_of_init'
> arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_encoder.o: in function 
> `rcar_du_encoder_init':
> 
> Remove the 'imply', and instead use a silent symbol that defaults
> to the correct setting.

This will result in the CMM always being selected when DU is, increasing
the kernel size even for devices that don't need it. I believe we need a
better construct in Kconfig to fix this.

> Fixes: e08e934d6c28 ("drm: rcar-du: Add support for CMM")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/rcar-du/Kconfig | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> index 0919f1f159a4..5e35f5934d62 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -4,7 +4,6 @@ config DRM_RCAR_DU
>   depends on DRM && OF
>   depends on ARM || ARM64
>   depends on ARCH_RENESAS || COMPILE_TEST
> - imply DRM_RCAR_CMM
>   imply DRM_RCAR_LVDS
>   select DRM_KMS_HELPER
>   select DRM_KMS_CMA_HELPER
> @@ -15,9 +14,8 @@ config DRM_RCAR_DU
> If M is selected the module will be called rcar-du-drm.
>  
>  config DRM_RCAR_CMM
> - tristate "R-Car DU Color Management Module (CMM) Support"
> + def_tristate DRM_RCAR_DU
>   depends on DRM && OF
> - depends on DRM_RCAR_DU
>   help
> Enable support for R-Car Color Management Module (CMM).
>  

-- 
Regards,

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


Re: [PATCH v1 3/4] dt-bindings: media: add wiring property to video-interfaces

2020-04-14 Thread Rob Herring
On Sun, Apr 12, 2020 at 08:20:11PM +0200, Sam Ravnborg wrote:
> The wiring property is used to describe the wiring between
> the connector and the panel. The property can be used when the
> wiring is used to change the mode from for example
> BGR to RGB. The first users are the at91sam9 family where
> such a wiring trick is sometimes used.
> The possilbe values are so far limited to what is required
> by the at91sam9 family, but using "text" allows us to extend
> this in the future.
> 
> There exists similar properties today:
>  - display/tilcdc/tilcdc.txt: blue-and-red-wiring
>  - display/atmel,lcdc.txt: atmel,lcd-wiring-mode
> 
> Neither of the above are defined as endpoint properties.
> 
> The new property "wiring" has a more general name and
> is defined as an endpoint property.
> It will replace atmel,lcd-wiring-mode and may replace
> blue-and-red-wiring.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Mauro Carvalho Chehab 
> Cc: Rob Herring 
> Cc: Hans Verkuil 
> Cc: linux-me...@vger.kernel.org
> ---
>  Documentation/devicetree/bindings/media/video-interfaces.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt 
> b/Documentation/devicetree/bindings/media/video-interfaces.txt
> index f884ada0bffc..c3bb87c5c9a9 100644
> --- a/Documentation/devicetree/bindings/media/video-interfaces.txt
> +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
> @@ -141,6 +141,9 @@ Optional endpoint properties
>  - link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for
>instance, this is the actual frequency of the bus, not bits per clock per
>lane value. An array of 64-bit unsigned integers.
> +- wiring: Wiring of data lines to display.
> +  "straight" - normal wiring.

Don't really need a property to express this...

> +  "red-blue-reversed" - red and blue lines reversed.

For a common property, I think this needs to be looked at in terms of 
formats and some of the format negotiation work Boris was doing.

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


Re: [PATCH v1 4/4] dt-bindings: display: add port support to atmel lcdc

2020-04-14 Thread Rob Herring
On Sun, Apr 12, 2020 at 08:20:12PM +0200, Sam Ravnborg wrote:
> Update the Atmel LCDC binding to include:
> - pwm. Used for backlight
> - endpoints using port node
>   Used for handle to panel
> - Added wiring property that is used to describe
>   the wiring between the LCDC and the panel
> 
> Existing properties that should not be used in new
> bindings are deprecated.
> 
> Updated example to include the updated way to specify panel etc.
> 
> Signed-off-by: Sam Ravnborg 
> ---
>  .../bindings/display/atmel/lcdc.yaml  | 94 ++-
>  1 file changed, 93 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/atmel/lcdc.yaml 
> b/Documentation/devicetree/bindings/display/atmel/lcdc.yaml
> index 7dcb9a4d5902..b5c2628f7805 100644
> --- a/Documentation/devicetree/bindings/display/atmel/lcdc.yaml
> +++ b/Documentation/devicetree/bindings/display/atmel/lcdc.yaml
> @@ -28,6 +28,7 @@ properties:
>  
>"#address-cells":
>  const: 1
> +
>"#size-cells":
>  const: 0
>  
> @@ -43,13 +44,84 @@ properties:
>lcd-supply:
>  description: Regulator for LCD supply voltage.
>  
> +  "#pwm-cells":
> +description:
> +  This PWM chip use the default 3 cells bindings
> +  defined in ../../pwm/pwm.yaml.
> +const: 3
> +
> +  clocks:
> +maxItems: 2
> +
> +  clock-names:
> +maxItems: 2
> +items:
> +  - const: lcdc_clk
> +  - const: hclk
> +
> +  port@0:

Just 'port' if there's only 1.

> +type: object
> +description: Endpoints of the display controller
> +
> +properties:
> +
> +  reg:
> +const: 0
> +
> +  "#address-cells":
> +const: 1
> +
> +  "#size-cells":
> +const: 0
> +
> +  endpoint@0:

Just 'endpoint' if there's only 1.

> +type: object
> +description: endpoint node that include phandle to panel
> +
> +properties:
> +
> +  reg:
> +const: 0
> +
> +  wiring:
> +enum:
> +  - straight
> +  - red-blue-reversed
> +description: |
> +  The LCDC is based on a blue-green-red configuration but to 
> adapt
> +  to SW only supporting red-green-blue the data lines for red 
> and blue
> +  may be reversed.
> +  See details in: 
> http://ww1.microchip.com/downloads/en/AppNotes/doc6300.pdf
> +  "straight" - default value. Data lines are not reversed, uses 
> BGR
> +  "red-blue-reversed" - red and green are reversed, uses RGB
> +
> +  remote-endpoint:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description:
> +  phandle to the panel node
> +
> +required:
> +  - reg
> +  - remote-endpoint
> +
> +additionalProperties: false
> +
> +required:
> +  - "#address-cells"
> +  - "#size-cells"
> +  - reg
> +
> +additionalProperties: false
> +
>display:
>  $ref: /schemas/types.yaml#/definitions/phandle
> +deprecated: true
>  description: phandle to display node
>  
>  patternProperties:
>"^display[0-9]$":
>  type: object
> +deprecated: true
>  description: |
>Display node is required to initialize the lcd panel.
>This should be in the board dts
> @@ -107,12 +179,32 @@ required:
>  
>  examples:
>- |
> +#include 
> +#include 
> +
>  fb {
>  compatible = "atmel,at91sam9263-lcdc";
>  reg = <0x0070 0x1000>;
> -interrupts = <23 3 0>;
> +interrupts = <26 IRQ_TYPE_LEVEL_HIGH 3>;
> +clocks = <&pmc PMC_TYPE_PERIPHERAL 26>, <&pmc PMC_TYPE_PERIPHERAL 
> 26>;
> +clock-names = "lcdc_clk", "hclk";
> +
> +/* pwm for backlight */
> +#pwm-cells = <3>;
> +
>  #address-cells = <1>;
>  #size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +endpoint@0 {
> +reg = <0>;
> +wiring = "red-blue-reversed";
> +remote-endpoint = <&panel_input>;
> +};
> +};
>  };
>  
>- |
> -- 
> 2.20.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 03/36] dt-bindings: display: add te-gpios to panel-common

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:36 +0200, Sam Ravnborg wrote:
> Several bindings specifies a "te-gpios" for tearing effect signal.
> Add this to panel-common so we have a shared definition.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../devicetree/bindings/display/panel/panel-common.yaml| 7 +++
>  1 file changed, 7 insertions(+)
> 

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


[PATCH v2] drm: Fix HDCP failures when SRM fw is missing

2020-04-14 Thread Sean Paul
From: Sean Paul 

The SRM cleanup in 79643fddd6eb2 ("drm/hdcp: optimizing the srm
handling") inadvertently altered the behavior of HDCP auth when
the SRM firmware is missing. Before that patch, missing SRM was
interpreted as the device having no revoked keys. With that patch,
if the SRM fw file is missing we reject _all_ keys.

This patch fixes that regression by returning success if the file
cannot be found. It also checks the return value from request_srm such
that we won't end up trying to parse the ksv list if there is an error
fetching it.

Fixes: 79643fddd6eb ("drm/hdcp: optimizing the srm handling")
Cc: sta...@vger.kernel.org
Cc: Ramalingam C 
Cc: Sean Paul 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sean Paul 

Changes in v2:
-Noticed a couple other things to clean up
---

Sorry for the quick rev, noticed a couple other loose ends that should
be cleaned up.

 drivers/gpu/drm/drm_hdcp.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 7f386adcf872..910108ccaae1 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -241,8 +241,12 @@ static int drm_hdcp_request_srm(struct drm_device *drm_dev,
 
ret = request_firmware_direct(&fw, (const char *)fw_name,
  drm_dev->dev);
-   if (ret < 0)
+   if (ret < 0) {
+   *revoked_ksv_cnt = 0;
+   *revoked_ksv_list = NULL;
+   ret = 0;
goto exit;
+   }
 
if (fw->size && fw->data)
ret = drm_hdcp_srm_update(fw->data, fw->size, revoked_ksv_list,
@@ -287,6 +291,8 @@ int drm_hdcp_check_ksvs_revoked(struct drm_device *drm_dev, 
u8 *ksvs,
 
ret = drm_hdcp_request_srm(drm_dev, &revoked_ksv_list,
   &revoked_ksv_cnt);
+   if (ret)
+   return ret;
 
/* revoked_ksv_cnt will be zero when above function failed */
for (i = 0; i < revoked_ksv_cnt; i++)
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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


Re: [PATCH v2 36/36] dt-bindings: display: move DSI panels to panel-simple-dsi

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:51:09 +0200, Sam Ravnborg wrote:
> Tomi noticed that several DSI panels was wrongly
> described in panel-simple.yaml.
> Move them to panel-simple-dsi.yaml where they belong.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Tomi Valkeinen 
> ---
>  .../bindings/display/panel/panel-simple-dsi.yaml  | 8 
>  .../devicetree/bindings/display/panel/panel-simple.yaml   | 8 
>  2 files changed, 8 insertions(+), 8 deletions(-)
> 

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


Re: [PATCH v2 35/36] dt-bindings: display: convert olimex,lcd-olinuxino to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:51:08 +0200, Sam Ravnborg wrote:
> v2:
>   - use "ic2" node name in example (Rob)
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Rob Herring 
> Cc: Stefan Mavrodiev 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/olimex,lcd-olinuxino.txt| 42 ---
>  .../display/panel/olimex,lcd-olinuxino.yaml   | 70 +++
>  MAINTAINERS   |  2 +-
>  3 files changed, 71 insertions(+), 43 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.yaml
> 

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


Re: [PATCH v2 34/36] dt-bindings: display: convert lgphilips,lb035q02 to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:51:07 +0200, Sam Ravnborg wrote:
> v2:
>   - drop use of spi-slave.yaml (Maxime)
>   - added unevaluatedProperties (maxime)
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Maxime Ripard 
> Cc: Tomi Valkeinen 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/lgphilips,lb035q02.txt  | 33 ---
>  .../display/panel/lgphilips,lb035q02.yaml | 59 +++
>  2 files changed, 59 insertions(+), 33 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml
> 

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


Re: [PATCH v2 33/36] dt-bindings: display: convert seiko,43wvf1g to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:51:06 +0200, Sam Ravnborg wrote:
> Signed-off-by: Sam Ravnborg 
> Reviewed-by: Marco Franchi 
> Cc: Marco Franchi 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../bindings/display/panel/seiko,43wvf1g.txt  | 23 -
>  .../bindings/display/panel/seiko,43wvf1g.yaml | 49 +++
>  2 files changed, 49 insertions(+), 23 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml
> 

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


Re: [PATCH v2 32/36] dt-bindings: display: convert sharp, lq150x1lg11 to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:51:05 +0200, Sam Ravnborg wrote:
> Signed-off-by: Sam Ravnborg 
> Cc: Peter Rosin 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/sharp,lq150x1lg11.txt   | 36 
>  .../display/panel/sharp,lq150x1lg11.yaml  | 58 +++
>  2 files changed, 58 insertions(+), 36 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.yaml
> 

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


Re: [PATCH v2 31/36] dt-bindings: display: convert sharp, ls037v7dw01 to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:51:04 +0200, Sam Ravnborg wrote:
> v2:
>   - Add min/maxItems to mode-gpios (Rob)
>   - Fix bug in description, mode is up to three gpios (Rob)
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Rob Herring 
> Cc: Tony Lindgren 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/sharp,ls037v7dw01.txt   | 43 
>  .../display/panel/sharp,ls037v7dw01.yaml  | 68 +++
>  2 files changed, 68 insertions(+), 43 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/sharp,ls037v7dw01.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/sharp,ls037v7dw01.yaml
> 

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


Re: [PATCH v2 30/36] dt-bindings: display: convert sharp, lq101r1sx01 to DT Schema

2020-04-14 Thread Rob Herring
On Wed, Apr 08, 2020 at 09:51:03PM +0200, Sam Ravnborg wrote:
> This binding describes a panel with a secondary channel.
> 
> v2:
>   - add check for required properties if link2 is present (Rob)
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Rob Herring 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/sharp,lq101r1sx01.txt   | 49 ---
>  .../display/panel/sharp,lq101r1sx01.yaml  | 85 +++
>  2 files changed, 85 insertions(+), 49 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.txt 
> b/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.txt
> deleted file mode 100644
> index f522bb8e47e1..
> --- a/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.txt
> +++ /dev/null
> @@ -1,49 +0,0 @@
> -Sharp Microelectronics 10.1" WQXGA TFT LCD panel
> -
> -This panel requires a dual-channel DSI host to operate. It supports two 
> modes:
> -- left-right: each channel drives the left or right half of the screen
> -- even-odd: each channel drives the even or odd lines of the screen
> -
> -Each of the DSI channels controls a separate DSI peripheral. The peripheral
> -driven by the first link (DSI-LINK1), left or even, is considered the primary
> -peripheral and controls the device. The 'link2' property contains a phandle
> -to the peripheral driven by the second link (DSI-LINK2, right or odd).
> -
> -Note that in video mode the DSI-LINK1 interface always provides the left/even
> -pixels and DSI-LINK2 always provides the right/odd pixels. In command mode it
> -is possible to program either link to drive the left/even or right/odd pixels
> -but for the sake of consistency this binding assumes that the same assignment
> -is chosen as for video mode.
> -
> -Required properties:
> -- compatible: should be "sharp,lq101r1sx01"
> -- reg: DSI virtual channel of the peripheral
> -
> -Required properties (for DSI-LINK1 only):
> -- link2: phandle to the DSI peripheral on the secondary link. Note that the
> -  presence of this property marks the containing node as DSI-LINK1.
> -- power-supply: phandle of the regulator that provides the supply voltage
> -
> -Optional properties (for DSI-LINK1 only):
> -- backlight: phandle of the backlight device attached to the panel
> -
> -Example:
> -
> - dsi@5430 {
> - panel: panel@0 {
> - compatible = "sharp,lq101r1sx01";
> - reg = <0>;
> -
> - link2 = <&secondary>;
> -
> - power-supply = <...>;
> - backlight = <...>;
> - };
> - };
> -
> - dsi@5440 {
> - secondary: panel@0 {
> - compatible = "sharp,lq101r1sx01";
> - reg = <0>;
> - };
> - };
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml 
> b/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml
> new file mode 100644
> index ..956608cada77
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml
> @@ -0,0 +1,85 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/sharp,lq101r1sx01.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Sharp Microelectronics 10.1" WQXGA TFT LCD panel
> +
> +maintainers:
> +  - Thierry Reding 
> +
> +description: |
> +  This panel requires a dual-channel DSI host to operate. It supports two 
> modes:
> +  - left-right: each channel drives the left or right half of the screen
> +  - even-odd: each channel drives the even or odd lines of the screen
> +
> +  Each of the DSI channels controls a separate DSI peripheral. The peripheral
> +  driven by the first link (DSI-LINK1), left or even, is considered the 
> primary
> +  peripheral and controls the device. The 'link2' property contains a phandle
> +  to the peripheral driven by the second link (DSI-LINK2, right or odd).
> +
> +  Note that in video mode the DSI-LINK1 interface always provides the 
> left/even
> +  pixels and DSI-LINK2 always provides the right/odd pixels. In command mode 
> it
> +  is possible to program either link to drive the left/even or right/odd 
> pixels
> +  but for the sake of consistency this binding assumes that the same 
> assignment
> +  is chosen as for video mode.
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +  compatible:
> +const: sharp,lq101r1sx01
> +
> +  reg: true
> +  power-supply: true
> +  backlight: true
> +
> +  link2:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description: |
> +  phandle to the DSI peripheral on the secondary link. Note that the
> +  presence

Re: [PATCH 2/2] drm/panfrost: add devfreq regulator support

2020-04-14 Thread Mark Brown
On Tue, Apr 14, 2020 at 08:20:23PM +0200, Clément Péron wrote:
> Hi Liam and Mark,

You might want to flag stuff like this in the subject line, I very
nearly deleted this without opening it since most of the email I get
about panfrost appears to be coming from me having sent patches rather
than being relevant.

> We are having an issue with Panfrost driver registering two times the
> same regulator and giving an error when trying to create the debugfs
> folder.

> Could you clarify if it is allowed for a device to register two times
> the same regulator?

> I check Documentation/power/regulator/regulator.rst but this point is
> not specified.

We don't actively prevent it and I can't think what other than debugfs
might run into problems (and that's just a warning) but it does seem
like a weird thing to want to do and like it's pointing to some
confusion in your code with two different parts of the device
controlling the same supply independently.  What's the use case here?


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 29/36] dt-bindings: display: convert sharp, ls043t1le01 to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:51:02 +0200, Sam Ravnborg wrote:
> The txt binding specified the property "power-supply".
> But the example and the actual implementation in the linux-kernel
> uses "avdd-supply".
> So the binding is adjusted to use avdd-supply as this seems
> to be the correct choice.
> There are no DT files in the linux kernel to check.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Werner Johansson 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/sharp,ls043t1le01.txt   | 22 
>  .../display/panel/sharp,ls043t1le01.yaml  | 51 +++
>  2 files changed, 51 insertions(+), 22 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.yaml
> 

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


Re: [PATCH v2 28/36] dt-bindings: display: drop unused simple-panel.txt

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:51:01 +0200, Sam Ravnborg wrote:
> There are no more references to simple-panel.txt.
> Delete it.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  Documentation/devicetree/bindings/display/panel/simple-panel.txt | 1 -
>  1 file changed, 1 deletion(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/simple-panel.txt
> 

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


Re: [PATCH v2 27/36] dt-bindings: display: convert sitronix,st7789v to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:51:00 +0200, Sam Ravnborg wrote:
> v2:
> - dropped use of spi-slave.yaml (Maxime)
> - added unevaluatedProperties (Maxime)
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Maxime Ripard 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/sitronix,st7789v.txt| 37 ---
>  .../display/panel/sitronix,st7789v.yaml   | 63 +++
>  2 files changed, 63 insertions(+), 37 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml
> 

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


Re: [PATCH v2 26/36] dt-bindings: display: convert sony, acx565akm to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:59 +0200, Sam Ravnborg wrote:
> v2:
>   - drop use of spi-slave.yaml (Maxime)
>   - add unevaluatedProperties (Maxime)
>   - rename node in example to panel (Rob)
> 
> Signed-off-by: Sam Ravnborg 
> Reviewed-by: Tomi Valkeinen 
> Cc: Tomi Valkeinen 
> Cc: Rob Herring 
> Cc: Maxime Ripard 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../bindings/display/panel/sony,acx565akm.txt | 30 --
>  .../display/panel/sony,acx565akm.yaml | 57 +++
>  2 files changed, 57 insertions(+), 30 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/sony,acx565akm.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml
> 

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


Re: [PATCH v2 25/36] dt-bindings: display: convert startek,startek-kd050c to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:58 +0200, Sam Ravnborg wrote:
> Signed-off-by: Sam Ravnborg 
> Cc: Marek Belisko 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/startek,startek-kd050c.txt  |  4 ---
>  .../display/panel/startek,startek-kd050c.yaml | 33 +++
>  2 files changed, 33 insertions(+), 4 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/startek,startek-kd050c.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/startek,startek-kd050c.yaml
> 

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


Re: [PATCH v2 24/36] dt-bindings: display: convert toppoly panels to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:57 +0200, Sam Ravnborg wrote:
> v2:
>   - dropped use of spi-slave.yaml (Maxime)
>   - added unevaluatedProperties (Maxime)
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Maxime Ripard 
> Cc: Marek Belisko 
> Cc: H. Nikolaus Schaller 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../bindings/display/panel/tpo,td.yaml| 65 +++
>  .../bindings/display/panel/tpo,td028ttec1.txt | 32 -
>  .../bindings/display/panel/tpo,td043mtea1.txt | 33 --
>  3 files changed, 65 insertions(+), 65 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/tpo,td.yaml
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/tpo,td043mtea1.txt
> 

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


Re: [PATCH v2 24/36] dt-bindings: display: convert toppoly panels to DT Schema

2020-04-14 Thread Rob Herring
On Thu, Apr 09, 2020 at 08:21:16AM +0200, H. Nikolaus Schaller wrote:
> Hi Sam,
> 
> > Am 08.04.2020 um 21:50 schrieb Sam Ravnborg :
> > 
> > v2:
> >  - dropped use of spi-slave.yaml (Maxime)
> >  - added unevaluatedProperties (Maxime)
> > 
> > Signed-off-by: Sam Ravnborg 
> > Cc: Maxime Ripard 
> > Cc: Marek Belisko 
> > Cc: H. Nikolaus Schaller 
> > Cc: Thierry Reding 
> > Cc: Sam Ravnborg 
> > ---
> > .../bindings/display/panel/tpo,td.yaml| 65 +++
> > .../bindings/display/panel/tpo,td028ttec1.txt | 32 -
> > .../bindings/display/panel/tpo,td043mtea1.txt | 33 --
> > 3 files changed, 65 insertions(+), 65 deletions(-)
> > create mode 100644 
> > Documentation/devicetree/bindings/display/panel/tpo,td.yaml
> > delete mode 100644 
> > Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
> > delete mode 100644 
> > Documentation/devicetree/bindings/display/panel/tpo,td043mtea1.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/display/panel/tpo,td.yaml 
> > b/Documentation/devicetree/bindings/display/panel/tpo,td.yaml
> > new file mode 100644
> > index ..4aa605613445
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/tpo,td.yaml
> > @@ -0,0 +1,65 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/tpo,td.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Toppoly TD Panels
> > +
> > +description: |
> > +  The panel must obey the rules for a SPI slave device as specified in
> > +  spi/spi-controller.yaml
> > +
> > +maintainers:
> > +  - Marek Belisko 
> > +  - H. Nikolaus Schaller 
> > +
> > +allOf:
> > +  - $ref: panel-common.yaml#
> > +
> > +properties:
> > +  compatible:
> > +enum:
> > +# Toppoly TD028TTEC1 Panel
> > +  - tpo,td028ttec1
> > +# Toppoly TD043MTEA1 Panel
> > +  - tpo,td043mtea1
> > +
> > +  reg: true
> > +  label: true
> > +  reset-gpios: true
> > +  backlight: true
> > +  port: true
> > +
> > +required:
> > +  - compatible
> > +  - port
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > +  - |
> > +spi {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +panel: panel@0 {
> > +compatible = "tpo,td043mtea1";
> > +reg = <0>;
> > +spi-max-frequency = <10>;
> > +spi-cpol;
> > +spi-cpha;
> > +
> > +label = "lcd";
> > +
> > +reset-gpios = <&gpio7 7 0>;
> > +
> > +port {
> > +lcd_in: endpoint {
> > +remote-endpoint = <&dpi_out>;
> > +};
> > +};
> > +};
> > +};
> 
> I think it is possible to add two examples (the one for tpo,td028ttec1)
> as well. The reason is that it must also have spi-cs-high; which isn't
> documented anywhere else and wasn't in tpo,td028ttec1.txt.

I don't think we need another example because examples are not a 
enumeration for what's allowed. There should be an if/then schema though 
for this. That can be a follow-up IMO.

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


[PATCH] drm: Fix HDCP failures when SRM fw is missing

2020-04-14 Thread Sean Paul
From: Sean Paul 

The SRM cleanup in 79643fddd6eb2 ("drm/hdcp: optimizing the srm
handling") inadvertently altered the behavior of HDCP auth when
the SRM firmware is missing. Before that patch, missing SRM was
interpreted as the device having no revoked keys. With that patch,
if the SRM fw file is missing we reject _all_ keys.

This patch fixes that regression by returning success if the file
cannot be found.

Fixes: 79643fddd6eb ("drm/hdcp: optimizing the srm handling")
Cc: sta...@vger.kernel.org
Cc: Ramalingam C 
Cc: Sean Paul 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/drm_hdcp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 7f386adcf872..3c36005d367b 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -241,8 +241,10 @@ static int drm_hdcp_request_srm(struct drm_device *drm_dev,
 
ret = request_firmware_direct(&fw, (const char *)fw_name,
  drm_dev->dev);
-   if (ret < 0)
+   if (ret < 0) {
+   ret = 0;
goto exit;
+   }
 
if (fw->size && fw->data)
ret = drm_hdcp_srm_update(fw->data, fw->size, revoked_ksv_list,
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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


Re: [RFC 0/6] Regressions for "imply" behavior change

2020-04-14 Thread Arnd Bergmann
On Tue, Apr 14, 2020 at 7:49 PM Saeed Mahameed  wrote:
> On Tue, 2020-04-14 at 17:25 +0200, Arnd Bergmann wrote:
> > On Tue, Apr 14, 2020 at 5:23 PM Jason Gunthorpe  wrote:
> > Correct.
> >
>
> Great !
>
> Then bottom line we will change mlx5/Kconfig: to
>
> depends on VXLAN || !VXLAN

Ok

> This will force MLX5_CORE to m when necessary to make vxlan reachable
> to mlx5_core.  So no need for explicit use of IS_REACHABLE().
> in mlx5 there are 4 of these:
>
> imply PTP_1588_CLOCK
> imply VXLAN
> imply MLXFW
> imply PCI_HYPERV_INTERFACE

As mentioned earlier, we do need to replace the 'imply PTP_1588_CLOCK'
with the same

 depends on PTP_1588_CLOCK || !PTP_1588_CLOCK

So far I have not seen problems for the other two options, so I assume they
are fine for now -- it seems to build just fine without PCI_HYPERV_INTERFACE,
and MLXFW has no other dependencies, meaning that 'imply' is the
same as 'select' here. Using 'select MLXFW' would make it clearer perhaps.

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


Re: [PATCH v2 23/36] dt-bindings: display: convert samsung,s6e8aa0 to DT Schema

2020-04-14 Thread Rob Herring
On Wed, Apr 08, 2020 at 09:50:56PM +0200, Sam Ravnborg wrote:
> Signed-off-by: Sam Ravnborg 
> Cc: Andrzej Hajda 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/samsung,s6e8aa0.txt | 56 ---
>  .../display/panel/samsung,s6e8aa0.yaml| 96 +++
>  2 files changed, 96 insertions(+), 56 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.txt 
> b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.txt
> deleted file mode 100644
> index 9e766c5f86da..
> --- a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.txt
> +++ /dev/null
> @@ -1,56 +0,0 @@
> -Samsung S6E8AA0 AMOLED LCD 5.3 inch panel
> -
> -Required properties:
> -  - compatible: "samsung,s6e8aa0"
> -  - reg: the virtual channel number of a DSI peripheral
> -  - vdd3-supply: core voltage supply
> -  - vci-supply: voltage supply for analog circuits
> -  - reset-gpios: a GPIO spec for the reset pin
> -  - display-timings: timings for the connected panel as described by [1]
> -
> -Optional properties:
> -  - power-on-delay: delay after turning regulators on [ms]
> -  - reset-delay: delay after reset sequence [ms]
> -  - init-delay: delay after initialization sequence [ms]
> -  - panel-width-mm: physical panel width [mm]
> -  - panel-height-mm: physical panel height [mm]
> -  - flip-horizontal: boolean to flip image horizontally
> -  - flip-vertical: boolean to flip image vertically
> -
> -The device node can contain one 'port' child node with one child
> -'endpoint' node, according to the bindings defined in [2]. This
> -node should describe panel's video bus.
> -
> -[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt
> -[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
> -
> -Example:
> -
> - panel {
> - compatible = "samsung,s6e8aa0";
> - reg = <0>;
> - vdd3-supply = <&vcclcd_reg>;
> - vci-supply = <&vlcd_reg>;
> - reset-gpios = <&gpy4 5 0>;
> - power-on-delay= <50>;
> - reset-delay = <100>;
> - init-delay = <100>;
> - panel-width-mm = <58>;
> - panel-height-mm = <103>;
> - flip-horizontal;
> - flip-vertical;
> -
> - display-timings {
> - timing0: timing-0 {
> - clock-frequency = <57153600>;
> - hactive = <720>;
> - vactive = <1280>;
> - hfront-porch = <5>;
> - hback-porch = <5>;
> - hsync-len = <5>;
> - vfront-porch = <13>;
> - vback-porch = <1>;
> - vsync-len = <2>;
> - };
> - };
> - };
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml 
> b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml
> new file mode 100644
> index ..67c99b0492e5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml
> @@ -0,0 +1,96 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/samsung,s6e8aa0.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung S6E8AA0 AMOLED LCD 5.3 inch panel
> +
> +maintainers:
> +  - Andrzej Hajda 
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +  compatible:
> +const: samsung,s6e8aa0
> +
> +  reg: true
> +  reset-gpios: true
> +  display-timings: true
> +
> +  vdd3-supply:
> +description: core voltage supply
> +
> +  vci-supply:
> +description: voltage supply for analog circuits
> + 
> +  power-on-delay:
> +description: delay after turning regulators on [ms]
> +
> +  reset-delay:
> +description: delay after reset sequence [ms]

Needs a type ref.

> +
> +  init-delay:
> +description: delay after initialization sequence [ms]

Same here.

> +
> +  panel-width-mm:
> +description: physical panel width [mm]
> +
> +  panel-height-mm:
> +description: physical panel height [mm]
> +
> +  flip-horizontal:
> +description: boolean to flip image horizontally

type: boolean

> +
> +  flip-vertical:
> +description: boolean to flip image vertically

type: boolean

> +
> +required:
> +  - compatible
> +  - reg
> +  - vdd3-supply 
> +  - vci-supply
> +  - reset-gpios
> +  - display-timings
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +dsi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +panel {

panel@0

> +compatible = "samsung,s6e8aa

Re: [PATCH v2 22/36] dt-bindings: display: convert samsung, ld9040 to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:55 +0200, Sam Ravnborg wrote:
> v2:
>   - drop use of spi-slave.yaml (Maxime)
>   - added unevaluatedProperties (Maxime)
>   - added type to width/height properties (Rob)
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Maxime Ripard 
> Cc: Rob Herring 
> Cc: Andrzej Hajda 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../bindings/display/panel/samsung,ld9040.txt |  66 ---
>  .../display/panel/samsung,ld9040.yaml | 107 ++
>  2 files changed, 107 insertions(+), 66 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/samsung,ld9040.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml
> 

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


Re: [PATCH v2 21/36] dt-bindings: display: convert samsung,s6d16d0 to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:54 +0200, Sam Ravnborg wrote:
> Signed-off-by: Sam Ravnborg 
> Reviewed-by: Linus Walleij 
> Cc: Linus Walleij 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/samsung,s6d16d0.txt | 30 --
>  .../display/panel/samsung,s6d16d0.yaml| 56 +++
>  2 files changed, 56 insertions(+), 30 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/samsung,s6d16d0.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/samsung,s6d16d0.yaml
> 

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


Re: [PATCH v2 20/36] dt-bindings: display: convert samsung AMOLED to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:53 +0200, Sam Ravnborg wrote:
> For samsung there was two AMOLED panels with the same
> description.
> Collect them in one binding file.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Hoegeun Kwon 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../panel/samsung,amoled-mipi-dsi.yaml| 65 +++
>  .../display/panel/samsung,s6e3ha2.txt | 31 -
>  .../display/panel/samsung,s6e63j0x03.txt  | 24 ---
>  3 files changed, 65 insertions(+), 55 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
> 

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


Re: [PATCH v2 19/36] dt-bindings: display: convert rocktech,jh057n00900 to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:52 +0200, Sam Ravnborg wrote:
> v2:
>   - Fix entry in MAINTAINERS
> 
> Signed-off-by: Sam Ravnborg 
> Reviewed-by: Guido Günther 
> Cc: "Guido Günther" 
> Cc: Purism Kernel Team 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/rocktech,jh057n00900.txt| 23 
>  .../display/panel/rocktech,jh057n00900.yaml   | 57 +++
>  MAINTAINERS   |  2 +-
>  3 files changed, 58 insertions(+), 24 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
> 

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


Re: [PATCH v2 18/36] dt-bindings: display: convert raydium,rm67191 to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:51 +0200, Sam Ravnborg wrote:
> v2:
>   - Fix entry in MAINTAINERS
>   - Add reg number to node name (Rob)
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Rob Herring 
> Cc: Robert Chiras 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/raydium,rm67191.txt | 41 --
>  .../display/panel/raydium,rm67191.yaml| 75 +++
>  MAINTAINERS   |  2 +-
>  3 files changed, 76 insertions(+), 42 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml
> 

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


Re: [PATCH v2 17/36] dt-bindings: display: convert osddisplays,osd101t2587-53ts to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:50 +0200, Sam Ravnborg wrote:
> osddisplays,osd101t2587-53ts is compatible with panel-simple-dsi binding,
> so list the compatible in the panel-simple-dsi binding file.
> 
> v2:
>   - It is a DSI panel, move to -dsi binding (Tomi)
> 
> Signed-off-by: Sam Ravnborg 
> Reviewed-by: Tomi Valkeinen 
> Cc: Peter Ujfalusi 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/osddisplays,osd101t2587-53ts.txt | 14 --
>  .../bindings/display/panel/panel-simple-dsi.yaml   |  2 ++
>  2 files changed, 2 insertions(+), 14 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/osddisplays,osd101t2587-53ts.txt
> 

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


Re: [PATCH v2 16/36] dt-bindings: display: convert lg,lg4573 to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:49 +0200, Sam Ravnborg wrote:
> v2:
>   - Dropped spi-slave (Maxime)
>   - Added unevaluatedProperties (Maxime)
>   - Deleted needless compatible from example (Rob)
> 
> Signed-off-by: Sam Ravnborg 
> Reviewed-by: Heiko Schocher 
> Cc: Maxime Ripard 
> Cc: Rob Herring 
> Cc: Heiko Schocher 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../bindings/display/panel/lg,lg4573.txt  | 19 
>  .../bindings/display/panel/lg,lg4573.yaml | 45 +++
>  2 files changed, 45 insertions(+), 19 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/lg,lg4573.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/lg,lg4573.yaml
> 

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


Re: [PATCH v2 15/36] dt-bindings: display: convert simple lg panels to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:48 +0200, Sam Ravnborg wrote:
> Add the lg panels that matches the panel-simple binding to
> panel-simple.yaml
> 
> Signed-off-by: Sam Ravnborg 
> Reviewed-by: Brian Masney 
> Cc: Brian Masney 
> Cc: Alexandre Courbot 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../devicetree/bindings/display/panel/lg,acx467akm-7.txt   | 7 ---
>  .../devicetree/bindings/display/panel/lg,ld070wx3-sl01.txt | 7 ---
>  .../devicetree/bindings/display/panel/lg,lh500wx1-sd03.txt | 7 ---
>  .../devicetree/bindings/display/panel/panel-simple.yaml| 6 ++
>  4 files changed, 6 insertions(+), 21 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/lg,acx467akm-7.txt
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/lg,ld070wx3-sl01.txt
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/lg,lh500wx1-sd03.txt
> 

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


Re: [PATCH v2 14/36] dt-bindings: display: convert kingdisplay,kd097d04 to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:47 +0200, Sam Ravnborg wrote:
> kingdisplay,kd097d04 matches the panel-simple-dsi binding.
> The only difference is that enable-gpios is now an optional
> property.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Nickey Yang 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/kingdisplay,kd097d04.txt| 22 ---
>  .../display/panel/panel-simple-dsi.yaml   |  2 ++
>  2 files changed, 2 insertions(+), 22 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/kingdisplay,kd097d04.txt
> 

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


Re: [PATCH v2 13/36] dt-bindings: display: convert kingdisplay,kd035g6-54nt to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:46 +0200, Sam Ravnborg wrote:
> v2:
>   - Drop use of spi-slave.yaml (Maxime)
>   - Introduce unevaluatedProperties (Maxime)
> 
> Signed-off-by: Sam Ravnborg 
> Reviewed-by: Paul Cercueil 
> Cc: Maxime Ripard 
> Cc: Paul Cercueil 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../panel/kingdisplay,kd035g6-54nt.txt| 42 
>  .../panel/kingdisplay,kd035g6-54nt.yaml   | 65 +++
>  2 files changed, 65 insertions(+), 42 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml
> 

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


Re: [PATCH v2 12/36] dt-bindings: display: convert jdi,lt070me05000 to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:45 +0200, Sam Ravnborg wrote:
> v2:
>   - drop address in dsi node in example (Rob)
> 
> Signed-off-by: Sam Ravnborg 
> Reviewed-by: Vinay Simha BN 
> Cc: Rob Herring 
> Cc: Vinay Simha BN 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/jdi,lt070me05000.txt| 31 -
>  .../display/panel/jdi,lt070me05000.yaml   | 69 +++
>  2 files changed, 69 insertions(+), 31 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.yaml
> 

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


Re: [PATCH v2 10/36] dt-bindings: display: convert innolux,p097pfg to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:43 +0200, Sam Ravnborg wrote:
> Signed-off-by: Sam Ravnborg 
> Cc: Lin Huang 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/innolux,p097pfg.txt | 24 
>  .../display/panel/innolux,p097pfg.yaml| 56 +++
>  2 files changed, 56 insertions(+), 24 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/innolux,p097pfg.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/innolux,p097pfg.yaml
> 

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


Re: [PATCH v2 11/36] dt-bindings: display: convert innolux,p120zdg-bf1 to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:44 +0200, Sam Ravnborg wrote:
> Signed-off-by: Sam Ravnborg 
> Reviewed-by: Douglas Anderson 
> Cc: Douglas Anderson 
> Cc: Sandeep Panda 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/innolux,p120zdg-bf1.txt | 22 --
>  .../display/panel/innolux,p120zdg-bf1.yaml| 43 +++
>  2 files changed, 43 insertions(+), 22 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.yaml
> 

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


Re: [PATCH v2 09/36] dt-bindings: display: convert innolux,p079zca to DT Schema

2020-04-14 Thread Rob Herring
On Wed, Apr 08, 2020 at 09:50:42PM +0200, Sam Ravnborg wrote:
> As the binding matches panel-simple, added the compatible to the
> panel-simple list.
> With this change enable-gpios is now optional.

But is a DSI panel, so it should be in panel-simple-dsi.yaml.

> 
> Signed-off-by: Sam Ravnborg 
> Cc: Chris Zhong 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/innolux,p079zca.txt | 22 ---
>  .../bindings/display/panel/panel-simple.yaml  |  2 ++
>  2 files changed, 2 insertions(+), 22 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt 
> b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
> deleted file mode 100644
> index 3ab8c7412cf6..
> --- a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
> +++ /dev/null
> @@ -1,22 +0,0 @@
> -Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
> -
> -Required properties:
> -- compatible: should be "innolux,p079zca"
> -- reg: DSI virtual channel of the peripheral
> -- power-supply: phandle of the regulator that provides the supply voltage
> -- enable-gpios: panel enable gpio
> -
> -Optional properties:
> -- backlight: phandle of the backlight device attached to the panel
> -
> -Example:
> -
> - &mipi_dsi {
> - panel@0 {
> - compatible = "innolux,p079zca";
> - reg = <0>;
> - power-supply = <...>;
> - backlight = <&backlight>;
> - enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
> - };
> - };
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
> b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index 8fc117d1547c..328df95cbe88 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -143,6 +143,8 @@ properties:
>- innolux,n116bge
>  # InnoLux 15.6" WXGA TFT LCD panel
>- innolux,n156bge-l21
> +# Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
> +  - innolux,p079zca
>  # Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel
>- innolux,zj070na-01p
>  # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
> -- 
> 2.20.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 08/36] dt-bindings: display: convert ilitek,ili9881c to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:41 +0200, Sam Ravnborg wrote:
> Updating this binding identified an issue in the example in
> the allwinner,sun6i-a31-mipi-dsi binding.
> Fix the example so no new warnings are introduced.
> 
> v2:
>   - fix example in allwinner,sun6i-a31-mipi-dsi (Rob)
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Rob Herring 
> Cc: Maxime Ripard 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/allwinner,sun6i-a31-mipi-dsi.yaml |  2 +-
>  .../display/panel/ilitek,ili9881c.txt | 20 
>  .../display/panel/ilitek,ili9881c.yaml| 50 +++
>  3 files changed, 51 insertions(+), 21 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
> 

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


Re: [PATCH v2 07/36] dt-bindings: display: convert ilitek, ili9322 to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:40 +0200, Sam Ravnborg wrote:
> The .txt binding explains:
> 
> "
> The following optional properties only apply to
> RGB and YUV input modes and
> can be omitted for BT.656 input modes:
> "
> 
> This constraint is not implmented in the DT Schema.
> 
> The original binding from the .txt file referenced
> properties that is included in panel-timing.yaml.
> 
> The properties in question are:
>   - pixelclk-active
>   - de-active
>   - hsync-active
>   - vsync-active
> 
> These properties was dropped in the conversion as they are not relevant.
> 
> v2:
>   - drop properties from panel-timing (Linus)
>   - drop use of spi-slave.yaml (Maxime)
>   - introduce unevaluatedProperties (Maxime)
>   - dropped unused properties (Linus)
>   - delete stray spaces
> 
> Signed-off-by: Sam Ravnborg 
> Reviewed-by: Linus Walleij 
> Cc: Linus Walleij 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../bindings/display/panel/ilitek,ili9322.txt | 49 -
>  .../display/panel/ilitek,ili9322.yaml | 71 +++
>  2 files changed, 71 insertions(+), 49 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/ilitek,ili9322.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml
> 

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


Re: [PATCH v2 06/36] dt-bindings: display: convert boe, himax8279d to DT Schema

2020-04-14 Thread Rob Herring
On Wed, Apr 08, 2020 at 09:50:39PM +0200, Sam Ravnborg wrote:
> v2:
>   - Fix entry in MAINTAINERS
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Jerry Han 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../bindings/display/panel/boe,himax8279d.txt | 24 
>  .../display/panel/boe,himax8279d.yaml | 59 +++
>  MAINTAINERS   |  2 +-
>  3 files changed, 60 insertions(+), 25 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt 
> b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
> deleted file mode 100644
> index 3caea2172b1b..
> --- a/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
> +++ /dev/null
> @@ -1,24 +0,0 @@
> -Boe Himax8279d 1200x1920 TFT LCD panel
> -
> -Required properties:
> -- compatible: should be "boe,himax8279d8p" and one of: "boe,himax8279d10p"
> -- reg: DSI virtual channel of the peripheral
> -- enable-gpios: panel enable gpio
> -- pp33-gpios: a GPIO phandle for the 3.3v pin that provides the supply 
> voltage
> -- pp18-gpios: a GPIO phandle for the 1.8v pin that provides the supply 
> voltage
> -
> -Optional properties:
> -- backlight: phandle of the backlight device attached to the panel
> -
> -Example:
> -
> - &mipi_dsi {
> - panel {
> - compatible = "boe,himax8279d8p", "boe,himax8279d10p";
> - reg = <0>;
> - backlight = <&backlight>;
> - enable-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> - pp33-gpios = <&gpio 35 GPIO_ACTIVE_HIGH>;
> - pp18-gpios = <&gpio 36 GPIO_ACTIVE_HIGH>;
> - };
> - };
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml 
> b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml
> new file mode 100644
> index ..e42b6a8ae176
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml
> @@ -0,0 +1,59 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/boe,himax8279d.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Boe Himax8279d 1200x1920 TFT LCD panel
> +
> +maintainers:
> +  - Jerry Han 
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +  compatible:
> +items:
> +  - const: boe,himax8279d8p
> +  - const: boe,himax8279d10p
> +
> +  backlight: true
> +  enable-gpios: true
> +  reg: true
> +
> +  pp33-gpios:
> +maxItems: 1
> +description: GPIO for the 3.3v pin that provides the supply voltage
> +
> +  pp18-gpios:
> +maxItems: 1
> +description: GPIO for the 1.8v pin that provides the supply voltage
> +
> +required:
> +  - compatible
> +  - reg
> +  - enable-gpios
> +  - pp33-gpios
> +  - pp18-gpios
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +
> +dsi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +panel {

panel@0

With that,

Reviewed-by: Rob Herring 

Double check the others. I won't repeat myself.

> +compatible = "boe,himax8279d8p", "boe,himax8279d10p";
> +reg = <0>;
> +backlight = <&backlight>;
> +enable-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> +pp33-gpios = <&gpio 35 GPIO_ACTIVE_HIGH>;
> +pp18-gpios = <&gpio 36 GPIO_ACTIVE_HIGH>;
> +};
> +};
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2b99fa16ba08..dba84e7726b7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5255,7 +5255,7 @@ DRM DRIVER FOR BOE HIMAX8279D PANELS
>  M:   Jerry Han 
>  S:   Maintained
>  F:   drivers/gpu/drm/panel/panel-boe-himax8279d.c
> -F:   Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
> +F:   Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml
>  
>  DRM DRIVER FOR FARADAY TVE200 TV ENCODER
>  M:   Linus Walleij 
> -- 
> 2.20.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 05/36] dt-bindings: display: convert arm,versatile-tft-panel to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:38 +0200, Sam Ravnborg wrote:
> v2:
>   - Fix entry in MAINTAINERS
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Linus Walleij 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/arm,versatile-tft-panel.txt | 31 ---
>  .../panel/arm,versatile-tft-panel.yaml| 51 +++
>  MAINTAINERS   |  2 +-
>  3 files changed, 52 insertions(+), 32 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml
> 

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


Re: [PATCH v2 04/36] dt-bindings: display: convert samsung,s6e63m0 to DT Schema

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:37 +0200, Sam Ravnborg wrote:
> The binding for this panel is a SPI slave.
> 
> v2:
>   - Drop use of spi-slave (Maxime)
>   - Introude unevaluatedProperties (Maxime)
>   - Drop reg entry in example (Rob)
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Maxime Ripard 
> Cc: Rob Herring 
> Cc: Jonathan Bakker 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/samsung,s6e63m0.txt | 33 --
>  .../display/panel/samsung,s6e63m0.yaml| 60 +++
>  2 files changed, 60 insertions(+), 33 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml
> 

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


Re: [PATCH v2 02/36] dt-bindings: display: look for dsi* nodes in dsi-controller

2020-04-14 Thread Rob Herring
On Wed,  8 Apr 2020 21:50:35 +0200, Sam Ravnborg wrote:
> Rob wrote:
> 
> Uhhh, it's looking for dsi-controller(@.*)? which is not the common
> case found in dts files. We should fix that to dsi(@.*)?.
> 
> See: https://lore.kernel.org/dri-devel/2020031903.GK29911@bogus/
> 
> Fix it.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Linus Walleij 
> Cc: Rob Herring 
> ---
>  Documentation/devicetree/bindings/display/dsi-controller.yaml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

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


Re: [PATCH v2 2/2] dt-bindings: Document the Synopsys ARC HDMI TX bindings

2020-04-14 Thread Sam Ravnborg
Hi Eugeniy.

On Tue, Apr 14, 2020 at 05:44:02PM +0300, Eugeniy Paltsev wrote:
> This patch adds documentation of device tree bindings for the Synopsys
> HDMI 2.0 TX encoder driver for ARC SoCs.
> 
> Signed-off-by: Eugeniy Paltsev 
Acked-by: Sam Ravnborg 

with a few nits addressed.

As already mentioned - the filename confuses.
Maybe tell why in changelog - og fix filename to follow compatible.

> ---
>  .../display/bridge/snps,arc-dw-hdmi.yaml  | 131 ++
>  1 file changed, 131 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml 
> b/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
> new file mode 100644
> index ..f52fc3b114b0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
> @@ -0,0 +1,131 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/snps,arc-dw-hdmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synopsys DesignWare HDMI 2.0 TX encoder driver
> +
> +maintainers:
> +  - Eugeniy Paltsev 
> +
> +description: |
> +  The HDMI transmitter is a Synopsys DesignWare HDMI 2.0 TX controller IP
> +  with a companion of Synopsys DesignWare HDMI 2.0 TX PHY IP.
> +
> +  These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
> +  Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
> +  with the following device-specific properties.
> +
> +properties:
> +  compatible:
> +const: snps,dw-hdmi-hsdk
> +
> +  reg:
> +maxItems: 1
> +description: |
> +  Memory mapped base address and length of the DWC HDMI TX registers.
> +
> +  clocks:
> +items:
> +  - description: The bus clock for AHB / APB
> +  - description: The internal register configuration clock
> +
> +  clock-names:
> +items:
> +  - const: iahb
> +  - const: isfr
> +
> +  reg-io-width:
> +allOf:
> +  - $ref: /schemas/types.yaml#/definitions/uint32
> +  - enum: [1, 4]
> +description:
> +  Width of the registers specified by the reg property. The
> +  value is expressed in bytes and must be equal to 1 or 4 if 
> specified.
> +  The register width defaults to 1 if the property is not present.
> +
> +  ports:
> +type: object
> +description: |
> +  A ports node with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +properties:
> +  "#address-cells":
> +const: 1
> +
> +  "#size-cells":
> +const: 0
> +
> +  port@0:
> +type: object
> +description: |
> +  Video input endpoints of the controller.
> +  Usually the associated with PGU.
Please rephrase this sentence. I am not sure how to read it.

> +
> +  port@1:
> +type: object
> +description: |
> +  Output endpoints of the controller. HDMI connector.
> +
> +required:
> +  - "#address-cells"
> +  - "#size-cells"
> +  - port@0
> +  - port@1
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - clock-names
> +  - ports
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +hdmi: hdmi@0x1 {
hdmi
> +compatible = "snps,dw-hdmi-hsdk";
> +reg = <0x1 0x1>;
> +reg-io-width = <4>;
> +interrupts = <14>;
> +clocks = <&apbclk>, <&hdmi_pix_clk>;
> +clock-names = "iahb", "isfr";
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +hdmi_enc_input: endpoint {
> +remote-endpoint = <&pgu_output>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +hdmi_enc_out: endpoint {
> +remote-endpoint = <&hdmi_con>;
> +};
> +};
> +};
> +};
> +
> +hdmi-out {
> +port {
> +hdmi_con: endpoint {
> +remote-endpoint = <&hdmi_enc_out>;
> +};
> +};
> +};
> +
> +pgu {
> +port_o: port {
> +pgu_output: endpoint {
> +remote-endpoint = <&hdmi_enc_input>;
> +};
> +};
> +};
> -- 
> 2.21.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/9] drm/vblank: Add vblank works

2020-04-14 Thread Tejun Heo
Hello,

On Tue, Apr 14, 2020 at 12:52:51PM -0400, Lyude Paul wrote:
> Hi, thanks for the response! And yes-I think this would actually be perfect
> for what we need, I guess one question I might as well ask since I've got you
> here: would patches to expose an unlocked version of kthread_queue_worker() be
> accepted? With something like that I should be able to just reuse the
> delayed_work_list and spinlocks that come with kthread_worker which would make
> the vblank works implementation a bit easier

Difficult to tell w/o looking at the code but if technically reasonable and
justified, I don't see a reason why something like that couldn't be accepted.
That said, whatever gain coming from sharing an inner lock like that usually
is miniscule and API and logic simplicity often easily outweighs.

Thanks.

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


Re: [PATCH] Optimized division operation to shift operation

2020-04-14 Thread Alex Deucher
On Tue, Apr 14, 2020 at 9:05 AM Bernard Zhao  wrote:
>
> On some processors, the / operate will call the compiler`s div lib,
> which is low efficient, We can replace the / operation with shift,
> so that we can replace the call of the division library with one
> shift assembly instruction.
>
> Signed-off-by: Bernard Zhao 

Applied.  thanks.

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 4 ++--
>  drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 4 ++--
>  drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
> index b205039..66cd078 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
> @@ -175,10 +175,10 @@ static int gmc_v6_0_mc_load_microcode(struct 
> amdgpu_device *adev)
> amdgpu_ucode_print_mc_hdr(&hdr->header);
>
> adev->gmc.fw_version = le32_to_cpu(hdr->header.ucode_version);
> -   regs_size = le32_to_cpu(hdr->io_debug_size_bytes) / (4 * 2);
> +   regs_size = le32_to_cpu(hdr->io_debug_size_bytes) >> 3;
> new_io_mc_regs = (const __le32 *)
> (adev->gmc.fw->data + 
> le32_to_cpu(hdr->io_debug_array_offset_bytes));
> -   ucode_size = le32_to_cpu(hdr->header.ucode_size_bytes) / 4;
> +   ucode_size = le32_to_cpu(hdr->header.ucode_size_bytes) >> 2;
> new_fw_data = (const __le32 *)
> (adev->gmc.fw->data + 
> le32_to_cpu(hdr->header.ucode_array_offset_bytes));
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> index 9da9596..ca26d63 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> @@ -193,10 +193,10 @@ static int gmc_v7_0_mc_load_microcode(struct 
> amdgpu_device *adev)
> amdgpu_ucode_print_mc_hdr(&hdr->header);
>
> adev->gmc.fw_version = le32_to_cpu(hdr->header.ucode_version);
> -   regs_size = le32_to_cpu(hdr->io_debug_size_bytes) / (4 * 2);
> +   regs_size = le32_to_cpu(hdr->io_debug_size_bytes) >> 3;
> io_mc_regs = (const __le32 *)
> (adev->gmc.fw->data + 
> le32_to_cpu(hdr->io_debug_array_offset_bytes));
> -   ucode_size = le32_to_cpu(hdr->header.ucode_size_bytes) / 4;
> +   ucode_size = le32_to_cpu(hdr->header.ucode_size_bytes) >> 2;
> fw_data = (const __le32 *)
> (adev->gmc.fw->data + 
> le32_to_cpu(hdr->header.ucode_array_offset_bytes));
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> index 27d83204..295039c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> @@ -318,10 +318,10 @@ static int gmc_v8_0_tonga_mc_load_microcode(struct 
> amdgpu_device *adev)
> amdgpu_ucode_print_mc_hdr(&hdr->header);
>
> adev->gmc.fw_version = le32_to_cpu(hdr->header.ucode_version);
> -   regs_size = le32_to_cpu(hdr->io_debug_size_bytes) / (4 * 2);
> +   regs_size = le32_to_cpu(hdr->io_debug_size_bytes) >> 3;
> io_mc_regs = (const __le32 *)
> (adev->gmc.fw->data + 
> le32_to_cpu(hdr->io_debug_array_offset_bytes));
> -   ucode_size = le32_to_cpu(hdr->header.ucode_size_bytes) / 4;
> +   ucode_size = le32_to_cpu(hdr->header.ucode_size_bytes) >> 2;
> fw_data = (const __le32 *)
> (adev->gmc.fw->data + 
> le32_to_cpu(hdr->header.ucode_array_offset_bytes));
>
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 1/2] DRM: ARC: add HDMI 2.0 TX encoder support

2020-04-14 Thread Sam Ravnborg
Hi Eugeniy.

On Tue, Apr 14, 2020 at 05:44:01PM +0300, Eugeniy Paltsev wrote:
> The Synopsys ARC SoCs (like HSDK4xD) include on-chip DesignWare HDMI
> encoders. Support them with a platform driver to provide platform glue
> data to the dw-hdmi driver.


Drivers looks lean and clean.
Acked-by: Sam Ravnborg 

But really take this as I found no whitespace erros or something...

A few drive-by comments below.

Sam

> 
> Signed-off-by: Eugeniy Paltsev 
> ---
>  MAINTAINERS   |   6 ++
>  drivers/gpu/drm/Makefile  |   2 +-
>  drivers/gpu/drm/arc/Kconfig   |   7 ++
>  drivers/gpu/drm/arc/Makefile  |   1 +
>  drivers/gpu/drm/arc/arc-dw-hdmi.c | 126 ++
>  5 files changed, 141 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/arc/arc-dw-hdmi.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a6fbdf354d34..2aaed1190370 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1258,6 +1258,12 @@ S: Supported
>  F:   drivers/gpu/drm/arc/
>  F:   Documentation/devicetree/bindings/display/snps,arcpgu.txt
>  
> +ARC DW HDMI DRIVER
> +M:   Eugeniy Paltsev 
> +S:   Supported
> +F:   drivers/gpu/drm/arc/arc-dw-hdmi.c
> +F:   Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml

I am confused about the filename of the binding.
Binding files are often named after their compatible.
But the compatible is: snps,dw-hdmi-hsdk

And the biding file seems to be named after the driver name.
This seems wrong - and I do nto see it explained.

> +
>  ARCNET NETWORK LAYER
>  M:   Michael Grzeschik 
>  L:   net...@vger.kernel.org
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 6493088a0fdd..5b0bcf7f45cd 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -109,7 +109,7 @@ obj-y += panel/
>  obj-y+= bridge/
>  obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
>  obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
> -obj-$(CONFIG_DRM_ARCPGU)+= arc/
> +obj-y+= arc/
>  obj-y+= hisilicon/
>  obj-$(CONFIG_DRM_ZTE)+= zte/
>  obj-$(CONFIG_DRM_MXSFB)  += mxsfb/
> diff --git a/drivers/gpu/drm/arc/Kconfig b/drivers/gpu/drm/arc/Kconfig
> index e8f3d63e0b91..baec9d2a4fba 100644
> --- a/drivers/gpu/drm/arc/Kconfig
> +++ b/drivers/gpu/drm/arc/Kconfig
> @@ -8,3 +8,10 @@ config DRM_ARCPGU
> Choose this option if you have an ARC PGU controller.
>  
> If M is selected the module will be called arcpgu.
> +
> +config DRM_ARC_DW_HDMI
> + tristate "ARC DW HDMI"
> + depends on DRM && OF
> + select DRM_DW_HDMI
> + help
> +   Synopsys DW HDMI driver for various ARC development boards
> diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
> index c7028b7427b3..7a156d8c2c3c 100644
> --- a/drivers/gpu/drm/arc/Makefile
> +++ b/drivers/gpu/drm/arc/Makefile
> @@ -1,3 +1,4 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  arcpgu-y := arcpgu_crtc.o arcpgu_hdmi.o arcpgu_sim.o arcpgu_drv.o
>  obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
> +obj-$(CONFIG_DRM_ARC_DW_HDMI) += arc-dw-hdmi.o
> diff --git a/drivers/gpu/drm/arc/arc-dw-hdmi.c 
> b/drivers/gpu/drm/arc/arc-dw-hdmi.c
> new file mode 100644
> index ..4869dd668a51
> --- /dev/null
> +++ b/drivers/gpu/drm/arc/arc-dw-hdmi.c
> @@ -0,0 +1,126 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +//
> +// Synopsys DW HDMI driver for various ARC development boards
> +//
> +// Copyright (C) 2020 Synopsys
> +// Author: Eugeniy Paltsev 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static const struct dw_hdmi_mpll_config snps_hdmi_mpll_cfg[] = {
> + {
> + 2700, {
> + { 0x00B3, 0x },
> + { 0x00B3, 0x },
> + { 0x00B3, 0x }
> + },
> + }, {
> + 7425, {
> + { 0x0072, 0x0001},
> + { 0x0072, 0x0001},
> + { 0x0072, 0x0001}
> + },
> + }, {
> + 14850, {
> + { 0x0051, 0x0002},
> + { 0x0051, 0x0002},
> + { 0x0051, 0x0002}
> + },
> + }, {
> + ~0UL, {
> + { 0x00B3, 0x },
> + { 0x00B3, 0x },
> + { 0x00B3, 0x },
> + },
> + }
> +};
> +
> +static const struct dw_hdmi_curr_ctrl snps_hdmi_cur_ctr[] = {
> + /* pixelclkbpp8bpp10   bpp12 */
This comment is very useful. Could you put one on top of
snps_hdmi_mpll_cfg too?

> + { 2700,  { 0x, 0x, 0x }, },
> + { 7425,  { 0x0008, 0x0008, 0x0008 }, },
> + { 14850, { 0x001b, 0x001b, 0x001b }, },
> + { ~0UL,  { 0x, 0x, 0x }, }
> +};
> +
> +
> +static const struct dw_hdmi_phy_config snps_hdmi_phy_co

Re: [PATCH v2] dt-bindings: display: convert rockchip rk3066 hdmi bindings to yaml

2020-04-14 Thread Rob Herring
On Fri,  3 Apr 2020 15:36:30 +0200, Johan Jonker wrote:
> Current dts files with 'hdmi' nodes for rk3066 are manually verified.
> In order to automate this process rockchip,rk3066-hdmi.txt
> has to be converted to yaml.
> 
> Signed-off-by: Johan Jonker 
> ---
> Changes v2:
>   Fix irq.h already included in arm-gic.h
> ---
>  .../display/rockchip/rockchip,rk3066-hdmi.txt  |  72 ---
>  .../display/rockchip/rockchip,rk3066-hdmi.yaml | 140 
> +
>  2 files changed, 140 insertions(+), 72 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
> 

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


Re: [PATCH v14 2/3] dt-bindings: display: mediatek: convert the document format from txt to yaml

2020-04-14 Thread Rob Herring
On Fri, Apr 03, 2020 at 04:03:49PM +0800, Jitao Shi wrote:
> Signed-off-by: Jitao Shi 
> ---
>  .../display/mediatek/mediatek,dpi.txt | 42 
>  .../display/mediatek/mediatek,dpi.yaml| 97 +++
>  2 files changed, 97 insertions(+), 42 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt 
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> deleted file mode 100644
> index 77def4456706..
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> +++ /dev/null
> @@ -1,42 +0,0 @@
> -Mediatek DPI Device
> -===
> -
> -The Mediatek DPI function block is a sink of the display subsystem and
> -provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a parallel
> -output bus.
> -
> -Required properties:
> -- compatible: "mediatek,-dpi"
> -  the supported chips are mt2701 , mt8173 and mt8183.
> -- reg: Physical base address and length of the controller's registers
> -- interrupts: The interrupt signal from the function block.
> -- clocks: device clocks
> -  See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> -- clock-names: must contain "pixel", "engine", and "pll"
> -- port: Output port node with endpoint definitions as described in
> -  Documentation/devicetree/bindings/graph.txt. This port should be connected
> -  to the input port of an attached HDMI or LVDS encoder chip.
> -
> -Optional properties:
> -- pinctrl-names: Contain "default" and "sleep".
> -
> -Example:
> -
> -dpi0: dpi@1401d000 {
> - compatible = "mediatek,mt8173-dpi";
> - reg = <0 0x1401d000 0 0x1000>;
> - interrupts = ;
> - clocks = <&mmsys CLK_MM_DPI_PIXEL>,
> -  <&mmsys CLK_MM_DPI_ENGINE>,
> -  <&apmixedsys CLK_APMIXED_TVDPLL>;
> - clock-names = "pixel", "engine", "pll";
> - pinctrl-names = "default", "sleep";
> - pinctrl-0 = <&dpi_pin_func>;
> - pinctrl-1 = <&dpi_pin_idle>;
> -
> - port {
> - dpi0_out: endpoint {
> - remote-endpoint = <&hdmi0_in>;
> - };
> - };
> -};
> diff --git 
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml 
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
> new file mode 100644
> index ..effdaa96aec3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
> @@ -0,0 +1,97 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: mediatek DPI Controller Device Tree Bindings
> +
> +maintainers:
> +  - CK Hu 
> +  - Jitao shi 
> +
> +description: |
> +  The Mediatek DPI function block is a sink of the display subsystem and
> +  provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a parallel
> +  output bus.
> +
> +properties:
> +  compatible:
> +enum:
> +  - mediatek,mt2701-dpi
> +  - mediatek,mt8173-dpi
> +  - mediatek,mt8183-dpi
> +
> +  reg:
> +maxItems: 1
> +
> +  interrupts:
> +maxItems: 1
> +
> +  clocks:
> +items:
> +  - description: Pixel Clock
> +  - description: Engine Clock
> +  - description: DPI PLL
> +
> +  clock-names:
> +items:
> +  - const: pixel
> +  - const: engine
> +  - const: pll
> +
> +  pinctrl-0: true
> +  pinctrl-1: true
> +
> +  pinctrl-names:
> +items:
> +  - const: default
> +  - const: sleep
> +
> +  port@0:

Should be 'port'. No 'reg' property, so no unit-address.

> +type: object
> +description:
> +  Output port node with endpoint definitions as described in
> +  Documentation/devicetree/bindings/graph.txt. This port should be 
> connected
> +  to the input port of an attached HDMI or LVDS encoder chip.
> +
> +properties:
> +  endpoint:
> +type: object
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - clocks
> +  - clock-names
> +  - port@0
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +#include 
> +#include 
> +#include 
> +dpi0: dpi@1401d000 {
> +compatible = "mediatek,mt8173-dpi";
> +reg = <0 0x1401d000 0 0x1000>;
> +interrupts = ;
> +clocks = <&mmsys CLK_MM_DPI_PIXEL>,
> + <&mmsys CLK_MM_DPI_ENGINE>,
> + <&apmixedsys CLK_APMIXED_TVDPLL>;
> +clock-names = "pixel", "engine", "pll";
> +pinctrl-names = "default", "sleep";
> +pinctrl-0 = <&dpi_pin_func>;
> +pinctrl-1 = <&dpi_pin_idle>;
> +
> +port@0 {
> +dpi0_out: endpoint {
> +remote-endpoint = <&hdmi0_in>;
> +};
> +   

Re: [PATCH v14 1/3] dt-bindings: display: mediatek: control dpi pins mode to avoid leakage

2020-04-14 Thread Rob Herring
On Fri, 3 Apr 2020 16:03:48 +0800, Jitao Shi wrote:
> Add property "pinctrl-names" to swap pin mode between gpio and dpi mode. Set
> the dpi pins to gpio mode and output-low to avoid leakage current when dpi
> disabled.
> 
> Signed-off-by: Jitao Shi 
> ---
>  .../devicetree/bindings/display/mediatek/mediatek,dpi.txt   | 6 ++
>  1 file changed, 6 insertions(+)
> 

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


Re: [PATCH 1/9] drm/vblank: Add vblank works

2020-04-14 Thread Lyude Paul
On Mon, 2020-04-13 at 16:42 -0400, Tejun Heo wrote:
> Hello,
> 
> On Mon, Apr 13, 2020 at 04:18:57PM -0400, Lyude Paul wrote:
> > Hi Tejun! Sorry to bother you, but have you had a chance to look at any of
> > this yet? Would like to continue moving this forward
> 
> Sorry, wasn't following this thread. Have you looked at kthread_worker?
> 

Hi, thanks for the response! And yes-I think this would actually be perfect
for what we need, I guess one question I might as well ask since I've got you
here: would patches to expose an unlocked version of kthread_queue_worker() be
accepted? With something like that I should be able to just reuse the
delayed_work_list and spinlocks that come with kthread_worker which would make
the vblank works implementation a bit easier
>  
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/kthread.h#n71
> 
> And, thanks a lot for the vblank explanation. I really enjoyed readin it. :)
> 
-- 
Cheers,
Lyude Paul (she/her)
Associate Software Engineer at Red Hat

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


[PATCH v2 11/33] docs: filesystems: fix renamed references

2020-04-14 Thread Mauro Carvalho Chehab
Some filesystem references got broken by a previous patch
series I submitted. Address those.

Signed-off-by: Mauro Carvalho Chehab 
Acked-by: David Sterba  # fs/affs/Kconfig
---
 Documentation/ABI/stable/sysfs-devices-node | 2 +-
 Documentation/ABI/testing/procfs-smaps_rollup   | 2 +-
 Documentation/admin-guide/cpu-load.rst  | 2 +-
 Documentation/admin-guide/nfs/nfsroot.rst   | 2 +-
 Documentation/driver-api/driver-model/device.rst| 4 ++--
 Documentation/driver-api/driver-model/overview.rst  | 2 +-
 Documentation/filesystems/dax.txt   | 2 +-
 Documentation/filesystems/dnotify.txt   | 2 +-
 Documentation/filesystems/ramfs-rootfs-initramfs.rst| 2 +-
 Documentation/filesystems/sysfs.rst | 2 +-
 Documentation/powerpc/firmware-assisted-dump.rst| 2 +-
 Documentation/process/adding-syscalls.rst   | 2 +-
 .../translations/it_IT/process/adding-syscalls.rst  | 2 +-
 Documentation/translations/zh_CN/filesystems/sysfs.txt  | 6 +++---
 drivers/base/core.c | 2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 +-
 fs/Kconfig  | 2 +-
 fs/Kconfig.binfmt   | 2 +-
 fs/adfs/Kconfig | 2 +-
 fs/affs/Kconfig | 2 +-
 fs/afs/Kconfig  | 6 +++---
 fs/bfs/Kconfig  | 2 +-
 fs/cramfs/Kconfig   | 2 +-
 fs/ecryptfs/Kconfig | 2 +-
 fs/hfs/Kconfig  | 2 +-
 fs/hpfs/Kconfig | 2 +-
 fs/isofs/Kconfig| 2 +-
 fs/namespace.c  | 2 +-
 fs/notify/inotify/Kconfig   | 2 +-
 fs/ntfs/Kconfig | 2 +-
 fs/ocfs2/Kconfig| 2 +-
 fs/proc/Kconfig | 4 ++--
 fs/romfs/Kconfig| 2 +-
 fs/sysfs/dir.c  | 2 +-
 fs/sysfs/file.c | 2 +-
 fs/sysfs/mount.c| 2 +-
 fs/sysfs/symlink.c  | 2 +-
 fs/sysv/Kconfig | 2 +-
 fs/udf/Kconfig  | 2 +-
 include/linux/kobject.h | 2 +-
 include/linux/kobject_ns.h  | 2 +-
 include/linux/relay.h   | 2 +-
 include/linux/sysfs.h   | 2 +-
 kernel/relay.c  | 2 +-
 lib/kobject.c   | 4 ++--
 45 files changed, 52 insertions(+), 52 deletions(-)

diff --git a/Documentation/ABI/stable/sysfs-devices-node 
b/Documentation/ABI/stable/sysfs-devices-node
index df8413cf1468..484fc04bcc25 100644
--- a/Documentation/ABI/stable/sysfs-devices-node
+++ b/Documentation/ABI/stable/sysfs-devices-node
@@ -54,7 +54,7 @@ Date: October 2002
 Contact:   Linux Memory Management list 
 Description:
Provides information about the node's distribution and memory
-   utilization. Similar to /proc/meminfo, see 
Documentation/filesystems/proc.txt
+   utilization. Similar to /proc/meminfo, see 
Documentation/filesystems/proc.rst
 
 What:  /sys/devices/system/node/nodeX/numastat
 Date:  October 2002
diff --git a/Documentation/ABI/testing/procfs-smaps_rollup 
b/Documentation/ABI/testing/procfs-smaps_rollup
index 274df44d8b1b..046978193368 100644
--- a/Documentation/ABI/testing/procfs-smaps_rollup
+++ b/Documentation/ABI/testing/procfs-smaps_rollup
@@ -11,7 +11,7 @@ Description:
Additionally, the fields Pss_Anon, Pss_File and Pss_Shmem
are not present in /proc/pid/smaps.  These fields represent
the sum of the Pss field of each type (anon, file, shmem).
-   For more details, see Documentation/filesystems/proc.txt
+   For more details, see Documentation/filesystems/proc.rst
and the procfs man page.
 
Typical output looks like this:
diff --git a/Documentation/admin-guide/cpu-load.rst 
b/Documentation/admin-guide/cpu-load.rst
index 2d01ce43d2a2..ebdecf864080 100644
--- a/Documentation/admin-guide/cpu-load.rst
+++ b/Documentation/admin-guide/cpu-load.rst
@@ -105,7 +105,7 @@ 

[PATCH v2 00/33] Documentation fixes for Kernel 5.8

2020-04-14 Thread Mauro Carvalho Chehab
Patches 1 to 5 contain changes to the documentation toolset:

- The first 3 patches help to reduce a lot the number of reported
  kernel-doc issues, by making the tool more smart.

- Patches 4 and 5 are meant to partially address the PDF
  build, with now requires Sphinx version 2.4 or upper.

The remaining patches fix broken references detected by
this tool:

./scripts/documentation-file-ref-check

and address other random errors due to tags being mis-interpreted
or mis-used.

They are independent each other, but some may depend on
the kernel-doc improvements.

PS.: Due to the large number of C/C, I opted to keep a smaller
set of C/C at this first e-mail (only e-mails with "L:" tag from
MAINTAINERS file).

Jon,

Those patches should apply cleanly at docs-next, once you
pull from v5.7-rc1.


-

v2:

- patches re-ordered;
- added reviewed/acked-by tags;
- rebased on the top of docs-next + v5.7-rc1.


Mauro Carvalho Chehab (33):
  scripts: kernel-doc: proper handle @foo->bar()
  scripts: kernel-doc: accept negation like !@var
  scripts: kernel-doc: accept blank lines on parameter description
  docs: update recommended Sphinx version to 2.4.4
  docs: LaTeX/PDF: drop list of documents
  MAINTAINERS: dt: update display/allwinner file entry
  MAINTAINERS: dt: fix pointers for ARM Integrator, Versatile and
RealView
  docs: dt: fix broken reference to phy-cadence-torrent.yaml
  docs: fix broken references to text files
  docs: fix broken references for ReST files that moved around
  docs: filesystems: fix renamed references
  docs: amu: supress some Sphinx warnings
  docs: arm64: booting.rst: get rid of some warnings
  docs: pci: boot-interrupts.rst: improve html output
  docs: ras: get rid of some warnings
  docs: ras: don't need to repeat twice the same thing
  docs: infiniband: verbs.c: fix some documentation warnings
  docs: spi: spi.h: fix a doc building warning
  docs: drivers: fix some warnings at base/platform.c when building docs
  docs: mm: userfaultfd.rst: use ``foo`` for literals
  docs: mm: userfaultfd.rst: use a cross-reference for a section
  docs: vm: index.rst: add an orphan doc to the building system
  docs: dt: qcom,dwc3.txt: fix cross-reference for a converted file
  docs: dt: fix a broken reference for a file converted to json
  docs: powerpc: cxl.rst: mark two section titles as such
  docs: i2c: rename i2c.svg to i2c_bus.svg
  docs: Makefile: place final pdf docs on a separate dir
  docs: dt: rockchip,dwc3.txt: fix a pointer to a renamed file
  ata: libata-core: fix a doc warning
  firewire: firewire-cdev.hL get rid of a docs warning
  fs: inode.c: get rid of docs warnings
  futex: get rid of a kernel-docs build warning
  lib: bitmap.c: get rid of some doc warnings

 Documentation/ABI/stable/sysfs-devices-node   |   2 +-
 Documentation/ABI/testing/procfs-smaps_rollup |   2 +-
 Documentation/Makefile|   6 +-
 Documentation/PCI/boot-interrupts.rst |  34 +--
 Documentation/admin-guide/cpu-load.rst|   2 +-
 Documentation/admin-guide/mm/userfaultfd.rst  | 209 +-
 Documentation/admin-guide/nfs/nfsroot.rst |   2 +-
 Documentation/admin-guide/ras.rst |  18 +-
 Documentation/arm64/amu.rst   |   5 +
 Documentation/arm64/booting.rst   |  36 +--
 Documentation/conf.py |  38 
 .../bindings/net/qualcomm-bluetooth.txt   |   2 +-
 .../bindings/phy/ti,phy-j721e-wiz.yaml|   2 +-
 .../devicetree/bindings/usb/qcom,dwc3.txt |   4 +-
 .../devicetree/bindings/usb/rockchip,dwc3.txt |   2 +-
 .../doc-guide/maintainer-profile.rst  |   2 +-
 .../driver-api/driver-model/device.rst|   4 +-
 .../driver-api/driver-model/overview.rst  |   2 +-
 Documentation/filesystems/dax.txt |   2 +-
 Documentation/filesystems/dnotify.txt |   2 +-
 .../filesystems/ramfs-rootfs-initramfs.rst|   2 +-
 Documentation/filesystems/sysfs.rst   |   2 +-
 Documentation/i2c/{i2c.svg => i2c_bus.svg}|   2 +-
 Documentation/i2c/summary.rst |   2 +-
 Documentation/memory-barriers.txt |   2 +-
 Documentation/powerpc/cxl.rst |   2 +
 .../powerpc/firmware-assisted-dump.rst|   2 +-
 Documentation/process/adding-syscalls.rst |   2 +-
 Documentation/process/submit-checklist.rst|   2 +-
 Documentation/sphinx/requirements.txt |   2 +-
 .../it_IT/process/adding-syscalls.rst |   2 +-
 .../it_IT/process/submit-checklist.rst|   2 +-
 .../translations/ko_KR/memory-barriers.txt|   2 +-
 .../translations/zh_CN/filesystems/sysfs.txt  |   8 +-
 .../zh_CN/process/submit-checklist.rst|   2 +-
 Documentation/virt/kvm/arm/pvtime.rst |   2 +-
 Documentation/virt/kvm/devices/vcpu.rst   |   2 +-
 Documentation/virt/kvm/hypercalls.rst |   4 +-
 Documentation/virt/kvm/mmu.rst|   2 +-
 Documentation/virt/kvm/review-checklist.rst   |   2 +-

[PATCH v2 09/33] docs: fix broken references to text files

2020-04-14 Thread Mauro Carvalho Chehab
Several references got broken due to txt to ReST conversion.

Several of them can be automatically fixed with:

scripts/documentation-file-ref-check --fix

Reviewed-by: Mathieu Poirier  # 
hwtracing/coresight/Kconfig
Reviewed-by: Paul E. McKenney  # memory-barrier.txt
Acked-by: Alex Shi  # translations/zh_CN
Acked-by: Federico Vaga  # translations/it_IT
Acked-by: Marc Zyngier  # kvm/arm64
Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/memory-barriers.txt|  2 +-
 Documentation/process/submit-checklist.rst   |  2 +-
 .../translations/it_IT/process/submit-checklist.rst  |  2 +-
 Documentation/translations/ko_KR/memory-barriers.txt |  2 +-
 .../translations/zh_CN/filesystems/sysfs.txt |  2 +-
 .../translations/zh_CN/process/submit-checklist.rst  |  2 +-
 Documentation/virt/kvm/arm/pvtime.rst|  2 +-
 Documentation/virt/kvm/devices/vcpu.rst  |  2 +-
 Documentation/virt/kvm/hypercalls.rst|  4 ++--
 arch/powerpc/include/uapi/asm/kvm_para.h |  2 +-
 drivers/gpu/drm/Kconfig  |  2 +-
 drivers/gpu/drm/drm_ioctl.c  |  2 +-
 drivers/hwtracing/coresight/Kconfig  |  2 +-
 fs/fat/Kconfig   |  8 
 fs/fuse/Kconfig  |  2 +-
 fs/fuse/dev.c|  2 +-
 fs/overlayfs/Kconfig |  6 +++---
 include/linux/mm.h   |  4 ++--
 include/uapi/linux/ethtool_netlink.h |  2 +-
 include/uapi/rdma/rdma_user_ioctl_cmds.h |  2 +-
 mm/gup.c | 12 ++--
 virt/kvm/arm/vgic/vgic-mmio-v3.c |  2 +-
 virt/kvm/arm/vgic/vgic.h |  4 ++--
 23 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/Documentation/memory-barriers.txt 
b/Documentation/memory-barriers.txt
index e1c355e84edd..eaabc3134294 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -620,7 +620,7 @@ because the CPUs that the Linux kernel supports don't do 
writes
 until they are certain (1) that the write will actually happen, (2)
 of the location of the write, and (3) of the value to be written.
 But please carefully read the "CONTROL DEPENDENCIES" section and the
-Documentation/RCU/rcu_dereference.txt file:  The compiler can and does
+Documentation/RCU/rcu_dereference.rst file:  The compiler can and does
 break dependencies in a great many highly creative ways.
 
CPU 1 CPU 2
diff --git a/Documentation/process/submit-checklist.rst 
b/Documentation/process/submit-checklist.rst
index 8e56337d422d..3f8e9d5d95c2 100644
--- a/Documentation/process/submit-checklist.rst
+++ b/Documentation/process/submit-checklist.rst
@@ -107,7 +107,7 @@ and elsewhere regarding submitting Linux kernel patches.
 and why.
 
 26) If any ioctl's are added by the patch, then also update
-``Documentation/ioctl/ioctl-number.rst``.
+``Documentation/userspace-api/ioctl/ioctl-number.rst``.
 
 27) If your modified source code depends on or uses any of the kernel
 APIs or features that are related to the following ``Kconfig`` symbols,
diff --git a/Documentation/translations/it_IT/process/submit-checklist.rst 
b/Documentation/translations/it_IT/process/submit-checklist.rst
index 995ee69fab11..3e575502690f 100644
--- a/Documentation/translations/it_IT/process/submit-checklist.rst
+++ b/Documentation/translations/it_IT/process/submit-checklist.rst
@@ -117,7 +117,7 @@ sottomissione delle patch, in particolare
 sorgenti che ne spieghi la logica: cosa fanno e perché.
 
 25) Se la patch aggiunge nuove chiamate ioctl, allora aggiornate
-``Documentation/ioctl/ioctl-number.rst``.
+``Documentation/userspace-api/ioctl/ioctl-number.rst``.
 
 26) Se il codice che avete modificato dipende o usa una qualsiasi interfaccia o
 funzionalità del kernel che è associata a uno dei seguenti simboli
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt 
b/Documentation/translations/ko_KR/memory-barriers.txt
index 2e831ece6e26..e50fe6541335 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -641,7 +641,7 @@ P 는 짝수 번호 캐시 라인에 저장되어 있고, 변수 B 는 홀수 
 리눅스 커널이 지원하는 CPU 들은 (1) 쓰기가 정말로 일어날지, (2) 쓰기가 어디에
 이루어질지, 그리고 (3) 쓰여질 값을 확실히 알기 전까지는 쓰기를 수행하지 않기
 때문입니다.  하지만 "컨트롤 의존성" 섹션과
-Documentation/RCU/rcu_dereference.txt 파일을 주의 깊게 읽어 주시기 바랍니다:
+Documentation/RCU/rcu_dereference.rst 파일을 주의 깊게 읽어 주시기 바랍니다:
 컴파일러는 매우 창의적인 많은 방법으로 종속성을 깰 수 있습니다.
 
CPU 1 CPU 2
diff --git a/Documentation/translations/zh_CN/filesystems/sysfs.txt 
b/Documentation/translations/zh_CN/filesystems/sysfs.txt
index ee1f37da5b23..a15c3ebdfa82 100644
--- a/Documentation/translations/zh_CN/filesystems/sysfs.txt
+++ b

Re: [PATCH 03/44] drm/device: Deprecate dev_private harder

2020-04-14 Thread Daniel Vetter
On Wed, Apr 08, 2020 at 09:02:07AM +0200, Sam Ravnborg wrote:
> On Fri, Apr 03, 2020 at 03:57:47PM +0200, Daniel Vetter wrote:
> > We've had lots of conversions to embeddeding, but didn't stop using
> > ->dev_private. Which defeats the point of this.
> > 
> > Signed-off-by: Daniel Vetter 
> Reviewed-by: Sam Ravnborg 

Went right ahead and pushed this since a doc patch only, thanks for taking
a look!
-Daniel

> > ---
> >  include/drm/drm_device.h | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> > 
> > diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> > index d39132b477dd..a55874db9dd4 100644
> > --- a/include/drm/drm_device.h
> > +++ b/include/drm/drm_device.h
> > @@ -88,9 +88,12 @@ struct drm_device {
> > /**
> >  * @dev_private:
> >  *
> > -* DRM driver private data. Instead of using this pointer it is
> > -* recommended that drivers use drm_dev_init() and embed struct
> > -* &drm_device in their larger per-device structure.
> > +* DRM driver private data. This is deprecated and should be left set to
> > +* NULL.
> > +*
> > +* Instead of using this pointer it is recommended that drivers use
> > +* drm_dev_init() and embed struct &drm_device in their larger
> > +* per-device structure.
> >  */
> > void *dev_private;
> >  
> > -- 
> > 2.25.1
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 09/44] drm/vboxvidoe: use managed pci functions

2020-04-14 Thread Daniel Vetter
On Wed, Apr 08, 2020 at 09:21:46AM +0200, Sam Ravnborg wrote:
> On Fri, Apr 03, 2020 at 03:57:53PM +0200, Daniel Vetter wrote:
> > Allows us to drop the cleanup code on the floor.
> > 
> > Signed-off-by: Daniel Vetter 
> > Cc: Hans de Goede 
> 
> With this change we avoid calling pci_disable_device()
> twise in case vbox_mm_init() fails.
> Once in vbox_hw_fini() and once in the error path.

Yup, I forgot to mention this in the commit message. I've added your
remark here as a quote, thanks for checking stuff in detail.
-Daniel

> 
> Which is just a small extra bonus.
> 
> Acked-by: Sam Ravnborg 
> 
> > ---
> >  drivers/gpu/drm/vboxvideo/vbox_drv.c  | 6 ++
> >  drivers/gpu/drm/vboxvideo/vbox_main.c | 7 +--
> >  2 files changed, 3 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c 
> > b/drivers/gpu/drm/vboxvideo/vbox_drv.c
> > index d34cddd809fd..c80695c2f6c0 100644
> > --- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
> > +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
> > @@ -55,13 +55,13 @@ static int vbox_pci_probe(struct pci_dev *pdev, const 
> > struct pci_device_id *ent)
> > pci_set_drvdata(pdev, vbox);
> > mutex_init(&vbox->hw_mutex);
> >  
> > -   ret = pci_enable_device(pdev);
> > +   ret = pcim_enable_device(pdev);
> > if (ret)
> > return ret;
> >  
> > ret = vbox_hw_init(vbox);
> > if (ret)
> > -   goto err_pci_disable;
> > +   return ret;
> >  
> > ret = vbox_mm_init(vbox);
> > if (ret)
> > @@ -93,8 +93,6 @@ static int vbox_pci_probe(struct pci_dev *pdev, const 
> > struct pci_device_id *ent)
> > vbox_mm_fini(vbox);
> >  err_hw_fini:
> > vbox_hw_fini(vbox);
> > -err_pci_disable:
> > -   pci_disable_device(pdev);
> > return ret;
> >  }
> >  
> > diff --git a/drivers/gpu/drm/vboxvideo/vbox_main.c 
> > b/drivers/gpu/drm/vboxvideo/vbox_main.c
> > index 9dcab115a261..1336ab9795fc 100644
> > --- a/drivers/gpu/drm/vboxvideo/vbox_main.c
> > +++ b/drivers/gpu/drm/vboxvideo/vbox_main.c
> > @@ -71,8 +71,6 @@ static void vbox_accel_fini(struct vbox_private *vbox)
> >  
> > for (i = 0; i < vbox->num_crtcs; ++i)
> > vbva_disable(&vbox->vbva_info[i], vbox->guest_pool, i);
> > -
> > -   pci_iounmap(vbox->ddev.pdev, vbox->vbva_buffers);
> >  }
> >  
> >  /* Do we support the 4.3 plus mode hint reporting interface? */
> > @@ -125,7 +123,7 @@ int vbox_hw_init(struct vbox_private *vbox)
> > /* Create guest-heap mem-pool use 2^4 = 16 byte chunks */
> > vbox->guest_pool = gen_pool_create(4, -1);
> > if (!vbox->guest_pool)
> > -   goto err_unmap_guest_heap;
> > +   return -ENOMEM;
> >  
> > ret = gen_pool_add_virt(vbox->guest_pool,
> > (unsigned long)vbox->guest_heap,
> > @@ -168,8 +166,6 @@ int vbox_hw_init(struct vbox_private *vbox)
> >  
> >  err_destroy_guest_pool:
> > gen_pool_destroy(vbox->guest_pool);
> > -err_unmap_guest_heap:
> > -   pci_iounmap(vbox->ddev.pdev, vbox->guest_heap);
> > return ret;
> >  }
> >  
> > @@ -177,5 +173,4 @@ void vbox_hw_fini(struct vbox_private *vbox)
> >  {
> > vbox_accel_fini(vbox);
> > gen_pool_destroy(vbox->guest_pool);
> > -   pci_iounmap(vbox->ddev.pdev, vbox->guest_heap);
> >  }
> > -- 
> > 2.25.1
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 1/1] dt-bindings: display: allow port and ports in panel-lvds

2020-04-14 Thread Sam Ravnborg
Hi Rob.

> > Cc: Thierry Reding 
> > Cc: dri-devel@lists.freedesktop.org
> > ---
> >  .../devicetree/bindings/display/panel/lvds.yaml| 10 +-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> Reviewed-by: Rob Herring 
> 
> One nit below...
> 
> > 
> > diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml 
> > b/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > index d0083301acbe..a5587c4f5ad0 100644
> > --- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
> > @@ -96,12 +96,20 @@ properties:
> >If set, reverse the bit order described in the data mappings below 
> > on all
> >data lanes, transmitting bits for slots 6 to 0 instead of 0 to 6.
> >  
> > +  port: true
> > +  ports: true
> > +
> >  required:
> >- compatible
> >- data-mapping
> >- width-mm
> >- height-mm
> >- panel-timing
> > -  - port
> > +
> > +oneOf:
> > +  - required:
> > +- port
> > +  - required:
> > +- ports
> 
> Should be indented 2 more spaces. It only matters for any scripted 
> processing we do on the files.

Fixed and pushed to drm-misc-next.
Will cherry-pick to drm-fixes.

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


Re: [RFC 4/6] drm/bridge/sii8620: fix extcon dependency

2020-04-14 Thread Daniel Vetter
On Tue, Apr 14, 2020 at 5:05 PM Arnd Bergmann  wrote:
>
> On Fri, Apr 10, 2020 at 8:56 AM Andrzej Hajda  wrote:
> >
> >
> > On 08.04.2020 22:27, Arnd Bergmann wrote:
> > > Using 'imply' does not work here, it still cause the same build
> > > failure:
> > >
> > > arm-linux-gnueabi-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function 
> > > `sii8620_remove':
> > > sil-sii8620.c:(.text+0x1b8): undefined reference to 
> > > `extcon_unregister_notifier'
> > > arm-linux-gnueabi-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function 
> > > `sii8620_probe':
> > > sil-sii8620.c:(.text+0x27e8): undefined reference to 
> > > `extcon_find_edev_by_node'
> > > arm-linux-gnueabi-ld: sil-sii8620.c:(.text+0x2870): undefined reference 
> > > to `extcon_register_notifier'
> > > arm-linux-gnueabi-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function 
> > > `sii8620_extcon_work':
> > > sil-sii8620.c:(.text+0x2908): undefined reference to `extcon_get_state'
> > >
> > > I tried the usual 'depends on EXTCON || !EXTCON' logic, but that caused
> > > a circular Kconfig dependency. Using IS_REACHABLE() is ugly but works.
> >
> > 'depends on EXTCON || !EXTCON' seems to be proper solution, maybe would be 
> > better to try to solve circular dependencies issue.
>
> I agree that would be nice, but I failed to come to a proper solution
> here. FWIW, there
> is one circular dependency that I managed to avoid by changing all
> drivers that select FB_DDC
> to depend on I2C rather than selecting it:
>
> drivers/i2c/Kconfig:8:error: recursive dependency detected!
> drivers/i2c/Kconfig:8: symbol I2C is selected by FB_DDC
> drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB
> drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
> drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by 
> DRM_SIL_SII8620
> drivers/gpu/drm/bridge/Kconfig:89: symbol DRM_SIL_SII8620 depends on EXTCON
> drivers/extcon/Kconfig:2: symbol EXTCON is selected by CHARGER_MANAGER
> drivers/power/supply/Kconfig:482: symbol CHARGER_MANAGER depends on 
> POWER_SUPPLY
> drivers/power/supply/Kconfig:2: symbol POWER_SUPPLY is selected by
> HID_BATTERY_STRENGTH
> drivers/hid/Kconfig:29: symbol HID_BATTERY_STRENGTH depends on HID
> drivers/hid/Kconfig:8: symbol HID is selected by I2C_HID
> drivers/hid/i2c-hid/Kconfig:5: symbol I2C_HID depends on I2C
>
> After that, Kconfig crashes with a segfault:
>
> drivers/video/fbdev/Kconfig:12:error: recursive dependency detected!
> drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
> drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by 
> DRM_SIL_SII8620
> drivers/gpu/drm/bridge/Kconfig:89: symbol DRM_SIL_SII8620 depends on EXTCON
> drivers/extcon/Kconfig:2: symbol EXTCON is selected by CHARGER_MANAGER
> drivers/power/supply/Kconfig:482: symbol CHARGER_MANAGER depends on 
> POWER_SUPPLY
> drivers/power/supply/Kconfig:2: symbol POWER_SUPPLY is selected by HID_ASUS
> drivers/hid/Kconfig:150: symbol HID_ASUS depends on LEDS_CLASS
> drivers/leds/Kconfig:17: symbol LEDS_CLASS depends on NEW_LEDS
> drivers/leds/Kconfig:9: symbol NEW_LEDS is selected by SENSORS_APPLESMC
> drivers/hwmon/Kconfig:327: symbol SENSORS_APPLESMC depends on HWMON
> drivers/hwmon/Kconfig:6: symbol HWMON is selected by EEEPC_LAPTOP
> drivers/platform/x86/Kconfig:260: symbol EEEPC_LAPTOP depends on ACPI_VIDEO
> make[3]: *** [/git/arm-soc/scripts/kconfig/Makefile:71: randconfig]
> Segmentation fault (core dumped)
>
> After changing EEEPC_LAPTOP and THINKPAD_ACPI to 'depends on HWMON' instead of
> 'select HWMON', I get this one:
>
> drivers/video/fbdev/Kconfig:12:error: recursive dependency detected!
> drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
> drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by 
> DRM_SIL_SII8620
> drivers/gpu/drm/bridge/Kconfig:89: symbol DRM_SIL_SII8620 depends on EXTCON
> drivers/extcon/Kconfig:2: symbol EXTCON is selected by CHARGER_MANAGER
> drivers/power/supply/Kconfig:482: symbol CHARGER_MANAGER depends on 
> POWER_SUPPLY
> drivers/power/supply/Kconfig:2: symbol POWER_SUPPLY is selected by HID_ASUS
> drivers/hid/Kconfig:150: symbol HID_ASUS depends on LEDS_CLASS
> drivers/leds/Kconfig:17: symbol LEDS_CLASS depends on NEW_LEDS
> drivers/leds/Kconfig:9: symbol NEW_LEDS is selected by BACKLIGHT_ADP8860
> drivers/video/backlight/Kconfig:316: symbol BACKLIGHT_ADP8860 depends
> on BACKLIGHT_CLASS_DEVICE
> drivers/video/backlight/Kconfig:143: symbol BACKLIGHT_CLASS_DEVICE is
> selected by FB_BACKLIGHT
> drivers/video/fbdev/Kconfig:187: symbol FB_BACKLIGHT depends on FB
>
> Changing all drivers that select 'FB_BACKLIGHT' or 'BACKLIGHT_CLASS_DEVICE' to
> 'depends on BACKLIGHT_CLASS_DEVICE' gets it to bui

Re: [RFC 0/6] Regressions for "imply" behavior change

2020-04-14 Thread Arnd Bergmann
On Tue, Apr 14, 2020 at 5:23 PM Jason Gunthorpe  wrote:
>
> On Tue, Apr 14, 2020 at 04:27:41PM +0200, Arnd Bergmann wrote:
> > On Tue, Apr 14, 2020 at 3:29 PM Jason Gunthorpe  wrote:
> > > On Fri, Apr 10, 2020 at 07:04:27PM +, Saeed Mahameed wrote:
> > which in turn leads to mlx5_core.ko *not* containing mlx5_vxlan.o,
> > and in turn causing that link error against
> > mlx5_vxlan_create/mlx5_vxlan_destroy, unless the IS_ENABLED()
> > is changed to IS_REACHABLE().
>
> What about the reverse if mlx5_core is 'm' and VLXAN is 'y'?
>
>  mlx5_core-m := mlx5_core.o
>  mlx5_core-y += mlx5_vxlan.o
>
> Magically works out?

Yes, Kbuild takes care of that case.

> > > IIRC that isn't what the expression does, if vxlan is 'n' then
> > >   n || !n == true
> >
> > It forces MLX5_CORE to 'm' or 'n' but not 'y' if VXLAN=m,
> > but allows any option if VXLAN=y
>
> And any option if VXLAN=n ?

Correct.

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


[PATCH v6 3/8] drm: bridge: synopsis: add dsi v1.01 support

2020-04-14 Thread 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.

Tested-by: Adrian Pop 
Tested-by: Arnaud Ferraris 
Signed-off-by: Adrian Ratiu 
---
Changes since v5:
  - Fixed cfg_phy_status range from [0,0] to [0,2]

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 f72643e25669..0ce2697d17a3 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

[PATCH v6 6/8] drm: stm: dw-mipi-dsi: let the bridge handle the HW version check

2020-04-14 Thread Adrian Ratiu
The stm mipi-dsi platform driver added a version test in
commit fa6251a747b7 ("drm/stm: dsi: check hardware version")
so that HW revisions other than v1.3x get rejected. The rockchip
driver had no such check and just assumed register layouts are
v1.3x compatible.

Having such tests was a good idea because only v130/v131 layouts
were supported at the time, however since adding multiple layout
support in the bridge, the version is automatically checked for
all drivers, compatible layouts get picked and unsupported HW is
automatically rejected by the bridge, so there's no use keeping
the test in the stm driver.

The main reason prompting this change is that the stm driver
test immediately disabled the peripheral clock after reading
the version, making the bridge read version 0x0 immediately
after in its own probe(), so we move the clock disabling after
the bridge does the version test.

Tested on STM32F769 and STM32MP1.

Cc: linux-st...@st-md-mailman.stormreply.com
Reported-by: Adrian Pop 
Tested-by: Adrian Pop 
Tested-by: Arnaud Ferraris 
Signed-off-by: Adrian Ratiu 
---
New in v6.
---
 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index 2e1f2664495d..7218e405d7e2 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -402,15 +402,6 @@ static int dw_mipi_dsi_stm_probe(struct platform_device 
*pdev)
goto err_dsi_probe;
}
 
-   dsi->hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
-   clk_disable_unprepare(pclk);
-
-   if (dsi->hw_version != HWVER_130 && dsi->hw_version != HWVER_131) {
-   ret = -ENODEV;
-   DRM_ERROR("bad dsi hardware version\n");
-   goto err_dsi_probe;
-   }
-
dw_mipi_dsi_stm_plat_data.base = dsi->base;
dw_mipi_dsi_stm_plat_data.priv_data = dsi;
 
@@ -423,6 +414,9 @@ static int dw_mipi_dsi_stm_probe(struct platform_device 
*pdev)
goto err_dsi_probe;
}
 
+   dsi->hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
+   clk_disable_unprepare(pclk);
+
return 0;
 
 err_dsi_probe:
-- 
2.26.0

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


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

2020-04-14 Thread 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 

Cc: Fabio Estevam 
Reviewed-by: Emil Velikov 
Tested-by: Adrian Pop 
Tested-by: Arnaud Ferraris 
Signed-off-by: Sjoerd Simons 
Signed-off-by: Martyn Welch 
Signed-off-by: Adrian Ratiu 
---
Changes since v5:
  - Reword to remove unrelated device tree patch mention (Fabio)
  - Move pllref_clk enable/disable to bind/unbind (Ezequiel)
  - Fix freescale.com -> nxp.com email addresses (Fabio)
  - Also added myself as module author (Fabio)
  - Use DRM_DEV_* macros for consistency, print more error msg

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 | 409 +
 3 files changed, 417 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 ..6914db8ce8cb
--- /dev/null
+++ b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
@@ -0,0 +1,409 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * i.MX6 drm driver - MIPI DSI Host Controller
+ *
+ * Copyright (C) 2011-2015 Freescale Semiconductor, Inc.
+ * Copyright (C) 2019-2020 Collabora, Ltd.
+ */
+
+#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,
+

[PATCH v6 7/8] drm: bridge: dw-mipi-dsi: split low power cfg register into fields

2020-04-14 Thread Adrian Ratiu
According to the Host Registers documentation for IMX, STM and RK
the LP cfg register should not be written entirely in one go because
some bits are reserved and should be kept to reset values, for eg.
BIT(15) which is reserved in all versions.

This also cleans up the code by removing the the ugly defines
and making field ranges & values written more explicit.

Tested-by: Adrian Pop 
Tested-by: Arnaud Ferraris 
Signed-off-by: Adrian Ratiu 
---
New in v6.
---
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 105 ++
 1 file changed, 33 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 0ce2697d17a3..cbbe31c0dbac 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -120,60 +120,6 @@
 #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)
-#define DCS_SW_1P_TX_LPBIT(17)
-#define DCS_SW_0P_TX_LPBIT(16)
-#define GEN_LW_TX_LP   BIT(14)
-#define GEN_SR_2P_TX_LPBIT(13)
-#define GEN_SR_1P_TX_LPBIT(12)
-#define GEN_SR_0P_TX_LPBIT(11)
-#define GEN_SW_2P_TX_LPBIT(10)
-#define GEN_SW_1P_TX_LPBIT(9)
-#define GEN_SW_0P_TX_LPBIT(8)
-#define TEAR_FX_EN BIT(0)
-
-#define CMD_MODE_ALL_LP(MAX_RD_PKT_SIZE_LP | \
-DCS_LW_TX_LP | \
-DCS_SR_0P_TX_LP | \
-DCS_SW_1P_TX_LP | \
-DCS_SW_0P_TX_LP | \
-GEN_LW_TX_LP | \
-GEN_SR_2P_TX_LP | \
-GEN_SR_1P_TX_LP | \
-GEN_SR_0P_TX_LP | \
-GEN_SW_2P_TX_LP | \
-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
 
@@ -257,7 +203,11 @@ struct dw_mipi_dsi {
struct regmap_field *field_dpi_vsync_active_low;
struct regmap_field *field_dpi_hsync_active_low;
struct regmap_field *field_cmd_mode_ack_rqst_en;
-   struct regmap_field *field_cmd_mode_all_lp_en;
+   struct regmap_field *field_cmd_mode_gen_sw_sr_en;
+   struct regmap_field *field_cmd_mode_dcs_sw_sr_en;
+   struct regmap_field *field_cmd_mode_gen_lw_en;
+   struct regmap_field *field_cmd_mode_dcs_lw_en;
+   struct regmap_field *field_cmd_mode_max_rd_pkt_size;
struct regmap_field *field_cmd_mode_en;
struct regmap_field *field_cmd_pkt_status;
struct regmap_field *field_vid_mode_en;
@@ -315,7 +265,11 @@ struct dw_mipi_dsi_variant {
struct reg_fieldcfg_dpi_hsync_active_low;
struct reg_fieldcfg_cmd_mode_en;
struct reg_fieldcfg_cmd_mode_ack_rqst_en;
-   struct reg_fieldcfg_cmd_mode_all_lp_en;
+   struct reg_fieldcfg_cmd_mode_gen_sw_sr_en;
+   struct reg_fie

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

2020-04-14 Thread Adrian Ratiu
Hello everyone,

Many thanks to all who have contributed to this new iteration,
especially to Arnaud Ferraris for his stm32mp1 testing and to
Adrian Pop for his stm32f7 testing & debugging help.

Further testing, especially on Rockchip devices, is very much
appreciated.

All reported issues have been addressed and this series should
apply cleanly on latest next-20200414 tree.

Tested on imx6dl, stm32mp1 and stm32f7.

Best wishes,
Adrian

Adrian Ratiu (8):
  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
  drm: stm: dw-mipi-dsi: let the bridge handle the HW version check
  drm: bridge: dw-mipi-dsi: split low power cfg register into fields
  drm: bridge: dw-mipi-dsi: fix bad register field offsets

 .../display/imx/fsl,mipi-dsi-imx6.yaml| 139 
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 691 +-
 drivers/gpu/drm/imx/Kconfig   |   7 +
 drivers/gpu/drm/imx/Makefile  |   1 +
 drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c| 409 +++
 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c |  12 +-
 6 files changed, 1050 insertions(+), 209 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 v6 8/8] drm: bridge: dw-mipi-dsi: fix bad register field offsets

2020-04-14 Thread Adrian Ratiu
According to the DSI Host Registers sections available in the IMX,
STM and RK ref manuals for 1.01, 1.30 and 1.31, the register fields
are smaller or bigger than what's coded in the driver, leading to
r/w in reserved spaces which might cause undefined behaviours.

Tested-by: Adrian Pop 
Tested-by: Arnaud Ferraris 
Signed-off-by: Adrian Ratiu 
---
New in v6.
---
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 46 +--
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index cbbe31c0dbac..7f6e3d1e2ad2 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -316,7 +316,7 @@ struct dw_mipi_dsi_variant {
 static const struct dw_mipi_dsi_variant dw_mipi_dsi_v130_v131_layout = {
.cfg_dpi_color_coding = REG_FIELD(DSI_DPI_COLOR_CODING, 0, 3),
.cfg_dpi_18loosely_en = REG_FIELD(DSI_DPI_COLOR_CODING, 8, 8),
-   .cfg_dpi_vid =  REG_FIELD(DSI_DPI_VCID, 0, 2),
+   .cfg_dpi_vid =  REG_FIELD(DSI_DPI_VCID, 0, 1),
.cfg_dpi_vsync_active_low = REG_FIELD(DSI_DPI_CFG_POL, 1, 1),
.cfg_dpi_hsync_active_low = REG_FIELD(DSI_DPI_CFG_POL, 2, 2),
.cfg_cmd_mode_ack_rqst_en = REG_FIELD(DSI_CMD_MODE_CFG, 1, 1),
@@ -325,29 +325,29 @@ static const struct dw_mipi_dsi_variant 
dw_mipi_dsi_v130_v131_layout = {
.cfg_cmd_mode_dcs_sw_sr_en =REG_FIELD(DSI_CMD_MODE_CFG, 16, 18),
.cfg_cmd_mode_dcs_lw_en =   REG_FIELD(DSI_CMD_MODE_CFG, 19, 19),
.cfg_cmd_mode_max_rd_pkt_size = REG_FIELD(DSI_CMD_MODE_CFG, 24, 24),
-   .cfg_cmd_mode_en =  REG_FIELD(DSI_MODE_CFG, 0, 31),
-   .cfg_cmd_pkt_status =   REG_FIELD(DSI_CMD_PKT_STATUS, 0, 31),
-   .cfg_vid_mode_en =  REG_FIELD(DSI_MODE_CFG, 0, 31),
+   .cfg_cmd_mode_en =  REG_FIELD(DSI_MODE_CFG, 0, 0),
+   .cfg_cmd_pkt_status =   REG_FIELD(DSI_CMD_PKT_STATUS, 0, 6),
+   .cfg_vid_mode_en =  REG_FIELD(DSI_MODE_CFG, 0, 0),
.cfg_vid_mode_type =REG_FIELD(DSI_VID_MODE_CFG, 0, 1),
.cfg_vid_mode_low_power =   REG_FIELD(DSI_VID_MODE_CFG, 8, 13),
.cfg_vid_mode_vpg_en =  REG_FIELD(DSI_VID_MODE_CFG, 16, 16),
.cfg_vid_mode_vpg_horiz =   REG_FIELD(DSI_VID_MODE_CFG, 24, 24),
-   .cfg_vid_pkt_size = REG_FIELD(DSI_VID_PKT_SIZE, 0, 10),
-   .cfg_vid_hsa_time = REG_FIELD(DSI_VID_HSA_TIME, 0, 31),
-   .cfg_vid_hbp_time = REG_FIELD(DSI_VID_HBP_TIME, 0, 31),
-   .cfg_vid_hline_time =   REG_FIELD(DSI_VID_HLINE_TIME, 0, 31),
-   .cfg_vid_vsa_time = REG_FIELD(DSI_VID_VSA_LINES, 0, 31),
-   .cfg_vid_vbp_time = REG_FIELD(DSI_VID_VBP_LINES, 0, 31),
-   .cfg_vid_vfp_time = REG_FIELD(DSI_VID_VFP_LINES, 0, 31),
-   .cfg_vid_vactive_time = REG_FIELD(DSI_VID_VACTIVE_LINES, 0, 31),
+   .cfg_vid_pkt_size = REG_FIELD(DSI_VID_PKT_SIZE, 0, 13),
+   .cfg_vid_hsa_time = REG_FIELD(DSI_VID_HSA_TIME, 0, 11),
+   .cfg_vid_hbp_time = REG_FIELD(DSI_VID_HBP_TIME, 0, 11),
+   .cfg_vid_hline_time =   REG_FIELD(DSI_VID_HLINE_TIME, 0, 14),
+   .cfg_vid_vsa_time = REG_FIELD(DSI_VID_VSA_LINES, 0, 9),
+   .cfg_vid_vbp_time = REG_FIELD(DSI_VID_VBP_LINES, 0, 9),
+   .cfg_vid_vfp_time = REG_FIELD(DSI_VID_VFP_LINES, 0, 9),
+   .cfg_vid_vactive_time = REG_FIELD(DSI_VID_VACTIVE_LINES, 0, 13),
.cfg_phy_txrequestclkhs =   REG_FIELD(DSI_LPCLK_CTRL, 0, 0),
-   .cfg_phy_bta_time = REG_FIELD(DSI_BTA_TO_CNT, 0, 31),
-   .cfg_phy_max_rd_time =  REG_FIELD(DSI_PHY_TMR_CFG, 0, 15),
+   .cfg_phy_bta_time = REG_FIELD(DSI_BTA_TO_CNT, 0, 15),
+   .cfg_phy_max_rd_time =  REG_FIELD(DSI_PHY_TMR_CFG, 0, 14),
.cfg_phy_lp2hs_time =   REG_FIELD(DSI_PHY_TMR_CFG, 16, 23),
.cfg_phy_hs2lp_time =   REG_FIELD(DSI_PHY_TMR_CFG, 24, 31),
-   .cfg_phy_max_rd_time_v131 = REG_FIELD(DSI_PHY_TMR_RD_CFG, 0, 15),
-   .cfg_phy_lp2hs_time_v131 =  REG_FIELD(DSI_PHY_TMR_CFG, 0, 15),
-   .cfg_phy_hs2lp_time_v131 =  REG_FIELD(DSI_PHY_TMR_CFG, 16, 31),
+   .cfg_phy_max_rd_time_v131 = REG_FIELD(DSI_PHY_TMR_RD_CFG, 0, 14),
+   .cfg_phy_lp2hs_time_v131 =  REG_FIELD(DSI_PHY_TMR_CFG, 0, 9),
+   .cfg_phy_hs2lp_time_v131 =  REG_FIELD(DSI_PHY_TMR_CFG, 16, 25),
.cfg_phy_clklp2hs_time =REG_FIELD(DSI_PHY_TMR_LPCLK_CFG, 0, 15),
.cfg_phy_clkhs2lp_time =REG_FIELD(DSI_PHY_TMR_LPCLK_CFG, 16, 
31),
.cfg_phy_testclr =  REG_FIELD(DSI_PHY_TST_CTRL0, 0, 0),
@@ -361,11 +361,11 @@ static const struct dw_mipi_dsi_variant 
dw_mipi_dsi_v130_v131_la

[PATCH v6 1/8] drm: bridge: dw_mipi_dsi: add initial regmap infrastructure

2020-04-14 Thread 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.

Suggested-by: Ezequiel Garcia 
Tested-by: Adrian Pop 
Tested-by: Arnaud Ferraris 
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

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

2020-04-14 Thread 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: Fabio Estevam 
Cc: devicet...@vger.kernel.org
Tested-by: Adrian Pop 
Tested-by: Arnaud Ferraris 
Signed-off-by: Sjoerd Simons 
Signed-off-by: Martyn Welch 
Signed-off-by: Adrian Ratiu 
---
Changes since v5:
  - Fixed missing reg warning (Fabio)
  - Updated dt-schema and fixed warnings (Rob)

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| 139 ++
 1 file changed, 139 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 ..10e289ea219a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
@@ -0,0 +1,139 @@
+# 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 {
+#address-cells = <1>;
+#size-cells = <0>;
+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 {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+panel_in: endpoint {
+remote-endpoint = <&dsi_out>;
+};
+};
+};
+};
+};
+
+...
-- 
2.26.0

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

[PATCH v6 2/8] drm: bridge: dw_mipi_dsi: abstract register access using reg_fields

2020-04-14 Thread 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 
Tested-by: Adrian Pop 
Tested-by: Arnaud Ferraris 
Signed-off-by: Adrian Ratiu 
---
Changes since v5:
  - Fix CONFIG_DEBUG_FS build (Adrian)
  - Fix DRM_MODE_FLAG_* test negation (Adrian)
  - Fixed cfg_phy_status range from [0,0] to [0,2]
  - Replace do {} while(0) with GCC extension ({}) (Andrzej)
  - Fixed payload no-op writes on STM devices (Adrian & Arnaud)

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 | 503 --
 1 file changed, 347 insertions(+), 156 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..f72643e25669 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 

  1   2   3   >