[PATCH v2 1/4] dt-bindings: media: rcar-vin: Describe optional ep properties

Describe the optional properties for endpoint nodes of port@0 and port@1 of the R-Car VIN driver device tree bindings documentation. Signed-off-by: Jacopo Mondi Acked-by: Niklas Söderlund ---

[PATCH v2 4/4] ARM: dts: rcar-gen2: Remove unused VIN properties

The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN driver and only confuse users. Remove them in all Gen2 SoC that use them. Signed-off-by: Jacopo Mondi --- arch/arm/boot/dts/r8a7790-lager.dts | 3 --- arch/arm/boot/dts/r8a7791-koelsch.dts | 3

[PATCH v2 2/4] dt-bindings: media: rcar-vin: Document data-active

Document 'data-active' property in R-Car VIN device tree bindings. Signed-off-by: Jacopo Mondi v1 -> v2: - HSYNC is used in place of data enable signal only when running with explicit synchronizations. - The property is no more mandatory when running with embedded

[PATCH v2 3/4] media: rcar-vin: Handle CLOCKENB pin polarity

Handle CLOCKENB pin polarity, or use HSYNC in its place if polarity is not specified and we're running on parallel data bus with explicit synchronism signals. While at there, simplify the media bus handling flags logic, inspecting flags only if the system is running on parallel media bus type and

[PATCH v2 0/4] media: rcar-vin: Brush endpoint properties

Hello, this series touches the bindings and the driver handling endpoint properties for digital subdevices of the R-Car VIN driver. The first patch simply documents what are the endpoint properties supported at the moment while the second extends them with 'data-active' one. As the VIN

[PATCH] PCI: rcar: Poll more often in rcar_pcie_wait_for_dl()

The data link active signal usually takes ~20 uSec to be asserted, poll the bit more often to avoid useless delays in this function. Use udelay() instead of usleep() for such a small delay as suggested by the timer documentation and because this will be used in atomic content later on when the

Re: [PATCH v4 2/3] arm64: dts: renesas: draak: Describe CVBS input

Hi Jacopo, Thank you for the patch. On Monday, 21 May 2018 17:45:41 EEST Jacopo Mondi wrote: > Describe CVBS video input through analog video decoder ADV7180 > connected to video input interface VIN4. > > The video input signal path is shared with HDMI video input, and > selected by on-board

[PATCH v4 2/3] arm64: dts: renesas: draak: Describe CVBS input

Describe CVBS video input through analog video decoder ADV7180 connected to video input interface VIN4. The video input signal path is shared with HDMI video input, and selected by on-board switches SW-53 and SW-54 with CVBS input selected by the default switches configuration. Signed-off-by:

[PATCH v4 3/3] arm64: dts: renesas: draak: Describe HDMI input

Describe HDMI input connector and ADV7612 HDMI decoder installed on R-Car Gen3 Draak board. The video signal routing to the HDMI decoder to the video input interface VIN4 is multiplexed with CVBS input path, and enabled/disabled through on-board switches SW-49, SW-50, SW-51 and SW-52. As the

[PATCH v4 1/3] dt-bindings: media: rcar-vin: Add R8A77995 support

Add compatible string for R-Car D3 R8A7795 to list of SoCs supported by rcar-vin driver. Signed-off-by: Jacopo Mondi Acked-by: Niklas Söderlund Reviewed-by: Laurent Pinchart Reviewed-by: Simon

[PATCH v4 0/3] arm64: dts: Draak: Enable video inputs and VIN4

Hello, this series enables HDMI, CVBS and VIN4 for R8A77995 Draak board. Compared to v3, the analog video decoder ADV7180 is now described in bindings with the compatible string "adi,adv7180cp" and its port nodes definition has been res-structured according to the chip bindings as reported by

[PATCH 03/03] arm64: dts: renesas: r8a77990: Add IPMMU devices nodes

From: Magnus Damm Add IPMMU device nodes for the R-Car E3 SoC aka r8a77990. The r8a77990 IPMMU is similar to r8a77995. Power domains are however different but the documentation seems unclear. As expected VC0 belongs to R8A77990_PD_A3VC however VP0 is for now

