Hi Eugeniu
Thank you for your reply
> > > Prior to adding M3-N Starter Kit to the list, rename:
> > > - "renesas,h3ulcb" => "renesas,ulcb"
> > > - "renesas,m3ulcb" => "renesas,ulcb"
> >
> > I'm not sure detail, but
> > does it mean, both H3/M3 board can boot/work with
> > "renesas,ulcb"
Hi Geert,
On Mon, Aug 06, 2018 at 05:15:37PM +0200, Geert Uytterhoeven wrote:
> Hi Eugeniu,
>
> On Sun, Aug 5, 2018 at 1:14 AM Eugeniu Rosca wrote:
> > According to R-Car Gen3 HW manual rev0.55E, R-Car M3-N has two CAN
> > interfaces, similar to H3, M3-W and other SoCs from the same family.
> >
On Mon, Aug 06, 2018 at 04:28:47PM +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.
Basically good. As of patch 1, we need to clarify HS400 handling. Maybe
this commit message needs a
Hi Kieran,
On Mon, Aug 06, 2018 at 12:11:22PM +0100, Kieran Bingham wrote:
> Hi Eugeniu,
>
> On 05/08/18 00:11, Eugeniu Rosca wrote:
> > According to R-Car Gen3 HW manual rev0.55E, R-Car M3-N has two CAN
>
> rev 0.55E sounds like rather an old version of this document. Do you
> have access to
> + !(host->mmc->ios.timing == MMC_TIMING_MMC_HS400 && !use_4tap))
I know this comes from the BSP but I cannot find any documentation why
ignoring SCC errors is different depending on using 4/8 taps.
I'll try to get more internal information...
signature.asc
Description: PGP
Describe the CSI2 and VIN (and their interconnections) in the R8A77980
device tree.
Signed-off-by: Sergei Shtylyov
---
This patch is against the 'renesas-devel-20180802v2-v4.18-rc7' branch of
Simon Horman's 'renesas.git' repo.
The R8A77980 CSI2/VIN DT binding updates have been posted earlier
Hi Niklas,
On Mon, Aug 6, 2018 at 9:43 PM Niklas Söderlund
wrote:
> Latest datasheet makes it clear that not all ES revisions of the H3 and
> M3-W have the 4-tap HS400 mode quirk, currently the quirk is set
> unconditionally for these two SoCs. Prepare to handle the quirk based on
> SoC revision
Hi Kieran,
On Mon, Aug 06, 2018 at 11:56:56AM +0100, Kieran Bingham wrote:
> Hi Eugeniu
>
> On 05/08/18 00:11, Eugeniu Rosca wrote:
> > After adding CAN support to arch/arm64/boot/dts/renesas/r8a77965.dtsi,
> > checkpatch complained that the new compatible string
> > "renesas,can-r8a77965" is
On 08/06/2018 06:21 PM, Sergei Shtylyov wrote:
>> After adding CAN support to arch/arm64/boot/dts/renesas/r8a77965.dtsi,
>> checkpatch complained that the new compatible string
>> "renesas,can-r8a77965" is not documented. Fix the warning.
>>
>> Signed-off-by: Eugeniu Rosca
>> ---
>>
Hi Sergei,
On Mon, Aug 06, 2018 at 06:21:09PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 08/05/2018 02:11 AM, Eugeniu Rosca wrote:
>
> > After adding CAN support to arch/arm64/boot/dts/renesas/r8a77965.dtsi,
> > checkpatch complained that the new compatible string
> > "renesas,can-r8a77965"
It was though all ES revisions of H3 and M3-W SoCs required the
TMIO_MMC_HAVE_4TAP_HS400 flag. Recent datasheet updates tells us this is
not true, only early ES revisions of the SoC do.
Since quirk matching based on ES revisions is now used to handle the
flag it's possible to align all Gen3
Hi,
Recent datasheet updates have made it clear that some quirks are not SoC
specific but SoC + ES version specific. Currently the quirks are
selected using compatibility values but whit this new information that
is not enough.
This small series adds support to select quirks based on SoC + ES
Latest datasheet makes it clear that not all ES revisions of the H3 and
M3-W have the 4-tap HS400 mode quirk, currently the quirk is set
unconditionally for these two SoCs. Prepare to handle the quirk based on
SoC revision instead of compatibility value by using soc_device_match()
and set the
Hi Wolfram,
On Mon, Aug 6, 2018 at 7:04 PM Wolfram Sang wrote:
> > Please try without that step, or do "echo none > /sys/power/pm_test".
>
> Did this now with a q'n'd hacked gpio driver (see below). Worked like a
> charm. So, the sata_rcar patch under discussion here seems to be fine.
> We only
On Mon, Aug 06, 2018 at 08:05:06PM +0200, Wolfram Sang wrote:
> On Wed, Jul 25, 2018 at 09:16:55PM +0200, Wolfram Sang wrote:
> > Update the binding docs for Renesas R-Car M3-N. No driver changes are
> > needed.
> >
> > Signed-off-by: Wolfram Sang
>
> Tejun, could you pick this also for 4.19?
>
On Wed, Jul 25, 2018 at 09:16:55PM +0200, Wolfram Sang wrote:
> Update the binding docs for Renesas R-Car M3-N. No driver changes are
> needed.
>
> Signed-off-by: Wolfram Sang
Tejun, could you pick this also for 4.19?
Thanks for picking the other patches already!
> ---
>
On Mon, Aug 06, 2018 at 12:40:05PM +0200, Wolfram Sang wrote:
> Since R-Car Gen2, a new bit has been introduced to the interrupt mask
> register. Update the code to handle it properly as well.
>
> Signed-off-by: Wolfram Sang
Applied to libata/for-4.19.
Thanks.
--
tejun
On Mon, Aug 06, 2018 at 12:42:00PM +0200, Wolfram Sang wrote:
> From: Masaharu Hayakawa
>
> According to documentation, setting of PHY registers is unnecessary with
> R-Car Gen3. The registers are not even described. So, don't initialize
> them.
>
> Signed-off-by: Masaharu Hayakawa
> [wsa:
Hi Geert,
> Please try without that step, or do "echo none > /sys/power/pm_test".
Did this now with a q'n'd hacked gpio driver (see below). Worked like a
charm. So, the sata_rcar patch under discussion here seems to be fine.
We only need the GPIO resume on specific boards. This is a seperate
Hi Geert,
On Monday, August 06, 2018 1, Geert Uytterhoeven wrote:
> BTW, it would have been very valuable to know that earlycon didn't work,
> as that
> would have helped in avoiding the earlycon breakage on other parts.
My apologies.
When I had first looked at this months ago, I quickly
Hello!
On 08/05/2018 02:11 AM, Eugeniu Rosca wrote:
> After adding CAN support to arch/arm64/boot/dts/renesas/r8a77965.dtsi,
> checkpatch complained that the new compatible string
> "renesas,can-r8a77965" is not documented. Fix the warning.
>
> Signed-off-by: Eugeniu Rosca
> ---
>
Hi Eugeniu,
On Sun, Aug 5, 2018 at 1:14 AM Eugeniu Rosca wrote:
> According to R-Car Gen3 HW manual rev0.55E, R-Car M3-N has two CAN
> interfaces, similar to H3, M3-W and other SoCs from the same family.
>
> Add CAN nodes to avoid below r8a77965-ulcb-kf.dtb build failure:
> Error:
Hi Wolfram,
On Mon, Aug 6, 2018 at 5:00 PM Wolfram Sang wrote:
> > "platform suspend"? Is that s2ram aka a full PSCI system suspend?
>
> It is this:
>
> echo platform > /sys/power/pm_test
> echo mem > /sys/power/state
Thanks!
> Is there a better name for it?
I don't know. It never gets to the
On Mon, Aug 6, 2018 at 1:13 PM Geert Uytterhoeven wrote:
> On Mon, Aug 6, 2018 at 12:38 PM Laurent Pinchart
> wrote:
> > On Sunday, 5 August 2018 02:11:02 EEST Eugeniu Rosca wrote:
> > > In the context of M3N-ULCB (RTP0RC77965SKBX010SA00) board bring-up, it's
> > > rather pointless to add a new
> "platform suspend"? Is that s2ram aka a full PSCI system suspend?
It is this:
echo platform > /sys/power/pm_test
echo mem > /sys/power/state
Is there a better name for it?
The HDD was also spinning down/up during the cycle...
> I guess not, as it is supposed to fail without PCA9654
On 08/06/2018 01:42 PM, Wolfram Sang wrote:
> From: Masaharu Hayakawa
>
> According to documentation, setting of PHY registers is unnecessary with
> R-Car Gen3. The registers are not even described. So, don't initialize
> them.
>
> Signed-off-by: Masaharu Hayakawa
> [wsa: updated commit
Hi Laurent,
On Mon, Aug 6, 2018 at 4:40 PM Laurent Pinchart
wrote:
> On Monday, 6 August 2018 17:34:34 EEST Geert Uytterhoeven wrote:
> > On Mon, Aug 6, 2018 at 4:16 PM Laurent Pinchart wrote:
> > > On Monday, 6 August 2018 17:07:54 EEST Geert Uytterhoeven wrote:
> > >> This reverts commit
Hello!
On 08/06/2018 01:40 PM, Wolfram Sang wrote:
> Since R-Car Gen2, a new bit has been introduced to the interrupt mask
> register. Update the code to handle it properly as well.
>
> Signed-off-by: Wolfram Sang
[...]
Reviewed-by: Sergei Shtylyov
> diff --git a/drivers/ata/sata_rcar.c
Hi Laurent,
On Mon, Aug 6, 2018 at 4:37 PM Laurent Pinchart
wrote:
> On Monday, 6 August 2018 17:07:51 EEST Geert Uytterhoeven wrote:
> > This RFC patch series was sparked by noticing that commit 2d4dd0da45401c7a
>
> Where can that commit be found ?
tty-next
> > ("serial: sh-sci: Allow for
On Monday, 6 August 2018 17:37:45 EEST Laurent Pinchart wrote:
> On Monday, 6 August 2018 17:07:51 EEST Geert Uytterhoeven wrote:
> > Hi all,
> >
> > This RFC patch series was sparked by noticing that commit 2d4dd0da45401c7a
>
> Where can that commit be found ?
I found it in -next, sorry
Hi Geert,
On Monday, 6 August 2018 17:34:34 EEST Geert Uytterhoeven wrote:
> On Mon, Aug 6, 2018 at 4:16 PM Laurent Pinchart wrote:
> > On Monday, 6 August 2018 17:07:54 EEST Geert Uytterhoeven wrote:
> >> This reverts commit dfc80387aefb78161f83732804c6d01c89c24595.
> >>
> >> Deriving the
Hi Chris,
On Mon, Aug 6, 2018 at 4:18 PM Chris Brandt wrote:
> On Monday, August 06, 2018 1, linux-sh-ow...@vger.kernel.org wrote:
> > Deriving the proper regshift value from the register block size is
> > fragile (it may have been rounded up in DT, and the mapping granularity
> > is usually
Hi Geert,
On Monday, 6 August 2018 17:07:51 EEST Geert Uytterhoeven wrote:
> Hi all,
>
> This RFC patch series was sparked by noticing that commit 2d4dd0da45401c7a
Where can that commit be found ?
> ("serial: sh-sci: Allow for compressed SCIF address") broke earlycon
> support on most
Hi Laurent,
On Mon, Aug 6, 2018 at 4:16 PM Laurent Pinchart
wrote:
> On Monday, 6 August 2018 17:07:54 EEST Geert Uytterhoeven wrote:
> > This reverts commit dfc80387aefb78161f83732804c6d01c89c24595.
> >
> > Deriving the proper regshift value from the register block size is
> > fragile, as it
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 Söderlund
---
drivers/mmc/host/tmio_mmc_core.c | 4 ++--
1 file changed, 2
Hi,
These patches triggers a retune if a SCC error is detected. They where
ported from the renesas BSP. Masaharu-san did all the real work I just
ported them to upstream and did small fixups.
These patches where broken out of my retuning series as more work where
needed to adapt them to the
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
---
* Changes since v1
- Use intermediate variable use_4tap to simplify check.
---
Hi Geert,
On Monday, August 06, 2018 1, linux-sh-ow...@vger.kernel.org wrote:
> Deriving the proper regshift value from the register block size is
> fragile (it may have been rounded up in DT, and the mapping granularity
> is usually PAGE_SIZE anyway), and turned out to be inappropriate for
>
Hi Geert,
Thank you for the patch.
On Monday, 6 August 2018 17:07:54 EEST Geert Uytterhoeven wrote:
> This reverts commit dfc80387aefb78161f83732804c6d01c89c24595.
>
> Deriving the proper regshift value from the register block size is
> fragile, as it may have been rounded up.
>
> Furthermore
Deriving the proper regshift value from the register block size is
fragile (it may have been rounded up in DT, and the mapping granularity
is usually PAGE_SIZE anyway), and turned out to be inappropriate for
earlycon support (the size is not easily available).
On DT systems, derive it from the
Hi all,
This RFC patch series was sparked by noticing that commit 2d4dd0da45401c7a
("serial: sh-sci: Allow for compressed SCIF address") broke earlycon
support on most Renesas ARM SoCs using SCIF ports, and by the fragility of
deriving regshift from the register block size (which may be
This reverts commit dfc80387aefb78161f83732804c6d01c89c24595.
Deriving the proper regshift value from the register block size is
fragile, as it may have been rounded up.
Furthermore we will need plat_sci_port.regshift again.
Signed-off-by: Geert Uytterhoeven
---
From: Yoshinori Sato
The first sh-sci port and earlycon use the same sci_port.
Hence after the initialization of the first port, earlycon may die.
Fis this by assigning a separate sci_port for earlycon.
Signed-off-by: Yoshinori Sato
[geert: Rebased, reworded]
Signed-off-by: Geert Uytterhoeven
With the compressed SCIF address range, the SCIF ports on most Renesas
SoCs now use regshift 1.
However, the earlycon setup code always assumes regshift zero, breaking
earlycon on R-Car, RZ/A1, and RZ/G SoCs.
Fix this by initializing regshift to 1 for the generic SCIF case, and
adding a special
Hi Laurent,
[Adding Rob and DT ML]
On 08/06/2018 01:42 PM, Laurent Pinchart wrote:
> Hi Eugeniu,
>
> Thank you for the patch.
>
> On Sunday, 5 August 2018 02:11:04 EEST Eugeniu Rosca wrote:
>> Following the recent change in dt-bindings [1], switch from
>> "renesas,h3ulcb" to "renesas,ulcb"
Hi Wolfram,
On Mon, Aug 6, 2018 at 12:43 PM Wolfram Sang
wrote:
> From: Masaharu Hayakawa
>
> According to documentation, setting of PHY registers is unnecessary with
> R-Car Gen3. The registers are not even described. So, don't initialize
> them.
>
> Signed-off-by: Masaharu Hayakawa
> [wsa:
Hi Laurent,
On Mon, Aug 6, 2018 at 12:38 PM Laurent Pinchart
wrote:
> On Sunday, 5 August 2018 02:11:02 EEST Eugeniu Rosca wrote:
> > In the context of M3N-ULCB (RTP0RC77965SKBX010SA00) board bring-up, it's
> > rather pointless to add a new "renesas,m3nulcb" compatible string. Any
> > SoC-level
Hi Linus,
Thanks for the feedback.
> Subject: Re: [PATCH v2 2/5] dt-bindings: gpio: rcar: Add gpio-reserved-ranges
> support
> > Update the DT bindings documentation with the optional
> > gpio-reserved-ranges properties.
> >
> > Signed-off-by: Biju Das
> > Reviewed-by: Fabrizio Castro
> (...)
Hi Eugeniu,
On 05/08/18 00:11, Eugeniu Rosca wrote:
> According to R-Car Gen3 HW manual rev0.55E, R-Car M3-N has two CAN
rev 0.55E sounds like rather an old version of this document. Do you
have access to the later rev1.00 release?
(Not an issue for this patch itself, I can confirm that
Hi Kieran,
On Monday, 6 August 2018 13:49:59 EEST Kieran Bingham wrote:
> On 06/08/18 11:45, Kieran Bingham wrote:
> > On 06/08/18 11:42, Laurent Pinchart wrote:
> >> On Sunday, 5 August 2018 02:11:04 EEST Eugeniu Rosca wrote:
> >>> Following the recent change in dt-bindings [1], switch from
>
On Mon, Aug 6, 2018 at 11:53 AM Biju Das wrote:
> Some platforms are not setting of_node in the driver. On these platforms
> defining gpio-reserved-ranges on device tree leads to kernel crash.
>
> It is due to some parts of the gpio core relying on the driver to set up
> of_node,while other
Hi Eugeniu
On 05/08/18 00:11, Eugeniu Rosca wrote:
> After adding CAN support to arch/arm64/boot/dts/renesas/r8a77965.dtsi,
> checkpatch complained that the new compatible string
> "renesas,can-r8a77965" is not documented. Fix the warning.
>
Thanks to the correct ordering of your patches, (you
On 06/08/18 11:45, Kieran Bingham wrote:
> Hi Laurent, Eugeniu,
>
> On 06/08/18 11:42, Laurent Pinchart wrote:
>> Hi Eugeniu,
>>
>> Thank you for the patch.
>>
>> On Sunday, 5 August 2018 02:11:04 EEST Eugeniu Rosca wrote:
>>> Following the recent change in dt-bindings [1], switch from
>>>
Hi Biju!
Thanks for the patches and sorry for slow feedback.
Luckily you have Geert to help out and I can see this is already
getting in nice shape.
On Thu, Aug 2, 2018 at 4:17 PM Biju Das wrote:
> Update the DT bindings documentation with the optional gpio-reserved-ranges
> properties.
>
>
Hi Laurent, Eugeniu,
On 06/08/18 11:42, Laurent Pinchart wrote:
> Hi Eugeniu,
>
> Thank you for the patch.
>
> On Sunday, 5 August 2018 02:11:04 EEST Eugeniu Rosca wrote:
>> Following the recent change in dt-bindings [1], switch from
>> "renesas,h3ulcb" to "renesas,ulcb" compatible string.
>>
From: Masaharu Hayakawa
According to documentation, setting of PHY registers is unnecessary with
R-Car Gen3. The registers are not even described. So, don't initialize
them.
Signed-off-by: Masaharu Hayakawa
[wsa: updated commit message]
Signed-off-by: Wolfram Sang
---
Tested with a Renesas
Hi Eugeniu,
Thank you for the patch.
On Sunday, 5 August 2018 02:11:04 EEST Eugeniu Rosca wrote:
> Following the recent change in dt-bindings [1], switch from
> "renesas,h3ulcb" to "renesas,ulcb" compatible string.
>
> [1] Documentation/devicetree/bindings/arm/shmobile.txt
>
> Signed-off-by:
Since R-Car Gen2, a new bit has been introduced to the interrupt mask
register. Update the code to handle it properly as well.
Signed-off-by: Wolfram Sang
---
Based on a report and prototype from the BSP team.
drivers/ata/sata_rcar.c | 20 +---
1 file changed, 13
Hi Eugeniu,
Thank you for the patch.
On Sunday, 5 August 2018 02:11:02 EEST Eugeniu Rosca wrote:
> In the context of M3N-ULCB (RTP0RC77965SKBX010SA00) board bring-up, it's
> rather pointless to add a new "renesas,m3nulcb" compatible string. Any
> SoC-level differences between the two variants of
Hello Eugeniu,
Thank you for the patch.
On Sunday, 5 August 2018 02:11:01 EEST Eugeniu Rosca wrote:
> Perform a 's/(h|m)3ulcb/ulcb/' substitution in below DTS filenames:
> - r8a7795-es1-h3ulcb.dts=> r8a7795-es1-ulcb.dts
> - r8a7795-es1-h3ulcb-kf.dts => r8a7795-es1-ulcb-kf.dts
> -
Some platforms are not setting of_node in the driver. On these platforms
defining gpio-reserved-ranges on device tree leads to kernel crash.
It is due to some parts of the gpio core relying on the driver to set up
of_node,while other parts do themselves.This inconsistent behaviour leads
to a
Hi Morimoto-san,
Thank you for your comments.
On Mon, Aug 06, 2018 at 12:33:34AM +, Kuninori Morimoto wrote:
> Hi Eugeniu
>
> > In the context of M3N-ULCB (RTP0RC77965SKBX010SA00) board bring-up, it's
> > rather pointless to add a new "renesas,m3nulcb" compatible string. Any
> > SoC-level
HI Geert,
Thanks for the feedback.
> -Original Message-
> From: Geert Uytterhoeven
> Sent: 04 August 2018 10:25
> To: Biju Das
> Cc: Linus Walleij ; open list:GPIO SUBSYSTEM
> ; Simon Horman ;
> Geert Uytterhoeven ; Chris Paterson
> ; Fabrizio Castro
> ; Linux-Renesas
63 matches
Mail list logo
