diff mbox

[5/9] i2c: rcar: init new messages in irq

Message ID 20151023094500.GD13380@katana
State Not Applicable
Headers show

Commit Message

Wolfram Sang Oct. 23, 2015, 9:45 a.m. UTC
> I had CONFIG_DRM_FBDEV_EMULATION disabled. I've then enabled it but also 
> merged git://people.freedesktop.org/~airlied/linux next in my branch, which 
> probably fixes the problem.

So, your tree is not strictly renesas-drivers-2015-10-13-v4.3-rc5?

> > I fixed it locally and will see if I see ADV7511 problems. I cannot
> > fully test HDMI probably, because it seems that this HDMI->DVI chain I
> > have does not work.
> 
> It's supposed to be supported, so that might be something we need to fix. More 
> work for me \o/ :-)

:/ Let me know if I can send you debug output.

> > Okay, so before any 'modetest' activity. Which kernelconfig?
> > shmobile_defconfig?
> 
> .config attached.

That one also probes for me... I only disabled DHCP and added my
initramfs. I patched the fbdev build error out and changed Lager dts to
use i2c-rcar (instead of i2c-sh_mobile).

Can you enable CONFIG_I2C_DEBUG_CORE in the config, apply this patch,
and send me the trace output and bootlog?

Thanks,

   Wolfram

Comments

Laurent Pinchart Oct. 23, 2015, 10:28 a.m. UTC | #1
Hi Wolfram,

On Friday 23 October 2015 11:45:00 Wolfram Sang wrote:
> > I had CONFIG_DRM_FBDEV_EMULATION disabled. I've then enabled it but also
> > merged git://people.freedesktop.org/~airlied/linux next in my branch,
> > which probably fixes the problem.
> 
> So, your tree is not strictly renesas-drivers-2015-10-13-v4.3-rc5?

I've tested it on renesas-drivers-2015-10-13-v4.3-rc5 without 
CONFIG_DRM_FBDEV_EMULATION, explaining why it compiled properly for me.

> >> I fixed it locally and will see if I see ADV7511 problems. I cannot
> >> fully test HDMI probably, because it seems that this HDMI->DVI chain I
> >> have does not work.
> > 
> > It's supposed to be supported, so that might be something we need to fix.
> > More work for me \o/ :-)
>
> :/ Let me know if I can send you debug output.

What's the exact issue ?

> >> Okay, so before any 'modetest' activity. Which kernelconfig?
> >> shmobile_defconfig?
> > 
> > .config attached.
> 
> That one also probes for me... I only disabled DHCP and added my initramfs.
> I patched the fbdev build error out and changed Lager dts to use i2c-rcar
> (instead of i2c-sh_mobile).
> 
> Can you enable CONFIG_I2C_DEBUG_CORE in the config, apply this patch,
> and send me the trace output and bootlog?

Please find both attached to this e-mail.
Wolfram Sang Oct. 23, 2015, 12:14 p.m. UTC | #2
> > :/ Let me know if I can send you debug output.
> 
> What's the exact issue ?

Best report ever: I simply don't get a picture :) No warnings, no
messages. I think we want to make sure my HDMI->DVI converter is proper,
though.

> > > .config attached.
> > 
> > That one also probes for me... I only disabled DHCP and added my initramfs.
> > I patched the fbdev build error out and changed Lager dts to use i2c-rcar
> > (instead of i2c-sh_mobile).

I made the ADV7180 and AK4642 built-in and this kernel still probes
rcar-du on my Lager and Magnus' Koelsch...

>           <idle>-0     [000] d.h1     1.498063: rcar_i2c_irq: msr 09090909
>           <idle>-0     [000] d.h1     1.498075: rcar_i2c_irq: msr 08080808
>           <idle>-0     [000] d.h1     1.498266: rcar_i2c_irq: msr 07070707
>           <idle>-0     [000] d.h1     1.498348: rcar_i2c_irq: msr 06060606
>           <idle>-0     [000] d.h1     1.498465: rcar_i2c_irq: msr 49494949

So, here is the NACK bit set. Which does not happen on my Lager and
Magnus' Koelsch. I am starting to wonder if you have a board with HW
issues? Could it be another I2C device interfering? Do you happen to
know if you have an earlier revision of Koelsch?

