renesas-drivers-2016-08-23-v4.8-rc3

renesas-drivers-2016-08-23-v4.8-rc3

[Geert Uytterhoeven]

I have pushed renesas-drivers-2016-08-23-v4.8-rc3 to
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git

This tree is meant to ease development of platform support and drivers
for Renesas ARM SoCs. It is created by merging (a) the for-next branches
of various subsystem trees and (b) branches with driver code submitted
or planned for submission to maintainers into the development branch of
Simon Horman's renesas.git tree.

Today's version is based on renesas-devel-20160823-v4.8-rc3.

Included branches with driver code:
  - clk-renesas-for-v4.9
  - sh-pfc-for-v4.9
  - topic/r8a7796-pfc-v3
  - topic/ipmmu-multi-arch-v4
  - topic/r8a7795-ipmmu-v2-rebased1
  - topic/r8a7796-ipmmu-v1-rebased1
  - topic/salvator-x-ipmmu-rfc-v3-rebased4
  - topic/spi-slave-v1-rebased1
  - git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
  - topic/sdr104-v4
  - topic/i2c-demux-v3-rebased3
  - topic/sdhi-gen3-dma-v3-rebased2
  - topic/r8a7796-sdhi-v2-rebased1
  - topic/pretimeout-v1-rebased1
  - topic/h3-pfc-set-voltage-v1-rebased2~1
  - https://git.ragnatech.se/linux
  - for-renesas-drivers
  - git://linuxtv.org/pinchartl/media.git
  - iommu/devel/du
  - git://linuxtv.org/pinchartl/media.git
  - vsp1/hgo
  - topic/fcpf-v1-rebased7
  - topic/fdp1-v2-rebased2

Included fixes:
  - [media] fdp1: vb2_queue dev conversion
  - [media] rcar-fcp: Make sure rcar_fcp_enable() returns 0 on success

Included subsystem trees:
  - git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git#linux-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git#clk-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git#for-next
  - git://git.infradead.org/users/dedekind/l2-mtd-2.6.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git#tty-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#i2c/for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git#usb-next
  - git://people.freedesktop.org/~airlied/linux#drm-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git#next
  - git://linuxtv.org/mchehab/media-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git#mmc-next
  - git://git.linaro.org/people/ulf.hansson/mmc.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git#for-next
  - git://git.linaro.org/people/daniel.lezcano/linux.git#clockevents/next
  - git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git#testing/next
  - git://git.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine.git#next
  - git://git.infradead.org/users/vkoul/slave-dma.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git#staging-next
  - git://git.armlinux.org.uk/~rmk/linux-arm.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git#for-next
  - git://git.infradead.org/users/jcooper/linux.git#irqchip/for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next
  - git://git.infradead.org/battery-2.6.git#master
  - git://www.linux-watchdog.org/linux-watchdog-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git#for-next/core
  - git://anongit.freedesktop.org/drm-intel#topic/drm-misc
  - git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git#next

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Kuninori Morimoto]

Hi Geert, Simon, Wolfram

> I have pushed renesas-drivers-2016-08-23-v4.8-rc3 to
> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git
> 
> This tree is meant to ease development of platform support and drivers
> for Renesas ARM SoCs. It is created by merging (a) the for-next branches
> of various subsystem trees and (b) branches with driver code submitted
> or planned for submission to maintainers into the development branch of
> Simon Horman's renesas.git tree.
> 
> Today's version is based on renesas-devel-20160823-v4.8-rc3.

I noticed that Lager "ES3.0" board can't boot on this and previous -rc2 branch.
In my and Shimoda-san's check, "ES2.0" seems have no problem.

It start works if I reverted this patch.

	09a28bb8b17e8cab3e9c120b7e37f631cc334a8f
	("ARM: dts: lager: use demuxer for IIC3/I2C3")

This is fail case of boot log on ES3.0 Lager board.

