| Message ID | 20121217075907.GQ24458@pengutronix.de |
|---|---|
| State | New |
| Headers | show |
>>>>> "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.
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
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
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
>>>>> "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
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
>>>>> "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?
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
>>>>> "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.
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) <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
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
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 | >
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. >
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