Hi,
> > + *
> > + * The constants a and b are calculated using two triplets of int values
> > PTAT
> > + * and THCODE. PTAT and THCODE can either be read from hardware or use hard
> > + * coded values from driver. The formula to calculate a and b are taken
> > from
> > + * BSP and sparsely docum
Hey,
On Mon, Dec 12, 2016 at 03:18:02PM +0100, Niklas Söderlund wrote:
> From: Wolfram Sang
>
> Add support for R-Car Gen3 thermal sensors. Polling only for now,
> interrupts will be added incrementally. Same goes for reading fuses.
> This is documented already, but no hardware available for now
On Mon, Dec 12, 2016 at 03:18:05PM +0100, Niklas Söderlund wrote:
> From: Niklas Söderlund
>
> The .thermal_init needs to be delayed a short amount of time after
> setting REG_GEN3_CTSR to allow for the TEMP register to contain
> something useful. If it's not delayed theses warnings are common du
On Wed, Dec 07, 2016 at 10:06:27AM +0100, Wolfram Sang wrote:
>
> > Would you please check the following from checkpatch too?
>
> I saw them and chose to ignore them. I am not strict with those warnings
> within the i2c subsystem as well. I can change the series if your mileage
> varies, of cours
Hi Niklas,
thanks for this work!
> +/*
> + * Linear approximation for temperature
> + *
> + * [reg] = [temp] * a + b => [temp] = ([reg] - b) / a
> + *
> + * The constants a and b are calculated using two triplets of int values PTAT
> + * and THCODE. PTAT and THCODE can either be read from hardwar
The drm driver .load() operation is prone to race conditions as it
initializes the driver after registering the device nodes. Its usage is
deprecated, inline it in the probe function and call drm_dev_alloc() and
drm_dev_register() explicitly.
For consistency inline the .unload() handler in the rem
The function will only be available if SDR104 was detected in probe,
so no need to check in the function itself again.
Signed-off-by: Wolfram Sang
---
drivers/mmc/host/sh_mobile_sdhi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_
Setup tuning when the board is HS200 enabled.
Signed-off-by: Wolfram Sang
---
drivers/mmc/host/sh_mobile_sdhi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mmc/host/sh_mobile_sdhi.c
index 2bd17890ec4b77..c79545e4f69444 10064
The capability for HW_RESET is only activated if SDR104 is present, so
no need to check for SDR104 in the function itself again.
Signed-off-by: Wolfram Sang
---
drivers/mmc/host/sh_mobile_sdhi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers/mm
Here is a series adding HS200 support to the SDHI driver. Building the actual
functionality on top of SDR104 support was rather easy. However, I figured the
checks for enabling tuning were rather scattered over the driver and could be
further improved. So I did some refactoring of that to make addi
The function will only be available if SDR104 was detected in probe,
so no need to check in the function itself again.
Signed-off-by: Wolfram Sang
---
drivers/mmc/host/sh_mobile_sdhi.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/
Prerequisites for tuning are the same as for hw_reset. We need an SCC
and a supported mode. Populate the tuning related functions only when
those conditions are met. This also removes a tiny race window.
Previously, the functions were populated when the SCC offset was not
initialized which could ha
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 da46ac73ff2ae3..f8e1211b1d9034 100644
--- a/arch/ar
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 56f3a91c72cc9b..d7758d3c0efa21 100644
--- a/arch/ar
By using the helper of_device_get_match_data(), we can skip some
checking and make the code simpler.
Signed-off-by: Wolfram Sang
---
drivers/mmc/host/sh_mobile_sdhi.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
b/drivers
We need a SCC unit for hw_reset. Those units can only be described in
of_data. So, of_data and a valid SCC offset are prerequisites for
enabling the hw_reset capability. Merge the two 'if' conditions into one
and add a check for an scc offset.
Signed-off-by: Wolfram Sang
---
drivers/mmc/host/sh_
On Fri, Dec 09, 2016 at 01:52:20PM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Fri, Dec 9, 2016 at 11:50 AM, Simon Horman
> wrote:
> > In the case of Renesas R-Car hardware we know that there are generations of
> > SoCs, e.g. Gen 1, Gen 2 and Gen 3. But beyond that its not clear what the
Hi Jonathan,
On 10/12/2016 19:04, Jonathan Cameron wrote:
On 07/12/16 08:29, jac...@jmondi.org wrote:
[snip]
This driver is so minimal, I wonder if there are not drivers for
similar devices to which I can add support for MAX11100 instead of
writing a new one from scratch. Anyone with more
On 12/12/2016 06:49 PM, Niklas Söderlund wrote:
Thanks for your feedback.
Not at all, it's my duty now. :-)
I should probably have warned you not to post the new version to netdev --
DaveM has closed his net-next.git tree (ahead of the usual time, which would
have been 4.9 release), so
Geert Uytterhoeven reported WoL worked on his Armadillo board.
Signed-off-by: Niklas Söderlund
---
drivers/net/ethernet/renesas/sh_eth.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/renesas/sh_eth.c
b/drivers/net/ethernet/renesas/sh_eth.c
index 348ed22..fafde6f 10064
This is based on public datasheet for sh7743 which shows it have the
same behavior and registers for WoL as other versions of sh_eth.
Signed-off-by: Niklas Söderlund
---
drivers/net/ethernet/renesas/sh_eth.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/renesas/sh_eth.
This is based on public datasheet for sh7763 which shows it have the
same behavior and registers for WoL as other versions of sh_eth.
Signed-off-by: Niklas Söderlund
---
drivers/net/ethernet/renesas/sh_eth.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/renesas/sh_eth.
Add generic functionality to support Wake-on-Lan using MagicPacket which
are supported by at least a few versions of sh_eth. Only add
functionality for WoL, no specific sh_eth version are marked to support
WoL yet.
WoL is enabled in the suspend callback by setting MagicPacket detection
and disabli
Tested on Gen2 r8a7791/Koelsch.
Signed-off-by: Niklas Söderlund
---
drivers/net/ethernet/renesas/sh_eth.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/renesas/sh_eth.c
b/drivers/net/ethernet/renesas/sh_eth.c
index 87640b9..348ed22 100644
--- a/d
Hi,
This series adds support for Wake-on-Lan using Magic Packet for a few
models of the sh_eth driver. Patch 1/5 adds generic support to control
and support WoL while patches 2/5 - 5/5 enable different models.
Changes since v1.
- Spit generic WoL functionality and device enablement to different
Hi Sergei,
Thanks for your feedback.
On 2016-12-11 00:25:41 +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 12/08/2016 05:56 PM, Niklas Söderlund wrote:
>
> > > You only enable the WOL support fo the R-Car gen2 chips but never say
> > > that
> > > explicitly, neither in the subject nor here.
>
On Mon, Dec 12, 2016 at 01:28:30PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 12/12/2016 12:11 PM, Simon Horman wrote:
>
> >Use recently added R-Car Gen 2 fallback binding for iii nodes in
>
>s/iii/iic/?
Yes, thanks for noticing that.
> >DT for r8a7790 SoC.
> >
> >This has no run-time e
From: Wolfram Sang
Signed-off-by: Hien Dang
Signed-off-by: Thao Nguyen
Signed-off-by: Khiem Nguyen
Signed-off-by: Wolfram Sang
Signed-off-by: Niklas Söderlund
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 58
1 file changed, 58 insertions(+)
diff --git a/a
From: Wolfram Sang
Signed-off-by: Hien Dang
Signed-off-by: Thao Nguyen
Signed-off-by: Khiem Nguyen
Signed-off-by: Wolfram Sang
Signed-off-by: Niklas Söderlund
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 58
1 file changed, 58 insertions(+)
diff --git a/a
From: Wolfram Sang
Add support for R-Car Gen3 thermal sensors. Polling only for now,
interrupts will be added incrementally. Same goes for reading fuses.
This is documented already, but no hardware available for now.
Signed-off-by: Hien Dang
Signed-off-by: Thao Nguyen
Signed-off-by: Khiem Nguy
From: Niklas Söderlund
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 work with only ints and if it worked
out resend the s
From: Niklas Söderlund
The .thermal_init needs to be delayed a short amount of time after
setting REG_GEN3_CTSR to allow for the TEMP register to contain
something useful. If it's not delayed theses warnings are common during
boot:
thermal thermal_zone0: failed to read out thermal zone (-5)
ther
From: Wolfram Sang
Signed-off-by: Hien Dang
Signed-off-by: Khiem Nguyen
Signed-off-by: Wolfram Sang
Signed-off-by: Niklas Söderlund
---
.../bindings/thermal/rcar-gen3-thermal.txt | 56 ++
1 file changed, 56 insertions(+)
create mode 100644
Documentation/devicetr
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
wrote:
> Use recently added R-Car Gen 2 fallback binding for iii nodes in
> DT for r8a7794 SoC.
iic etc...
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7794 and
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
wrote:
> Use recently added R-Car Gen 2 fallback binding for iii nodes in
> DT for r8a7791 SoC.
iic etc...
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7791 and
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
wrote:
> Use recently added R-Car Gen 2 fallback binding for iii nodes in
> DT for r8a7793 SoC.
iic etc...
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7793 and
Hi SImon,
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
wrote:
> Use recently added R-Car Gen 2 fallback binding for iii nodes in
As Sergei already pointed out: s/iii/iic/.
You may also want to s/i2c/iic/ in the one-line summary, to avoid having
multiple different patches with the same one-lin
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
wrote:
> Use recently added R-Car Gen 3 fallback binding for i2c nodes in
> DT for r8a7796 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7796 and the
> fall
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
wrote:
> Use recently added R-Car Gen 3 fallback binding for i2c nodes in
> DT for r8a7795 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7795 and the
> fall
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
wrote:
> Use recently added R-Car Gen 2 fallback binding for i2c nodes in
> DT for r8a7794 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7794 and the
> fall
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
wrote:
> Use recently added R-Car Gen 2 fallback binding for i2c nodes in
> DT for r8a7793 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7793 and the
> fall
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
wrote:
> Use recently added R-Car Gen 2 fallback binding for i2c nodes in
> DT for r8a7792 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7792 and the
> fall
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
wrote:
> Use recently added R-Car Gen 2 fallback binding for i2c nodes in
> DT for r8a7791 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7791 and the
> fall
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
wrote:
> Use recently added R-Car Gen 2 fallback binding for i2c nodes in
> DT for r8a7790 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7790 and the
> fall
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
wrote:
> Use recently added R-Car Gen 1 fallback binding for i2c nodes in
> DT for r8a7779 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7779 and the
> fall
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
wrote:
> Use recently added R-Car Gen 1 fallback binding for i2c nodes in
> DT for r8a7778 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7778 and the
> fall
On 12/12/2016 12:11 PM, Simon Horman wrote:
Use recently added R-Car Gen 2 fallback binding for iii nodes in
s/iii/iic/?
DT for r8a7793 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7793 and the
fall
On 12/12/2016 12:11 PM, Simon Horman wrote:
Use recently added R-Car Gen 2 fallback binding for iii nodes in
s/iii/iic/?
DT for r8a7794 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7794 and the
fall
Hello.
On 12/12/2016 12:11 PM, Simon Horman wrote:
Use recently added R-Car Gen 2 fallback binding for iii nodes in
s/iii/iic/?
DT for r8a7791 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7791 and
Hello!
On 12/12/2016 12:11 PM, Simon Horman wrote:
Use recently added R-Car Gen 2 fallback binding for iii nodes in
s/iii/iic/?
DT for r8a7790 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7790 and
Hello!
On 12/9/2016 3:36 PM, Ulrich Hecht wrote:
Sets the closest match for a desired RX trigger level.
Signed-off-by: Ulrich Hecht
---
drivers/tty/serial/sh-sci.c | 55 +
1 file changed, 55 insertions(+)
diff --git a/drivers/tty/serial/sh-sci.c b
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 2 and Gen 3. But beyond that it's not clear what the
relationship between IP blocks might be. For example, I believe that
r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
descendant o
Use recently added R-Car Gen 2 fallback binding for iii nodes in
DT for r8a7791 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7791 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman
---
a
Use recently added R-Car Gen 2 fallback binding for i2c nodes in
DT for r8a7793 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7793 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman
---
a
Use recently added R-Car Gen 2 fallback binding for iii nodes in
DT for r8a7794 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7794 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman
---
a
Use recently added R-Car Gen 2 fallback binding for i2c nodes in
DT for r8a7794 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7794 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman
---
a
Use recently added R-Car Gen 2 fallback binding for iii nodes in
DT for r8a7793 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7793 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman
---
a
Use recently added R-Car Gen 2 fallback binding for i2c nodes in
DT for r8a7792 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7792 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman
---
a
Use recently added R-Car Gen 3 fallback binding for i2c nodes in
DT for r8a7796 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7796 and the
fallback binding for R-Car Gen 3.
Signed-off-by: Simon Horman
---
a
Use recently added R-Car Gen 3 fallback binding for i2c nodes in
DT for r8a7795 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7795 and the
fallback binding for R-Car Gen 3.
Signed-off-by: Simon Horman
---
a
Use recently added R-Car Gen 2 fallback binding for iii nodes in
DT for r8a7790 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7790 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman
---
a
Use recently added R-Car Gen 1 fallback binding for i2c nodes in
DT for r8a7778 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7778 and the
fallback binding for R-Car Gen 1.
Signed-off-by: Simon Horman
---
a
-specific and R-Car fallback bindings for all the cases covered by
this patch-set.
Based on renesas-devel-20161212-v4.9
Simon Horman (13):
ARM: dts: r8a7779: Use R-Car Gen 1 fallback binding for i2c nodes
ARM: dts: r8a7778: Use R-Car Gen 1 fallback binding for i2c nodes
ARM: dts: r8a7790: Use R
Use recently added R-Car Gen 2 fallback binding for i2c nodes in
DT for r8a7791 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7791 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman
---
a
Use recently added R-Car Gen 1 fallback binding for i2c nodes in
DT for r8a7779 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7779 and the
fallback binding for R-Car Gen 1.
Signed-off-by: Simon Horman
---
a
Use recently added R-Car Gen 2 fallback binding for i2c nodes in
DT for r8a7790 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7790 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman
---
a
Provide separaate sd0 and sd0_uhs nodes rather than duplicate sd0 nodes.
Cc: Vladimir Barinov
Cc: Sergei Shtylyov
Fixes: 93373c309a70 ("arm64: dts: h3ulcb: rename SDHI0 pins")
Signed-off-by: Simon Horman
---
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 2 +-
1 file changed, 1 insertion(+),
Hi Olof, Hi Kevin, Hi Arnd,
Please consider these Renesas ARM based SoC fixes for v4.10.
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", t
68 matches
Mail list logo