--- Lager ES3.0 fail case ----------
...
[    1.913412] renesas_usbhs e6590000.usb: Error applying setting, reverse things back
[    1.921304] renesas_usbhs e6590000.usb: transceiver found
[    1.926859] renesas_usbhs e6590000.usb: gadget probed
[    1.932000] renesas_usbhs e6590000.usb: USB function not selected (GPIO 854)
[    1.939923] renesas_usbhs e6590000.usb: probe failed (-524)
[    1.945531] renesas_usbhs: probe of e6590000.usb failed with error -524
[    1.952341] udc-core: couldn't find an available UDC - added [g_ether] to list of pending drivers
[    1.961942] mousedev: PS/2 mouse device common for all mice
[    1.967855] i2c /dev entries driver
[    1.973420] i2c-sh_mobile e6500000.i2c: I2C adapter 4, bus speed 100000 Hz
[    1.981611] i2c-sh_mobile e6510000.i2c: I2C adapter 5, bus speed 100000 Hz
[    1.989938] i2c-sh_mobile e6520000.i2c: I2C adapter 6, bus speed 100000 Hz
[    2.005654] i2c-sh_mobile e60b0000.i2c: I2C adapter 7, bus speed 100000 Hz
[    2.013187] i2c 11-0058: Masking da9063 interrupt sources
[    2.025088] da9063 11-0058: Device detected (chip-ID: 0x61, var-ID: 0x30)
[    2.039533] random: fast init done
[    2.062877] da9063-rtc da9063-rtc: rtc core: registered da9063-rtc as rtc0
[    3.041588] random: crng init done
<dead here>

--- Lager ES3.0 success case, similar point ---
...
[    1.985492] renesas_usbhs e6590000.usb: Error applying setting, reverse things back
[    1.993381] renesas_usbhs e6590000.usb: transceiver found
[    1.998938] renesas_usbhs e6590000.usb: gadget probed
[    2.004077] renesas_usbhs e6590000.usb: USB function not selected (GPIO 854)
[    2.012002] renesas_usbhs e6590000.usb: probe failed (-524)
[    2.017610] renesas_usbhs: probe of e6590000.usb failed with error -524
[    2.024425] udc-core: couldn't find an available UDC - added [g_ether] to list of pending drivers
[    2.034025] mousedev: PS/2 mouse device common for all mice
[    2.055108] da9063-rtc da9063-rtc: rtc core: registered da9063-rtc as rtc0
[    2.067039] i2c /dev entries driver
[    2.072592] i2c-sh_mobile e6500000.i2c: I2C adapter 4, bus speed 100000 Hz
[    2.080764] i2c-sh_mobile e6510000.i2c: I2C adapter 5, bus speed 100000 Hz
[    2.089084] i2c-sh_mobile e6520000.i2c: I2C adapter 6, bus speed 100000 Hz
[    2.104220] adv7180 10-0020: chip found @ 0x20 (i2c-demux (master i2c-6))
[    2.123473] rcar_jpu fe980000.jpeg-codec: encoder device registered as /dev/video0
[    2.131053] rcar_jpu fe980000.jpeg-codec: decoder device registered as /dev/video1
[    2.138970] vsp1: probe of fe920000.vsp1 failed with error -38
[    2.144941] vsp1: probe of fe928000.vsp1 failed with error -38
[    2.150894] vsp1: probe of fe930000.vsp1 failed with error -38
[    2.156860] vsp1: probe of fe938000.vsp1 failed with error -38
...

Best regards
---
Kuninori Morimoto

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 219 bytes --]

> 
> 	09a28bb8b17e8cab3e9c120b7e37f631cc334a8f
> 	("ARM: dts: lager: use demuxer for IIC3/I2C3")

Can you try this patch I sent yesterday?

[PATCH] i2c: mux: demux-pinctrl: run properly with multiple instances


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Kuninori Morimoto]

Hi Wolfram

Thank you for your feedback

> > 	09a28bb8b17e8cab3e9c120b7e37f631cc334a8f
> > 	("ARM: dts: lager: use demuxer for IIC3/I2C3")
> 
> Can you try this patch I sent yesterday?
> 
> [PATCH] i2c: mux: demux-pinctrl: run properly with multiple instances

I tried it, but same result.

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 92 bytes --]

> I tried it, but same result.

I see. Do we have a list of changes between ES2.0 and 3.0?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Kuninori Morimoto]

Hi Wolfram

> > I tried it, but same result.
> 
> I see. Do we have a list of changes between ES2.0 and 3.0?

We checked difference about I2C/IIC/PFC between ES2.0 and ES3.0,
but we couldn't find.

