Patchwork devicetree support for efikasb

login
register
mail settings
Submitter Sascha Hauer
Date Dec. 17, 2012, 7:59 a.m.
Message ID <20121217075907.GQ24458@pengutronix.de>
Download mbox
Permalink /patch/206793/
State New
Headers show

Pull-request

git://git.pengutronix.de/git/imx/linux-2.6.git work/efikasb

Comments

Sascha Hauer - Dec. 17, 2012, 7:59 a.m.
Hi all,

I recently put some work into my Efika MX smartbook. Here are patches
to make it work with a current kernel. It turned out that most of the
stuff is quite straight forward. Unfortunately there is a lot missing
in the USB area. Without USB support the Smartbook is pretty much
useless, so most of the patches are for adding USB support.

What currently works is:

- USB
- Display
- Battery
- keyboard/touchpad
- Sound (used to work, currently broken)
- Wifi
- LEDs

I'm not posting the patches here since I do not consider them ready, but
for everyone interested you can pull the following git tree. I have no
idea if the patches work together with the preinstalled U-Boot, I use
barebox on the Smartbook.

Since it's a spare time project I have no schedule when to continue. If
you want to push this forward, please let me know, I may have soemthing
newer then.

Sascha


The following changes since commit 11520e5e7c1855fc3bf202bb3be35a39d9efa034:

  Revert "x86-64/efi: Use EFI to deal with platform wall clock (again)" (2012-12-15 15:20:41 -0800)

are available in the git repository at:

  git://git.pengutronix.de/git/imx/linux-2.6.git work/efikasb

for you to fetch changes up to 4de30514cbd7126ba06062e39ba4701f2bca1a37:

  ARM i.MX: Adjust imx_v6_v7_defconfig for efikasb (2012-12-16 19:10:06 +0100)

----------------------------------------------------------------
Marc Kleine-Budde (5):
      usb: chipidea: usbmisc: unset global varibale usbmisc on driver remove
      usb: chipidea: usbmisc: fix a potential race condition
      usb: chipidea: usbmisc: prepare driver to handle more than one soc
      usb: chipidea: usbmisc: add support for ahb, ipg and per clock
      usb: chipidea: ci13xxx-imx: add "dr_mode" property to device tree bindings

Michael Grzeschik (8):
      ARM: dts: imx: rename imx5x usb entries as in imx6q.dtsi
      ARM: dts: imx: add imx5x phy-mode entries
      usb: chipidea: usbmisc: rename file, struct and functions to usbmisc_imx
      usb: chipidea: usbmisc: add mx53 support
      usb: chipidea: usbmisc: add post handling and errata fix for mx25
      usb: chipidea: ci13xxx_imx: add 2nd and 3rd clock to support imx5x and newer
      usb: add phy connection by phy-mode
      usb: chipidea: ci13xxx-imx: create dynamic platformdata

Peter Chen (5):
      Revert "USB: chipidea: add vbus detect for udc"
      usb: chipidea: add otg file
      usb: chipidea: add otg id switch and vbus connect/disconnect detect
      usb: chipidea: create the gadget at ci_hdrc_probe even at host role
      usb: chipidea: imx: add internal vbus regulator control

