Re: [GIT PULL] Renesas ARM Based SoC Fixes for v4.10

On Wed, Jan 04, 2017 at 04:10:09PM +0100, Arnd Bergmann wrote: > On Monday, December 12, 2016 9:30:00 AM CET Simon Horman wrote: > > This provides an sd0_uhs node rather than duplicate sdh0 nodes > > resolving an error introduced in a clean-up patch. > > > > This pull request is based on "Second

Re: [PATCH v2 2/2] phy: sun4i-usb: Replace the deprecated extcon API

On Fri, Dec 30, 2016 at 12:11 PM, Chanwoo Choi wrote: > This patch replaces the deprecated extcon API as following: > - extcon_set_cable_state_() -> extcon_set_state_sync() > > Cc: Kishon Vijay Abraham I > Cc: Maxime Ripard

Re: [PATCH v2 16/29] drm: bridge: dw-hdmi: Detect PHY type at runtime

Hi Jose, On Tuesday 20 Dec 2016 15:01:52 Jose Abreu wrote: > On 20-12-2016 13:11, Laurent Pinchart wrote: > > On Tuesday 20 Dec 2016 11:39:21 Jose Abreu wrote: > >> On 20-12-2016 01:33, Laurent Pinchart wrote: > >>> Detect the PHY type and use it to handle the PHY type-specific SVSRET > >>>

Re: [PATCHv6 0/4] thermal: add driver for R-Car Gen3

On Thu, Dec 22, 2016 at 11:38:19AM +0100, Niklas Söderlund wrote: > Hi all, > > The series adds thermal support to Renesas R-Car Gen3 SoCs. It's tested > on Salvator-X H3 and M3-W SoC. > > Wolfram asked me to have a look at the comments for v4 and to try and > rework the temperature formulas to

[PATCH] sh_eth: R8A7740 supports packet shecksumming

