Hello,
On Wednesday, 17 October 2018 20:48:01 EEST Laurent Pinchart wrote:
> The LVDS0 encoder on Koelsh and Porter, and the LVDS1 encoder on Lager,
> are enabled in DT but have no device connected to their output. This
> result in spurious messages being printed to the kernel log such as
>
>
The LVDS0 encoder on Koelsh and Porter, and the LVDS1 encoder on Lager,
are enabled in DT but have no device connected to their output. This
result in spurious messages being printed to the kernel log such as
rcar-du feb0.display: no connector for encoder /soc/lvds@feb9, skipping
Fix it
> Subject: Re: Delay between stop condition and start condition
>
>
> > The passthrough mode is not default, it gets activated by the driver so that
> > drm_get_edid can then fetch the EDID. One other nasty thing is that to end
> > the conversation
> > with the monitor you are supposed to write
On Tue, 9 Oct 2018 22:10:14 +0300, Sergei Shtylyov wrote:
> Document the R-Car V3H (R8A77980) SoC in the Renesas R-Car gen3 thermal
> bindings.
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt |4 +++-
> 1 file changed, 3
> The passthrough mode is not default, it gets activated by the driver so that
> drm_get_edid can then fetch the EDID. One other nasty thing is that to end
> the conversation
> with the monitor you are supposed to write 0x00 to register 0x1a of the HDMI
> transmitter,
> which means the SoC puts
> Subject: Re: Delay between stop condition and start condition
>
>
> > be fixed in its driver. It probably could be a generic driver, or?
>
> Wishful thinking. Setting the passthrough mode is probably not default,
> so it is device specific.
The passthrough mode is not default, it gets activated
On 2018-10-17 14:16, Wolfram Sang wrote:
>
>> Or, add an I2C gate driver (sort of like an I2C mux with only one child
>> bus) in the HDMI transmitter driver and implement the delay there. Then
>> move the monitor to this new gate/mux child bus.
>
> That would actually be my preferred solution.
Hi Wolfram,
On Wed, Oct 17, 2018 at 2:21 PM Wolfram Sang wrote:
> > be fixed in its driver. It probably could be a generic driver, or?
>
> Wishful thinking. Setting the passthrough mode is probably not default,
> so it is device specific.
According to the block diagram in
> be fixed in its driver. It probably could be a generic driver, or?
Wishful thinking. Setting the passthrough mode is probably not default,
so it is device specific.
signature.asc
Description: PGP signature
> Or, add an I2C gate driver (sort of like an I2C mux with only one child
> bus) in the HDMI transmitter driver and implement the delay there. Then
> move the monitor to this new gate/mux child bus.
That would actually be my preferred solution. Because it describes the
HW setup best. It is the
On Tue, Oct 16, 2018 at 3:24 PM Geert Uytterhoeven
wrote:
> When submitting a DMA request fails, the driver is supposed to fall back
> to PIO. However, this never really worked due to various reasons
> (sh-sci driver issues and dmaengine framework limitations).
>
> There are three places where
On 2018-10-17 12:32, Wolfram Sang wrote:
> Hi Fabrizio, everyone,
>
> Thanks for bringing this up!
>
>> What's the best way to address this? I could pull in the HDMI
>> transmitter driver the code to read the EDID back from the monitor so
>> that I can fit device specific delays without
Hello Wolfram,
Thank you so much for your feedback!
> Subject: Re: Delay between stop condition and start condition
>
> Hi Fabrizio, everyone,
>
> Thanks for bringing this up!
>
> > What's the best way to address this? I could pull in the HDMI
> > transmitter driver the code to read the EDID
Hi Fabrizio, everyone,
Thanks for bringing this up!
> What's the best way to address this? I could pull in the HDMI
> transmitter driver the code to read the EDID back from the monitor so
> that I can fit device specific delays without impacting the generic
> implementation of the EDID readback,
Enable the R-Car thermal driver as a module.
This driver is used in conjunction with the R-Car V3M (r8a77970),
E3 (r8a77990) and D3 (r8a77995) SoCs.
Signed-off-by: Simon Horman
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig
Enable the R-Car thermal driver.
This driver is used in conjunction with the R-Car V3M (r8a77970),
E3 (r8a77990) and D3 (r8a77995) SoCs.
Signed-off-by: Simon Horman
---
N.B: This is targeted at the devel branch of the renesas tree
but not upstream where renesas_defconfig does not currently
On Wed, Oct 17, 2018 at 11:56:43AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Mon, Oct 15, 2018 at 5:40 PM Simon Horman wrote:
> > On Thu, Oct 11, 2018 at 03:54:55PM +0200, Simon Horman wrote:
> > > On Thu, Oct 11, 2018 at 10:55:07AM +0200, Geert Uytterhoeven wrote:
> > > > For
On Thu, Oct 11, 2018 at 10:55:08AM +0200, Geert Uytterhoeven wrote:
> For consistency with arm64, where vendors have a single Kconfig symbol
> in arch/arm64/Kconfig.platforms.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Note that drivers/clk/ is included before drivers/soc/. Hence when
>
On Mon, Oct 15, 2018 at 11:12:26PM +0900, Yoshihiro Kaneko wrote:
> This patch adds the thermal device node and the thermal-zone for
> the R8A77990 SoC.
>
> Signed-off-by: Yoshihiro Kaneko
Thanks,
This looks fine to me but I will wait to see if there are other reviews
before applying.
Hi Simon,
On Mon, Oct 15, 2018 at 5:40 PM Simon Horman wrote:
> On Thu, Oct 11, 2018 at 03:54:55PM +0200, Simon Horman wrote:
> > On Thu, Oct 11, 2018 at 10:55:07AM +0200, Geert Uytterhoeven wrote:
> > > For consistency with other vendors, which have a single Kconfig symbol
> > > in
On Mon, Oct 15, 2018 at 11:11:57PM +0900, Yoshihiro Kaneko wrote:
> This series adds thermal support for R-Car E3 (R8A77990).
>
> This series is based on the next branch of Eduardo Valentin's
> linux-soc-thermal
> tree.
>
> Yoshihiro Kaneko (2):
> dt-bindings: thermal: rcar-thermal: add
Hi Simon,
On Wed, Oct 17, 2018 at 10:57 AM Simon Horman wrote:
> On Tue, Oct 16, 2018 at 03:04:50PM +0900, Yoshihiro Shimoda wrote:
> > This patch revises the reg size of each hsusb device node for
> > r8a7795, r8a7796 and r8a77965.
> >
> > Reported-by: Biju Das
> > Fixes: d2422e108812 ("arm64:
On Fri, Oct 12, 2018 at 05:04:08PM +0100, Lorenzo Pieralisi wrote:
> On Mon, Oct 08, 2018 at 09:34:45AM +0200, Simon Horman wrote:
> > On Thu, Oct 04, 2018 at 05:07:47PM +0100, Biju Das wrote:
> > > Add support for r8a7744. The Renesas RZ/G1N (R8A7744) PCIe controller
> > > is identical to the
On Mon, Oct 15, 2018 at 12:55:17PM +0200, Wolfram Sang wrote:
> Update the comment because we don't set the pointer to NULL anymore.
> Also use the correct pointer name 'dma_ops' instead of 'dma_map_ops'.
>
> Fixes: 1874619a7df4 ("ARM: dma-mapping: Set proper DMA ops in
>
Hi Shimoda-San,
Thanks for the patch.
> -Original Message-
> From: linux-renesas-soc-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Yoshihiro Shimoda
> Sent: 16 October 2018 07:05
> To: ho...@verge.net.au; magnus.d...@gmail.com
> Cc: linux-renesas-soc@vger.kernel.org;
Hello Simon,
Thank you for your feedback.
> >
> > +static int r8a77470_pin_to_pocctrl(struct sh_pfc *pfc, unsigned int pin,
> > + u32 *pocctrl)
> > +{
> > +int bit = -EINVAL;
> > +
> > +*pocctrl = 0xe60600b0;
> > +
> > +if (pin >= RCAR_GP_PIN(0, 5) && pin <= RCAR_GP_PIN(0, 10))
> > +bit = 0;
>
Hi Steve,
On Wed, Oct 17, 2018 at 10:57 AM Steve Twiss
wrote:
> On 12 October 2018 08:20 Geert Uytterhoeven wrote:
> > Subject: [PATCH v2 3/3] thermal: da9062/61: Prevent hardware access during
> > system suspend
> >
> > The workqueue used for monitoring the hardware may run while the device
> >
On Tue, Oct 16, 2018 at 03:04:50PM +0900, Yoshihiro Shimoda wrote:
> This patch revises the reg size of each hsusb device node for
> r8a7795, r8a7796 and r8a77965.
>
> Reported-by: Biju Das
> Fixes: d2422e108812 ("arm64: dts: r8a7795: Add HSUSB device node")
> Fixes: 4725f2b88057 ("arm64: dts:
On Tue, Oct 16, 2018 at 03:05:09PM +0900, Yoshihiro Shimoda wrote:
> This patch adds/enables USB2.0 peripheral for R-Car [DE]3 boards.
> So, the default mode on each board is:
> - R-Car D3 Draak board (has a type-A connector) = host.
> - R-Car E3 Ebisu board (has a type-B micro connector) =
Hi Simon,
On Wed, Oct 17, 2018 at 10:13 AM Simon Horman wrote:
> On Tue, Oct 16, 2018 at 10:36:33PM +0300, Sergei Shtylyov wrote:
> > Describe MSIOF in the R8A779{7|8}0 device trees.
> >
> > The DMA props are deliberately omitted as the MSIOF DMA doesn't work on
> > R8A77970 (due to IPMMU issue)
On Tue, Oct 16, 2018 at 11:33:43AM +0100, Fabrizio Castro wrote:
> Add SH_PFC_PIN_CFG_IO_VOLTAGE definition for the SDHI pins
> capable of switching voltage, also add pin groups and functions
> for SDHI0 and SDHI1. Please note that with the RZ/G1C only 1
> bit of the POC Control Register is used
On Tue, Oct 16, 2018 at 02:00:36PM +0200, Geert Uytterhoeven wrote:
> Some VIN channels support less than 24 lanes. As union vin_data always
> consumes space for 24 lanes, this wastes memory.
>
> Hence introduce new smaller unions vin_data12 and vin_data16, to
> accommodate VIN channels with
On Tue, Oct 16, 2018 at 01:33:39PM +0300, Laurent Pinchart wrote:
> Geert Uytterhoeven has long taken over and I'm not involved anymore with
> the Renesas pinctrl driver. Remove myself from the maintainers list.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Simon Horman
> ---
>
On Tue, Oct 16, 2018 at 10:22:05PM +0300, Sergei Shtylyov wrote:
> Document the R-Car V3{M|H} (R8A779{7|8}0) SoCs in the Renesas MSIOF
> bindings.
>
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Simon Horman
>
> ---
> The patch is against the 'for-next' branch of Mark Brown's 'spi.git' repo.
On Tue, Oct 16, 2018 at 10:36:33PM +0300, Sergei Shtylyov wrote:
> Describe MSIOF in the R8A779{7|8}0 device trees.
>
> The DMA props are deliberately omitted as the MSIOF DMA doesn't work on
> R8A77970 (due to IPMMU issue) and the RT-DMAC isn't supported on R8A77980.
For the record: In the
35 matches
Mail list logo