Sascha Hauer (11):
      usb chipidea: Add ULPI support
      Arm i.MX5 clk: Add PATA and SRTC clocks
      ARM i.MX51: Add PATA support
      ata i.MX pata: Set bus timing
      RTC i.MX dryice: Add devicetree support
      ARM i.MX5 dts: Add SRTC device
      ARM i.MX51 dts: Add clocks to USB devices
      DRM i.MX: Add efika LVDS support
      ARM i.MX: Add Efika Smartbook devicetree
      ARM efikasb: HACK: enable backlight
      ARM i.MX: Adjust imx_v6_v7_defconfig for efikasb

 .../devicetree/bindings/clock/imx5-clock.txt       |    2 +
 .../devicetree/bindings/usb/ci13xxx-imx.txt        |    6 +
 arch/arm/boot/dts/Makefile                         |    1 +
 arch/arm/boot/dts/imx28.dtsi                       |    2 +
 arch/arm/boot/dts/imx51-genesi-efika-sb.dts        |  312 +++++++++++++
 arch/arm/boot/dts/imx51.dtsi                       |   70 ++-
 arch/arm/boot/dts/imx53.dtsi                       |   18 +-
 arch/arm/configs/imx_v6_v7_defconfig               |   49 +-
 arch/arm/mach-imx/clk-imx51-imx53.c                |    4 +-
 arch/arm/mach-imx/imx51-dt.c                       |   36 ++
 drivers/ata/pata_imx.c                             |   70 +++
 drivers/of/Kconfig                                 |   12 +
 drivers/of/Makefile                                |    1 +
 drivers/of/of_usbphy.c                             |   49 ++
 drivers/rtc/Kconfig                                |    2 +-
 drivers/rtc/rtc-imxdi.c                            |   11 +
 drivers/staging/imx-drm/Kconfig                    |    4 +
 drivers/staging/imx-drm/Makefile                   |    1 +
 drivers/staging/imx-drm/mtl017.c                   |  469 ++++++++++++++++++++
 drivers/usb/chipidea/Kconfig                       |    1 +
 drivers/usb/chipidea/Makefile                      |    4 +-
 drivers/usb/chipidea/bits.h                        |   13 +
 drivers/usb/chipidea/ci.h                          |   19 +-
 drivers/usb/chipidea/ci13xxx_imx.c                 |  158 +++++--
 drivers/usb/chipidea/ci13xxx_imx.h                 |    3 +
 drivers/usb/chipidea/core.c                        |  290 ++++++++++--
 drivers/usb/chipidea/host.c                        |   16 +
 drivers/usb/chipidea/otg.c                         |   61 +++
 drivers/usb/chipidea/otg.h                         |    6 +
 drivers/usb/chipidea/udc.c                         |   41 +-
 drivers/usb/chipidea/usbmisc_imx.c                 |  256 +++++++++++
 drivers/usb/chipidea/usbmisc_imx6q.c               |  162 -------
 include/linux/of_usbphy.h                          |   15 +
 include/linux/usb/chipidea.h                       |   16 +
 include/linux/usb/phy.h                            |    8 +
 35 files changed, 1894 insertions(+), 294 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx51-genesi-efika-sb.dts
 create mode 100644 drivers/of/of_usbphy.c
 create mode 100644 drivers/staging/imx-drm/mtl017.c
 create mode 100644 drivers/usb/chipidea/otg.c
 create mode 100644 drivers/usb/chipidea/otg.h
 create mode 100644 drivers/usb/chipidea/usbmisc_imx.c
 delete mode 100644 drivers/usb/chipidea/usbmisc_imx6q.c
 create mode 100644 include/linux/of_usbphy.h
Peter Korsgaard - Dec. 17, 2012, 8:21 a.m.
>>>>> "Sascha" == Sascha Hauer <s.hauer@pengutronix.de> writes:

Hi,

 Sascha> I'm not posting the patches here since I do not consider them
 Sascha> ready, but for everyone interested you can pull the following
 Sascha> git tree.

Thanks, I'll give it a try.

 Sascha> Since it's a spare time project I have no schedule when to
 Sascha> continue. If you want to push this forward, please let me know,
 Sascha> I may have soemthing newer then.

I for one would certainly be interested in this getting mainlined.
Arnaud Patard (Rtp) - Dec. 17, 2012, 11:27 a.m.
Sascha Hauer <s.hauer@pengutronix.de> writes:

> Hi all,

Hi,

>
> I recently put some work into my Efika MX smartbook. Here are patches
> to make it work with a current kernel. It turned out that most of the
> stuff is quite straight forward. Unfortunately there is a lot missing
> in the USB area. Without USB support the Smartbook is pretty much
> useless, so most of the patches are for adding USB support.
>
> What currently works is:
>
> - USB

Is it working or not ? Or you meant that it's working only if you merge
the usbmisc-related for imx5* patches ?

> - Display

Given that you wrote something for the mlt017, do you happen to have a
sii9022 driver too ? :)

> - Battery

I've not noticed something for the ac power supply in the dts. Did I miss something?

> - keyboard/touchpad

Did you try using the white led for 'caps lock' ?

> - Sound (used to work, currently broken)
> - Wifi

How did you enable it ? Did you configure the gpios to always enable it ?

> - LEDs

You're not mentionning pata. Is it working or not ?

>
> I'm not posting the patches here since I do not consider them ready, but
> for everyone interested you can pull the following git tree. I have no
> idea if the patches work together with the preinstalled U-Boot, I use
> barebox on the Smartbook.

I've (very quickly) tested it yesterday and it didn't even boot. I've
yet to look at the serial port output to check if it's a problem on my
side or a bug in the kernel.

>
> Since it's a spare time project I have no schedule when to continue. If
> you want to push this forward, please let me know, I may have soemthing
> newer then.

I'm still interested in getting mainline working on efika devices.

Arnaud
Sascha Hauer - Dec. 17, 2012, 11:50 a.m.
On Mon, Dec 17, 2012 at 12:27:56PM +0100, Arnaud Patard wrote:
> Sascha Hauer <s.hauer@pengutronix.de> writes:
> 
> > Hi all,
> 
> Hi,
> 
> >
> > I recently put some work into my Efika MX smartbook. Here are patches
> > to make it work with a current kernel. It turned out that most of the
> > stuff is quite straight forward. Unfortunately there is a lot missing
> > in the USB area. Without USB support the Smartbook is pretty much
> > useless, so most of the patches are for adding USB support.
> >
> > What currently works is:
> >
> > - USB
> 
> Is it working or not ? Or you meant that it's working only if you merge
> the usbmisc-related for imx5* patches ?