Thanks,

   Wolfram
Laurent Pinchart Oct. 23, 2015, 1:14 p.m. UTC | #3
Hi Wolfram,

On Friday 23 October 2015 14:14:39 Wolfram Sang wrote:
> > > :/ Let me know if I can send you debug output.
> > 
> > What's the exact issue ?
> 
> Best report ever: I simply don't get a picture :) No warnings, no
> messages. I think we want to make sure my HDMI->DVI converter is proper,
> though.

Does it work with other HDMI sources ?

> > > > .config attached.
> > > 
> > > That one also probes for me... I only disabled DHCP and added my
> > > initramfs. I patched the fbdev build error out and changed Lager dts to
> > > use i2c-rcar (instead of i2c-sh_mobile).
> 
> I made the ADV7180 and AK4642 built-in and this kernel still probes
> rcar-du on my Lager and Magnus' Koelsch...

It's CONFIG_DRM_I2C_ADV7511 that you need for HDMI output.

I have ADV7180 and AK4642 built as modules in my kernel.

> >           <idle>-0     [000] d.h1     1.498063: rcar_i2c_irq: msr 09090909
> >           <idle>-0     [000] d.h1     1.498075: rcar_i2c_irq: msr 08080808
> >           <idle>-0     [000] d.h1     1.498266: rcar_i2c_irq: msr 07070707
> >           <idle>-0     [000] d.h1     1.498348: rcar_i2c_irq: msr 06060606
> >           <idle>-0     [000] d.h1     1.498465: rcar_i2c_irq: msr 49494949
> 
> So, here is the NACK bit set. Which does not happen on my Lager and
> Magnus' Koelsch. I am starting to wonder if you have a board with HW
> issues?

It works fine when reverting this patch :-/

> Could it be another I2C device interfering?

I wouldn't rule anything out, but I don't see why reverting this patch would 
help then.

> Do you happen to know if you have an earlier revision of Koelsch?

RTPORC7791SEB00010S
KOELSCH SN.057

I'm not sure if that tells anything about the board revision.
Wolfram Sang Oct. 25, 2015, 3:53 p.m. UTC | #4
Hi,

so I did some testing regarding my setup.

> > Best report ever: I simply don't get a picture :) No warnings, no
> > messages. I think we want to make sure my HDMI->DVI converter is proper,
> > though.
> 
> Does it work with other HDMI sources ?

I borrowed another HDMI monitor. There, my Lager board produces proper
HDMI output, both with plain HDMI connection as well as with the
HDMI->DVI converter. No I2C issues.

Seems I have to dump this other monitor which didn't even display the
output of the Chromecast I had lying around.


> > So, here is the NACK bit set. Which does not happen on my Lager and
> > Magnus' Koelsch. I am starting to wonder if you have a board with HW
> > issues?
> 
> It works fine when reverting this patch :-/

Tricky. Your binary kernel didn't even start on first try on my Lager
and Magnus' Koelsch. Will check that again tomorrow.

> > Do you happen to know if you have an earlier revision of Koelsch?
> 
> RTPORC7791SEB00010S
> KOELSCH SN.057
> 
> I'm not sure if that tells anything about the board revision.

Magnus, what does your board say?

Thanks,

   Wolfram
Wolfram Sang Oct. 29, 2015, 7:23 p.m. UTC | #5
Laurent,

> RTPORC7791SEB00010S
> KOELSCH SN.057
> 
> I'm not sure if that tells anything about the board revision.

Can you try this patch I just sent out?

"i2c: rcar: make sure clocks are on when doing hw init"

We know that Koelsch boards have different bootloaders leaving the
clocks in different states. What you see could be the result of a
disabled clock.
diff mbox

Patch

diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 1921294afc87ce..cd56f77550cac1 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -418,6 +418,7 @@  static irqreturn_t rcar_i2c_irq(int irq, void *ptr)
 	rcar_i2c_write(priv, ICMCR, val & RCAR_BUS_MASK_DATA);
 
 	msr = rcar_i2c_read(priv, ICMSR);
+trace_printk("msr %08x\n", msr);
 
 	/* Only handle interrupts that are currently enabled */
 	msr &= rcar_i2c_read(priv, ICMIER);