[PATCH 02/03] arm64: dts: renesas: r8a77980: Add IPMMU devices nodes

From: Magnus Damm Add IPMMU device nodes for the R-Car V3H SoC aka r8a77980. The r8a77980 IPMMU is quite similar to r8a77970 however VC0 has been added. The IMSSTR bit assignment has also been reworked. Power domains are also quite different however the the

[PATCH 00/03] arm64: dts: renesas: Add IPMMU device nodes

arm64: dts: renesas: Add IPMMU device nodes [PATCH 01/03] arm64: dts: renesas: r8a77965: Add IPMMU devices nodes [PATCH 02/03] arm64: dts: renesas: r8a77980: Add IPMMU devices nodes [PATCH 03/03] arm64: dts: renesas: r8a77990: Add IPMMU devices nodes This series adds IPMMU device nodes to R-Car

[PATCH 01/03] arm64: dts: renesas: r8a77965: Add IPMMU devices nodes

From: Magnus Damm Add IPMMU device nodes for the R-Car M3-N SoC aka r8a77965. The r8a77965 IPMMU is quite similar to r8a7796 however VP0 has been added and PV1 has been removed. Also the IMSSTR bit assignment has been reworked. Signed-off-by: Magnus Damm

[PATCH] iommu/ipmmu-vmsa: Document R-Car V3H and E3 IPMMU DT bindings

From: Magnus Damm Update the IPMMU DT binding documentation to include the compat strings for the IPMMU devices included in the R-Car V3H and E3 SoCs. Signed-off-by: Magnus Damm --- Developed on top of

Re: [PATCH v4 0/4] mmc: renesas_sdhi: add eMMC HS400 mode support

On 13 May 2018 at 10:23, Simon Horman wrote: > Hi Ulf, > > On Wed, Apr 18, 2018 at 11:56:56AM +0200, Simon Horman wrote: >> Hi, >> >> this patch-set provides SDHI driver support for eMMC HS400. >> >> Based on mmc-v4.17-2 >> >> Dependencies for applying these patches: >> * none

[PATCH] arm64: dts: renesas: r8a77995: Add IPMMU power domains

From: Magnus Damm Add power domain information to the R-Car D3 IPMMU device nodes. As specified by the data sheet, all the IPMMU devices are always on. Signed-off-by: Magnus Damm --- Developed on top of renesas-devel-20180518-v4.17-rc5

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven wrote: > > Indeed. From a quick glance, it looks like drivers/crypto/ccree/cc_driver.c > does not distinguish between the absence of the clock property, and an > actual error in getting the clock, and never considers any

Re: [PATCH V5] PCI: rcar: Use runtime PM to control controller clock

On 04/19/2018 12:00 PM, Geert Uytterhoeven wrote: > Hi Marek, > > On Tue, Apr 10, 2018 at 6:17 PM, Marek Vasut wrote: >> On 04/10/2018 05:28 PM, Geert Uytterhoeven wrote: >> The pairing looks as follows: >> >> .- rcar_pcie_parse_request_of_pci_ranges() >> |

Re: [PATCH V5] PCI: rcar: Use runtime PM to control controller clock

On 05/21/2018 03:03 PM, Lorenzo Pieralisi wrote: > On Mon, May 21, 2018 at 01:08:36PM +0200, Marek Vasut wrote: >> On 05/14/2018 05:49 PM, Lorenzo Pieralisi wrote: >>> On Mon, May 14, 2018 at 05:32:04PM +0200, Marek Vasut wrote: On 05/01/2018 12:55 PM, Lorenzo Pieralisi wrote: > On Fri,

[PATCH 4/4] PCI: rcar: Teardown MSI setup if rcar_pcie_enable() fails

If the rcar_pcie_enable() fails and MSIs are enabled, the setup done in rcar_pcie_enable_msi() is never undone. Add a function to tear down the MSI setup by disabling the MSI handling in the PCIe block, deallocating the pages requested for the MSIs and zapping the IRQ mapping. Signed-off-by:

[PATCH 3/4] PCI: rcar: Add missing irq_dispose_mapping() into failpath

The rcar_pcie_get_resources() is another misnomer with a side effect. The function does not only get resources, but also maps MSI IRQs via irq_of_parse_and_map(). In case anything fails afterward, the IRQ mapping must be disposed through irq_dispose_mapping() which is not done. This patch handles

[PATCH 1/4] PCI: rcar: Rename rcar_pcie_parse_request_of_pci_ranges()

The function name is just too confusing, rename it, no functional change. Rename the function to rcar_pcie_alloc_and_parse_pci_resource_list() as it's matching failpath function is pci_free_resource_list() so the names align much better and the new name also describes what the function does much

[PATCH 2/4] PCI: rcar: Pull bus clock enable/disable from rcar_pcie_get_resources()

The rcar_pcie_get_resources() is another misnomer with a side effect. The function does not only get resources, but also enables/disables bus clock. This is forgotten in the probe() function though and if anything in probe() fails after rcar_pcie_get_resources() is called, the bus clock are never

Re: [PATCH v3 2/3] arm64: dts: renesas: draak: Describe CVBS input

Hi Jacopo, On Monday, 21 May 2018 15:33:40 EEST jacopo mondi wrote: > On Mon, May 21, 2018 at 01:54:55PM +0300, Laurent Pinchart wrote: > > On Monday, 21 May 2018 12:57:05 EEST jacopo mondi wrote: > >> On Fri, May 18, 2018 at 06:12:15PM +0300, Laurent Pinchart wrote: > >>> On Friday, 18 May 2018

Re: [PATCH V5] PCI: rcar: Use runtime PM to control controller clock

On Mon, May 21, 2018 at 01:08:36PM +0200, Marek Vasut wrote: > On 05/14/2018 05:49 PM, Lorenzo Pieralisi wrote: > > On Mon, May 14, 2018 at 05:32:04PM +0200, Marek Vasut wrote: > >> On 05/01/2018 12:55 PM, Lorenzo Pieralisi wrote: > >>> On Fri, Apr 13, 2018 at 02:48:19PM +0200, Simon Horman wrote:

Re: [PATCH v3 2/3] arm64: dts: renesas: draak: Describe CVBS input

Hi Laurent, On Mon, May 21, 2018 at 01:54:55PM +0300, Laurent Pinchart wrote: > Hi Jacopo, > > On Monday, 21 May 2018 12:57:05 EEST jacopo mondi wrote: > > On Fri, May 18, 2018 at 06:12:15PM +0300, Laurent Pinchart wrote: > > > On Friday, 18 May 2018 17:47:57 EEST Jacopo Mondi wrote: > > >>

Re: [PATCH v2] usb: gadget: function: printer: avoid wrong list handling in printer_write()

Hi Greg, Yoshihiro Shimoda writes: > When printer_write() calls usb_ep_queue(), a udc driver (e.g. > renesas_usbhs driver) may call usb_gadget_giveback_request() in > the udc .queue ops immediately. Then, printer_write() calls > list_add(>list, >tx_reqs_active)

Re: [PATCH v2] mmc: renesas_sdhi: Add r8a77965 support

On 9 May 2018 at 14:38, Yoshihiro Kaneko wrote: > From: Masaharu Hayakawa > > This patch adds r8a77965 support in SDHI. > > Signed-off-by: Masaharu Hayakawa > Signed-off-by: Yoshihiro Kaneko

[PATCH v2] usb: gadget: function: printer: avoid wrong list handling in printer_write()

When printer_write() calls usb_ep_queue(), a udc driver (e.g. renesas_usbhs driver) may call usb_gadget_giveback_request() in the udc .queue ops immediately. Then, printer_write() calls list_add(>list, >tx_reqs_active) wrongly. After that, if we do unbind the printer driver, WARN_ON() happens in

RE: [PATCH/RFC] usb: gadget: function: printer: avoid wrong list handling in printer_write()

Hi, > From: Felipe Balbi, Sent: Monday, May 21, 2018 7:19 PM > > Hi, > > Yoshihiro Shimoda writes: > > Hi, > > > >> From: Felipe Balbi, Sent: Monday, May 21, 2018 5:05 PM > > > >> seems like it would be better to just move this like before > >>

Re: [PATCH V5] PCI: rcar: Use runtime PM to control controller clock