It's working with the patches in the git branch. It requires usbmisc
patches and also ULPI support for the chipidea driver. I only bashed
the chipidea driver until it worked. The last time I looked at the
chipidea driver patches on the mailing list they were so much in flux
that it didn't make sense to me to post even more patches. I hope
this settles soon.

> 
> > - Display
> 
> Given that you wrote something for the mlt017, do you happen to have a
> sii9022 driver too ? :)

Only a very old one which won't work with the current code.

> 
> > - Battery
> 
> I've not noticed something for the ac power supply in the dts. Did I miss something?

I only added the following for the battery which is enough to detect it:

	battery: battery@0b {
		compatible = "sbs,sbs-battery";
		reg = <0x0b>;
		sbs,battery-detect-gpios = <&gpio3 6 1>;
	};

I haven't done anything with the ac power supply yet. I suppose it's
detectable via a gpio, right?

> 
> > - keyboard/touchpad
> 
> Did you try using the white led for 'caps lock' ?

No, I only registered it as LED, I haven't tried to wire it up the caps
lock functionality. For me capslock is the most useless feature on a
keyboard, I usually reconfigure this to a addition modifier key anyway
;)

> 
> > - Sound (used to work, currently broken)
> > - Wifi
> 
> How did you enable it ? Did you configure the gpios to always enable it ?

I configured the corresponding gpio as input, so it seems to get
overwritten by the wifi switch. I don't know the schematics, but I'm
able to turn Wifi off and on with the switch.


> 
> > - LEDs
> 
> You're not mentionning pata. Is it working or not ?

Ah, missed that. PATA is working aswell. Only PIO though.

> 
> >
> > I'm not posting the patches here since I do not consider them ready, but
> > for everyone interested you can pull the following git tree. I have no
> > idea if the patches work together with the preinstalled U-Boot, I use
> > barebox on the Smartbook.
> 
> I've (very quickly) tested it yesterday and it didn't even boot. I've
> yet to look at the serial port output to check if it's a problem on my
> side or a bug in the kernel.

Do you mean barebox doesn't boot or the kernel doesn't boot?

Sascha
Arnaud Patard (Rtp) - Dec. 17, 2012, 12:04 p.m.
Sascha Hauer <s.hauer@pengutronix.de> writes:

> On Mon, Dec 17, 2012 at 12:27:56PM +0100, Arnaud Patard wrote:
>> Sascha Hauer <s.hauer@pengutronix.de> writes:
>> 
>> > Hi all,
>> 
>> Hi,
>> 
>> >
>> > I recently put some work into my Efika MX smartbook. Here are patches
>> > to make it work with a current kernel. It turned out that most of the
>> > stuff is quite straight forward. Unfortunately there is a lot missing
>> > in the USB area. Without USB support the Smartbook is pretty much
>> > useless, so most of the patches are for adding USB support.
>> >
>> > What currently works is:
>> >
>> > - USB
>> 
>> Is it working or not ? Or you meant that it's working only if you merge
>> the usbmisc-related for imx5* patches ?
>
> It's working with the patches in the git branch. It requires usbmisc
> patches and also ULPI support for the chipidea driver. I only bashed
> the chipidea driver until it worked. The last time I looked at the
> chipidea driver patches on the mailing list they were so much in flux
> that it didn't make sense to me to post even more patches. I hope
> this settles soon.
>
>> 
>> > - Display
>> 
>> Given that you wrote something for the mlt017, do you happen to have a
>> sii9022 driver too ? :)
>
> Only a very old one which won't work with the current code.
>

ok. so it's near to no driver for current kernels.

>> 
>> > - Battery
>> 
>> I've not noticed something for the ac power supply in the dts. Did I miss something?
>
> I only added the following for the battery which is enough to detect it:
>
> 	battery: battery@0b {
> 		compatible = "sbs,sbs-battery";
> 		reg = <0x0b>;
> 		sbs,battery-detect-gpios = <&gpio3 6 1>;
> 	};
>
> I haven't done anything with the ac power supply yet. I suppose it's
> detectable via a gpio, right?

it's gpio 3 3. Was wondering if it was not in the dts due to missing
information or due to not working.

>
>> 
>> > - keyboard/touchpad
>> 
>> Did you try using the white led for 'caps lock' ?
>
> No, I only registered it as LED, I haven't tried to wire it up the caps
> lock functionality. For me capslock is the most useless feature on a
> keyboard, I usually reconfigure this to a addition modifier key anyway
> ;)
>
>> 
>> > - Sound (used to work, currently broken)
>> > - Wifi
>> 
>> How did you enable it ? Did you configure the gpios to always enable it ?
>
> I configured the corresponding gpio as input, so it seems to get
> overwritten by the wifi switch. I don't know the schematics, but I'm
> able to turn Wifi off and on with the switch.

