date:20161130

[linux-sunxi] Re: [PATCH 12/14] fdt: eth_fixup: Add hook for board to override MAC

2016-11-30 Thread Simon Glass

Hi,

On 25 November 2016 at 08:30, Olliver Schinagl  wrote:
> This patch adds a method for the board to set the MAC address if the
> environment is not yet set. The environment based MAC addresses are not
> touched, but if the fdt has an alias set, it is parsed and put into the
> environment.
>
> E.g. The environment contains ethaddr and eth1addr, and the fdt contains
> an ethernet1 nothing happens. If the fdt contains ethernet2 however, it
> is parsed and inserted into the environment as eth2addr.
>
> Signed-off-by: Olliver Schinagl 
> ---
>  common/fdt_support.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/common/fdt_support.c b/common/fdt_support.c
> index c34a13c..f127392 100644
> --- a/common/fdt_support.c
> +++ b/common/fdt_support.c
> @@ -465,6 +465,11 @@ int fdt_fixup_memory(void *blob, u64 start, u64 size)
> return fdt_fixup_memory_banks(blob, , , 1);
>  }
>
> +__weak int board_get_enetaddr(const int i, unsigned char *mac_addr)
> +{
> +   return -ENOSYS;
> +}
> +
>  void fdt_fixup_ethernet(void *fdt)
>  {
> int i, prop;
> @@ -507,7 +512,8 @@ void fdt_fixup_ethernet(void *fdt)
> if (fdt_eth_addr)
> eth_parse_enetaddr(fdt_eth_addr, mac_addr);
> else
> -   continue;
> +   if (board_get_enetaddr(i, mac_addr) < 0)
> +   continue;
>
> do_fixup_by_path(fdt, path, "mac-address",
>  _addr, 6, 0);
> --
> 2.10.2
>

Much as I don't want to pin this on any one patch, but I feel that our
DT fixup stuff is a bit out of control. We have so many functions that
do this, and they are called from various places. At some point we
need to think about the infrastructure.

IMO we should move to a linker list approach a bit like SPL did
recently (SPL_LOAD_IMAGE_METHOD). Then boards and subsystems can
register (at build-time) a fixup routine and they all get called one
after the other.

We could also (later) add run-time support for registering fixups,
that drivers could use.

Regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] a13

2016-11-30 Thread сергей moobi

Yes know where to get images with the new kernel) tomorrow I will try to 
rewrite all the chips of tablet and version of the processor. can you 
something advise then. and it's a Chinese tablet samsung p7110. I tried 
to collect myself but nothing is impossible. thank you that responded.


четверг, 1 декабря 2016 г., 1:40:11 UTC+3 пользователь dhlynch2 написал:
>
> The only mention of a particular board in any of what you provided was 
> that one of the images was for a Lime. I beleive that is an A10. 
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] a13

2016-11-30 Thread David H. Lynch Jr.

The only mention of a particular board in any of what you provided was
that one of the images was for a Lime. I beleive that is an A10. 

All of the Linux versions from the images you list are old to very old
- except possibly the Armbian image - if that is for the right board. 

For all 3.X linux versions for Allwinner CPU's there is a ;fex file
that must be configured specific not merely to the CPU, but also the
board. This is loosely like the device tree in 4.X versions of Linux. 
If you do not have a fex specific to your board properly integrated to
the image it will likely boot - because of the large similarities
between AllWinner boards/cpus, but many things will not work.

It is my guess that is your problem. 

I have had pretty good experience with Armbian - both legacy and
development kernels. If your requirements allow you to use recent 4.x
kernels. that eliminates fex, files - but requires device tree files,
but there is a greater likelyhood that the correct dtb for your board
might be selected automatically.  However there are features missing
from the 4.x kernels and if you need those features then I think the
most recent kernels for AllWinner would be 3.4.113 - but 3.4.113 is
itself fairly old, so support for newer hardware may be missing.

This 3.x/4.x tradeoff is a problem for everyone using AllWinner. 
The good news is that the Allwinner support in the 4.x kernels is
getting better all the time - cudos to the developers in this group. 

I would also note that there are lots of broken sd card images for
AllWinner based devices available on the Web. 

For AllWinner based devices I would recommend the latest image from
Armbian specific to your board.  Someone else here may have another
recommendation. 


 



Original Message-
From: сергей moobi 
To: linux-sunxi 
Cc: dh...@dlasys.net
Subject: Re: [linux-sunxi] a13
Date: Wed, 30 Nov 2016 14:07:42 -0800 (PST)



-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] a13

2016-11-30 Thread сергей moobi

kernel version 3.0.72 and 3.0.62+. adapter rtl8188etv 
debian_d50.tgz A13_ubuntu_precise_3.4.29_anubis_XCORE_R1.img 
A13_debian_armel_34_67_WIFI_GCC_GPIO_IN_OUT_I2C_100KHz_UVC_python_TS_release_1 
A13_ubuntu_precise_3.4.29_kickstart_anubis_R1.img 
Armbian_5.20_Lime2_Debian_jessie_3.4.112_desktop 
lubuntu-desktop-12.04-3-720p-512MB-miniand.com 
lubuntu14-04-arm-allwinner.img olinuxino_xfce-r18

and everywhere the same. can't configure network. not wifi, not eth0. more 
or less works debian50. but alas, everything is at a stage of tests and 
left. to have network and all would be solved.

четверг, 1 декабря 2016 г., 0:09:47 UTC+3 пользователь dhlynch2 написал:
>
> More information, please.  
>
> What A13 board ? I have used the  
> A13-OLinuXino as well the wifi version. 
>
> What Linux kernel are you using ? 
> I think mostly this list is in regard to 4.X versions. 
>
> What are the images you are trying ? 
>
>
>
>
>
> -Original Message- 
> From: сергей moobi  
> Reply-to: serge...@gmail.com  
> To: linux-sunxi  
> Subject: [linux-sunxi] a13 
> Date: Tue, 29 Nov 2016 21:53:28 -0800 (PST) 
>
>
> --  
> You received this message because you are subscribed to the Google 
> Groups "linux-sunxi" group. 
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to linux-sunxi...@googlegroups.com . 
> For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] a13

2016-11-30 Thread David H. Lynch Jr.

More information, please. 

What A13 board ? I have used the 
A13-OLinuXino as well the wifi version. 

What Linux kernel are you using ?
I think mostly this list is in regard to 4.X versions. 

What are the images you are trying ?





-Original Message-
From: сергей moobi 
Reply-to: sergejmo...@gmail.com
To: linux-sunxi 
Subject: [linux-sunxi] a13
Date: Tue, 29 Nov 2016 21:53:28 -0800 (PST)


-- 
You received this message because you are subscribed to the Google
Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

2016-11-30 Thread Maxime Ripard

On Wed, Nov 30, 2016 at 09:41:26PM +0100, Jernej Škrabec wrote:
> > > > > The only
> > > > > code left from you is for DE2. HDMI stuff is basically copied from
> > > > > Rockhip
> > > > > driver (including EDID reading), TCON code is now reverted to the same
> > > > > as
> > > > > it is in sunxi_display.c. I think it is worth to take a look at EDID
> > > > > code
> > > > > and compare it.
> > > > 
> > > > So is the TCON of DE 2.0 identical to the original TCON?
> > > > 
> > > > If so, we should reuse sun4i-tcon ...
> > > 
> > > Well, TCON is splitted in two parts (two base addresses), one for HDMI and
> > > one for TV. However, register offsets are same as before, so I guess
> > > driver reusage make sense. I think that there are few additional
> > > registers, but they can be ignored for simplefb.
> > 
> > The TCON1 of the H3 is not usable (no ckock). Analog TV has its own
> > clock and I/O area.
> > 
> 
> True, H3 user manual can be misleading sometimes. But this doesn't change the 
> fact that TCON0 has same register offsets with same meaning.

Then yes, we should definitely share the drivers too. So, in the end,
the only thing that is actually new is the display-engine?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

2016-11-30 Thread Jernej Škrabec