The R8A7740 GEther controller supports the packet checksum offloading but the 'hw_crc' (bad name, I'll fix it) flag isn't set in the R8A7740 data, thus CSMR isn't cleared... Fixes: 73a0d907301e ("net: sh_eth: add support R8A7740") Signed-off-by: Sergei Shtylyov

Re: [PATCH] sh_eth: enable RX descriptor word 0 shift on SH7734

From: Sergei Shtylyov Date: Wed, 04 Jan 2017 23:10:23 +0300 > The RX descriptor word 0 on SH7734 has the RFS[9:0] field in bits 16-25 > (bits 0-15 usually used for that are occupied by the packet checksum). > Thus we need to set the 'shift_rd0' field in the

[PATCH] sh_eth: enable RX descriptor word 0 shift on SH7734

The RX descriptor word 0 on SH7734 has the RFS[9:0] field in bits 16-25 (bits 0-15 usually used for that are occupied by the packet checksum). Thus we need to set the 'shift_rd0' field in the SH7734 SoC data... Fixes: f0e81fecd4f8 ("net: sh_eth: Add support SH7734") Signed-off-by: Sergei

Re: [PATCH] sh_eth: fix EESIPR values for SH77{34|63}

On 01/04/2017 10:18 PM, Sergei Shtylyov wrote: As the SH77{34|63} manuals are freely available, I've checked the EESIPR values written against the manuals, and they appeared to set the reserved bits 11-15 (which should be 0 on write). Fix those EESIPR values. Fixes: 380af9e390ec ("net:

[PATCH] sh_eth: fix EESIPR values for SH77{34|63}

As the SH77{34|63} manuals are freely available, I've checked the EESIPR values written against the manuals, and they appeared to set the reserved bits 11-15 (which should be 0 on write). Fix those EESIPR values. Fixes: 380af9e390ec ("net: sh_eth: CPU dependency code collect to "struct

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

On 01/03/2017 01:18 PM, Laurent Pinchart wrote: > Hi Marek, Hi, > 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

Re: [PATCH 0/2] sh_eth: E-MAC interrupt handler cleanups

From: Sergei Shtylyov Date: Wed, 04 Jan 2017 15:09:36 +0300 >Here's a set of 3 patches against DaveM's 'net-next.git' repo. I'm cleaning > up the E-MAC interrupt handling with the main goal of factoring out the E-MAC > interrupt handler into a separate

Applied "spi: rspi: Remove useless memory allocation failure message" to the spi tree

The patch spi: rspi: Remove useless memory allocation failure message has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "spi: sh-msiof: Remove useless memory allocation failure message" to the spi tree

The patch spi: sh-msiof: Remove useless memory allocation failure message has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Re: [PATCH v2 2/3] swiotlb: Convert swiotlb_force from int to enum

On Wed, Jan 04, 2017 at 05:57:17PM +, Catalin Marinas wrote: > On Fri, Dec 16, 2016 at 02:28:41PM +0100, Geert Uytterhoeven wrote: > > Convert the flag swiotlb_force from an int to an enum, to prepare for > > the advent of more possible values. > > > > Suggested-by: Konrad Rzeszutek Wilk

Re: [PATCH v2 2/3] swiotlb: Convert swiotlb_force from int to enum

On Fri, Dec 16, 2016 at 02:28:41PM +0100, Geert Uytterhoeven wrote: > Convert the flag swiotlb_force from an int to an enum, to prepare for > the advent of more possible values. > > Suggested-by: Konrad Rzeszutek Wilk > Signed-off-by: Geert Uytterhoeven

Re: [PATCH v2 3/3] swiotlb: Add swiotlb=noforce debug option

On Fri, Dec 16, 2016 at 02:28:42PM +0100, Geert Uytterhoeven wrote: > diff --git a/Documentation/admin-guide/kernel-parameters.txt > b/Documentation/admin-guide/kernel-parameters.txt > index 21e2d88637050b7a..24fb691b2da5f78d 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++

[PATCH RESEND 1/2] arm64: dts: r8a7795: enable HS200 for eMMC

Signed-off-by: Wolfram Sang --- arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts index

[PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

Simon, as Ulf picked up the driver patches for HS200 support, it is now safe to pick up the DTS patches, I'd say? I rebased them to the dt-for-4.11 branch. All the best, Wolfram Wolfram Sang (2): arm64: dts: r8a7795: enable HS200 for eMMC arm64: dts: r8a7796: enable HS200 for eMMC

[PATCH RESEND 2/2] arm64: dts: r8a7796: enable HS200 for eMMC

Signed-off-by: Wolfram Sang --- arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts index

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

For OF platforms, this is called via of_dma_configure(), that checks dma-ranges of node that is *parent* for host bridge. Host bridge currently does not control this at all. >>> >>> We need to think about this a bit. Is it actually the PCI host >>> bridge that limits the ranges

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

Hi Daniel, On Wednesday 04 Jan 2017 15:58:25 Daniel Vetter wrote: > On Wed, Jan 04, 2017 at 04:33:57PM +0200, Laurent Pinchart wrote: > > On Wednesday 04 Jan 2017 14:51:48 Daniel Vetter wrote: > >> Hm, something like drm_bridge_panel_bridge_init(dev, panel) should be > >> enough, or not? My idea

Re: [GIT PULL] Renesas ARM Based SoC Fixes for v4.10

On Monday, December 12, 2016 9:30:00 AM CET Simon Horman wrote: > This provides an sd0_uhs node rather than duplicate sdh0 nodes > resolving an error introduced in a clean-up patch. > > This pull request is based on "Second Round of Renesas ARM Based SoC DT > Updates for v4.10", tagged as

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

On Wed, Jan 04, 2017 at 04:33:57PM +0200, Laurent Pinchart wrote: > On Wednesday 04 Jan 2017 14:51:48 Daniel Vetter wrote: > > Hm, something like drm_bridge_panel_bridge_init(dev, panel) should be > > enough, or not? My idea is to use this for the case where the only > > thing in dt is the panel,

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

On Wednesday, January 4, 2017 5:30:19 PM CET Nikita Yushchenko wrote: > >> For OF platforms, this is called via of_dma_configure(), that checks > >> dma-ranges of node that is *parent* for host bridge. Host bridge > >> currently does not control this at all. > > > > We need to think about this a

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

>> For OF platforms, this is called via of_dma_configure(), that checks >> dma-ranges of node that is *parent* for host bridge. Host bridge >> currently does not control this at all. > > We need to think about this a bit. Is it actually the PCI host > bridge that limits the ranges here, or the

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

Hi Daniel, On Wednesday 04 Jan 2017 14:51:48 Daniel Vetter wrote: > On Wed, Jan 4, 2017 at 2:08 PM, Laurent Pinchart wrote: > > On Wednesday 04 Jan 2017 09:18:18 Daniel Vetter wrote: > >> On Tue, Nov 29, 2016 at 10:57:07PM +0200, Laurent Pinchart wrote: > >>> On Tuesday 29 Nov 2016 10:54:09

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

On Wed, Jan 4, 2017 at 2:08 PM, Laurent Pinchart wrote: > Hi Daniel, > > On Wednesday 04 Jan 2017 09:18:18 Daniel Vetter wrote: >> On Tue, Nov 29, 2016 at 10:57:07PM +0200, Laurent Pinchart wrote: >> > On Tuesday 29 Nov 2016 10:54:09 Daniel Vetter wrote: >> >>

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

On Wednesday, January 4, 2017 9:24:09 AM CET Nikita Yushchenko wrote: > > commit 9a57d58d116800a535510053136c6dd7a9c26e25 > > Author: Arnd Bergmann > > Date: Tue Nov 17 14:06:55 2015 +0100 > > > > [EXPERIMENTAL] ARM64: check implement dma_set_mask > > > > Needs work

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

Hi Daniel, On Wednesday 04 Jan 2017 09:18:18 Daniel Vetter wrote: > On Tue, Nov 29, 2016 at 10:57:07PM +0200, 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

Re: [PATCH 3/3] sh_eth: factor out sh_eth_emac_interrupt()

On 01/04/2017 03:11 PM, Sergei Shtylyov wrote: The E-MAC interrupt (EESR.ECI) is not always caused by an error condition, so it really shouldn't be handled by sh_eth_error(). Factor out the E-MAC interrupt handler, sh_eth_emac_interrupt(), removing the ECI bit from the EESR's values

Clarification about frame buffer

hello all,        I just started to play with RCAR Boards..Before that , one of my confusion in kernel level is that  "is there only one frame buffer for video output? Now I got a documentation about frame buffer https://www.kernel.org/doc/Documentation/fb/framebuffer.txt In my knowledge

Re: [PATCH 3/3] sh_eth: factor out sh_eth_emac_interrupt()

On 01/04/2017 03:13 PM, Sergei Shtylyov wrote: The E-MAC interrupt (EESR.ECI) is not always caused by an error condition, so it really shouldn't be handled by sh_eth_error(). Factor out the E-MAC interrupt handler, sh_eth_emac_interrupt(), removing the ECI bit from the EESR's values

[PATCH 1/3] sh_eth: handle only enabled E-MAC interrupts

The driver should only handle the enabled E-MAC interrupts, like it does for the E-DMAC interrupts since commit 3893b27345ac ("sh_eth: workaround for spurious ECI interrupt"), so mask ECSR with ECSIPR when reading it in sh_eth_error(). Signed-off-by: Sergei Shtylyov

[PATCH 0/2] sh_eth: E-MAC interrupt handler cleanups

Hello. Here's a set of 3 patches against DaveM's 'net-next.git' repo. I'm cleaning up the E-MAC interrupt handling with the main goal of factoring out the E-MAC interrupt handler into a separate function. [1/3] sh_eth: handle only enabled E-MAC interrupts [2/3] sh_eth: no need for *else*

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

Hi Thierry, On Wednesday 04 Jan 2017 08:06:54 Thierry Reding wrote: > 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

Re: [PATCH v4 00/14] ARM: dts: r8a779x: use demuxer for I2C

Bump... > Yes, this is a bug in the rcar-vin driver which is addressed in the Gen3 > patches. However I'm not sure those patches will make it to v4.10, not > much review from the V4L2 side yet (Geert and Sergei have had a few > comments so there will at lest be one more iteration). Seems your

[PATCH 2/2] spi: sh-msiof: Remove useless memory allocation failure message

Printing an error on memory allocation failure is unnecessary. Signed-off-by: Geert Uytterhoeven --- drivers/spi/spi-sh-msiof.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c index

[PATCH 1/2] spi: rspi: Remove useless memory allocation failure message

Printing an error on memory allocation failure is unnecessary. Signed-off-by: Geert Uytterhoeven --- drivers/spi/spi-rspi.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/spi/spi-rspi.c b/drivers/spi/spi-rspi.c index

Re: [PATCH v2 08/13] arm64: dts: r8a7795: salvator-x: Add DU LVDS output endpoint

On Wed, Jan 04, 2017 at 03:07:14AM +0200, Laurent Pinchart wrote: > Hi Simon, > > Could you please pick this patch up ? Hi Laurent, I believe this is present in v4.10-rc1 as ea3c17b03b9b ("arm64: dts: r8a7795: salvator-x: Add DU LVDS output endpoint").

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

On Wed, Jan 04, 2017 at 03:06:24AM +0200, Laurent Pinchart wrote: > 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

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

Hi Kieran, Thanks for the patch! On Tue, Jan 03, 2017 at 05:05:58PM +, Kieran Bingham wrote: > 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

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

On Tue, Nov 29, 2016 at 10:57:07PM +0200, Laurent Pinchart wrote: > Hi Daniel, > > 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