afaik, the wifi switch is killing bluetooth and wifi (and overrides the
gpios). With the gpios, you can get either bluetooth or wifi enabled
See http://git.rtp-net.org/?p=efika.git;a=blob;f=rfkill.patch for
instance.


>
>
>> 
>> > - LEDs
>> 
>> You're not mentionning pata. Is it working or not ?
>
> Ah, missed that. PATA is working aswell. Only PIO though.

it was pio before so that's fine. I had some stuff to try to get pata on
DT before but I got stuck at the 'usb not working' stage. So, it's nice
to see that there's already a known-to-be-working one.

>
>> 
>> >
>> > I'm not posting the patches here since I do not consider them ready, but
>> > for everyone interested you can pull the following git tree. I have no
>> > idea if the patches work together with the preinstalled U-Boot, I use
>> > barebox on the Smartbook.
>> 
>> I've (very quickly) tested it yesterday and it didn't even boot. I've
>> yet to look at the serial port output to check if it's a problem on my
>> side or a bug in the kernel.
>
> Do you mean barebox doesn't boot or the kernel doesn't boot?

No idea. All I get is a black screen, so I need to look at the serial
output. Oh, it's uboot not barebox btw. Sorry for the confusion.

Arnaud
Peter Korsgaard - Dec. 17, 2012, 12:37 p.m.
>>>>> "Arnaud" == Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org> writes:

Hi,

 >> - keyboard/touchpad

 Arnaud> Did you try using the white led for 'caps lock' ?

Related to that, what happened to the capsl/numl led triggers? I posted
a patch for it back in 2010, and I think you did as well some time
later, and at one time something was pending in MM - But I don't seem to
find anything in mainline?

http://peter.korsgaard.com/patches/linux/leds-add-led-trigger-for-input-subsystem-led-events.patch
Arnaud Patard (Rtp) - Dec. 17, 2012, 2:07 p.m.
Peter Korsgaard <jacmet@sunsite.dk> writes:

>>>>>> "Arnaud" == Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org> writes:
>
> Hi,
>
>  >> - keyboard/touchpad
>
>  Arnaud> Did you try using the white led for 'caps lock' ?
>
> Related to that, what happened to the capsl/numl led triggers? I posted
> a patch for it back in 2010, and I think you did as well some time
> later, and at one time something was pending in MM - But I don't seem to
> find anything in mainline?

When I sent my version, I got some feedback from Samuel that it would be
better to try and use the patches he sent but it didn't work on my
smartbook. iirc, after debugging, what I found was seen by Samuel as a
problem somewhere else which was preventing his patches to work, maybe on
framebuffer side. As I was (am ) using a out of tree fb driver, I
stopped here, hoping that maybe it would be working with the kms one.

On a side note, I thought that Samuel's patches were about to be merged
but from your question, it may be not. Right ?

Arnaud
Peter Korsgaard - Dec. 17, 2012, 2:24 p.m.
>>>>> "Arnaud" == Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org> writes:

Hi,

 Arnaud> When I sent my version, I got some feedback from Samuel that it
 Arnaud> would be better to try and use the patches he sent but it
 Arnaud> didn't work on my smartbook. iirc, after debugging, what I
 Arnaud> found was seen by Samuel as a problem somewhere else which was
 Arnaud> preventing his patches to work, maybe on framebuffer side. As I
 Arnaud> was (am ) using a out of tree fb driver, I stopped here, hoping
 Arnaud> that maybe it would be working with the kms one.

Ok.

 Arnaud> On a side note, I thought that Samuel's patches were about to
 Arnaud> be merged but from your question, it may be not. Right ?

Well, I don't see anything in mainline with a quick grep, and as this
was ~2 years ago ..

Samuel, what happened to the ledtriggers-for-keyboard-leds stuff?
Samuel Thibault - Dec. 17, 2012, 2:30 p.m.
Peter Korsgaard, le Mon 17 Dec 2012 15:24:15 +0100, a écrit :
> Samuel, what happened to the ledtriggers-for-keyboard-leds stuff?

AIUI, it's still in the TODO list of Dmitry Torokhov (latest version
was sent on Date: Mon, 14 Nov 2011 05:06:13 +0100). There was a Kconfig
issue that might be what is blocking it:

“
> --- a/drivers/char/Kconfig
> +++ b/drivers/char/Kconfig
> @@ -8,6 +8,7 @@ config VT
>       bool "Virtual terminal" if EMBEDDED
>       depends on !S390
>       select INPUT
> +     select LEDS_INPUT

This will not work as LEDS_INPUT is itself depends and selects other
symbols and "select" statement does not propagate dependencies.
”

Samuel
Peter Korsgaard - Dec. 17, 2012, 2:40 p.m.
>>>>> "Samuel" == Samuel Thibault <samuel.thibault@ens-lyon.org> writes:

Hi,

 Samuel> AIUI, it's still in the TODO list of Dmitry Torokhov (latest
 Samuel> version was sent on Date: Mon, 14 Nov 2011 05:06:13
 Samuel> +0100). There was a Kconfig issue that might be what is
 Samuel> blocking it:

 Samuel> “
 >> --- a/drivers/char/Kconfig
 >> +++ b/drivers/char/Kconfig
 >> @@ -8,6 +8,7 @@ config VT
 >> bool "Virtual terminal" if EMBEDDED
 >> depends on !S390
 >> select INPUT
 >> +     select LEDS_INPUT

 Samuel> This will not work as LEDS_INPUT is itself depends and selects other
 Samuel> symbols and "select" statement does not propagate dependencies.

Ok, but that could either be solved by also selecting NEW_LEDS to pull
in LEDS_INPUT dependencies, so if we still want to be able to build
without pulling in the leds subsystem you could do 'select LEDS_INPUT if
NEW_LEDS' and stick the implementation inside an #ifdef NEW_LEDS.
Matt Sealey - Dec. 18, 2012, 1:12 a.m.
On Mon, Dec 17, 2012 at 5:50 AM, Sascha Hauer <s.hauer@pengutronix.de>wrote:

> On Mon, Dec 17, 2012 at 12:27:56PM +0100, Arnaud Patard wrote:
> > Sascha Hauer <s.hauer@pengutronix.de> writes:
> >
> > > Hi all,
> >
> > > - USB
> >
> > Is it working or not ? Or you meant that it's working only if you merge
> > the usbmisc-related for imx5* patches ?
>
> It's working with the patches in the git branch. It requires usbmisc
> patches and also ULPI support for the chipidea driver. I only bashed
> the chipidea driver until it worked. The last time I looked at the
> chipidea driver patches on the mailing list they were so much in flux
> that it didn't make sense to me to post even more patches. I hope
> this settles soon.