So, it seems
 1) unknown chip something ?
 2) board individual difference ?
 3) uboot difference ?
 4) difference of mounted / socketed chip

I asked to Magnus to enable remote access to my ES3.0 board.
You will get announce from him about it.

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Magnus Damm]

Hi Morimoto-san, everyone,

On Wed, Aug 24, 2016 at 9:58 AM, Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
>
> Hi Geert, Simon, Wolfram
>
>> I have pushed renesas-drivers-2016-08-23-v4.8-rc3 to
>> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git
>>
>> This tree is meant to ease development of platform support and drivers
>> for Renesas ARM SoCs. It is created by merging (a) the for-next branches
>> of various subsystem trees and (b) branches with driver code submitted
>> or planned for submission to maintainers into the development branch of
>> Simon Horman's renesas.git tree.
>>
>> Today's version is based on renesas-devel-20160823-v4.8-rc3.
>
> I noticed that Lager "ES3.0" board can't boot on this and previous -rc2 branch.
> In my and Shimoda-san's check, "ES2.0" seems have no problem.
>
> It start works if I reverted this patch.
>
>         09a28bb8b17e8cab3e9c120b7e37f631cc334a8f
>         ("ARM: dts: lager: use demuxer for IIC3/I2C3")
>

FYI, I have now received the problematic Lager ES3 board from
Morimoto-san and I will install it for remote access.

How can we check which ES version we are running? I recall seeing some
patch from Geert that printed out useful information during boot, any
chance that could make it upstream (if it is not already)?

Cheers,

/ magnus

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Geert Uytterhoeven]

Hi Magnus,

On Thu, Aug 25, 2016 at 4:42 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> On Wed, Aug 24, 2016 at 9:58 AM, Kuninori Morimoto
> <kuninori.morimoto.gx@renesas.com> wrote:
>> I noticed that Lager "ES3.0" board can't boot on this and previous -rc2 branch.
>> In my and Shimoda-san's check, "ES2.0" seems have no problem.
>>
>> It start works if I reverted this patch.
>>
>>         09a28bb8b17e8cab3e9c120b7e37f631cc334a8f
>>         ("ARM: dts: lager: use demuxer for IIC3/I2C3")
>
> FYI, I have now received the problematic Lager ES3 board from
> Morimoto-san and I will install it for remote access.
>
> How can we check which ES version we are running? I recall seeing some
> patch from Geert that printed out useful information during boot, any
> chance that could make it upstream (if it is not already)?

It's part of my topic/renesas-debug branch. Just merge that into latest
renesas-drivers and see...

Note that that branch also has the debug code to disable unused MSTP
clocks during boot. If you only want the SoC identification, just cherry-pick
commit c8e302adee4a1f9c ("[LOCAL] soc: renesas: Print SoC Product Version").

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]


> > How can we check which ES version we are running? I recall seeing some
> > patch from Geert that printed out useful information during boot, any
> > chance that could make it upstream (if it is not already)?
> 
> It's part of my topic/renesas-debug branch. Just merge that into latest
> renesas-drivers and see...

I second Magnus in wanting this upstream. The FIXMEs are about the
cache. Maybe submit an initial version without cache report first? Or
are there other issues? It would be really helpful to have this in the
bootlogs by default, I'd say.

Thanks,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Geert Uytterhoeven]

On Thu, Aug 25, 2016 at 6:46 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
>> > How can we check which ES version we are running? I recall seeing some
>> > patch from Geert that printed out useful information during boot, any
>> > chance that could make it upstream (if it is not already)?
>>
>> It's part of my topic/renesas-debug branch. Just merge that into latest
>> renesas-drivers and see...
>
> I second Magnus in wanting this upstream. The FIXMEs are about the
> cache. Maybe submit an initial version without cache report first? Or
> are there other issues? It would be really helpful to have this in the
> bootlogs by default, I'd say.

I've accidentally stumbled upon a patch from Arnd to match against
SoC revisions:
[PATCH 1/4] base: soc: introduce soc_device_match() interface
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-May/431902.html

Now, soc_device_register() seems to be the API to publish the SoC
revision. Unfortunately the SoC bus itself is registered from a core_initcall(),
which may be too late for our purposes.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]