Dne sreda, 30. november 2016 ob 20:37:24 CET je Jean-Francois Moine 
napisal(a):
> On Wed, 30 Nov 2016 20:14:11 +0100
> 
> Jernej Škrabec  wrote:
> > Dne četrtek, 01. december 2016 ob 03:03:14 CET je Icenowy Zheng 
napisal(a):
> > > 2016年12月1日 02:49于 Jernej Skrabec 写道：
> > > 
> > > > Hi Jean-François,
> > > > 
> > > > Dne sreda, 30. november 2016 10.35.08 UTC+1 je oseba Jean-François
> > > > Moine
> > 
> > napisala:
> > > >> On Tue, 29 Nov 2016 22:59:32 +0100
> > > >> 
> > > >> Maxime Ripard  wrote:
> > > >> > > > I'm still not sure which pipeline should I use.
> > > >> > > > 
> > > >> > > > And, it seems that HDMI Slow Clock is not needed?
> > > >> > > > 
> > > >> > > > (seems that it's only for EDID, but simplefb won't use EDID)
> > > >> > > 
> > > >> > > So, I don't see how this may work.
> > > >> > > How can the u-boot know the resolutions of the HDMI display
> > > >> > > device?
> > > >> > > 
> > > >> > > In other words: I have a new H3 board with the last u-boot and
> > > >> > > kernel.
> > > >> > > I plug my (rather old or brand new) HDMI display device.
> > > >> > > After powering on the system, I hope to get something on the
> > > >> > > screen.
> > > >> > > How?
> > > >> > 
> > > >> > If it works like the driver for the first display engine in U-Boot,
> > > >> > it
> > > >> > will use the preferred mode reported by the EDID, and will fallback
> > > >> > to
> > > >> > 1024x768 if it cannot access it.
> > > >> 
> > > >> Icenowy wrote: "simplefb won't use EDID"
> > > >> 
> > > >> Then, if it is like in the kernel, the 1024x768 mode is VGA. It does
> > > >> not work with HDMI (different timings).
> > > > 
> > > > U-Boot driver now accept any timings recommended by EDID. So far it
> > > > was tested with at least following resolutions:
> > > > - 1920x1080 @ 60 Hz
> > > > - 1280x1024 @ 60 Hz
> > > > - 1280x800 @ 60 Hz (slight clock difference)
> > > > - 800x480 (not sure about frame rate)
> > > > - 3840x2160 @ 30 Hz (4K)
> > > 
> > > I tested on 1024x600 (If my memory is right, it's @ 60Hz)
> > > 
> > > > and nobody complained so far. I'm pretty sure 1024x768 would work.
> 
> Check the timings offered by the DRM core.

I'm not really familiar with DRM code, but my Linux laptop happily works with 
1024x768 @ 75 Hz and other non CEA resolutions through HDMI, so I guess it 
should be possible here too. Isn't function drm_add_edid_modes() designed 
exactly for that?

Anyway, this is off topic for simplefb. Simplefb driver will just take over 
framebuffer set up by U-Boot with some additional info like width, height, 
pitch... It doesn't have to deal with HW directly.

> 
> > > >> > Maybe it would be worth exchanging on the EDID code that has been
> > > >> > done
> > > >> > for the u-boot driver too, so that it can be fixed in your driver.
> > > >> 
> > > >> The u-boot got my code, and, up to now, I could not fix the random or
> > > >> permanent failures of EDID reading in some boards.
> > > > 
> > > > I only have one OPi2, but as I said, EDID always worked for me.
> 
> Happy guy!
> 
> > > > The only
> > > > code left from you is for DE2. HDMI stuff is basically copied from
> > > > Rockhip
> > > > driver (including EDID reading), TCON code is now reverted to the same
> > > > as
> > > > it is in sunxi_display.c. I think it is worth to take a look at EDID
> > > > code
> > > > and compare it.
> > > 
> > > So is the TCON of DE 2.0 identical to the original TCON?
> > > 
> > > If so, we should reuse sun4i-tcon ...
> > 
> > Well, TCON is splitted in two parts (two base addresses), one for HDMI and
> > one for TV. However, register offsets are same as before, so I guess
> > driver reusage make sense. I think that there are few additional
> > registers, but they can be ignored for simplefb.
> 
> The TCON1 of the H3 is not usable (no ckock). Analog TV has its own
> clock and I/O area.
> 

True, H3 user manual can be misleading sometimes. But this doesn't change the 
fact that TCON0 has same register offsets with same meaning.

> --
> Ken ar c'hentañ   | ** Breizh ha Linux atav! **
> Jef   |   http://moinejf.free.fr/


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

2016-11-30 Thread Jean-Francois Moine

On Wed, 30 Nov 2016 20:14:11 +0100
Jernej Škrabec  wrote:

> Dne četrtek, 01. december 2016 ob 03:03:14 CET je Icenowy Zheng napisal(a):
> > 2016年12月1日 02:49于 Jernej Skrabec 写道：
> > 
> > > Hi Jean-François,
> > > 
> > > Dne sreda, 30. november 2016 10.35.08 UTC+1 je oseba Jean-François Moine 
> napisala:
> > >> On Tue, 29 Nov 2016 22:59:32 +0100
> > >> 
> > >> Maxime Ripard  wrote:
> > >> > > > I'm still not sure which pipeline should I use.
> > >> > > > 
> > >> > > > And, it seems that HDMI Slow Clock is not needed?
> > >> > > > 
> > >> > > > (seems that it's only for EDID, but simplefb won't use EDID)
> > >> > > 
> > >> > > So, I don't see how this may work.
> > >> > > How can the u-boot know the resolutions of the HDMI display device?
> > >> > > 
> > >> > > In other words: I have a new H3 board with the last u-boot and
> > >> > > kernel.
> > >> > > I plug my (rather old or brand new) HDMI display device.
> > >> > > After powering on the system, I hope to get something on the screen.
> > >> > > How?
> > >> > 
> > >> > If it works like the driver for the first display engine in U-Boot, it
> > >> > will use the preferred mode reported by the EDID, and will fallback to
> > >> > 1024x768 if it cannot access it.
> > >> 
> > >> Icenowy wrote: "simplefb won't use EDID"
> > >> 
> > >> Then, if it is like in the kernel, the 1024x768 mode is VGA. It does
> > >> not work with HDMI (different timings).
> > > 
> > > U-Boot driver now accept any timings recommended by EDID. So far it
> > > was tested with at least following resolutions:
> > > - 1920x1080 @ 60 Hz
> > > - 1280x1024 @ 60 Hz
> > > - 1280x800 @ 60 Hz (slight clock difference)
> > > - 800x480 (not sure about frame rate)
> > > - 3840x2160 @ 30 Hz (4K)
> > 
> > I tested on 1024x600 (If my memory is right, it's @ 60Hz)
> > 
> > > and nobody complained so far. I'm pretty sure 1024x768 would work.

Check the timings offered by the DRM core.

> > > 
> > >> > Maybe it would be worth exchanging on the EDID code that has been done
> > >> > for the u-boot driver too, so that it can be fixed in your driver.
> > >> 
> > >> The u-boot got my code, and, up to now, I could not fix the random or
> > >> permanent failures of EDID reading in some boards.
> > > 
> > > I only have one OPi2, but as I said, EDID always worked for me.

Happy guy!

> > > The only
> > > code left from you is for DE2. HDMI stuff is basically copied from Rockhip
> > > driver (including EDID reading), TCON code is now reverted to the same as
> > > it is in sunxi_display.c. I think it is worth to take a look at EDID code
> > > and compare it.
> > 
> > So is the TCON of DE 2.0 identical to the original TCON?
> > 
> > If so, we should reuse sun4i-tcon ...
> 
> Well, TCON is splitted in two parts (two base addresses), one for HDMI and 
> one 
> for TV. However, register offsets are same as before, so I guess driver 
> reusage make sense. I think that there are few additional registers, but they 
> can be ignored for simplefb.

The TCON1 of the H3 is not usable (no ckock). Analog TV has its own
clock and I/O area.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

2016-11-30 Thread Jernej Škrabec

Dne četrtek, 01. december 2016 ob 03:03:14 CET je Icenowy Zheng napisal(a):
> 2016年12月1日 02:49于 Jernej Skrabec 写道：
> 
> > Hi Jean-François,
> > 
> > Dne sreda, 30. november 2016 10.35.08 UTC+1 je oseba Jean-François Moine 
napisala:
> >> On Tue, 29 Nov 2016 22:59:32 +0100
> >> 
> >> Maxime Ripard  wrote:
> >> > > > I'm still not sure which pipeline should I use.
> >> > > > 
> >> > > > And, it seems that HDMI Slow Clock is not needed?
> >> > > > 
> >> > > > (seems that it's only for EDID, but simplefb won't use EDID)
> >> > > 
> >> > > So, I don't see how this may work.
> >> > > How can the u-boot know the resolutions of the HDMI display device?
> >> > > 
> >> > > In other words: I have a new H3 board with the last u-boot and
> >> > > kernel.
> >> > > I plug my (rather old or brand new) HDMI display device.
> >> > > After powering on the system, I hope to get something on the screen.
> >> > > How?
> >> > 
> >> > If it works like the driver for the first display engine in U-Boot, it
> >> > will use the preferred mode reported by the EDID, and will fallback to
> >> > 1024x768 if it cannot access it.
> >> 
> >> Icenowy wrote: "simplefb won't use EDID"
> >> 
> >> Then, if it is like in the kernel, the 1024x768 mode is VGA. It does
> >> not work with HDMI (different timings).
> > 
> > U-Boot driver now accept any timings recommended by EDID. So far it
> > was tested with at least following resolutions:
> > - 1920x1080 @ 60 Hz
> > - 1280x1024 @ 60 Hz
> > - 1280x800 @ 60 Hz (slight clock difference)
> > - 800x480 (not sure about frame rate)
> > - 3840x2160 @ 30 Hz (4K)
> 
> I tested on 1024x600 (If my memory is right, it's @ 60Hz)
> 
> > and nobody complained so far. I'm pretty sure 1024x768 would work.
> > 
> >> > Maybe it would be worth exchanging on the EDID code that has been done
> >> > for the u-boot driver too, so that it can be fixed in your driver.
> >> 
> >> The u-boot got my code, and, up to now, I could not fix the random or
> >> permanent failures of EDID reading in some boards.
> > 
> > I only have one OPi2, but as I said, EDID always worked for me. The only
> > code left from you is for DE2. HDMI stuff is basically copied from Rockhip
> > driver (including EDID reading), TCON code is now reverted to the same as
> > it is in sunxi_display.c. I think it is worth to take a look at EDID code
> > and compare it.
> 
> So is the TCON of DE 2.0 identical to the original TCON?
> 
> If so, we should reuse sun4i-tcon ...
> 

Well, TCON is splitted in two parts (two base addresses), one for HDMI and one 
for TV. However, register offsets are same as before, so I guess driver 
reusage make sense. I think that there are few additional registers, but they 
can be ignored for simplefb.

> >  
> > 
> >> --
> >> Ken ar c'hentañ|  ** Breizh ha Linux atav! **
> >> Jef|http://moinejf.free.fr/
> > 
> > Best regards,
> > Jernej Škrabec
> > 
> > --
> > You received this message because you are subscribed to the Google Groups
> > "linux-sunxi" group. To unsubscribe from this group and stop receiving
> > emails from it, send an email to
> > linux-sunxi+unsubscr...@googlegroups.com. For more options, visit
> > https://groups.google.com/d/optout.

Best regards,
Jernej Škrabec

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

2016-11-30 Thread Jernej Skrabec

Hi Jean-François,

Dne sreda, 30. november 2016 10.35.08 UTC+1 je oseba Jean-François Moine 
napisala:
>
> On Tue, 29 Nov 2016 22:59:32 +0100 
> Maxime Ripard  wrote: 
>
> > > > I'm still not sure which pipeline should I use. 
> > > > 
> > > > And, it seems that HDMI Slow Clock is not needed? 
> > > > 
> > > > (seems that it's only for EDID, but simplefb won't use EDID) 
> > > 
> > > So, I don't see how this may work. 
> > > How can the u-boot know the resolutions of the HDMI display device? 
> > > 
> > > In other words: I have a new H3 board with the last u-boot and kernel. 
> > > I plug my (rather old or brand new) HDMI display device. 
> > > After powering on the system, I hope to get something on the screen. 
> > > How? 
> > 
> > If it works like the driver for the first display engine in U-Boot, it 
> > will use the preferred mode reported by the EDID, and will fallback to 
> > 1024x768 if it cannot access it. 
>
> Icenowy wrote: "simplefb won't use EDID" 
>
> Then, if it is like in the kernel, the 1024x768 mode is VGA. It does 
> not work with HDMI (different timings). 
>

U-Boot driver now accept any timings recommended by EDID. So far it
was tested with at least following resolutions:
- 1920x1080 @ 60 Hz
- 1280x1024 @ 60 Hz
- 1280x800 @ 60 Hz (slight clock difference)
- 800x480 (not sure about frame rate)
- 3840x2160 @ 30 Hz (4K)

and nobody complained so far. I'm pretty sure 1024x768 would work.


> > Maybe it would be worth exchanging on the EDID code that has been done 
> > for the u-boot driver too, so that it can be fixed in your driver. 
>
> The u-boot got my code, and, up to now, I could not fix the random or 
> permanent failures of EDID reading in some boards. 
>
>
I only have one OPi2, but as I said, EDID always worked for me. The only
code left from you is for DE2. HDMI stuff is basically copied from Rockhip
driver (including EDID reading), TCON code is now reverted to the same as
it is in sunxi_display.c. I think it is worth to take a look at EDID code 
and
compare it.
 

> -- 
> Ken ar c'hentañ|  ** Breizh ha Linux atav! ** 
> Jef|http://moinejf.free.fr/


Best regards,
Jernej Škrabec 

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support

2016-11-30 Thread Jernej Skrabec

Hi Laurent,

Dne sreda, 30. november 2016 09.08.22 UTC+1 je oseba Laurent Pinchart 
napisala:
>
> Hi Jernej, 
>
> On Tuesday 29 Nov 2016 15:24:25 Jernej Skrabec wrote: 
> > Dne torek, 29. november 2016 23.56.31 UTC+1 je oseba Laurent Pinchart 
> > napisala: 
> > > On Tuesday 29 Nov 2016 14:47:20 Jernej Skrabec wrote: 
> > >> Dne torek, 29. november 2016 22.37.03 UTC+1 je oseba Maxime Ripard 
> > > napisala: 
> > >>> On Tue, Nov 29, 2016 at 11:18:35AM +0100, Jean-Francois Moine wrote: 
> >  This patchset series adds HDMI video support to the Allwinner 
> >  sun8i SoCs which include the display engine 2 (DE2). 
> >  The driver contains the code for the A83T and H3 SoCs, and 
> >  some H3 boards, but it could be used/extended for other SoCs 
> >  (A64, H2, H5) and boards (Banana PIs, Orange PIs). 
> > >>> 
> > >>> Honestly, I'm getting a bit worried by the fact that you ignore 
> > >>> reviews. 
> > >>> 
> > >>> On the important reviews that you got that are to be seen as major 
> > >>> issues that block the inclusion, we have: 
> > >>>   - The fact that the HDMI driver is actually just a designware IP, 
> > >>> and while you should use the driver that already exists, you 
> just 
> > >>> duplicated all that code. 
> > >> 
> > >> That might be hard thing to do. A83T fits perfectly, but H3 and newer 
> > >> SoCs do not. They are using completely different HDMI phy. Decoupling 
> > >> controller and phy code means rewritting a good portion of the code, 
> > >> unless some tricks are applied, like calling phy function pointers, 
> if 
> > >> they are defined. 
> > > 
> > > Same HDMI TX but different HDMI TX PHY ? Kieran is working on 
> decoupling 
> > > the PHY configuration code for a Renesas SoC, that might be of 
> interest to 
> > > you. 
> > 
> > Exactly. I'm developing only U-Boot driver, but Jean-Francois will 
> probably 
> > have more interest in this. 
>
> We'll post patches as soon as they're ready. 
>

Great. Is datasheet public? I'm curious if HDMI PHY is by any chance 
similar.
 

>
> By the way, do you know if the H3 and newer SoCs use a different PHY from 
> Synopsys, or a custom PHY developed by Allwinner ? 
>
>
Unfortunatelly, noone managed to identify PHY and Alliwinner never released 
a
bit of information about HDMI. Does config2_id code 0xFE (PHY type) tell you
anything?
 

> > >> Register addresses also differ, but that can be easily solved by 
> using 
> > >> undocumented magic value to restore them. 
> > > 
> > > I love that :-) 
> > 
> > Is it allowed to use magic number which was found in binary blob? I'm 
> new in 
> > all this. 
>
> I don't really see a problem with that, we have many drivers in the kernel 
> that have been developed through reverse-engineering. You should not 
> include 
> large pieces of code that have been obtained through decompilation of a 
> proprietary binary blob as those could be protected by copyright, but 
> writing 
> to undocumented registers based on information found through usage of a 
> binary 
> driver isn't a problem. (Please remember that I'm not a lawyer though) 
>
> > >>>   - The fact that you ignored Rob (v6) and I (v5) comment on using 
> OF 
> > >>> graph to model the connection between the display engine and the 
> > >>> TCON. Something that Laurent also pointed out in this version. 
> > >>>   
> > >>>   - The fact that you ignored that you needed an HDMI connector node 
> > >>> as a child of the HDMI controller. This has been reported by Rob 
> > >>> (v6) and yet again in this version by Laurent. 
> > >>>   
> > >>>   - And finally the fact that we can't have several display engine 
> in 
> > >>> parallel, if needs be. This has happened in the past already on 
> > >>> Allwinner SoCs, so it's definitely something we should consider 
> in 
> > >>> the DT bindings, since we can't break them. 
> > >>> 
> > >>> Until those are fixed, I cannot see how this driver can be merged, 
> > >>> unfortunately. 
>

Best regards,
Jernej Škrabec

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

2016-11-30 Thread Icenowy Zheng



30.11.2016, 17:28, "Jean-Francois Moine" :
> On Wed, 30 Nov 2016 10:20:21 +0200
> Laurent Pinchart  wrote:
>
>>  > Well, I don't see what this connector can be.
>>  > May you give me a DT example?
>>
>>  Sure.
>>
>>  arch/arm/boot/dts/r8a7791-koelsch.dts
>>
>>  /* HDMI encoder */
>>
>>  hdmi@39 {
>>  compatible = "adi,adv7511w";
>>  reg = <0x39>;
>>  interrupt-parent = <>;
>>  interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
>>
>>  adi,input-depth = <8>;
>>  adi,input-colorspace = "rgb";
>>  adi,input-clock = "1x";
>>  adi,input-style = <1>;
>>  adi,input-justification = "evenly";
>>
>>  ports {
>>  #address-cells = <1>;
>>  #size-cells = <0>;
>>
>>  port@0 {
>>  reg = <0>;
>>  adv7511_in: endpoint {
>>  remote-endpoint = <_out_rgb>;
>>  };
>>  };
>>
>>  port@1 {
>>  reg = <1>;
>>  adv7511_out: endpoint {
>>  remote-endpoint = <_con>;
>>  };
>>  };
>>  };
>>  };
>>
>>  /* HDMI connector */
>>
>>  hdmi-out {
>>  compatible = "hdmi-connector";
>>  type = "a";
>>
>>  port {
>>  hdmi_con: endpoint {
>>  remote-endpoint = <_out>;
>>  };
>>  };
>>  };
>
> Hi Laurent,
>
> Sorry for I don't see the interest:
> - it is obvious that the HDMI connector is a 'hdmi-connector'!

Yes, it means the wire between the HDMI pins on the SoC and the connector ;-)