Oh my, I found out the real "Efika MX has a hardware bug" (referenced in
Sascha's "add ULPI" patch) issue just now and we all really have to discuss
this with Michael and Peter who are doing a bunch of chipidea stuff.. it's
actually far more complicated than just setting that bit as actually the
Smarttop doesn't need it, but the Smartbook does - but while setting that
bit would technically violate the USB specification because of the *intent*
of that bit, the implementation of the SMSC3317 PHY in use means it is
completely harmless *as long as* you are not intending to use it as a real
OTG port.

FYI, on the SMSC3317 ChrgVBus bit in ULPI OTG control simply connects the
VDD33 supply to VBUS. It does not perform or initiate any SRP or OTG
operations, it is just an internal switch for supply.

On Smarttop you don't need to touch this bit; the Smarttop has this
properly implemented in that if you enable DrvVBus or DrvVBusExternal bits
in OTG control (actually also technically a weird hack, but SMSC recommends
this configuration for hosts) then the SMSC3317 "CPEN" pin is activated. On
Smarttop, this enables supply of +5V (that is the rail name in the
schematic..) to VBUS, which is supplied to a Terminus FE1.1 HUB. This is
absolutely correct behavior and completely in line with the SMSC datasheets
for their USB PHYs.

Also on Smarttop, the USB DR port in Host mode is used to directly connect
an ASIX ethernet controller. On the current drivers, otg_set_vbus is called
on this port, but in actual fact it isn't required to be driven from the
MX51 at all (it isn't even traced out). The ASIX VBUS input is driven by
the same +5V rail as the H1 VBUS. Overcurrent protection could also be
disabled here since the regulator is quite solid and there's no hotplug
mess to deal with.

On Smartbook, H1 and H2 require this bit set since they connect PHY_VBUS to
HUB_VBUS_DET - this is a 3.3V IO to enable the hub downstream logic, so
while this is quite FREAKISH behavior, it is not technically violating any
USB specification in the broadest sense since PHY_VBUS isn't being used to
actually *drive* VBUS anywhere. All USB ports are backed by SMSC2514 hubs
and those hub ports where necessary are protected by ESD devices which
correctly handle and use the +5V supply for port VBUS and report
overcurrent.

We need to codify the ability to;

* set DrvVbus and/or DrvVbusExternal depending on port configuration, even
if it's a dedicated Host port. Or not, as the case may be. I can't find
anything in the USB specs that says DrvVbus should be enabled or disabled
on any basis that it controls any external logic. I am not sure they need
to be enabled at all on the SMSC3317 for Smartbook.. they do for Smarttop
for the H1 PHY but not for the internal UTMI PHY. I guess this is supposed
to be predicated on the presence or not of the "vbus-supply" property, so
this may actually be basically done already.

* Hack ChrgVBus for the Smartbook ports. I have a theory.. could we give it
a vbus-supply regulator, and call it "chrgvbus" and look for it and use it
to predicate setting the bit in the ULPI OTG control?

> Given that you wrote something for the mlt017, do you happen to have a
> > sii9022 driver too ? :)
>
> Only a very old one which won't work with the current code.


We are working on this internally and have been for some time.. people keep
moving the goalposts (and DRM is fundamentally not suited for the way it
needs to be done anyway).

> > - Battery
> >
> > I've not noticed something for the ac power supply in the dts. Did I
> miss something?
>
> I only added the following for the battery which is enough to detect it:
>
>         battery: battery@0b {
>                 compatible = "sbs,sbs-battery";
>                 reg = <0x0b>;
>                 sbs,battery-detect-gpios = <&gpio3 6 1>;
>         };
>
> I haven't done anything with the ac power supply yet. I suppose it's
> detectable via a gpio, right?


It is but apart from notifying userspace there's not a lot of point in it.
We experimented with it on the ancient kernel we shipped originally by
hooking it up to SW_DOCK or something (or was it SW_AC? I dunno) and inside
the battery driver looking for that input event rather than fixing GPIOs
into the driver. I guess if the sbs battery driver is using GPIOs directly,
we should do that too (but I do wonder, if the battery detect stuff is
behind some extra management controller via i2c or spi like on a Chromebook
or our MX53 design, we need far more code and a brand new binding here,
*or* a fake GPIO-expander-like controller driver to handle it just because
it isn't abstracted this way yet...)

> > - Sound (used to work, currently broken)
> > > - Wifi
> >
> > How did you enable it ? Did you configure the gpios to always enable it ?
>
> I configured the corresponding gpio as input, so it seems to get
> overwritten by the wifi switch. I don't know the schematics, but I'm
> able to turn Wifi off and on with the switch.


There are individual unit enables for 3G, Wifi and Bluetooth.

Think of the switch as a hardware override - "Airplane Mode" which forces
all of the individual unit enables off if you flick it to the "rf off"
position.

Quite literally, in the "rf on" position, the individual unit enables are
truly individual so you can have a working combination or preference of 3G,
Wifi and Bluetooth in the terminal to save battery, and just flick that
switch when the cabin crew asks :)


> > > - LEDs
> >
> > You're not mentionning pata. Is it working or not ?
>
> Ah, missed that. PATA is working aswell. Only PIO though.


We still have patches staged for PIO4 timings around which gives it a
teeeeeensy performance bump. One day we're all going to have to sit down
and figure out ATA SDMA. BTW I think we should change it to fsl,imx51-pata
to the compatibility (and add a match for fsl,imx35-pata too to the driver)
since there are implementation differences that might appear later (i.MX35
can't run DMA depending on certain clock speeds for example, and uses ADMA,
and i.MX5 uses SDMA)

> > I'm not posting the patches here since I do not consider them ready, but
> > > for everyone interested you can pull the following git tree. I have no
> > > idea if the patches work together with the preinstalled U-Boot, I use
> > > barebox on the Smartbook.
> >
> > I've (very quickly) tested it yesterday and it didn't even boot. I've
> > yet to look at the serial port output to check if it's a problem on my
> > side or a bug in the kernel.
>
> Do you mean barebox doesn't boot or the kernel doesn't boot?


Arnaud; it won't boot off the standard (or mainline) U-Boot because the
pins aren't muxed properly in either for some of the peripherals. We have a
plan;

1) update U-Boot to adequately set the pins up
2) add the correct pinctrls to the device tree (0x80000000 is imx-pinctrl
for "do not touch it" which is what is in Sascha's DT, so assumes that the
bootloader fixed it up already)

That way modern U-Boot people will have it muxed properly and people with
older U-Boots will still get working hardware. We still didn't release the
new U-Boot though, it simply didn't pass QA and there are some obvious bugs
(see above USB hack which is not perfect, and some problems booting kernels
of very specific sizes), regulator support is completely hosed (wrong
voltages *everywhere* and missing setup for some things).

We have an in-development device tree which essentially fixes all the
regulator issues Linux-side, too, and adds led triggers and all kinds of
stuff, in various stages of development and testing, but without USB we
can't QA wireless/3g/bluetooth/keyboard/touchpad/ethernet functionality and
display is obviously stalled because DRM sucks and because we got lazy on
the driver writing (because DRM sucks). I reckon that we'll push something
by the end of the week though for U-Boot and kernel like we did a couple
months ago.
Arnaud Patard (Rtp) - Dec. 18, 2012, 10:30 a.m.
Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org> writes:
Hi,


>>
>>> 
>>> >
>>> > I'm not posting the patches here since I do not consider them ready, but
>>> > for everyone interested you can pull the following git tree. I have no
>>> > idea if the patches work together with the preinstalled U-Boot, I use
>>> > barebox on the Smartbook.
>>> 
>>> I've (very quickly) tested it yesterday and it didn't even boot. I've
>>> yet to look at the serial port output to check if it's a problem on my
>>> side or a bug in the kernel.
>>
>> Do you mean barebox doesn't boot or the kernel doesn't boot?
>
> No idea. All I get is a black screen, so I need to look at the serial
> output. Oh, it's uboot not barebox btw. Sorry for the confusion.

