On Fri, Jul 13, 2018 at 1:08 AM, Geert Uytterhoeven
wrote:
> R-Mobile APE6, R-Car Gen2, and RZ/G1 SoCs have Cortex-A7 and/or
> Cortex-A15 CPU cores, all of which have ARM architectured timers.
>
> Force use of the ARM architectured timer on these SoCs.
> This allows to:
> - Remove the calls to
On Tue, Jul 10, 2018 at 11:42:15PM +0200, Wolfram Sang wrote:
> I2C clients may misunderstand recovery pulses if they can't read SDA to
> bail out early. In the worst case, as a write operation. To avoid that
> and if we can write SDA, try to send STOP to avoid the
> misinterpretation.
>
>
When we we initialize the pins, make sure it looks like STOP by dividing
the delay into halves. It shouldn't matter because SDA is expected to be
held low by a device, but for super-safety, let's do it.
Signed-off-by: Wolfram Sang
---
drivers/i2c/i2c-core-base.c | 5 +++--
1 file changed, 3
> > More importantly, isn't a ->get_bus_free implementation a sufficient
> > requirement
> > for recovery? I.e. even if both ->get_sda and ->set_sda are missing?
>
> In my case, it isn't. It needs set_sda (== STOP) to achieve a useful
> result. Hmm, I think this needs better documentation...
Hi Geert,
On Thursday, July 12, 2018, Geert Uytterhoeven wrote:
> Yeah, that's why I asked: setup-r7s72100.c is the smallest setup file.
>
> It uses shmobile_init_delay() to preset loops-per-jiffy, to avoid
> calibrating the
> delay loop, and shmobile_init_late() to make s2ram do more than
Hi Chris,
On Thu, Jul 12, 2018 at 5:40 PM Chris Brandt wrote:
> On Thursday, July 12, 2018, Geert Uytterhoeven wrote:
> > I'm wondering if you could do without any board code, i.e. without
> > setup-r7s9210.c?
>
> I think I see them being removed for R-Car.
> ButI'm not sure how that
> For the short term, I will remove the sanity check from the I2C core and
> hope the user properly set up the GPIO.
For the record, this patch is here:
http://patchwork.ozlabs.org/patch/943115/
Forgot to cc linux-gpio.
signature.asc
Description: PGP signature
This check did not work as intended. I2C is open drain, so this function
will likely always have presented the GPIO as input because
gpiod_get_direction doesn't know about open drain states. Remove this
check for now. We can add it again once we know how to get more precise
information about the
On Thu, Jul 12, 2018 at 11:15:01AM +0200, Geert Uytterhoeven wrote:
> Allow gpiolib to read back the current I/O direction configuration by
> implementing the .get_direction() callback.
>
> Signed-off-by: Geert Uytterhoeven
So, despite it didn't help solving my original case because of an
R-Mobile APE6, R-Car Gen2, and RZ/G1 SoCs have Cortex-A7 and/or
Cortex-A15 CPU cores, all of which have ARM architectured timers.
Force use of the ARM architectured timer on these SoCs.
This allows to:
- Remove the calls to shmobile_init_delay() from the corresponding
machine vectors,
-
On Wed, Jul 11, 2018 at 06:33:19PM +0200, Wolfram Sang wrote:
> EINVAL is very generic, use ENOTSUPP in case the gpiochip does not
> provide this function. While removing the assignment from the 'status'
> variable, use better indentation in the declaration block.
>
> Signed-off-by: Wolfram Sang
Hi Geert,
On Thursday, July 12, 2018, Geert Uytterhoeven wrote:
> As the IP cores are the same in all variants, using
> "renesas,r7s9210-" should be fine for matching drivers to IP
> cores. Same for CONFIG_ARCH_R7S9210.
>
> However, as the actual dies differ between H, M, and L versions, there
Hi Geert,
On Thursday, July 12, 2018, Geert Uytterhoeven wrote:
> I'm wondering if you could do without any board code, i.e. without
> setup-r7s9210.c?
I think I see them being removed for R-Car.
ButI'm not sure how that actually works.
I'll have a look.
As you can see, there's really
On Wed, Jul 11, 2018 at 04:20:49PM +0200, Geert Uytterhoeven wrote:
> Hi all,
>
> This patch series contains various improvements for OSC and RCLK
> handling on R-Car Gen3 SoCs.
>
> This has been tested on R-Car H3 ES1.0/ES2.0, R-Car M3-W ES1.0, R-Car
> D3, and R-Car E3.
> The R-Car V3H
Hi Simon,
On Thu, Jul 12, 2018 at 3:56 PM Simon Horman wrote:
> On Wed, Jul 11, 2018 at 04:20:54PM +0200, Geert Uytterhoeven wrote:
> > R-Car Gen3 Hardware Manual Rev.0.54 documents the relation between the
> > MD13 and MD14 mode pins, and the OSC EXTAL predivider, as used by the
> > OSC clock.
On Wed, Jul 11, 2018 at 04:20:56PM +0200, Geert Uytterhoeven wrote:
> Add a clock type and macro for defining clocks where the parent and
> divider are selected based on the value of the RCKCR.CKSEL bit.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/clk/renesas/rcar-gen3-cpg.c | 23
On Wed, Jul 11, 2018 at 04:20:54PM +0200, Geert Uytterhoeven wrote:
> R-Car Gen3 Hardware Manual Rev.0.54 documents the relation between the
> MD13 and MD14 mode pins, and the OSC EXTAL predivider, as used by the
> OSC clock. Hence augment the configuration structure with all
> documented
Hi Chris,
On Thu, Jul 12, 2018 at 3:15 PM Chris Brandt wrote:
> On Thursday, July 12, 2018, Geert Uytterhoeven wrote:
> > > + - RZ/A2 (R7S9210)
> > > +compatible = "renesas,r7s9210"
> >
> > There seems to be a difference between the r7s92104x and the r7s92105x
> > parts (with "x" just
Hi Geert,
On Thursday, July 12, 2018, Geert Uytterhoeven wrote:
> > + - RZ/A2 (R7S9210)
> > +compatible = "renesas,r7s9210"
>
> There seems to be a difference between the r7s92104x and the r7s92105x
> parts (with "x" just denoting a different packaging)?
> Do we need one more digit?
From
On Thu, Jul 05, 2018 at 04:18:41PM +0200, Niklas Söderlund wrote:
> From: Masaharu Hayakawa
>
> Checking for SCC error during retuning is unnecessary.
>
> Signed-off-by: Masaharu Hayakawa
> [Niklas: fix small style issue]
> Signed-off-by: Niklas Söderlund
> ---
>
On Thu, Jul 05, 2018 at 04:18:39PM +0200, Niklas Söderlund wrote:
> From: Masaharu Hayakawa
>
> SDR104 and HS200 need to check for SCC error. If SCC error is detected,
> retuning is necessary.
>
> Signed-off-by: Masaharu Hayakawa
> [Niklas: update commit message]
> Signed-off-by: Niklas
Hi Chris,
On Thu, Jul 12, 2018 at 5:02 AM Chris Brandt wrote:
> Add the RZ/A2 SoC to the Renesas SoC collection.
>
> Signed-off-by: Chris Brandt
> --- /dev/null
> +++ b/arch/arm/mach-shmobile/setup-r7s9210.c
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * r7s9210
Hi Chris,
On Thu, Jul 12, 2018 at 5:02 AM Chris Brandt wrote:
> Add device tree bindings documentation for Renesas RZ/A2 (r7s9210) SoC.
>
> Signed-off-by: Chris Brandt
Reviewed-by: Geert Uytterhoeven
> --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> +++
Hi Phil,
On Thu, Jul 12, 2018 at 2:03 PM Phil Edworthy wrote:
> On 11 July 2018 16:02, Phil Edworthy wrote:
> > On 11 July 2018 13:42, Geert Uytterhoeven wrote:
> > > On Wed, Jul 11, 2018 at 2:30 PM Phil Edworthy wrote:
> > > > The Renesas RZ/N1 UART is based on the Synopsys DW UART, but has
> >
Hi Geert,
On 11 July 2018 13:39, Geert Uytterhoeven wrote:
> On Wed, Jul 11, 2018 at 2:30 PM Phil Edworthy wrote:
> > The RZ/N1 UART is a modified Synopsys DesignWare UART.
> > The modifications only relate to DMA so you could actually use the
> > controller with the Synopsys compatible string if
Hi Geert,
On 11 July 2018 16:02, Phil Edworthy wrote:
> On 11 July 2018 13:42, Geert Uytterhoeven wrote:
> > On Wed, Jul 11, 2018 at 2:30 PM Phil Edworthy wrote:
> > > The Renesas RZ/N1 UART is based on the Synopsys DW UART, but has
> > > additional registers for DMA. This patch does not address
Allow gpiolib to read back the current I/O direction configuration by
implementing the .get_direction() callback.
Signed-off-by: Geert Uytterhoeven
---
drivers/gpio/gpio-rcar.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c
index
On Fri, Apr 13, 2018 at 07:27:59PM +0200, Geert Uytterhoeven wrote:
> Hi Ulrich,
>
> On Fri, Apr 13, 2018 at 7:00 PM, Ulrich Hecht
> wrote:
> > These patches make sure that the device is up while the suspend/resume code
> > is executed. Up-port from the BSP, tested not to break stuff.
> >
> >
28 matches
Mail list logo