> - the physical connector type may be changed on any board by a soldering
>   iron or a connector to connector cable.

I can always alter the devices on a board ;-)

But I should also alter the dt after altering the board.

> - what does the software do with the connector type?
> - why not to put the connector information in the HDMI device?
>
> And, if I follow you, the graph of ports could also be used to describe
> the way the various parts of the SoCs are powered, to describe the pin
> connections, to describe the USB connectors, to describe the board
> internal hubs and bridges...
>
> --
> Ken ar c'hentañ | ** Breizh ha Linux atav! **
> Jef | http://moinejf.free.fr/
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: a13

2016-11-30 Thread сергей moobi

wireless Internet access keg8188etv can not seem to run. moreover I tried 
to connect the network card. the system sees it only if you enter the 
command ifconfig -a. when you attempt to do the command ifconfig eth1 up no 
space left on device. despite the fact that enough space.

среда, 30 ноября 2016 г., 12:06:16 UTC+3 пользователь сергей moobi написал:
>
> good afternoon. I can not run Linux on the A13 processor. or rather it 
> runs but does not run the external keyboard and WiFi. already I tried a 
> bunch of images but does not work
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 12/14] fdt: eth_fixup: Add hook for board to override MAC

2016-11-30 Thread Hans de Goede


Hi,