After digging a little bit, turns out that someone failed to make sure
that clocks are enabled before reading/writing some
registers. imx51_ipu_mipi_setup() is called very early in the boot and
it's way before the clocks are enabled. So, as the clock is not enabled
when booting on my sb, it's freezing hard. A quick hack to move the call
to the end of mx51_clocks_init() allows to boot.

Then, I'm getting a oops. i2c doesn't seem to work (maybe related to
Matt and Steev remarks about pinctrl settings) so the edid is not found
and when the mtl017 driver is trying to fall back, it falls back the the
edid which may be provided by the dts. As it's not the case, it's
crashing at the memcmp() call. With a new test to check that, I can boot
on my mmc.

PATA is detected too but usb doesn't detect anything on the bus.

Next steps will probably be something like checking mtl017/lvds,lcd
gpios/regulators/pinctrl and then look at usb.

Oh, btw, the smartbook have only 512M of ram, not 1G so you need to fix
that in your dts file.

Arnaud
Sascha Hauer - Dec. 19, 2012, 8:56 a.m.
On Tue, Dec 18, 2012 at 11:30:17AM +0100, Arnaud Patard wrote:
> Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org> writes:
> Hi,
> 
> 
> >>
> >>> 
> >>> >
> >>> > I'm not posting the patches here since I do not consider them ready, but
> >>> > for everyone interested you can pull the following git tree. I have no
> >>> > idea if the patches work together with the preinstalled U-Boot, I use
> >>> > barebox on the Smartbook.
> >>> 
> >>> I've (very quickly) tested it yesterday and it didn't even boot. I've
> >>> yet to look at the serial port output to check if it's a problem on my
> >>> side or a bug in the kernel.
> >>
> >> Do you mean barebox doesn't boot or the kernel doesn't boot?
> >
> > No idea. All I get is a black screen, so I need to look at the serial
> > output. Oh, it's uboot not barebox btw. Sorry for the confusion.
> 
> After digging a little bit, turns out that someone failed to make sure
> that clocks are enabled before reading/writing some
> registers. imx51_ipu_mipi_setup() is called very early in the boot and
> it's way before the clocks are enabled. So, as the clock is not enabled
> when booting on my sb, it's freezing hard. A quick hack to move the call
> to the end of mx51_clocks_init() allows to boot.

Shawn already noticed this. A fix should appear soon in mainline.

> 
> Then, I'm getting a oops. i2c doesn't seem to work (maybe related to
> Matt and Steev remarks about pinctrl settings) so the edid is not found
> and when the mtl017 driver is trying to fall back, it falls back the the
> edid which may be provided by the dts. As it's not the case, it's
> crashing at the memcmp() call. With a new test to check that, I can boot
> on my mmc.
> 
> PATA is detected too but usb doesn't detect anything on the bus.
> 
> Next steps will probably be something like checking mtl017/lvds,lcd
> gpios/regulators/pinctrl and then look at usb.

This is probably because I'm using barebox. The i2c pinmux is probably
configured in the bootloader correctly. That should be easy to fix.
USB may be more work though...

> 
> Oh, btw, the smartbook have only 512M of ram, not 1G so you need to fix
> that in your dts file.

Will do. The bootloader fixes that for me currently, so I didn't realize
this.

Sascha
Steev Klimaszewski - Dec. 20, 2012, 4:34 p.m.
Hi Sascha,