> I noticed that Lager "ES3.0" board can't boot on this and previous -rc2 branch.
> In my and Shimoda-san's check, "ES2.0" seems have no problem.

I understand the issue now. It is not about ES3.0 vs. ES2.0, it is about
cold-boot vs. warm-boot. I remembered the DA9xxx interrupt storm
problems we had, and voila, I could reproduce the lockup on ES2.0 here,
but you need to cold-boot and have the da9xxx drivers enabled.

The fixup which we have in mach-shmobile/regulator-quirk-rcar-gen2.c is
flaky. It only works if the da9xxx devices are added before their
drivers are registered. Only then it can apply the fixes to both
devices. Otherwise, the driver for the first device gets probed before
the fix for the second can be applied. This is what happens with the IP
core switcher which is initialized after the i2c drivers are already
loaded. The same issue would happen without the IP core switcher if one
loads the I2C master driver as a module.

So, we need to disable both da9xxx once we detected one. I first had the
idea of installing mini i2c drivers which are loaded before the "real"
ones and prepare the devices accordingly and then hand over. But even
sketching this looks ugly, so I suggest to just use i2c_transfer with
hardcoded i2c_messages and device addresses. The fixup is used on
specific boards only, and the addresses are not going to change there.
If so, the new boards need a new compatible value.

I will work the i2c_transfer solution right after I had lunch.

Regards,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Kuninori Morimoto]

Hi Wolfram

> > I noticed that Lager "ES3.0" board can't boot on this and previous -rc2 branch.
> > In my and Shimoda-san's check, "ES2.0" seems have no problem.
> 
> I understand the issue now. It is not about ES3.0 vs. ES2.0, it is about
> cold-boot vs. warm-boot. I remembered the DA9xxx interrupt storm
> problems we had, and voila, I could reproduce the lockup on ES2.0 here,
> but you need to cold-boot and have the da9xxx drivers enabled.

It seems lager board has 2 type of DA9xxx chip, type A, and type B.
We don't know which chip your / my board has.

My *current* Lager board has no issue on cold / warm boot.
Magnus has my previous Lager board, so I can't try it today.
I think my current board and previous board have different type of chip.
Magnus will bring me my previous board tomorrow, so I will check it,
and try your solution.

Best regards
---
Kuninori Morimoto

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Geert Uytterhoeven]

Hi Morimoto-san,

On Wed, Aug 31, 2016 at 8:20 AM, Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
>> > I noticed that Lager "ES3.0" board can't boot on this and previous -rc2 branch.
>> > In my and Shimoda-san's check, "ES2.0" seems have no problem.
>>
>> I understand the issue now. It is not about ES3.0 vs. ES2.0, it is about
>> cold-boot vs. warm-boot. I remembered the DA9xxx interrupt storm
>> problems we had, and voila, I could reproduce the lockup on ES2.0 here,
>> but you need to cold-boot and have the da9xxx drivers enabled.
>
> It seems lager board has 2 type of DA9xxx chip, type A, and type B.
> We don't know which chip your / my board has.
>
> My *current* Lager board has no issue on cold / warm boot.
> Magnus has my previous Lager board, so I can't try it today.
> I think my current board and previous board have different type of chip.
> Magnus will bring me my previous board tomorrow, so I will check it,
> and try your solution.

The revision doesn't seem to be printed on the chip package, but it is
identified by the da9063 driver (CONFIG_REGULATOR_DA9063=y).

My Koelsch has:

     da9063 6-0058: Device detected (chip-ID: 0x61, var-ID: 0x30)

which corresponds to PMIC_DA9063_AD.
Magnus' Lager (remote access) has the same version.

(after adding the missing pieces to DT) Magnus's Gose has:

    da9063 6-0058: Device detected (chip-ID: 0x61, var-ID: 0x50)

which corresponds to PMIC_DA9063_BB.

Which revision do you have?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 285 bytes --]


> The revision doesn't seem to be printed on the chip package, but it is
> identified by the da9063 driver (CONFIG_REGULATOR_DA9063=y).

Am I recalling correctly that noone of us has access to DA9063
documentation? Is this still true? Or do we know the differences of the
revisions?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Geert Uytterhoeven]