On 30-11-16 11:50, Olliver Schinagl wrote:

Hey maime,

Sorry for constantly getting your e-mail address wrong! Sorry!

On 30-11-16 10:12, maxime.rip...@free-electrons.com wrote:

On Wed, Nov 30, 2016 at 09:00:51AM +, Marcel Ziswiler wrote:

Hi Olliver

On Fri, 2016-11-25 at 16:30 +0100, Olliver Schinagl wrote:

This patch adds a method for the board to set the MAC address if the
environment is not yet set. The environment based MAC addresses are
not
touched, but if the fdt has an alias set, it is parsed and put into
the
environment.

E.g. The environment contains ethaddr and eth1addr, and the fdt
contains
an ethernet1 nothing happens. If the fdt contains ethernet2 however,
it
is parsed and inserted into the environment as eth2addr.

My humble understanding of device tree fixup is that it works the other
way around (e.g. it is the device tree that usually gets fixed up). So
the least I would advice for this patch is to change its naming but
most possibly such code also does not belong into the common
fdt_support implementation.

First, yes I noticed this as well, the nameing is the wrong way around. It took 
me a few reading times as well. I guess I did not full understand Hans's 
suggestion comment. So there's some work needed here.

I don't really have the context of this patch, but in the DT at least,
you can specify the mac address using the local-mac-address
property. I guess we should honor that too. But I don't really know
how that's related to an alias. If the device is probed and the
property is there, use it, otherwise don't.

This came from the sdio_realtek module on some sunxi boards, where the device 
tree has configured it obviously for linux, but u-boot has no notion of it. But 
u-boot IS responsible to generate (the same) MAC address for the device. So 
yes, u-boot inserts a mac address into the device-tree for a found alias.

E.g. ethernet2 is an alias without a MAC address configured for it. Thus u-boot 
is used to generate the MAC address for this node and inserts it into the dtb. 
What I haven't double checked (just blindly assumed, which is the mother) if 
this code also inserts the mac into the environment, but the kernel only gets 
this information via the dtb anyway, right? Either via the dtb, or via the MAC 
register bytes where it is stored in some drivers.


About the setting of the MAC in the environment for devices u-boot
knows nothing about, but which have an alias in the dt, this is
not necessary, it was done in the old code as a way to make the
u-boot fdt code pick up the MAC and inject it into the dtb
passed to the kernel. If this can now happen without setting
it in the env that step can be skipped.

Regards,

Hans

p.s.

I've NOT been following these (and related threads). If anyone
has any questions for me, please send me a direct mail which
does not have "PATCH" in the subject, otherwise I will likely
not seeing as I'm mostly ignoring these threads (sorry -ENOTIME).

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 12/14] fdt: eth_fixup: Add hook for board to override MAC

2016-11-30 Thread Olliver Schinagl


Hey maime,

Sorry for constantly getting your e-mail address wrong! Sorry!

On 30-11-16 10:12, maxime.rip...@free-electrons.com wrote:

On Wed, Nov 30, 2016 at 09:00:51AM +, Marcel Ziswiler wrote:

Hi Olliver

On Fri, 2016-11-25 at 16:30 +0100, Olliver Schinagl wrote:

This patch adds a method for the board to set the MAC address if the
environment is not yet set. The environment based MAC addresses are
not
touched, but if the fdt has an alias set, it is parsed and put into
the
environment.

E.g. The environment contains ethaddr and eth1addr, and the fdt
contains
an ethernet1 nothing happens. If the fdt contains ethernet2 however,
it
is parsed and inserted into the environment as eth2addr.

My humble understanding of device tree fixup is that it works the other
way around (e.g. it is the device tree that usually gets fixed up). So
the least I would advice for this patch is to change its naming but
most possibly such code also does not belong into the common
fdt_support implementation.
First, yes I noticed this as well, the nameing is the wrong way around. 
It took me a few reading times as well. I guess I did not full 
understand Hans's suggestion comment. So there's some work needed here.

I don't really have the context of this patch, but in the DT at least,
you can specify the mac address using the local-mac-address
property. I guess we should honor that too. But I don't really know
how that's related to an alias. If the device is probed and the
property is there, use it, otherwise don't.
This came from the sdio_realtek module on some sunxi boards, where the 
device tree has configured it obviously for linux, but u-boot has no 
notion of it. But u-boot IS responsible to generate (the same) MAC 
address for the device. So yes, u-boot inserts a mac address into the 
device-tree for a found alias.


E.g. ethernet2 is an alias without a MAC address configured for it. Thus 
u-boot is used to generate the MAC address for this node and inserts it 
into the dtb. What I haven't double checked (just blindly assumed, which 
is the mother) if this code also inserts the mac into the environment, 
but the kernel only gets this information via the dtb anyway, right? 
Either via the dtb, or via the MAC register bytes where it is stored in 
some drivers.


olliver


Maxime



--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

2016-11-30 Thread Jean-Francois Moine

On Wed, 30 Nov 2016 11:52:25 +0200
Laurent Pinchart  wrote:

> Hi Jean-François,
> 
> On Wednesday 30 Nov 2016 10:27:57 Jean-Francois Moine wrote:
> > On Wed, 30 Nov 2016 10:20:21 +0200 Laurent Pinchart wrote:
> > >> Well, I don't see what this connector can be.
> > >> May you give me a DT example?
> > > 
> > > Sure.
> > > 
> > > arch/arm/boot/dts/r8a7791-koelsch.dts
> > > 
> > > /* HDMI encoder */
[snip]
> > > /* HDMI connector */
> > > 
> > > hdmi-out {
> > > compatible = "hdmi-connector";
> > > type = "a";
> > > 
> > > port {
> > > hdmi_con: endpoint {
> > > remote-endpoint = <_out>;
> > > };
> > > };
> > > };
[snip]
> > - what does the software do with the connector type?
> 
> That's up to the software to decide, the DT bindings should describe the 
> hardware in the most accurate and usable way for the OS as possible. One of 
> my 
> longer term goals is to add connector drivers to handle DDC and HPD when 
> they're not handled by the encoder (they are in the above example).
> 
> If the DDC was connected to a general-purpose I2C bus of the SoC, and the HPD 
> to a GPIO, we would have
> 
>   hdmi-out {
>   compatible = "hdmi-connector";
>   type = "a";
>   /* I2C bus and GPIO references are made up for the example */
>   ddc-i2c-bus = <>;
>   hpd-gpios = < 7 GPIO_ACTIVE_HIGH>
> 
>   port {
>   hdmi_con: endpoint {
>   remote-endpoint = <_out>;
>   };
>   };
>   };
> 
> and both HPD and EDID reading should be handled by the connector driver.
[snip]

Hi Laurent,

OK. I understand. This connector complexity should be added in all DTs,
and the same code would be used.

Actually, for component binding, I use drm_of_component_probe():

- from the DRM master, loop on the "ports" phandle array and bind the
  CRTCs,

- for each CRTC, loop on the first remote port level and bind the
  encoders/connectors

Now, this should be:

- from the DRM master, loop on the first remote ports level and bind
  the CRTCs,

- for each CRTC, loop on the second remote port level and bind the
  encoders (and bridges?),

- for each encoder, loop on the third remote port level and bind the
  connectors.

Then, it would be nice to have a generic function for doing this job.

Otherwise, from your description:

>   hdmi-out {
>   compatible = "hdmi-connector";
>   type = "a";
>   /* I2C bus and GPIO references are made up for the example */
>   ddc-i2c-bus = <>;
>   hpd-gpios = < 7 GPIO_ACTIVE_HIGH>

the "hdmi-connector" is a big piece of software. It must handle a lot
of more and more exotic connectors.
So, I hope that you have written a "simple-hdmi-connector" which does
nothing but setting the connector type.
Where is it?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support

2016-11-30 Thread Laurent Pinchart

Hi Jean-François,

On Wednesday 30 Nov 2016 10:05:45 Jean-Francois Moine wrote:
> On Tue, 29 Nov 2016 22:36:50 +0100 Maxime Ripard wrote:
> > On Tue, Nov 29, 2016 at 11:18:35AM +0100, Jean-Francois Moine wrote:
> > > This patchset series adds HDMI video support to the Allwinner
> > > sun8i SoCs which include the display engine 2 (DE2).
> > > The driver contains the code for the A83T and H3 SoCs, and
> > > some H3 boards, but it could be used/extended for other SoCs
> > > (A64, H2, H5) and boards (Banana PIs, Orange PIs).
> > 
> > Honestly, I'm getting a bit worried by the fact that you ignore
> > reviews.
> > 
> > On the important reviews that you got that are to be seen as major
> > 
> > issues that block the inclusion, we have:
> >   - The fact that the HDMI driver is actually just a designware IP,
> > and while you should use the driver that already exists, you just
> > duplicated all that code.
> 
> The DW registers in the A83T and H3 are obfuscated, so, the code in
> bridge/DW cannot be used as it is. There should be either a translation
> table or a function to compute the register addresses.

Jernej mentioned there could be a way to restore the original Synopsys memory 
map. If that works then using the dw-hdmi could be an option.

> More, it is not sure that the bridge/DW code would work with Allwinner's
> SoCs.

If it doesn't work and can't be made to work in a non-invasive way they it 
should certainly not be used :-)

> It seems that they got some schematics from DesignWare, but, is it really
> the same hardware?

That's not really relevant, as long as the hardware is compatible, it doesn't 
matter if it's a Synopsys IP or a custom implementation of the HDMI TX with a 
compatible interface.

> Also, if some changes had to be done in the bridge code, I could not check
> if this would break or not the other SoCs.

Nothing new here, all drivers that support multiple SoCs have the same 
problem. That's why we have maintainers, testers and board farms to try and 
catch issues as early as possible.

> Eventually, I went the same way as omap/hdmi5: different driver.

I might try to fix that for OMAP5 at some point, we'll see.

> >   - The fact that you ignored Rob (v6) and I (v5) comment on using OF
> > graph to model the connection between the display engine and the
> > TCON. Something that Laurent also pointed out in this version.
> 
> I simply use the drm function drm_of_component_probe().
> If this one is in the DRM core, why should I not use it?
> If it must not be used, it would be nice to mark it as deprecated and
> to update the code of the drivers which are using it.

I haven't used that function so I can't comment here, except for the fact that 
DT bindings are not designed based on a given OS implementation. It should be 
the other way around, the bindings should be designed to clearly describe the 
hardware in a clean and consistent way that can be used by any host software, 
and the Linux helper functions should then be developed based on those 
bindings.

> >   - The fact that you ignored that you needed an HDMI connector node
> > as a child of the HDMI controller. This has been reported by Rob
> > (v6) and yet again in this version by Laurent.
> 
> As I don't know what is a DT 'connector', I cannot go further.
> I hope Laurent will give me clearer explanations and a real example.

Done, we can discuss this in that part of the mail thread.

> >   - And finally the fact that we can't have several display engine in
> > parallel, if needs be. This has happened in the past already on
> > Allwinner SoCs, so it's definitely something we should consider in
> > the DT bindings, since we can't break them.
> 
> IIRC, I proposed my driver before yours, and the DE2 is completely
> different from the other display engines.
> What you are telling is "add more code to already complex code and have
> a big driver for all SoCs in each kernels".
> I think it should be better to have small modules, each one treating
> specific hardware, and to let only the needed code in the kernel memory
> at startup time.
> 
> > Until those are fixed, I cannot see how this driver can be merged,
> > unfortunately.
> 
> No problem. I just wanted to help people by giving the job I did on the
> boards I have. My boards are working for almost one year, fine enough
> for I use them as daily desktop computers. I don't want to spend one
> more year for having my code in the Linux kernel: there are so much
> other exciting things to do...

And you're certainly welcome to contribute drivers to the kernel, that's 
always appreciated. Of course, to ensure a reasonable level of quality and 
consistency between drivers, the review process often requires changes to be 
made to the code being submitted. When it comes to drivers I mostly pay 
attention to DT bindings, userspace APIs and modification to common code. 
Driver code itself, as long as it's reasonably clean and doesn't impede 
development of

[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

2016-11-30 Thread Laurent Pinchart

Hi Jean-François,

On Wednesday 30 Nov 2016 10:27:57 Jean-Francois Moine wrote:
> On Wed, 30 Nov 2016 10:20:21 +0200 Laurent Pinchart wrote:
> >> Well, I don't see what this connector can be.
> >> May you give me a DT example?
> > 
> > Sure.
> > 
> > arch/arm/boot/dts/r8a7791-koelsch.dts
> > 
> > /* HDMI encoder */
> > 
> > hdmi@39 {
> > compatible = "adi,adv7511w";
> > reg = <0x39>;
> > interrupt-parent = <>;
> > interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
> > 
> > adi,input-depth = <8>;
> > adi,input-colorspace = "rgb";
> > adi,input-clock = "1x";
> > adi,input-style = <1>;
> > adi,input-justification = "evenly";
> > 
> > ports {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > 
> > port@0 {
> > reg = <0>;
> > adv7511_in: endpoint {
> > remote-endpoint = <_out_rgb>;
> > };
> > };
> > 
> > port@1 {
> > reg = <1>;
> > adv7511_out: endpoint {
> > remote-endpoint = <_con>;
> > };
> > };
> > };
> > 
> > };
> > 
> > /* HDMI connector */
> > 
> > hdmi-out {
> > compatible = "hdmi-connector";
> > type = "a";
> > 
> > port {
> > hdmi_con: endpoint {
> > remote-endpoint = <_out>;
> > };
> > };
> > };
> 
> Hi Laurent,
> 
> Sorry for I don't see the interest:
> - it is obvious that the HDMI connector is a 'hdmi-connector'!

It still has to be told to the drivers, they don't know how to identify a 
connector by looking at it :-)

> - the physical connector type may be changed on any board by a soldering
>   iron or a connector to connector cable.

Which is also true for any other component on the board. DT (and for that 
matter any firmware description of the platform) isn't soldering-proof.

> - what does the software do with the connector type?

That's up to the software to decide, the DT bindings should describe the 
hardware in the most accurate and usable way for the OS as possible. One of my 
longer term goals is to add connector drivers to handle DDC and HPD when 
they're not handled by the encoder (they are in the above example).

If the DDC was connected to a general-purpose I2C bus of the SoC, and the HPD 
to a GPIO, we would have

hdmi-out {
compatible = "hdmi-connector";
type = "a";
/* I2C bus and GPIO references are made up for the example */
ddc-i2c-bus = <>;
hpd-gpios = < 7 GPIO_ACTIVE_HIGH>

port {
hdmi_con: endpoint {
remote-endpoint = <_out>;
};
};
};

and both HPD and EDID reading should be handled by the connector driver.

> - why not to put the connector information in the HDMI device?

Because the connector is separate from the encoder. It's not uncommon 
(depending on the encoder type) to have the encoder output connected to a non-
connector entity such as another chained encoder.

For example most LVDS encoders are connected to a panel, but I have a board 
with the following encoders chain.

CRTC -- parallel RGB --> on-SoC LVDS encoder -- LVDS --> on-board LVDS decoder 
-- parallel RGB --> HDMI encoder -- HDMI --> HDMI connector