I've given the patchset a (very) quick once over, but both myself and
Arnaud have tested PATA - any chance you could push them to the ata mailing
list to get accepted (I believe that's where they belong) - Feel free to
add my Tested-By: and Arnaud said his as well.


On Wed, Dec 19, 2012 at 2:56 AM, Sascha Hauer <s.hauer@pengutronix.de>wrote:

> On Tue, Dec 18, 2012 at 11:30:17AM +0100, Arnaud Patard wrote:
> > Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org> writes:
> > Hi,
> >
> >
> > >>
> > >>>
> > >>> >
> > >>> > I'm not posting the patches here since I do not consider them
> ready, but
> > >>> > for everyone interested you can pull the following git tree. I
> have no
> > >>> > idea if the patches work together with the preinstalled U-Boot, I
> use
> > >>> > barebox on the Smartbook.
> > >>>
> > >>> I've (very quickly) tested it yesterday and it didn't even boot. I've
> > >>> yet to look at the serial port output to check if it's a problem on
> my
> > >>> side or a bug in the kernel.
> > >>
> > >> Do you mean barebox doesn't boot or the kernel doesn't boot?
> > >
> > > No idea. All I get is a black screen, so I need to look at the serial
> > > output. Oh, it's uboot not barebox btw. Sorry for the confusion.
> >
> > After digging a little bit, turns out that someone failed to make sure
> > that clocks are enabled before reading/writing some
> > registers. imx51_ipu_mipi_setup() is called very early in the boot and
> > it's way before the clocks are enabled. So, as the clock is not enabled
> > when booting on my sb, it's freezing hard. A quick hack to move the call
> > to the end of mx51_clocks_init() allows to boot.
>
> Shawn already noticed this. A fix should appear soon in mainline.
>
> >
> > Then, I'm getting a oops. i2c doesn't seem to work (maybe related to
> > Matt and Steev remarks about pinctrl settings) so the edid is not found
> > and when the mtl017 driver is trying to fall back, it falls back the the
> > edid which may be provided by the dts. As it's not the case, it's
> > crashing at the memcmp() call. With a new test to check that, I can boot
> > on my mmc.
> >
> > PATA is detected too but usb doesn't detect anything on the bus.
> >
> > Next steps will probably be something like checking mtl017/lvds,lcd
> > gpios/regulators/pinctrl and then look at usb.
>
> This is probably because I'm using barebox. The i2c pinmux is probably
> configured in the bootloader correctly. That should be easy to fix.
> USB may be more work though...
>
> >
> > Oh, btw, the smartbook have only 512M of ram, not 1G so you need to fix
> > that in your dts file.
>
> Will do. The bootloader fixes that for me currently, so I didn't realize
> this.
>
> Sascha
>
> --
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
>
Matt Sealey - Dec. 25, 2012, 2:49 a.m.
also Tested-by: Matt Sealey <matt@genesi-usa.com>

Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.


On Thu, Dec 20, 2012 at 10:34 AM, Steev Klimaszewski
<steev@genesi-usa.com>wrote:

> Hi Sascha,
>
> I've given the patchset a (very) quick once over, but both myself and
> Arnaud have tested PATA - any chance you could push them to the ata mailing
> list to get accepted (I believe that's where they belong) - Feel free to
> add my Tested-By: and Arnaud said his as well.
>
>
> On Wed, Dec 19, 2012 at 2:56 AM, Sascha Hauer <s.hauer@pengutronix.de>wrote:
>
>> On Tue, Dec 18, 2012 at 11:30:17AM +0100, Arnaud Patard wrote:
>> > Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org> writes:
>> > Hi,
>> >
>> >
>> > >>
>> > >>>
>> > >>> >
>> > >>> > I'm not posting the patches here since I do not consider them
>> ready, but
>> > >>> > for everyone interested you can pull the following git tree. I
>> have no
>> > >>> > idea if the patches work together with the preinstalled U-Boot, I
>> use
>> > >>> > barebox on the Smartbook.
>> > >>>
>> > >>> I've (very quickly) tested it yesterday and it didn't even boot.
>> I've
>> > >>> yet to look at the serial port output to check if it's a problem on
>> my
>> > >>> side or a bug in the kernel.
>> > >>
>> > >> Do you mean barebox doesn't boot or the kernel doesn't boot?
>> > >
>> > > No idea. All I get is a black screen, so I need to look at the serial
>> > > output. Oh, it's uboot not barebox btw. Sorry for the confusion.
>> >
>> > After digging a little bit, turns out that someone failed to make sure
>> > that clocks are enabled before reading/writing some
>> > registers. imx51_ipu_mipi_setup() is called very early in the boot and
>> > it's way before the clocks are enabled. So, as the clock is not enabled
>> > when booting on my sb, it's freezing hard. A quick hack to move the call
>> > to the end of mx51_clocks_init() allows to boot.
>>
>> Shawn already noticed this. A fix should appear soon in mainline.
>>
>> >
>> > Then, I'm getting a oops. i2c doesn't seem to work (maybe related to
>> > Matt and Steev remarks about pinctrl settings) so the edid is not found
>> > and when the mtl017 driver is trying to fall back, it falls back the the
>> > edid which may be provided by the dts. As it's not the case, it's
>> > crashing at the memcmp() call. With a new test to check that, I can boot
>> > on my mmc.
>> >
>> > PATA is detected too but usb doesn't detect anything on the bus.
>> >
>> > Next steps will probably be something like checking mtl017/lvds,lcd
>> > gpios/regulators/pinctrl and then look at usb.
>>
>> This is probably because I'm using barebox. The i2c pinmux is probably
>> configured in the bootloader correctly. That should be easy to fix.
>> USB may be more work though...
>>
>> >
>> > Oh, btw, the smartbook have only 512M of ram, not 1G so you need to fix
>> > that in your dts file.
>>
>> Will do. The bootloader fixes that for me currently, so I didn't realize
>> this.
>>
>> Sascha
>>
>> --
>> Pengutronix e.K.                           |                             |
>> Industrial Linux Solutions                 | http://www.pengutronix.de/ |
>> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
>>  |
>> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555|
>>
>
>
>
> --
> Best Regards,
> Steev
>
> Steev Klimaszewski <steev@genesi-usa.com>
> Senior Software Engineer, Genesi USA, Inc.
>