Hi Wolfram,

On Wed, Aug 31, 2016 at 10:07 AM, Wolfram Sang <wsa@the-dreams.de> wrote:
> Am I recalling correctly that noone of us has access to DA9063
> documentation? Is this still true? Or do we know the differences of the
> revisions?

Yes.

I had completely forgotten I did apply for documentation on their website
a long time ago. No response.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Kuninori Morimoto]

Hi Geert, Wolfram

> > Magnus has my previous Lager board, so I can't try it today.
> > I think my current board and previous board have different type of chip.
> > Magnus will bring me my previous board tomorrow, so I will check it,
> > and try your solution.
> 
> The revision doesn't seem to be printed on the chip package, but it is
> identified by the da9063 driver (CONFIG_REGULATOR_DA9063=y).
> 
> My Koelsch has:
> 
>      da9063 6-0058: Device detected (chip-ID: 0x61, var-ID: 0x30)
> 
> which corresponds to PMIC_DA9063_AD.
> Magnus' Lager (remote access) has the same version.
> 
> (after adding the missing pieces to DT) Magnus's Gose has:
> 
>     da9063 6-0058: Device detected (chip-ID: 0x61, var-ID: 0x50)
> 
> which corresponds to PMIC_DA9063_BB.
> 
> Which revision do you have?

Thank you for your help. I found the hot-spot.
The issue was not ES2.0 vs ES3.0, not DA9063 Type,
not Hot/Cold boot, and not uboot version on my desk.
It was dipswitch.
I can reproduce this on Lager board now.
If I OFF:ed on SW8 : 4bit (= MD21), kernel boot will be failed.
It happened on both board

ES2.0 : da9063 11-0058: Device detected (chip-ID: 0x61, var-ID: 0x50)
ES3.0 : da9063 11-0058: Device detected (chip-ID: 0x61, var-ID: 0x30)

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 167 bytes --]


> I can reproduce this on Lager board now.
> If I OFF:ed on SW8 : 4bit (= MD21), kernel boot will be failed.
> It happened on both board

Even with my recent patch?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Kuninori Morimoto]

Hi Wolfram

> > I can reproduce this on Lager board now.
> > If I OFF:ed on SW8 : 4bit (= MD21), kernel boot will be failed.
> > It happened on both board
> 
> Even with my recent patch?

I tried your patch, and it solved this issue.
Thanks.
I will post Tested-by to it

Best regards
---
Kuninori Morimoto

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Geert Uytterhoeven]

Hi Morimoto-san,

On Thu, Sep 1, 2016 at 9:06 AM, Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
>> > I can reproduce this on Lager board now.
>> > If I OFF:ed on SW8 : 4bit (= MD21), kernel boot will be failed.
>> > It happened on both board
>>
>> Even with my recent patch?
>
> I tried your patch, and it solved this issue.

Interesting...

Does "[PATCH/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow booting secondary CPU
cores in debug mode", without Wolfram's patch, also fix it?

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Kuninori Morimoto]

Hi Geert

> >> Even with my recent patch?
> >
> > I tried your patch, and it solved this issue.
> 
> Interesting...
> 
> Does "[PATCH/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow booting secondary CPU
> cores in debug mode", without Wolfram's patch, also fix it?

Interesting...

Your patch (without Wolfram's patch) also solved this issue

Re: renesas-drivers-2016-08-23-v4.8-rc3

[Geert Uytterhoeven]

Hi Morimoto-san,

On Fri, Sep 2, 2016 at 3:38 AM, Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
>> >> Even with my recent patch?
>> >
>> > I tried your patch, and it solved this issue.
>>
>> Interesting...
>>
>> Does "[PATCH/RFT 0/4] ARM: shmobile: R-Car Gen2: Allow booting secondary CPU
>> cores in debug mode", without Wolfram's patch, also fix it?
>
> Interesting...
>
> Your patch (without Wolfram's patch) also solved this issue

I can offer some explanation, though...

The regulator quirk code masks all interrupts and events. Some of these events
are error states, but not all of them are. Hence they may be set (and cause
problems due to unhandled interrupts without the quirk) depending on power
consumption on the various power rails. The latter are influenced by secondary
CPU booting, and possibly by configuration of reset debug hardware.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds