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

2015-10-29 Thread Wolfram Sang 
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.



signature.asc
Description: Digital signature

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

2015-10-25 Thread Wolfram Sang 
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



signature.asc
Description: Digital signature

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

2015-10-23 Thread Laurent Pinchart 
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.

> >   -0 [000] d.h1 1.498063: rcar_i2c_irq: msr 09090909
> >   -0 [000] d.h1 1.498075: rcar_i2c_irq: msr 08080808
> >   -0 [000] d.h1 1.498266: rcar_i2c_irq: msr 07070707
> >   -0 [000] d.h1 1.498348: rcar_i2c_irq: msr 06060606
> >   -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.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2015-10-23 Thread Wolfram Sang 
> > :/ 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...

>   -0 [000] d.h1 1.498063: rcar_i2c_irq: msr 09090909
>   -0 [000] d.h1 1.498075: rcar_i2c_irq: msr 08080808
>   -0 [000] d.h1 1.498266: rcar_i2c_irq: msr 07070707
>   -0 [000] d.h1 1.498348: rcar_i2c_irq: msr 06060606
>   -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



signature.asc
Description: Digital signature

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

2015-10-23 Thread Laurent Pinchart 
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.

-- 
Regards,

Laurent Pinchart
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.3.0-rc5-04061-gb9653e9c000d-dirty (laurent@avalon) (gcc version 4.7.3 20130205 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.02-01-20130221 - Linaro GCC 2013.02) ) #89 SMP Fri Oct 23 13:16:05 EEST 2015
[0.00] CPU: ARMv7 Processor [413fc0f2] revision 2 (ARMv7), cr=30c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[0.00] Machine model: Koelsch
[0.00] debug: ignoring loglevel setting.
[0.00] cma: Reserved 256 MiB at 0x7000
[0.00] cma: Reserved 64 MiB at 0x6c00
[0.00] Forcing write-allocate cache policy for SMP
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 524288
[0.00] free_area_init_node: node 0, pgdat c0678ec0, node_mem_map e7fd8000
[0.00]   DMA zone: 1536 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 196608 pages, LIFO batch:31
[0.00]   HighMem zone: 327680 pages, LIFO batch:31
[0.00] PERCPU: Embedded 12 pages/cpu @e7f9 s17920 r8192 d23040 u49152
[0.00] pcpu-alloc: s17920 r8192 d23040 u49152 alloc=12*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 522752
[0.00] Kernel command line: ignore_loglevel rw root=/dev/nfs ip=dhcp
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 1742976K/2097152K available (4276K kernel code, 304K rwdata, 1652K rodata, 392K init, 2183K bss, 26496K reserved, 327680K cma-reserved, 1048576K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xf080 - 0xff80   ( 240 MB)
[0.00] lowmem  : 0xc000 - 0xf000   ( 768 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc05d3034   (5933 kB)
[0.00]   .init : 0xc05d4000 - 0xc0636000   ( 392 kB)
[0.00]   .data : 0xc0636000 - 0xc0682364   ( 305 kB)
[0.00].bss : 0xc0685000 - 0xc08a6c9c   (2184 kB)
[0.00] Hierarchical RCU implementation.
[0.00] 	Build-time adjustment of leaf fanout to 32.
[0.00] 	RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
[0.00] 
[0.00] **
[0.00] **   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **
[0.00] **  **
[0.00] ** trace_printk() being used. Allocating extra memory.  **
[0.00] **  **
[0.00] ** This means that this is a DEBUG kernel and it is **
[0.00] ** unsafe for production use.   **
[0.00] **  **
[0.00] ** If you see this message and you are not debugging**
[0.00] ** the kernel, report this immediately to your vendor!  **
[0.00] **  **
[0.00] **   NOTICE NOTICE

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

2015-10-23 Thread Geert Uytterhoeven 
On Fri, Oct 23, 2015 at 10:06 AM, Wolfram Sang  wrote:
>> b9653e9c000dc2ebd9c8712442c659ccd1586e22 from Geert's drivers tree ? On my
>
> Does that build for you?
>
> drivers/gpu/drm/drm_fb_helper.c: In function 'restore_fbdev_mode':
> drivers/gpu/drm/drm_fb_helper.c:448:5: error: 'error' undeclared (first use 
> in this function)
>
> ??

Sorry, my fault. Wrong merge resolution:

--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -445,7 +445,7 @@ static int restore_fbdev_mode(struct drm_fb_helper *fb_helpe
if (crtc->funcs->cursor_set2) {
ret = crtc->funcs->cursor_set2(crtc, NULL, 0, 0, 0, 0, 0
if (ret)
-   error = true;
+   return ret;
} else if (crtc->funcs->cursor_set) {
ret = crtc->funcs->cursor_set(crtc, NULL, 0, 0, 0);
if (ret)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2015-10-23 Thread Wolfram Sang 

> 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

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);



signature.asc
Description: Digital signature

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

2015-10-23 Thread Wolfram Sang 
> -   error = true;
> +   return ret;

Yup, did that, too :)



signature.asc
Description: Digital signature

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

2015-10-23 Thread Wolfram Sang 

> Do you have a Koelsch board now ? Could you try 

Nope, I only have Lager. I'd be surprised if it really was a Koelsch
only issue, though...

> b9653e9c000dc2ebd9c8712442c659ccd1586e22 from Geert's drivers tree ? On my 

Does that build for you?

drivers/gpu/drm/drm_fb_helper.c: In function 'restore_fbdev_mode':
drivers/gpu/drm/drm_fb_helper.c:448:5: error: 'error' undeclared (first use in 
this function)

??

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. Tested that with a kernel which used to work in
Dublin. Need to get another HDMI device.

> board the adv7511 fails to probe completely due to the regmap_read() failure.

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

Thanks,

   Wolfram



signature.asc
Description: Digital signature

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

2015-10-22 Thread Laurent Pinchart 
Hi Wolfram,

On Thursday 22 October 2015 13:05:05 Wolfram Sang wrote:
> On Thu, Oct 22, 2015 at 02:10:52AM +0300, Laurent Pinchart wrote:
> > On Thursday 03 September 2015 22:20:09 Wolfram Sang wrote:
> > > From: Wolfram Sang 
> > > 
> > > Setting up new messages was done in process context while handling a
> > > message was in interrupt context. Because of the HW design, this IP core
> > > is sensitive to timing, so the context switches were too expensive. Move
> > > this setup to interrupt context as well.
> > > 
> > > In my test setup, this fixed the occasional 'data byte sent twice' issue
> > > which a number of people have seen. It also fixes to send REP_START
> > > after a read message which was wrongly send as a STOP + START sequence
> > > before.
> > 
> > I'm afraid this patch has been found by git bisect to break HDMI on
> > Koelsch
> > 
> > :-(
> > 
> > The regmap_read(adv7511->regmap, ADV7511_REG_CHIP_REVISION, ) call in
> > drivers/gpu/drm/i2c/adv7511.c returns -ENXIO.
> > 
> > Reverting the patch on top of Geert's current drivers master branch fixes
> > the problem.
> 
> But HDMI worked on Koelsch in Dublin??

I know :-)

Do you have a Koelsch board now ? Could you try 
b9653e9c000dc2ebd9c8712442c659ccd1586e22 from Geert's drivers tree ? On my 
board the adv7511 fails to probe completely due to the regmap_read() failure.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2015-10-22 Thread Wolfram Sang 
On Thu, Oct 22, 2015 at 02:10:52AM +0300, Laurent Pinchart wrote:
> Hi Wolfram,
> 
> On Thursday 03 September 2015 22:20:09 Wolfram Sang wrote:
> > From: Wolfram Sang 
> > 
> > Setting up new messages was done in process context while handling a
> > message was in interrupt context. Because of the HW design, this IP core
> > is sensitive to timing, so the context switches were too expensive. Move
> > this setup to interrupt context as well.
> > 
> > In my test setup, this fixed the occasional 'data byte sent twice' issue
> > which a number of people have seen. It also fixes to send REP_START
> > after a read message which was wrongly send as a STOP + START sequence
> > before.
> 
> I'm afraid this patch has been found by git bisect to break HDMI on Koelsch 
> :-( 
> 
> The regmap_read(adv7511->regmap, ADV7511_REG_CHIP_REVISION, ) call in 
> drivers/gpu/drm/i2c/adv7511.c returns -ENXIO.
> 
> Reverting the patch on top of Geert's current drivers master branch fixes the 
> problem.

But HDMI worked on Koelsch in Dublin??



signature.asc
Description: Digital signature

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

2015-10-21 Thread Laurent Pinchart 
Hi Wolfram,

On Thursday 03 September 2015 22:20:09 Wolfram Sang wrote:
> From: Wolfram Sang 
> 
> Setting up new messages was done in process context while handling a
> message was in interrupt context. Because of the HW design, this IP core
> is sensitive to timing, so the context switches were too expensive. Move
> this setup to interrupt context as well.
> 
> In my test setup, this fixed the occasional 'data byte sent twice' issue
> which a number of people have seen. It also fixes to send REP_START
> after a read message which was wrongly send as a STOP + START sequence
> before.

I'm afraid this patch has been found by git bisect to break HDMI on Koelsch 
:-( 

The regmap_read(adv7511->regmap, ADV7511_REG_CHIP_REVISION, ) call in 
drivers/gpu/drm/i2c/adv7511.c returns -ENXIO.

Reverting the patch on top of Geert's current drivers master branch fixes the 
problem.

> Signed-off-by: Wolfram Sang 
> ---
>  drivers/i2c/busses/i2c-rcar.c | 74 +++-
>  1 file changed, 37 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
> index 6e459a338ccc75..36c79301044b71 100644
> --- a/drivers/i2c/busses/i2c-rcar.c
> +++ b/drivers/i2c/busses/i2c-rcar.c
> @@ -266,6 +266,13 @@ static void rcar_i2c_prepare_msg(struct rcar_i2c_priv
> *priv) rcar_i2c_write(priv, ICMIER, read ? RCAR_IRQ_RECV : RCAR_IRQ_SEND);
> }
> 
> +static void rcar_i2c_next_msg(struct rcar_i2c_priv *priv)
> +{
> + priv->msg++;
> + priv->msgs_left--;
> + rcar_i2c_prepare_msg(priv);
> +}
> +
>  /*
>   *   interrupt functions
>   */
> @@ -308,21 +315,17 @@ static int rcar_i2c_irq_send(struct rcar_i2c_priv
> *priv, u32 msr) * [ICRXTX] -> [SHIFT] -> [I2C bus]
>*/
> 
> - if (priv->flags & ID_LAST_MSG)
> + if (priv->flags & ID_LAST_MSG) {
>   /*
>* If current msg is the _LAST_ msg,
>* prepare stop condition here.
>* ID_DONE will be set on STOP irq.
>*/
>   rcar_i2c_write(priv, ICMCR, RCAR_BUS_PHASE_STOP);
> - else
> - /*
> -  * If current msg is _NOT_ last msg,
> -  * it doesn't call stop phase.
> -  * thus, there is no STOP irq.
> -  * return ID_DONE here.
> -  */
> - return ID_DONE;
> + } else {
> + rcar_i2c_next_msg(priv);
> + return 0;
> + }
>   }
> 
>   rcar_i2c_write(priv, ICMSR, RCAR_IRQ_ACK_SEND);
> @@ -366,7 +369,10 @@ static int rcar_i2c_irq_recv(struct rcar_i2c_priv
> *priv, u32 msr) else
>   rcar_i2c_write(priv, ICMCR, RCAR_BUS_PHASE_DATA);
> 
> - rcar_i2c_write(priv, ICMSR, RCAR_IRQ_ACK_RECV);
> + if (priv->pos == msg->len && !(priv->flags & ID_LAST_MSG))
> + rcar_i2c_next_msg(priv);
> + else
> + rcar_i2c_write(priv, ICMSR, RCAR_IRQ_ACK_RECV);
> 
>   return 0;
>  }
> @@ -461,6 +467,7 @@ static irqreturn_t rcar_i2c_irq(int irq, void *ptr)
> 
>   /* Stop */
>   if (msr & MST) {
> + priv->msgs_left--; /* The last message also made it */
>   rcar_i2c_flags_set(priv, ID_DONE);
>   goto out;
>   }
> @@ -500,35 +507,28 @@ static int rcar_i2c_master_xfer(struct i2c_adapter
> *adap, /* This HW can't send STOP after address phase */
>   if (msgs[i].len == 0) {
>   ret = -EOPNOTSUPP;
> - break;
> - }
> -
> - /* init each data */
> - priv->msg = [i];
> - priv->msgs_left = num - i;
> -
> - rcar_i2c_prepare_msg(priv);
> -
> - time_left = wait_event_timeout(priv->wait,
> -  rcar_i2c_flags_has(priv, ID_DONE),
> -  adap->timeout);
> - if (!time_left) {
> - rcar_i2c_init(priv);
> - ret = -ETIMEDOUT;
> - break;
> - }
> -
> - if (rcar_i2c_flags_has(priv, ID_NACK)) {
> - ret = -ENXIO;
> - break;
> - }
> -
> - if (rcar_i2c_flags_has(priv, ID_ARBLOST)) {
> - ret = -EAGAIN;
> - break;
> + goto out;
>   }
> + }
> 
> - ret = i + 1; /* The number of transfer */
> + /* init data */
> + priv->msg = msgs;
> + priv->msgs_left = num;
> +
> + rcar_i2c_prepare_msg(priv);
> +
> + time_left = wait_event_timeout(priv->wait,
> +  rcar_i2c_flags_has(priv, ID_DONE),
> +  num *