Re: [PATCH v2 05/13] drm: panels: Constify device node argument to of_drm_find_panel()

On Sat, Nov 19, 2016 at 05:28:05AM +0200, Laurent Pinchart wrote: > The argument is never modified by the function, make it const. > > Signed-off-by: Laurent Pinchart > --- > drivers/gpu/drm/drm_panel.c | 2 +- > include/drm/drm_panel.h | 4 ++-- >

Re: [PATCH v2.1 04/13] drm: Add data transmission order bus flag

On Wed, Jan 04, 2017 at 02:39:26AM +0200, Laurent Pinchart wrote: > The flags indicate whether data is transmitted lsb to msb or msb to lsb > on the bus. > > The exact meaning is bus-type dependent. For instance, for LVDS buses > the flags indicate whether the seven data bits transmitted in a

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

> commit 9a57d58d116800a535510053136c6dd7a9c26e25 > Author: Arnd Bergmann > Date: Tue Nov 17 14:06:55 2015 +0100 > > [EXPERIMENTAL] ARM64: check implement dma_set_mask > > Needs work for coherent mask > > Signed-off-by: Arnd Bergmann

Re: [PATCH v3 06/13] drm: bridge: Add LVDS encoder driver

Hi Daniel, On Tuesday 29 Nov 2016 22:57:07 Laurent Pinchart wrote: > On Tuesday 29 Nov 2016 10:54:09 Daniel Vetter wrote: > > On Tue, Nov 29, 2016 at 11:04:36AM +0200, Laurent Pinchart wrote: > >> The LVDS encoder driver is a DRM bridge driver that supports the > >> parallel to LVDS encoders that

Re: [PATCH v2 07/13] arm64: dts: r8a7795: Add PWM support

Hi Simon, On Monday 21 Nov 2016 11:18:59 Laurent Pinchart wrote: > On Monday 21 Nov 2016 09:27:38 Geert Uytterhoeven wrote: > > On Sat, Nov 19, 2016 at 4:28 AM, Laurent Pinchart wrote: > >> Add the 7 PWM channels to the r8a7795 device tree, in the disabled > >> state. > >> > >> Signed-off-by:

[PATCH v2.1 04/13] drm: Add data transmission order bus flag

The flags indicate whether data is transmitted lsb to msb or msb to lsb on the bus. The exact meaning is bus-type dependent. For instance, for LVDS buses the flags indicate whether the seven data bits transmitted in a clock pulse are sent in normal order (msb to lsb, slots 0 to 6) or reverse

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