I can't support that if the LVDS encoder driver hardcodes the assumption that 
the encoder output is connected to a panel. This kind of usage might be less 
common for HDMI but is certainly not inconceivable.

> And, if I follow you, the graph of ports could also be used to describe
> the way the various parts of the SoCs are powered, to describe the pin
> connections, to describe the USB connectors, to describe the board
> internal hubs and bridges...

It should be used where applicable, it's not meant as the only possible 
hardware description for all pieces of the system.

-- 
Regards,

Laurent Pinchart

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

2016-11-30 Thread Jean-Francois Moine

On Tue, 29 Nov 2016 22:59:32 +0100
Maxime Ripard  wrote:

> > > I'm still not sure which pipeline should I use.
> > > 
> > > And, it seems that HDMI Slow Clock is not needed?
> > > 
> > > (seems that it's only for EDID, but simplefb won't use EDID)
> > 
> > So, I don't see how this may work.
> > How can the u-boot know the resolutions of the HDMI display device?
> > 
> > In other words: I have a new H3 board with the last u-boot and kernel.
> > I plug my (rather old or brand new) HDMI display device.
> > After powering on the system, I hope to get something on the screen.
> > How?
> 
> If it works like the driver for the first display engine in U-Boot, it
> will use the preferred mode reported by the EDID, and will fallback to
> 1024x768 if it cannot access it.

Icenowy wrote: "simplefb won't use EDID"

Then, if it is like in the kernel, the 1024x768 mode is VGA. It does
not work with HDMI (different timings).

> Maybe it would be worth exchanging on the EDID code that has been done
> for the u-boot driver too, so that it can be fixed in your driver.

The u-boot got my code, and, up to now, I could not fix the random or
permanent failures of EDID reading in some boards.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

2016-11-30 Thread Jean-Francois Moine

On Wed, 30 Nov 2016 10:20:21 +0200
Laurent Pinchart  wrote:

> > Well, I don't see what this connector can be.
> > May you give me a DT example?
> 
> Sure.
> 
> arch/arm/boot/dts/r8a7791-koelsch.dts
> 
> /* HDMI encoder */
> 
> hdmi@39 {
> compatible = "adi,adv7511w";
> reg = <0x39>;
> interrupt-parent = <>;
> interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
> 
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> adi,input-style = <1>;
> adi,input-justification = "evenly";
> 
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> 
> port@0 {
> reg = <0>;
> adv7511_in: endpoint {
> remote-endpoint = <_out_rgb>;
> };
> };
> 
> port@1 {
> reg = <1>;
> adv7511_out: endpoint {
> remote-endpoint = <_con>;
> };
> };
> };
> };
> 
> /* HDMI connector */
> 
> hdmi-out {
> compatible = "hdmi-connector";
> type = "a";
> 
> port {
> hdmi_con: endpoint {
> remote-endpoint = <_out>;
> };
> };
> };

Hi Laurent,

Sorry for I don't see the interest:
- it is obvious that the HDMI connector is a 'hdmi-connector'!
- the physical connector type may be changed on any board by a soldering
  iron or a connector to connector cable.
- what does the software do with the connector type?
- why not to put the connector information in the HDMI device?

And, if I follow you, the graph of ports could also be used to describe
the way the various parts of the SoCs are powered, to describe the pin
connections, to describe the USB connectors, to describe the board
internal hubs and bridges...

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 12/14] fdt: eth_fixup: Add hook for board to override MAC

2016-11-30 Thread maxime.rip...@free-electrons.com

On Wed, Nov 30, 2016 at 09:00:51AM +, Marcel Ziswiler wrote:
> Hi Olliver
> 
> On Fri, 2016-11-25 at 16:30 +0100, Olliver Schinagl wrote:
> > This patch adds a method for the board to set the MAC address if the
> > environment is not yet set. The environment based MAC addresses are
> > not
> > touched, but if the fdt has an alias set, it is parsed and put into
> > the
> > environment.
> > 
> > E.g. The environment contains ethaddr and eth1addr, and the fdt
> > contains
> > an ethernet1 nothing happens. If the fdt contains ethernet2 however,
> > it
> > is parsed and inserted into the environment as eth2addr.
> 
> My humble understanding of device tree fixup is that it works the other
> way around (e.g. it is the device tree that usually gets fixed up). So
> the least I would advice for this patch is to change its naming but
> most possibly such code also does not belong into the common
> fdt_support implementation.

I don't really have the context of this patch, but in the DT at least,
you can specify the mac address using the local-mac-address
property. I guess we should honor that too. But I don't really know
how that's related to an alias. If the device is probed and the
property is there, use it, otherwise don't.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] a13

2016-11-30 Thread сергей moobi

good afternoon. I can not run Linux on the A13 processor. or rather it runs 
but does not run the external keyboard and WiFi. already I tried a bunch of 
images but does not work

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] a13

2016-11-30 Thread сергей moobi

good afternoon. I can not run Linux on the A13 processor. or rather it runs 
but does not run the external keyboard and WiFi. already I tried a bunch of 
images but does not work

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support

2016-11-30 Thread Jean-Francois Moine

On Tue, 29 Nov 2016 22:36:50 +0100
Maxime Ripard  wrote:

> On Tue, Nov 29, 2016 at 11:18:35AM +0100, Jean-Francois Moine wrote:
> > This patchset series adds HDMI video support to the Allwinner
> > sun8i SoCs which include the display engine 2 (DE2).
> > The driver contains the code for the A83T and H3 SoCs, and
> > some H3 boards, but it could be used/extended for other SoCs
> > (A64, H2, H5) and boards (Banana PIs, Orange PIs).
> 
> Honestly, I'm getting a bit worried by the fact that you ignore
> reviews.
> 
> On the important reviews that you got that are to be seen as major
> issues that block the inclusion, we have:
>   - The fact that the HDMI driver is actually just a designware IP,
> and while you should use the driver that already exists, you just
> duplicated all that code.

The DW registers in the A83T and H3 are obfuscated, so, the code in
bridge/DW cannot be used as it is. There should be either a translation
table or a function to compute the register addresses.

More, it is not sure that the bridge/DW code would work with
Allwinner's SoCs. It seems that they got some schematics from
DesignWare, but, is it really the same hardware? Also, if some changes
had to be done in the bridge code, I could not check if this would
break or not the other SoCs.

Eventually, I went the same way as omap/hdmi5: different driver.

>   - The fact that you ignored Rob (v6) and I (v5) comment on using OF
> graph to model the connection between the display engine and the
> TCON. Something that Laurent also pointed out in this version.

I simply use the drm function drm_of_component_probe().
If this one is in the DRM core, why should I not use it?
If it must not be used, it would be nice to mark it as deprecated and
to update the code of the drivers which are using it.

>   - The fact that you ignored that you needed an HDMI connector node
> as a child of the HDMI controller. This has been reported by Rob
> (v6) and yet again in this version by Laurent.

As I don't know what is a DT 'connector', I cannot go further.
I hope Laurent will give me clearer explanations and a real example.

>   - And finally the fact that we can't have several display engine in
> parallel, if needs be. This has happened in the past already on
> Allwinner SoCs, so it's definitely something we should consider in
> the DT bindings, since we can't break them.

IIRC, I proposed my driver before yours, and the DE2 is completely
different from the other display engines.
What you are telling is "add more code to already complex code and have
a big driver for all SoCs in each kernels".
I think it should be better to have small modules, each one treating
specific hardware, and to let only the needed code in the kernel memory
at startup time.

> Until those are fixed, I cannot see how this driver can be merged,
> unfortunately.

No problem. I just wanted to help people by giving the job I did on the
boards I have. My boards are working for almost one year, fine enough
for I use them as daily desktop computers. I don't want to spend one
more year for having my code in the Linux kernel: there are so much
other exciting things to do...

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

2016-11-30 Thread Laurent Pinchart

Hi Jean-François,

On Wednesday 30 Nov 2016 09:12:08 Jean-Francois Moine wrote:
> On Tue, 29 Nov 2016 22:10:01 +0200 Laurent Pinchart wrote:
> > On Tuesday 29 Nov 2016 21:04:55 Jean-Francois Moine wrote:
> >> On Tue, 29 Nov 2016 21:33 +0200 Laurent Pinchart wrote:
> > You need a third port for the HDMI encoder output, connected to an
> > HDMI connector DT node.
>  
>  I don't see what you mean. The HDMI device is both the encoder
> >>> 
>  and connector (as the TDA998x):
> >>> The driver might create both an encoder and a connector, but I very
> >>> much doubt that the "allwinner,sun8i-a83t-hdmi" hardware contains a
> >>> connector, unless the SoC package has an HDMI connector coming out of
> >>> it :-)
> >>> 
>  plane -> DE2 mixer ---> TCON -> HDMI -> display device
>  - plane --- CRTC -   - encoder  \
> connector -- (HDMI cable)
>   audio-controller -   - audio-codec /
> >> 
> >> The schema is the same as the Dove Cubox: the TDA998x is just a chip
> >> with some wires going out and the physical connector is supposed to be
> >> at the end of the wires.
> > 
> > I've missed the Dove Cubox DT bindings when they were submitted.
> > Fortunately (or unfortunately for you, depending on how you look at it
> > ;-)) I've paid more attention this time.
> > 
> >> Here, the HDMI pins of the SoC go to a pure hardware chip and then to
> >> the physical connector. Which software entity do you want to add?
> > 
> > I don't want to add a software entity, I just want to model the connector
> > in DT as it's present in the system. Even though that's more common for
> > other bus types than HDMI (LVDS for instance) it wouldn't be
> > inconceivable to connect the HDMI signals to an on-board chim instead of
> > an HDMI connector, so the HDMI encoder output should be modelled by a
> > port and connected to a connector DT node in this case.
> 
> Well, I don't see what this connector can be.
> May you give me a DT example?

Sure.

arch/arm/boot/dts/r8a7791-koelsch.dts

/* HDMI encoder */

hdmi@39 {
compatible = "adi,adv7511w";
reg = <0x39>;
interrupt-parent = <>;
interrupts = <29 IRQ_TYPE_LEVEL_LOW>;

adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
adi,input-style = <1>;
adi,input-justification = "evenly";

ports {
#address-cells = <1>;
#size-cells = <0>;

port@0 {
reg = <0>;
adv7511_in: endpoint {
remote-endpoint = <_out_rgb>;
};
};

port@1 {
reg = <1>;
adv7511_out: endpoint {
remote-endpoint = <_con>;
};
};
};
};

/* HDMI connector */

hdmi-out {
compatible = "hdmi-connector";
type = "a";

port {
hdmi_con: endpoint {
remote-endpoint = <_out>;
};
};
};

-- 
Regards,

Laurent Pinchart

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [U-Boot] [PATCH 1/6] net: dw: Add read_rom_hwaddr net_op hook

2016-11-30 Thread Olliver Schinagl


Hey Simon,


On 29-11-16 22:41, Simon Glass wrote:

Hi Oliver,

On 28 November 2016 at 03:38, Olliver Schinagl  wrote:

On 27-11-16 18:02, Simon Glass wrote:

Hi,

On 25 November 2016 at 08:38, Olliver Schinagl  wrote:

Add the read_rom_hwaddr net_op hook so that it can be called from boards
to read the mac from a ROM chip.

Signed-off-by: Olliver Schinagl 
---
   drivers/net/designware.c | 16 
   1 file changed, 16 insertions(+)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 9e6d726..3f2f67c 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -230,6 +230,21 @@ static int _dw_write_hwaddr(struct dw_eth_dev *priv,
u8 *mac_id)
  return 0;
   }

+__weak int dw_board_read_rom_hwaddr(unsigned char *enetaddr, int id)
+{
+   return -ENOSYS;
+}
+
+static int designware_eth_read_rom_hwaddr(struct udevice *dev)
+{
+   struct eth_pdata *pdata = dev_get_platdata(dev);
+
+   if (!dev)
+   return -ENOSYS;
+
+   return dw_board_read_rom_hwaddr(pdata->enetaddr, dev->seq);
+}
+
   static void dw_adjust_link(struct eth_mac_regs *mac_p,
 struct phy_device *phydev)
   {
@@ -685,6 +700,7 @@ static const struct eth_ops designware_eth_ops = {
  .free_pkt   = designware_eth_free_pkt,
  .stop   = designware_eth_stop,
  .write_hwaddr   = designware_eth_write_hwaddr,
+   .read_rom_hwaddr= designware_eth_read_rom_hwaddr,
   };

   static int designware_eth_ofdata_to_platdata(struct udevice *dev)

You should not call board code from a driver. But since this is a
sunxi driver, why not move all the code that reads the serial number
into this file?

Hey Simon,

unless I missunderstand, this is how Joe suggested in a while ago, and how
it has been implemented in a few other drivers. Can you elaborate a bit
more?

Yes...drivers must not call into board-specific code, nor have
board-specific #defines. This limits their usefulness for other
boards.
Hmm, well as I said, I just followed Joe's suggestion with his example. 
also isn't this exactly how the zynq does it as well?


Adding hooks like this (particularly with the word 'board' in the
name) should be avoided.

We end up with bidirectional coupling between the board and the
driver. The board should use the driver but not the other way around.
I understand that you are trying to get around this by using a weak
function, but with driver model I'm really trying hard to avoid weak
functions. They normally indicate an ad-hoc API and can generally be
avoided with a bit more design thought.

If you have a standard way of reading the serial number which is
supported by all sunxi boards, then you should be able to add your
changes to the sunxi Ethernet driver (which uses designware.c?). Then
you can leave the designware.c code alone and avoid adding a hook.
Well yes and no. We use designware, but also sunxi_emac, and some 
sdio_realtek that does not have a driver yet. But in essence, this is 
somewhat what I do in this patch I guess. I have the weak driver 
specific function in the sunxi code.


But I think I'm starting to understand your solution and will read up on 
the rockchip patches and rewrite this bit.


In a sense you end up subclassing the designware driver.

Also see this series which deals with a similar problem with rockchip:

http://lists.denx.de/pipermail/u-boot/2016-November/274256.html

Regards,
Simon


--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

2016-11-30 Thread Jean-Francois Moine

On Tue, 29 Nov 2016 22:10:01 +0200
Laurent Pinchart  wrote:

> Hi Jean-François,
> 
> On Tuesday 29 Nov 2016 21:04:55 Jean-Francois Moine wrote:
> > On Tue, 29 Nov 2016 21:33 +0200 Laurent Pinchart wrote:
> > >>> You need a third port for the HDMI encoder output, connected to an
> > >>> HDMI connector DT node.
> > >> 
> > >> I don't see what you mean. The HDMI device is both the encoder
> > >> and connector (as the TDA998x):
> > >
> > > The driver might create both an encoder and a connector, but I very much
> > > doubt that the "allwinner,sun8i-a83t-hdmi" hardware contains a connector,
> > > unless the SoC package has an HDMI connector coming out of it :-)
> > > 
> > >> plane -> DE2 mixer ---> TCON -> HDMI -> display device
> > >> - plane --- CRTC -   - encoder  \
> > >>connector -- (HDMI cable)
> > >>  audio-controller -   - audio-codec /
> > 
> > The schema is the same as the Dove Cubox: the TDA998x is just a chip
> > with some wires going out and the physical connector is supposed to be
> > at the end of the wires.
> 
> I've missed the Dove Cubox DT bindings when they were submitted. Fortunately 
> (or unfortunately for you, depending on how you look at it ;-)) I've paid 
> more 
> attention this time.
> 
> > Here, the HDMI pins of the SoC go to a pure hardware chip and then to
> > the physical connector. Which software entity do you want to add?
> 
> I don't want to add a software entity, I just want to model the connector in 
> DT as it's present in the system. Even though that's more common for other 
> bus 
> types than HDMI (LVDS for instance) it wouldn't be inconceivable to connect 
> the HDMI signals to an on-board chim instead of an HDMI connector, so the 
> HDMI 
> encoder output should be modelled by a port and connected to a connector DT 
> node in this case.

Well, I don't see what this connector can be.
May you give me a DT example?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 09/14] net: Add ability to set MAC address via EEPROM

2016-11-30 Thread Olliver Schinagl


Hey Michal,


On 29-11-16 19:54, Michal Simek wrote:

On 29.11.2016 17:45, Olliver Schinagl wrote:

Hey Michal,


On 28-11-16 09:21, Michal Simek wrote:

On 25.11.2016 16:30, Olliver Schinagl wrote:

This patch allows Kconfig to enable and set parameters to make it
possible to read the MAC address from an EEPROM. The net core layer then
uses this information to read MAC addresses from this EEPROM.

Besides the various tuneables as to how to access the eeprom (bus,
address, addressing mode/length, 2 configurable that are EEPROM generic
(e.g. SPI or some other form of access) which are:

NET_ETHADDR_EEPROM_OFFSET, indicating where in the EEPROM the start of
the MAC address is. The default is 8 allowing for 8 bytes before the MAC
for other purposes (header MAGIC for example).

NET_ETHADDR_EEPROM_CRC8, indicating the MAC is appended with a CRC8-CCIT
checksum that should be verified.

Currently only I2C eeproms have been tested and thus only those options
are available, but shouldn't be a limit. NET_ETHADDR_EEPROM_SPI can be
just as created and added.

The code currently first checks if there is a non-zero MAC address in
the eeprom. If that fails to be the case, the read_rom_hwaddr can be
used by a board to supply the MAC in other ways.

If both these fails, the other code is still in place to query the
environent, which then can be used to override the hardware supplied
data.

Signed-off-by: Olliver Schinagl 
---
   doc/README.enetaddr | 99
+
   include/net.h   | 14 
   net/Kconfig | 59 +++
   net/eth-uclass.c|  9 +++--
   net/eth_common.c| 34 ++
   net/eth_legacy.c|  2 ++
   6 files changed, 214 insertions(+), 3 deletions(-)

diff --git a/doc/README.enetaddr b/doc/README.enetaddr
index 50e4899..89c1f7d 100644
--- a/doc/README.enetaddr
+++ b/doc/README.enetaddr
@@ -47,6 +47,105 @@ Correct flow of setting up the MAC address
(summarized):
   Previous behavior had the MAC address always being programmed into
hardware
   in the device's init() function.
   +
+ EEPROM
+
+
+Boards may come with an EEPROM specifically to store configuration
bits, such
+as a MAC address. Using CONFIG_NET_ETHADDR_EEPROM enables this feature.
+Depending on the board, the EEPROM may be connected on various
methods, but
+currently, only the I2C bus can be used via
CONFIG_NET_ETHADDR_EEPROM_I2C.
+
+The following config options are available,
+CONFIG_NET_ETHADDR_EEPROM_I2C_BUS is the I2C bus on which the eeprom
is present.
+CONFIG_NET_ETHADDR_EEPROM_I2C_ADDR sets the address of the EEPROM,
which
+defaults to the very common 0x50. Small size EEPROM's generally use
single byte
+addressing but larger EEPROM's may use double byte addressing, which
can be
+configured using CONFIG_NET_ETHADDR_EEPROM_ADDRLEN.
+
+Within the EEPROM, the MAC address can be stored on any arbitrary
offset,
+CONFIG_NET_ETHADDR_EEPROM_OFFSET sets this to 8 as a default
however, allowing
+the first 8 bytes to be used for an optional data, for example a
configuration
+struct where the mac address is part of.
+
+Appending the 6 (ARP_HLEN) bytes is a CRC8 byte over the previous
ARP_HLEN
+bytes. Whether to check this CRC8 or not is dependent on
+CONFIG_NET_ETHADDR_EEPROM_CRC8.
+
+To keep things nicely aligned, a final 'reserved' byte is added to
the mac
+address + crc8 combo.
+
+A board may want to store more information in its eeprom, using the
following
+example layout, this can be achieved.
+
+struct mac_addr {
+uint8_t mac[ARP_HLEN];
+uint8_t crc8;
+uint8_t reserved;
+};
+
+struct config_eeprom {
+uint32_t magic;
+uint8_t version;
+uint8_t reserved[2];
+uint8_t mac_cnt;
+struct mac_addr[mac_cnt];
+};
+
+Filling this in:
+struct config_eeprom eeprom = {
+.magic = { 'M', 'g', 'i', 'c' },
+.reserved = { 0x00, 0x00 },
+.mac_cnt = 2,
+.mac_addr = {
+{
+.mac = {
+0x01, 0x23, 0x45,
+0x67, 0x89, 0xab,
+},
+.crc8 = 0xbe,
+.reserved = 0x00,
+}, {
+.mac = {
+0xba, 0x98, 0x76,
+0x54, 0x32, 0x10,
+},
+.crc8 = 0x82,
+.reserved = 0x00,
+},
+},
+};
+
+The eeprom content would look like this.
+
+  4d 67 69 63 01 00 00 02  01 23 45 67 89 ab be 00
|Mgic.#Eg|
+0010  ba 98 76 54 32 10 82 00  |..vT2...|
+
+This can be done from linux using the i2c-tools:
+
+i2cset I2CBUS 0x50 0x08 0x01
+i2cset I2CBUS 0x50 0x09 0x23
+i2cset I2CBUS 0x50 0x0a 0x45
+i2cset I2CBUS 0x50 0x0b 0x67
+i2cset I2CBUS 0x50 0x0c 0x89
+i2cset I2CBUS 0x50 0x0d 0xab
+i2cset I2CBUS 0x50 0x0e 0xbe
+
+Alternativly this can be done from the u-boot console as:
+
+u-boot> mm.b 0
+: 00 ? 01
+0001: 23 ? 23
+0002: 45 ? 45
+0003: 67 ? 67
+0004: 89 ? 89
+0005: ab ? ab

[linux-sunxi] Re: [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support

2016-11-30 Thread Laurent Pinchart

Hi Jernej,

On Tuesday 29 Nov 2016 15:24:25 Jernej Skrabec wrote:
> Dne torek, 29. november 2016 23.56.31 UTC+1 je oseba Laurent Pinchart
> napisala:
> > On Tuesday 29 Nov 2016 14:47:20 Jernej Skrabec wrote:
> >> Dne torek, 29. november 2016 22.37.03 UTC+1 je oseba Maxime Ripard
> > napisala:
> >>> On Tue, Nov 29, 2016 at 11:18:35AM +0100, Jean-Francois Moine wrote:
>  This patchset series adds HDMI video support to the Allwinner
>  sun8i SoCs which include the display engine 2 (DE2).
>  The driver contains the code for the A83T and H3 SoCs, and
>  some H3 boards, but it could be used/extended for other SoCs
>  (A64, H2, H5) and boards (Banana PIs, Orange PIs).
> >>> 
> >>> Honestly, I'm getting a bit worried by the fact that you ignore
> >>> reviews.
> >>> 
> >>> On the important reviews that you got that are to be seen as major
> >>> issues that block the inclusion, we have:
> >>>   - The fact that the HDMI driver is actually just a designware IP,
> >>> and while you should use the driver that already exists, you just
> >>> duplicated all that code.
> >> 
> >> That might be hard thing to do. A83T fits perfectly, but H3 and newer
> >> SoCs do not. They are using completely different HDMI phy. Decoupling
> >> controller and phy code means rewritting a good portion of the code,
> >> unless some tricks are applied, like calling phy function pointers, if
> >> they are defined.
> > 
> > Same HDMI TX but different HDMI TX PHY ? Kieran is working on decoupling
> > the PHY configuration code for a Renesas SoC, that might be of interest to
> > you.
> 
> Exactly. I'm developing only U-Boot driver, but Jean-Francois will probably
> have more interest in this.

We'll post patches as soon as they're ready.

By the way, do you know if the H3 and newer SoCs use a different PHY from 
Synopsys, or a custom PHY developed by Allwinner ?

> >> Register addresses also differ, but that can be easily solved by using
> >> undocumented magic value to restore them.
> > 
> > I love that :-)
> 
> Is it allowed to use magic number which was found in binary blob? I'm new in
> all this.

I don't really see a problem with that, we have many drivers in the kernel 
that have been developed through reverse-engineering. You should not include 
large pieces of code that have been obtained through decompilation of a 
proprietary binary blob as those could be protected by copyright, but writing 
to undocumented registers based on information found through usage of a binary 
driver isn't a problem. (Please remember that I'm not a lawyer though)

> >>>   - The fact that you ignored Rob (v6) and I (v5) comment on using OF
> >>> graph to model the connection between the display engine and the
> >>> TCON. Something that Laurent also pointed out in this version.
> >>>   
> >>>   - The fact that you ignored that you needed an HDMI connector node
> >>> as a child of the HDMI controller. This has been reported by Rob
> >>> (v6) and yet again in this version by Laurent.
> >>>   
> >>>   - And finally the fact that we can't have several display engine in
> >>> parallel, if needs be. This has happened in the past already on
> >>> Allwinner SoCs, so it's definitely something we should consider in
> >>> the DT bindings, since we can't break them.
> >>> 
> >>> Until those are fixed, I cannot see how this driver can be merged,
> >>> unfortunately.

-- 
Regards,

Laurent Pinchart

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 12/14] fdt: eth_fixup: Add hook for board to override MAC

Re: [linux-sunxi] a13

Re: [linux-sunxi] a13

Re: [linux-sunxi] a13

Re: [linux-sunxi] a13

Re: [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

Re: [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

Re: [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

Re: [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

[linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

[linux-sunxi] Re: [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support

Re: [linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

[linux-sunxi] Re: a13

[linux-sunxi] Re: [PATCH 12/14] fdt: eth_fixup: Add hook for board to override MAC

[linux-sunxi] Re: [PATCH 12/14] fdt: eth_fixup: Add hook for board to override MAC

[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

[linux-sunxi] Re: [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support

[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

[linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

[linux-sunxi] Re: [PATCH 12/14] fdt: eth_fixup: Add hook for board to override MAC

[linux-sunxi] a13

[linux-sunxi] a13

[linux-sunxi] Re: [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support

[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

[linux-sunxi] Re: [U-Boot] [PATCH 1/6] net: dw: Add read_rom_hwaddr net_op hook

[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

[linux-sunxi] Re: [PATCH 09/14] net: Add ability to set MAC address via EEPROM

[linux-sunxi] Re: [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support

29 matches

Site Navigation

Mail list logo

Footer information