On 05/14/2018 05:49 PM, Lorenzo Pieralisi wrote: > On Mon, May 14, 2018 at 05:32:04PM +0200, Marek Vasut wrote: >> On 05/01/2018 12:55 PM, Lorenzo Pieralisi wrote: >>> On Fri, Apr 13, 2018 at 02:48:19PM +0200, Simon Horman wrote: On Tue, Apr 10, 2018 at 06:17:04PM +0200, Marek Vasut wrote:

Re: [PATCH v3 2/3] arm64: dts: renesas: draak: Describe CVBS input

Hi Jacopo, On Monday, 21 May 2018 12:57:05 EEST jacopo mondi wrote: > On Fri, May 18, 2018 at 06:12:15PM +0300, Laurent Pinchart wrote: > > On Friday, 18 May 2018 17:47:57 EEST Jacopo Mondi wrote: > >> Describe CVBS video input through analog video decoder ADV7180 > >> connected to video input

RE: [PATCH/RFC] usb: gadget: function: printer: avoid wrong list handling in printer_write()

Hi, Yoshihiro Shimoda writes: > Hi, > >> From: Felipe Balbi, Sent: Monday, May 21, 2018 5:05 PM > >> seems like it would be better to just move this like before >> usb_ep_queue(): >> >> modified drivers/usb/gadget/function/f_printer.c >> @@ -631,19 +631,19

Re: [PATCH v3 2/3] arm64: dts: renesas: draak: Describe CVBS input

Hi Laurent, On Fri, May 18, 2018 at 06:12:15PM +0300, Laurent Pinchart wrote: > Hi Jacopo, > > Thank you for the patch. > > On Friday, 18 May 2018 17:47:57 EEST Jacopo Mondi wrote: > > Describe CVBS video input through analog video decoder ADV7180 > > connected to video input interface VIN4. > >

Re: [PATCH 2/2] tests: suspend/resume: Increase number of processed frames

On 21/05/18 10:09, Laurent Pinchart wrote: > Hi Kieran, > > On Monday, 21 May 2018 11:58:44 EEST Kieran Bingham wrote: >> On 21/05/18 09:51, Laurent Pinchart wrote: >>> On Monday, 21 May 2018 11:16:05 EEST Kieran Bingham wrote: On 19/05/18 21:34, Laurent Pinchart wrote: > The

[PATCH v2 1/2] vsp-lib: Capture the kernel log messages in test log files

It can be useful to capture kernel log messages in test log files for diagnostic purpose. Add a simple mechanism to do so by capturing the full kernel log at the end of the test. The kernel log is cleared first before starting the test to avoid capturing unrelated messages. Signed-off-by: Laurent

[PATCH v2 0/2] vsp-tests: Fix suspend/resume test

Hello, This small series fixes the VSP suspend/resume test to ensure that the VSP is running when suspending. The first patch isn't strictly required, but was helpful when debugging the second patch, so I've included it in the series. Laurent Pinchart (2): vsp-lib: Capture the kernel log

[PATCH v2 2/2] tests: suspend/resume: Increase number of processed frames

The suspend/resume test starts a run of 300 frames and suspends the system one second later. On some SoCs (namely H3 ES2.0) the VSP bandwidth is high enough to complete processing of 300 frames in less than a second. The test thus suspends and resumes the system with the VSP idle instead of

Re: [PATCH 2/2] tests: suspend/resume: Increase number of processed frames

Hi Kieran, On Monday, 21 May 2018 11:58:44 EEST Kieran Bingham wrote: > On 21/05/18 09:51, Laurent Pinchart wrote: > > On Monday, 21 May 2018 11:16:05 EEST Kieran Bingham wrote: > >> On 19/05/18 21:34, Laurent Pinchart wrote: > >>> The suspend/resume test starts a run of 300 frames and suspends

Re: [PATCH 1/2] vsp-lib: Capture the kernel log messages in test log files

Hi Niklas, On Sunday, 20 May 2018 13:47:53 EEST Niklas Söderlund wrote: > On 2018-05-19 23:34:25 +0300, Laurent Pinchart wrote: > > It can be useful to capture kernel log messages in test log files for > > diagnostic purpose. Add a simple mechanism to do so by capturing the > > full kernel log at