On Tuesday, January 3, 2017 6:44:44 PM CET Will Deacon wrote: > > @@ -347,6 +348,16 @@ static int __swiotlb_get_sgtable(struct device *dev, > > struct sg_table *sgt, > > > > static int __swiotlb_dma_supported(struct device *hwdev, u64 mask) > > { > > +#ifdef CONFIG_PCI > > + if

[PATCH 10/19] sh: Don't set the sh-sci platform data scscr CKE0 bit

The bit is only set by platforms that also set the CKE1 but, in which case its value is ignored by the device. Don't set it, this simplifies platform data and only leaves the CKE1 bit to be handled. Signed-off-by: Laurent Pinchart ---

[PATCH 18/19] serial: sh-sci: Remove unused platform data capabilities field

The field isn't set by any platform but is only used internally in the driver to hold data parsed from DT. Move it to the sci_port structure. Signed-off-by: Laurent Pinchart --- drivers/tty/serial/sh-sci.c | 11 +++ include/linux/serial_sci.h

[PATCH 16/19] serial: sh-sci: Remove the platform data dma slave rx/tx channel IDs

Only SH platforms still use platform data for the sh-sci, and none of them declare DMA channels connected to the SCI. Remove the corresponding platform data fields and simplify the driver accordingly. Signed-off-by: Laurent Pinchart ---

[PATCH 17/19] serial: sh-sci: Remove manual break debouncing

The sh-sci driver implements manual break debouncing for a few SH platforms by reading the value of the RX pin port register. This feature is optional and the driver considers all negative or zero values of the platform data port_reg field as invalid. As the four platforms that set the field to a

[PATCH 09/19] sh: Don't set the sh-sci platform data regshift field

The regshift value is computed automatically by the driver, there's no need to set it in platform data. Specify the associated memory resource lengths to ensure proper computation of the value. Signed-off-by: Laurent Pinchart ---

[PATCH 11/19] sh: Don't set the sh-sci platform data REIE bit when not implemented

According to the datasheets, the sh7760 SIM and sh7723 SCIFA instances don't implement the REIE bit. Don't set it in platform data. Signed-off-by: Laurent Pinchart --- arch/sh/kernel/cpu/sh4/setup-sh7760.c | 1 - arch/sh/kernel/cpu/sh4a/setup-sh7723.c

[PATCH 06/19] sh: Don't set the sh-sci pdata UPF_BOOT_AUTOCONF flags

The flag is set by the driver internally, don't set it in platform data. Signed-off-by: Laurent Pinchart --- arch/sh/kernel/cpu/sh2/setup-sh7619.c | 3 --- arch/sh/kernel/cpu/sh2a/setup-mxg.c| 1 - arch/sh/kernel/cpu/sh2a/setup-sh7201.c | 8

[PATCH 08/19] sh: sh3: sh770x: Fix platform data for the IRDA serial port

Even though most of its registers are 8-bit wide, the IRDA has two 16-bit registers that make it a 16-bit peripheral and not a 8-bit peripheral with addresses shifted by one. Fix the memory resource size and the platform data regshift value. Signed-off-by: Laurent Pinchart

[PATCH 13/19] serial: sh-sci: Replace regmap array with port parameters

Turn the regmap two-dimensional array to an array of port parameters and store a pointer to the port parameters in the sci_port structure. This will allow handling additional port type dependent parameters. Signed-off-by: Laurent Pinchart ---

[PATCH 05/19] sh: sh726[49]: Don't set sh-sci pdata scscr TOIE bit

The SCIF ports on sh7264 and sh7269 don't support the TOIE bit according to the datasheets. Signed-off-by: Laurent Pinchart --- arch/sh/kernel/cpu/sh2a/setup-sh7264.c | 16 arch/sh/kernel/cpu/sh2a/setup-sh7269.c | 16

[PATCH 15/19] serial: sh-sci: Extend sci_port_params with more port parameters

The fifo size, overrun register and mask, sampling rate mask and error mask all depend on the port type only and don't need to be computed at runtime. Add them to the sci_port_parameters structure. Signed-off-by: Laurent Pinchart ---

[PATCH 07/19] sh: Don't set sh-sci port_reg

The driver considers all negative or zero values of the port_reg field as invalid. The four platforms that set the field to a register address all use an address higher than 0x7fff, which is thus considered by the driver as invalid. The feature is thus never used, remove it. The feature could

[PATCH 12/19] serial: sh-sci: Remove initialization of zero fields in sci_port_params

The compiler zeros uninitialized fields, don't zero them manually. Signed-off-by: Laurent Pinchart --- drivers/tty/serial/sh-sci.c | 94 - 1 file changed, 94 deletions(-) diff --git

[PATCH 14/19] serial: sh-sci: Constify platform data

The driver modifies platform data for internal purpose only. Fix that and make the platform data structure const. Signed-off-by: Laurent Pinchart --- drivers/tty/serial/sh-sci.c | 97 +++-- 1 file changed, 49

[PATCH 01/19] serial: sh-sci: Set the SCSCR TE and RE bits in the driver

The Transmit Enable and Receive Enable bits are set in the scscr field of all instances of the sh-sci platform data. Set them in the driver directly to prepare for their removal from platform data. Signed-off-by: Laurent Pinchart ---

[PATCH 03/19] sh: Don't set sh-sci pdata scscr TE and RE bits

The bits are set by the driver internally, don't set them in platform data. Signed-off-by: Laurent Pinchart --- arch/sh/kernel/cpu/sh2/setup-sh7619.c | 6 +++--- arch/sh/kernel/cpu/sh2a/setup-mxg.c| 2 +- arch/sh/kernel/cpu/sh2a/setup-sh7201.c |

[PATCH 02/19] serial: sh-sci: Don't rely on platform data flags when not needed

The UPF_BOOT_AUTOCONF platform data flag is set by all platforms, hardcode it. The UPF_IOREMAP flag is set by a single SH platform and thus needs to be kept. However, for ARM platforms, we can base the decision on whether an OF node is present and bypass the platform data flags completely.

[PATCH 00/19] sh-sci: Platform data simplification

Hello, Most of the patches in this series have been sitting in my development tree for three years now. While rebasing all my development branches I decided it was time to send them out in case they're considered useful. I've then thrown a few additional patches in to move the driver further in

Re: [PATCH v2 01/13] devicetree/bindings: display: Document common panel properties

On Mon, Dec 19, 2016 at 10:54 AM, Laurent Pinchart wrote: > Hi Rob, > > On Monday 19 Dec 2016 09:38:49 Rob Herring wrote: >> On Sun, Dec 18, 2016 at 2:54 PM, Laurent Pinchart wrote: >> > On Tuesday 29 Nov 2016 20:23:41 Laurent Pinchart wrote: >> >> On Tuesday 29

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

On 01/03/2017 01:01 PM, Nikita Yushchenko wrote: >>> It is possible that PCI device supports 64-bit DMA addressing, and thus >>> it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host >>> bridge has limitations on inbound transactions addressing. Example of >>> such setup is

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

>> It is possible that PCI device supports 64-bit DMA addressing, and thus >> it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host >> bridge has limitations on inbound transactions addressing. Example of >> such setup is NVME SSD device connected to RCAR PCIe controller. >> >>

Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask

On Thu, Dec 29, 2016 at 11:45:03PM +0300, Nikita Yushchenko wrote: > It is possible that PCI device supports 64-bit DMA addressing, and thus > it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host > bridge has limitations on inbound transactions addressing. Example of > such

Re: [PATCH] media: entity: Catch unbalanced media_pipeline_stop calls

On 03/01/17 13:36, Laurent Pinchart wrote: > Hi Kieran, > > Thank you for the patch. > > On Tuesday 03 Jan 2017 13:12:11 Kieran Bingham wrote: >> Drivers must not perform unbalanced calls to stop the entity pipeline, >> however if they do they will fault in the core media code, as the >>

RE: [PATCH v2 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding

Hi Laurent, Geert, Thanks for the review comments. > > On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram wrote: > >> Add binding documentation for Renesas R-Car Digital Radio Interface > >> (DRIF) controller. > >> > >> Signed-off-by: Ramesh Shanmugasundaram > >>

Re: [PATCH] media: entity: Catch unbalanced media_pipeline_stop calls

Hi Kieran, Thank you for the patch. On Tuesday 03 Jan 2017 13:12:11 Kieran Bingham wrote: > Drivers must not perform unbalanced calls to stop the entity pipeline, > however if they do they will fault in the core media code, as the > entity->pipe will be set as NULL. We handle this gracefully in

[PATCH] media: entity: Catch unbalanced media_pipeline_stop calls

Drivers must not perform unbalanced calls to stop the entity pipeline, however if they do they will fault in the core media code, as the entity->pipe will be set as NULL. We handle this gracefully in the core with a WARN for the developer. Replace the erroneous check on zero streaming counts,

Re: [PATCH] clk: vc5: Add support for IDT VersaClock 5P49V5923B

Hi Marek, Thank you for the patch. On Monday 02 Jan 2017 14:46:29 Geert Uytterhoeven wrote: > On Wed, Dec 28, 2016 at 1:00 AM, Marek Vasut wrote: > > Add driver for IDT VersaClock 5 5P49V5923B chip. This chip has two > > clock inputs, XTAL or CLK, which are muxed into

Re: [PATCH] ARM: dts: r8a7791: link DU to VSPDs

Hi Sergei, On Thursday 15 Dec 2016 01:07:52 Sergei Shtylyov wrote: > Add the "vsps" property to the DU device node in order to link this node to > the VSPD nodes. > > Signed-off-by: Sergei Shtylyov I'd like to first address the issues I've pointed out on the

Re: [PATCH] ARM: dts: r8a7794: link DU to VSPD

Hi Sergei, On Thursday 29 Dec 2016 00:35:07 Sergei Shtylyov wrote: > Add the "vsps" property to the DU device node in order to link this node to > the (single) VSPD node. > > Signed-off-by: Sergei Shtylyov I'd like to first address the issues I've pointed