Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Tuesday, August 28, 2018 11:13 PM
>
> usb2_phy1 accidentally uses the same clock/reset as usb2_phy0.
>
> Fixes: b5857630a829a8d5 ("arm64: dts: renesas: r8a77965: add usb2_phy nodes")
> Signed-off-by: Geert Uytterhoeven
Thank you for the patch!
R
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Tuesday, August 28, 2018 10:57 PM
>
> Should be "renesas,usbhs-r8a77965", not "renesas,usbhs-r8a7796".
>
> Fixes: a06e8af801760a98 ("arm64: dts: renesas: r8a77965: add HS-USB node")
> Signed-off-by: Geert Uytterhoeven
Thank you for the patch!
Re
From: Hoan Nguyen An
About the formula for temperature calculation
[reg] = [temp] * a + b <=> [temp] = ([reg] - b) / a
Using "(mcelsius * tsc-> coef.aX) / 1000" instead of
"DIV_ROUND_CLOSEST(mcelsius, 1000) * tsc-> coef.aX"
to avoid and reduce inaccuracy due to rounding the integer division.
S
From: Hoan Nguyen An
This patch to avoid and reduce the inaccuracy in the calculation when
DIV_ROUND() and then calculates the conversion, I think, should change the
order: calculate the conversion and then DIV_ROUND().
Although I'm not sure there will be an error, but I have encountered proble
Hi Jacopo and Laurent,
On 2018-08-28 13:40:34 +0300, Laurent Pinchart wrote:
[snip]
> > >>> - The media_device_ops or at least the .link_notify() callback
> > >>> of that
> > >>> struct must be changed so not one driver in the media graph is
> > >>> responsible for all links. In this case r
Add a helper to allow host drivers checking if a retune is in progress.
Signed-off-by: Niklas Söderlund
---
include/linux/mmc/host.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index beed7121c7818b74..2a5fe75dd0821d03 100644
--- a/
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 v3
- Use the newly introduce helper mmc_doing_retune() instead of checking
host->mmc->doing_re
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 recen
From: Masaharu Hayakawa
SDR104, HS200 and HS400 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
---
* Changes since v3
- Updated commit message to mention also HS400
Fix warning when running with CONFIG_DMA_API_DEBUG_SG=y by allocating a
device_dma_parameters structure and filling in the max segment size. The
size used is the result of a discussion with Renesas hardware engineers
and unfortunately not found in the datasheet.
renesas_sdhi_internal_dmac ee1400
On Wed, Aug 29, 2018 at 09:42:38AM +0200, Wolfram Sang wrote:
> To prevent removing if NOWAYOUT, we invalidate the .remove function and
> suppress the bind/unbind attributes in sysfs. These are driver
> capabilities, so we need to set it up at runtime during init. To avoid
> boilerplate, introduce
On Wednesday, August 29, 2018 1, Daniel Lezcano wrote:
> My concern is if we can avoid changing the TIMER_OF_DECLARE because of
> the boot order, it would be better.
>
> Can returning EPROBE_DEFER fix this issue? Or use the 'complex
> dependencies' [1]?
So I tried just returning -EPROBE_DEFER, bu
On Wednesday, August 29, 2018 1, Daniel Lezcano wrote:
>
> My concern is if we can avoid changing the TIMER_OF_DECLARE because of
> the boot order, it would be better.
>
> Can returning EPROBE_DEFER fix this issue? Or use the 'complex
> dependencies' [1]?
I'll try returning EPROBE_DEFER and see
Hi Niklas,
> I tested it on M3-W ES1.0 and it H3 ES2.0 and it works as I expect it to
> do, but forcing a retune due to SCC error is beyond my skill-set. I
> checked the documentation and can't find anything contradicting
> Shimoda-sans information from the HW team. So to the best of my
> know
On 29/08/2018 17:44, Chris Brandt wrote:
> On Wednesday, August 29, 2018 1, Daniel Lezcano wrote:
>> Can the boot constraints [1] solve this issue instead of the changes you
>> are proposing ?
>>
>> [1] https://lwn.net/Articles/747250/
>
> Thanks for the suggestion, but...
>
> I grepped for "boot
On Wed, Aug 29, 2018 at 09:42:38AM +0200, Wolfram Sang wrote:
> To prevent removing if NOWAYOUT, we invalidate the .remove function and
> suppress the bind/unbind attributes in sysfs. These are driver
> capabilities, so we need to set it up at runtime during init. To avoid
> boilerplate, introduce
On Wednesday, August 29, 2018 1, Daniel Lezcano wrote:
> Can the boot constraints [1] solve this issue instead of the changes you
> are proposing ?
>
> [1] https://lwn.net/Articles/747250/
Thanks for the suggestion, but...
I grepped for "boot_constraint" and it shows up nowhere in the current
k
Hi Geert,
Thanks for your patch.
On 2018-08-28 16:14:44 +0200, Geert Uytterhoeven wrote:
> To preserve alphabetical sort order.
>
> Fixes: 4c529600eef0a6b7 ("arm64: dts: renesas: r8a77965: Add R-Car Gen3
> thermal support")
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Niklas Söderlund
>
Hi Wolfram,
Thanks for your feedback,
On 2018-08-29 09:16:04 +0200, Wolfram Sang wrote:
>
> > + /*
> > +* Skip checking SCC errors when running on 4 taps in HS400 mode as
> > +* any retuning would still result in the same 4 taps being used.
> > +*/
>
> Did you verify this? I didn'
On 29/08/2018 15:29, Chris Brandt wrote:
> The newer RZ/A clock control driver no longer registers all its clocks
> using DT, therefore the clocks required by this driver are no longer
> present at the beginning of boot.
>
> Because of this, TIMER_OF_DECLARE can no longer be used because this
> ca
Hi Niklas,
Thanks for the feedback. I confirm it works.
> Subject: Re: Regarding VIN test(cvbs capture:- PAL resolution)
>
> Hi Biju,
>
> On 2018-08-29 10:41:16 +, Biju Das wrote:
> > Hi All,
> >
> > I started testing vin on R-Car Gen3(CVBS input from DVD player
> > connected to R-Car M3-W
The R7S9210 belongs to the RZ/A2 SoC series
Signed-off-by: Chris Brandt
---
Documentation/devicetree/bindings/timer/renesas,ostm.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/timer/renesas,ostm.txt
b/Documentation/devicetree/bindings
Modify the driver to take into accound clock drivers that are not 100% DT,
and also update the binding documentation.
Chris Brandt (2):
clocksource/drivers/ostm: Delay driver registration
dt-bindings: timer: ostm: Add R7S9210 support
.../devicetree/bindings/timer/renesas,ostm.txt | 3 +-
The newer RZ/A clock control driver no longer registers all its clocks
using DT, therefore the clocks required by this driver are no longer
present at the beginning of boot.
Because of this, TIMER_OF_DECLARE can no longer be used because this
causes the driver to get probed too early before the pa
Add support for the R7S9210 (RZ/A2) Clock Pulse Generator and Module
Standby.
The Module Standby HW in the RZ/A series is very close to R-Car HW, except
for how the registers are laid out.
The MSTP registers are only 8-bits wide, there is no status registers
(MSTPST), and the register offsets are
Hi Biju,
On 29/08/18 12:19, Biju Das wrote:
> Hi Kieran,
>
> Thanks for the feedback.
>
>> Could you check to see the output of any of the following is correct:
>>
>> media-ctl -d /dev/media1 --get-v4l2 "'adv748x 4-0070 afe':0"
>> .. (and 1,2,3,4,5,6 if necessary)
>> media-ctl -d /dev/media1
Hi Biju,
On 2018-08-29 10:41:16 +, Biju Das wrote:
> Hi All,
>
> I started testing vin on R-Car Gen3(CVBS input from DVD player connected to
> R-Car M3-W,kernel:-renesas-devel-20180827-4.19-rc1)
> based on the information present in https://elinux.org/R-Car/Tests:rcar-vin.
>
> Looks like P
Hi Kieran,
Thanks for the feedback.
> Subject: Re: Regarding VIN test(cvbs capture:- PAL resolution)
> On 29/08/18 11:41, Biju Das wrote:
> > Hi All,
> >
> >
> >
> > I started testing vin on R-Car Gen3(CVBS input from DVD player
> > connected to R-Car M3-W,kernel:-renesas-devel-20180827-4.19-rc
Hi Biju,
On 29/08/18 11:41, Biju Das wrote:
> Hi All,
>
>
>
> I started testing vin on R-Car Gen3(CVBS input from DVD player
> connected to R-Car M3-W,kernel:-renesas-devel-20180827-4.19-rc1)
>
> based on the information present in https://elinux.org/R-Car/Tests:rcar-vin.
>
>
>
> Looks l
From: Hoan Nguyen An
Add PWM-2 channel(CN28 - pin30) support for Salvator-X
Signed-off-by: Hoan Nguyen An
---
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
b/arch/arm64/boot/dt
From: Hoan Nguyen An
Since the Salvator-X boards have 2 PWM channels, this patch adds the PWM-2
channel, I tested by measuring the output signal at CN28-pin30.
Hoan Nguyen An (1):
arm64: dts: salvator-common: Add PWM-2 channel
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 11 ++
Hi Geert,
On Tuesday, 28 August 2018 15:10:52 EEST Geert Uytterhoeven wrote:
> Hi Sergei, Laurent, Kieran,
>
> On Wed, Jun 13, 2018 at 10:11 PM Sergei Shtylyov wrote:
> > Describe the interconnected FCPVD0, VSPD0, DU, and LVDS0 devices in the
> > R8A77980 device tree...
> >
> > Based on the orig
On Tue, Aug 7, 2018 at 10:03 AM Biju Das wrote:
> Update the DT bindings documentation with the optional gpio-reserved-ranges
> properties.
>
> Signed-off-by: Biju Das
> Reviewed-by: Fabrizio Castro
Patch applied with the ACKs.
Yours,
Linus Walleij
On Tue, Aug 7, 2018 at 10:03 AM Biju Das wrote:
> GPIO hole is present in RZ/G1C SoC. Valid GPIO pins on bank3 are in the
> range GP3_0 to GP3_16 and GP3_27 to GP3_29. The GPIO pins between GP3_17
> to GP3_26 are unused. Add support for handling unused GPIO's.
>
> Signed-off-by: Biju Das
Patch
Allow PCI drivers to prevent removing if NOWAYOUT, too.
Note: This is only a build-tested proof-of-concept!
Signed-off-by: Wolfram Sang
---
include/linux/watchdog.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index c8ecbc53c807..7f
Use the new macro to prevent removing the driver if NOWAYOUT.
Signed-off-by: Wolfram Sang
---
drivers/watchdog/renesas_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
index f45cb183fa75..92339c744cce 100644
To prevent removing if NOWAYOUT, we invalidate the .remove function and
suppress the bind/unbind attributes in sysfs. These are driver
capabilities, so we need to set it up at runtime during init. To avoid
boilerplate, introduce module_watchdog_driver() similar to
module_driver(). On top of that, w
Use the new macro to prevent removing the driver if NOWAYOUT.
Signed-off-by: Wolfram Sang
---
drivers/watchdog/i6300esb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/i6300esb.c b/drivers/watchdog/i6300esb.c
index 950c71a8bb22..939224789e2a 100644
--- a/dr
So, here is my second approach, now avoiding probe() and targetting the init
call. To avoid boilerplate, I introduced macros similar to module_driver(). It
still feels a little adventurous because of hard-coding
'.driver.suppress_bind_attts' in the macro and trusting various driver types
(like plat
On Mon, Aug 27, 2018 at 05:13:21PM +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.
HS400, 8 taps, too, or am I missing something?
signature.asc
Description: PGP signature
> + /*
> + * Skip checking SCC errors when running on 4 taps in HS400 mode as
> + * any retuning would still result in the same 4 taps being used.
> + */
Did you verify this? I didn't have the time to do so :(
signature.asc
Description: PGP signature
> I think this design is less messy as the quirks gets added in
> renesas_sdhi_core.c instead of needing to keep
> renesas_sdhi_internal_dmac.c and renesas_sdhi_sys_dmac.c in sync with
> the quirks.
>
> Wolfram what do you think about this design?
I wonder if we can improve it if we base it o
42 matches
Mail list logo