Re: [PATCH 2/2] tests: suspend/resume: Increase number of processed frames

On 21/05/18 09:51, Laurent Pinchart wrote: > Hi Kieran, > > On Monday, 21 May 2018 11:16:05 EEST Kieran Bingham wrote: >> Hi Laurent, >> >> Thank you for the patch, >> >> On 19/05/18 21:34, Laurent Pinchart wrote: >>> The suspend/resume test starts a run of 300 frames and suspends the >>> system

RE: [PATCH/RFC] usb: gadget: function: printer: avoid wrong list handling in printer_write()

Hi, > From: Felipe Balbi, Sent: Monday, May 21, 2018 5:05 PM > seems like it would be better to just move this like before > usb_ep_queue(): > > modified drivers/usb/gadget/function/f_printer.c > @@ -631,19 +631,19 @@ printer_write(struct file *fd, const char __user *buf, > size_t len,

Re: [PATCH 2/2] tests: suspend/resume: Increase number of processed frames

Hi Kieran, On Monday, 21 May 2018 11:16:05 EEST Kieran Bingham wrote: > Hi Laurent, > > Thank you for the patch, > > On 19/05/18 21:34, Laurent Pinchart wrote: > > The suspend/resume test starts a run of 300 frames and suspends the > > system one second later. On some SoCs (namely H3 ES2.0) the

Re: [PATCH 2/2] tests: suspend/resume: Increase number of processed frames

Hi Laurent, Thank you for the patch, On 19/05/18 21:34, Laurent Pinchart wrote: > The suspend/resume test starts a run of 300 frames and suspends the > system one second later. On some SoCs (namely H3 ES2.0) the VSP > bandwidth is high enough to complete processing of 300 frames in less > than a

RE: [PATCH/RFC] usb: gadget: function: printer: avoid wrong list handling in printer_write()

Hi, Yoshihiro Shimoda writes: > Hi, > >> From: Felipe Balbi, Sent: Monday, May 21, 2018 3:57 PM >> >> Hi, >> >> Yoshihiro Shimoda writes: >> > The usb_ep_queue() in printer_write() is possible to call req->complete(). >> >

RE: [PATCH/RFC] usb: gadget: function: printer: avoid wrong list handling in printer_write()

Hi, > From: Felipe Balbi, Sent: Monday, May 21, 2018 3:57 PM > > Hi, > > Yoshihiro Shimoda writes: > > The usb_ep_queue() in printer_write() is possible to call req->complete(). > > In that case, since tx_complete() calls list_add(>list, >tx_reqs), > >

[PATCH] i2c: mux: improve error message for failed symlink

Trivial, but still: the failed symlink is not *for* the channel but a link *to* the channel. Signed-off-by: Wolfram Sang --- Found this while adding a similar message to the demux driver. drivers/i2c/i2c-mux.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v2 2/2] i2c: mux: demux-pinctrl: add symlinks to the demux device in sysfs

Similar to mux devices, create special symlinks to connect the demuxed bus with the demux device. Signed-off-by: Wolfram Sang --- Changes since v1: * check sysfs_create_link and print WARN if something fails drivers/i2c/muxes/i2c-demux-pinctrl.c | 10

[PATCH v2 0/2] i2c: mux: demux-pinctrl: improve device relationships

While researching some PM behaviour within I2C, I found out that the i2c-demux driver does not play well with that due to broken relationship with other devices. Patch 1 ensures the right parent-child relationship. Patch 2 makes the connection between the demux device and the demuxed bus similar

[PATCH v2 1/2] i2c: mux: demux-pinctrl: use proper parent device for demux adapter

Due to a typo, the wrong parent device was assigned to the newly created demuxing adapter device. It got connected to the demuxing platform device but not to the selected parent I2C adapter device. Fix it to get a proper parent-child relationship of the demuxed busses. Signed-off-by: Wolfram Sang

Re: [PATCH/RFC] usb: gadget: function: printer: avoid wrong list handling in printer_write()

Hi, Yoshihiro Shimoda writes: > The usb_ep_queue() in printer_write() is possible to call req->complete(). > In that case, since tx_complete() calls list_add(>list, >tx_reqs), > printer_write() should not call list_add(>list, >tx_reqs_active) > because the