[request for testing] isl, cyapa on chromebooks

[Andriy Gapon]

If you have a Chromebook where you are currently able to use isl and cyapa
drivers, could you please test the following code change?
https://people.freebsd.org/~avg/ig4-i2c.diff

The change moves the drivers from the SMBus to the I2C bus and as such some
configuration changes are required.
Namely, you will now need iicbus driver either in the kernel configuration or as
a module. For now the smbus driver is also required.
You also need to add some entries to /boot/device.hints:
hint.isl.0.at="iicbus0"
hint.isl.0.addr=0x88
hint.isl.1.at="iicbus1"
hint.isl.1.addr=0x88
hint.cyapa.0.at="iicbus0"
hint.cyapa.0.addr=0xce
hint.cyapa.1.at="iicbus1"
hint.cyapa.1.addr=0xce

The hints are required because auto-probing (either via the bus enumeration or
self-identification) is disabled for now for safety reason.
Also, as I understand, the Intel chipset used in the supported Chromebooks
provides to i2c buses (possibly in addition in an smbus) and I am not sure on
which of the i2c buses the devices reside.

The changes are build tested only, because I do not have access to the hardware.
So, kernel panics, etc are not unexpected.

Please let me know if drivers attach at all and if there are any issues with them.
A verbose dmesg would be of great help. That could be obtained by booting in a
verbose mode if the drivers are auto-loaded or by setting debug.bootverbose=1
before loading the drivers if that's done manually.

Please also note that ig4 driver is changed, so it too has to be rebuilt if you
are going to build individual modules rather than do a kernel + modules build.

I will appreciate your testing and feedback.
Thank you!
--
Andriy Gapon
_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

[Michael Gmelin]

Thanks for working on this.

I have currently access to two c720 Chromebooks, one with a cyapa
touchpad, the other with a (yet) unsupported replacement I'm planning to
work on.

I upgraded the latter the r306641, applied your patches (cleanly) and
ran "make kernel" (GENERIC kernel), added the entries to device.hints
and rebooted. Unfortunately ig4 won't load:

# kldload ig4
link_elf_obj: symbol iicbus_transfer_desc undefined
linker_load_file: Unsupported file type

I also noticed that isl cannot be built from the module source
directory:

# cd /usr/src/sys/modules/i2c/isl
# make
..
/usr/src/sys/sys/vnode.h:571:10: fatal error: 'vnode_if.h' file not
found
#include "vnode_if.h"
^
1 error generated
*** Error code 1

This can be easily fixed by removing "#include <sys/vnode.h>" from
isl.c (line 56).

Best,
Michael

--
Michael Gmelin

[Andriy Gapon]

On 03/10/2016 19:07, Michael Gmelin wrote:
> I upgraded the latter the r306641, applied your patches (cleanly) and
> ran "make kernel" (GENERIC kernel), added the entries to device.hints
> and rebooted. Unfortunately ig4 won't load:
>
> # kldload ig4
> link_elf_obj: symbol iicbus_transfer_desc undefined
> linker_load_file: Unsupported file type

Hmm, seems like forgot to declare the iicbus module dependency.
Could you please kldload iicbus and see if that helps?
Meanwhile I'll add the dependency.

> I also noticed that isl cannot be built from the module source
> directory:
>
> # cd /usr/src/sys/modules/i2c/isl
> # make

> ...

> /usr/src/sys/sys/vnode.h:571:10: fatal error: 'vnode_if.h' file not
> found
> #include "vnode_if.h"
> ^
> 1 error generated
> *** Error code 1
>
> This can be easily fixed by removing "#include <sys/vnode.h>" from
> isl.c (line 56).

Thank you for reporting this!
Looks like I overlooked this because I didn't do make clean after removing
vnode_if.h from the Makefile.
Will fix this too.

--
Andriy Gapon

[Michael Gmelin]

On Mon, 3 Oct 2016 19:41:17 +0300
Andriy Gapon <a...@FreeBSD.org> wrote:

> On 03/10/2016 19:07, Michael Gmelin wrote:
> > I upgraded the latter the r306641, applied your patches (cleanly)
> > and ran "make kernel" (GENERIC kernel), added the entries to
> > device.hints and rebooted. Unfortunately ig4 won't load:
> >
> > # kldload ig4
> > link_elf_obj: symbol iicbus_transfer_desc undefined
> > linker_load_file: Unsupported file type
>
> Hmm, seems like forgot to declare the iicbus module dependency.
> Could you please kldload iicbus and see if that helps?
> Meanwhile I'll add the dependency.

Unfortunately this doesn't help, you should be able to reproduce it
yourself without access to the actual hardware though.

I worked around this by adding the iicbus dependency to ig4_pci.c (and
also to "files").

Now loading ig4 works and both lynx point controllers are detected.
Loading isl doesn't create any output and doesn't seem to detect any
devices. Also, devinfo shows both controllers (ig4iic0, ig4iic1), but
no iicbus devices.

# devinfo | grep iic
ig4iic0
ig4iic1

-m

--
Michael Gmelin

[Andriy Gapon]

On 03/10/2016 23:25, Michael Gmelin wrote:
> On Mon, 3 Oct 2016 19:41:17 +0300
> Andriy Gapon <a...@FreeBSD.org> wrote:
>
>> On 03/10/2016 19:07, Michael Gmelin wrote:
>>> I upgraded the latter the r306641, applied your patches (cleanly)
>>> and ran "make kernel" (GENERIC kernel), added the entries to
>>> device.hints and rebooted. Unfortunately ig4 won't load:
>>>
>>> # kldload ig4
>>> link_elf_obj: symbol iicbus_transfer_desc undefined
>>> linker_load_file: Unsupported file type
>>
>> Hmm, seems like forgot to declare the iicbus module dependency.
>> Could you please kldload iicbus and see if that helps?
>> Meanwhile I'll add the dependency.
>
> Unfortunately this doesn't help, you should be able to reproduce it
> yourself without access to the actual hardware though.
>
> I worked around this by adding the iicbus dependency to ig4_pci.c (and
> also to "files").

Okay, this should be in the latest patch anyway.

> Now loading ig4 works and both lynx point controllers are detected.
> Loading isl doesn't create any output and doesn't seem to detect any
> devices. Also, devinfo shows both controllers (ig4iic0, ig4iic1), but
> no iicbus devices.
>
> # devinfo | grep iic
> ig4iic0
> ig4iic1

Is there anything interesting from from ig4 in the log / dmesg?
Could you please check that your copy of the patch contains this chunk?
@@ -549,7 +780,7 @@ ig4iic_attach(ig4iic_softc_t *sc)
IG4_CTL_RESTARTEN |
IG4_CTL_SPEED_STD);

- sc->smb = device_add_child(sc->dev, "smbus", -1);
+ sc->smb = device_add_child(sc->dev, "iicbus", -1);
if (sc->smb == NULL) {
device_printf(sc->dev, "smbus driver not found\n");
error = ENXIO;

--
Andriy Gapon

[Michael Gmelin]

On Tue, 4 Oct 2016 01:04:10 +0300

Andriy Gapon <a...@FreeBSD.org> wrote:

> On 03/10/2016 23:25, Michael Gmelin wrote:
> > On Mon, 3 Oct 2016 19:41:17 +0300
> > Andriy Gapon <a...@FreeBSD.org> wrote:
> >
> >> On 03/10/2016 19:07, Michael Gmelin wrote:
> >>> I upgraded the latter the r306641, applied your patches (cleanly)
> >>> and ran "make kernel" (GENERIC kernel), added the entries to
> >>> device.hints and rebooted. Unfortunately ig4 won't load:
> >>>
> >>> # kldload ig4
> >>> link_elf_obj: symbol iicbus_transfer_desc undefined
> >>> linker_load_file: Unsupported file type
> >>
> >> Hmm, seems like forgot to declare the iicbus module dependency.
> >> Could you please kldload iicbus and see if that helps?
> >> Meanwhile I'll add the dependency.
> >
> > Unfortunately this doesn't help, you should be able to reproduce it
> > yourself without access to the actual hardware though.
> >
> > I worked around this by adding the iicbus dependency to ig4_pci.c
> > (and also to "files").
>
> Okay, this should be in the latest patch anyway.

Based on what you wrote, I wasn't aware that there was a new patch. I
downloaded the latest version from the same URL as your first one and
built a new kernel.

>
> > Now loading ig4 works and both lynx point controllers are detected.
> > Loading isl doesn't create any output and doesn't seem to detect any
> > devices. Also, devinfo shows both controllers (ig4iic0, ig4iic1),
> > but no iicbus devices.
> >
> > # devinfo | grep iic
> > ig4iic0
> > ig4iic1
>
> Is there anything interesting from from ig4 in the log / dmesg?
> Could you please check that your copy of the patch contains this
> chunk? @@ -549,7 +780,7 @@ ig4iic_attach(ig4iic_softc_t *sc)
> IG4_CTL_RESTARTEN |
> IG4_CTL_SPEED_STD);
>
> - sc->smb = device_add_child(sc->dev, "smbus", -1);
> + sc->smb = device_add_child(sc->dev, "iicbus", -1);
> if (sc->smb == NULL) {
> device_printf(sc->dev, "smbus driver not found\n");
> error = ENXIO;
>

That code was in there, yes.

iicbus(0|1) actually show up in devinfo -v, but nothing else works.

You can find a log file and various outputs (dmesg, devinfo etc) here:

https://people.freebsd.org/~grembo/c720-20161104.log

-m

--
Michael Gmelin

[Andriy Gapon]

On 04/10/2016 12:46, Michael Gmelin wrote:
> iicbus(0|1) actually show up in devinfo -v, but nothing else works.
>
> You can find a log file and various outputs (dmesg, devinfo etc) here:
>
> https://people.freebsd.org/~grembo/c720-20161104.log

Thank you.
Could you please double-check that device.hints contains the necessary hints?
Could you also set debug.bootverbose=1 before kldload ig4 and kldload isl and
show me any new log messages that appear after doing kldload?

--
Andriy Gapon

[Michael Gmelin]

On Tue, 4 Oct 2016 13:07:28 +0300
Andriy Gapon <a...@FreeBSD.org> wrote:

> On 04/10/2016 12:46, Michael Gmelin wrote:
> > iicbus(0|1) actually show up in devinfo -v, but nothing else works.
> >
> > You can find a log file and various outputs (dmesg, devinfo etc)
> > here:
> >
> > https://people.freebsd.org/~grembo/c720-20161104.log
>
> Thank you.
> Could you please double-check that device.hints contains the
> necessary hints? Could you also set debug.bootverbose=1 before
> kldload ig4 and kldload isl and show me any new log messages that
> appear after doing kldload?
>

Double-checked the hints, it's all ok.

Please find a more verbose log file of loading the kernel modules here:

https://people.freebsd.org/~grembo/c720-20161105.log

-m

--
Michael Gmelin

[Andriy Gapon]

On 05/10/2016 01:48, Michael Gmelin wrote:
> Double-checked the hints, it's all ok.
>
> Please find a more verbose log file of loading the kernel modules here:
>
> https://people.freebsd.org/~grembo/c720-20161105.log

Unfortunately this doesn't provide any new insights.

Could you please add some printf-s to iicbus_hinted_child() in
sys/dev/iicbus/iicbus.c to see whether the isl devices are really added via the
hints and what their properties are?
Also, some printf-s to isl_probe() to see if it gets called and where it fails.
And, just in case, to ig4iic_start() to see if gets called.

Thank you!

--
Andriy Gapon

[Michael Gmelin]

> On 05 Oct 2016, at 07:48, Andriy Gapon <a...@FreeBSD.org> wrote:
>
>> On 05/10/2016 01:48, Michael Gmelin wrote:
>> Double-checked the hints, it's all ok.
>>
>> Please find a more verbose log file of loading the kernel modules here:
>>
>> https://people.freebsd.org/~grembo/c720-20161105.log
>
> Unfortunately this doesn't provide any new insights.
>
> Could you please add some printf-s to iicbus_hinted_child() in
> sys/dev/iicbus/iicbus.c to see whether the isl devices are really added via the
> hints and what their properties are?
> Also, some printf-s to isl_probe() to see if it gets called and where it fails.
> And, just in case, to ig4iic_start() to see if gets called.
>

ig4iic_start is called, but iicbus_hinted_child, isl_probe, iicbus_probe and iicbus_attach are not.

-m

[Michael Gmelin]

> On 05 Oct 2016, at 13:32, Malcolm Matalka <mmat...@gmail.com> wrote:

> > https://lists.freebsd.org/mailman/listinfo/freebsd-mobile
> > To unsubscribe, send any mail to "freebsd-mobil...@freebsd.org"
>
> I'm running a laptop that uses an Elantech touch pad over i2c. I think I get Elantech is quite close to cyapa, would this patch be a good place to start for trying to get the touchpad to work? There is also an Elantech patch happening for the next release but that is not over i2c. I'm interested in making the change I just have little idea of this layer of the machinery.
>
I'm having such a machine here myself (one with cyapa, one with elan for testing) and planning to work on it soon (once avg@ is done with this changes). I also know another user in person waiting for this, so there is definitely demand and enough hands for testing.

[Malcolm Matalka]

Den 5 okt. 2016 13:19 skrev "Michael Gmelin" <gre...@freebsd.org>:
>
>
>

> https://lists.freebsd.org/mailman/listinfo/freebsd-mobile
> To unsubscribe, send any mail to "freebsd-mobil...@freebsd.org"

I'm running a laptop that uses an Elantech touch pad over i2c. I think I
get Elantech is quite close to cyapa, would this patch be a good place to
start for trying to get the touchpad to work? There is also an Elantech
patch happening for the next release but that is not over i2c. I'm
interested in making the change I just have little idea of this layer of
the machinery.

Thanks,
/Malcolm

[Malcolm Matalka]

Nice! I'd love to follow along in development and learn whatever can. I've
never worked at device driver level before. Do you have a suggested time I
can start harassing you more about testing?

Den 5 okt. 2016 13:48 skrev "Michael Gmelin" <gre...@freebsd.org>:

>
>
> On 05 Oct 2016, at 13:32, Malcolm Matalka <mmat...@gmail.com> wrote:
>
> Den 5 okt. 2016 13:19 skrev "Michael Gmelin" <gre...@freebsd.org>:
> >
> >
> >
> > > On 05 Oct 2016, at 07:48, Andriy Gapon <a...@FreeBSD.org

[Andriy Gapon]

On 05/10/2016 14:19, Michael Gmelin wrote:
>
> ig4iic_start is called, but iicbus_hinted_child, isl_probe, iicbus_probe and
> iicbus_attach are not.

Thank you!
Now I think I see where I made a silly mistake.
Please try an updated version of the patch from here
https://people.freebsd.org/~avg/ig4-i2c.v3.diff
It contains a fix and some cosmetic changes on top of the previous patch.

--
Andriy Gapon

[Matthias Apitz]

El día Wednesday, October 05, 2016 a las 04:01:25PM +0300, Andriy Gapon escribió:

> On 05/10/2016 14:19, Michael Gmelin wrote:
> >
> > ig4iic_start is called, but iicbus_hinted_child, isl_probe, iicbus_probe and
> > iicbus_attach are not.
>
> Thank you!
> Now I think I see where I made a silly mistake.
> Please try an updated version of the patch from here
> https://people.freebsd.org/~avg/ig4-i2c.v3.diff
> It contains a fix and some cosmetic changes on top of the previous patch.

Hi Andriy,

I have an Acer C720 too, since around two years and it works fine,
thanks to Michael, with the cyapa chip. I have my C720 in daily heavy
usage, actually with r292778. Should I apply the above patch or do I
need to update before to a more recent CURRENT? I have a second C720
where I could do such test/update more easy, but this is current not in
my hands and has, after a repair at Acer, a Elan touch pad.
But I could prepare an USB key with 12-CURRENT, just for test.

Btw: What is the reason for this change of ig4/i2c/cyapa driver?

Last thing: I propose to remove freebsd-mobile@ from the thread.

matthias
--
Matthias Apitz, ✉ gu...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045

[Andriy Gapon]

On 06/10/2016 07:47, Matthias Apitz wrote:
> El día Wednesday, October 05, 2016 a las 04:01:25PM +0300, Andriy Gapon escribió:
>
>> On 05/10/2016 14:19, Michael Gmelin wrote:
>>>
>>> ig4iic_start is called, but iicbus_hinted_child, isl_probe, iicbus_probe and
>>> iicbus_attach are not.
>>
>> Thank you!
>> Now I think I see where I made a silly mistake.
>> Please try an updated version of the patch from here
>> https://people.freebsd.org/~avg/ig4-i2c.v3.diff
>> It contains a fix and some cosmetic changes on top of the previous patch.
>
> Hi Andriy,
>
> I have an Acer C720 too, since around two years and it works fine,
> thanks to Michael, with the cyapa chip. I have my C720 in daily heavy
> usage, actually with r292778. Should I apply the above patch or do I
> need to update before to a more recent CURRENT?

I think that the patch should apply.
But if it doesn't...

> I have a second C720
> where I could do such test/update more easy, but this is current not in
> my hands and has, after a repair at Acer, a Elan touch pad.
> But I could prepare an USB key with 12-CURRENT, just for test.

The more testing the better!

> Btw: What is the reason for this change of ig4/i2c/cyapa driver?

The reason is that the hardware that ig4 handles is really an I2C controller.
Moreover, isl and cyapa need to issue I2C commands that can not be mapped to
SMBus commands to talk to their hardware.
I am not sure why Matt Dillon (who I believe is the original author of the code)
chose to use smbus(4) instead of iicbus(4). And to make that work he had to
"extend" smbus(4) with smbus_trans() method which does not really map to
anything defined by the SMBus specification and which can not be implemented on
any of real pure SMBus controllers (like intpm or ichsmb). The closest command
that SMBus supports is 'Block write - block read process call', but it's not
quite the same.

> Last thing: I propose to remove freebsd-mobile@ from the thread.

Okay. I just was not sure where I can find FreeBSD Chromebook owners.

--
Andriy Gapon

[Michael Gmelin]

> On 05 Oct 2016, at 15:01, Andriy Gapon <a...@FreeBSD.org> wrote:
>
>> On 05/10/2016 14:19, Michael Gmelin wrote:
>>
>> ig4iic_start is called, but iicbus_hinted_child, isl_probe, iicbus_probe and
>> iicbus_attach are not.
>
> Thank you!
> Now I think I see where I made a silly mistake.
> Please try an updated version of the patch from here
> https://people.freebsd.org/~avg/ig4-i2c.v3.diff
> It contains a fix and some cosmetic changes on top of the previous patch.
>

Isl attaches cleanly on iicbus1 now, but it doesn't appear to function (all inputs, like dev.isl.ir etc, are stuck at 0).

-m

[Andriy Gapon]

On 06/10/2016 10:08, Michael Gmelin wrote:
>
>
>> On 05 Oct 2016, at 15:01, Andriy Gapon <a...@FreeBSD.org> wrote:
>>
>>> On 05/10/2016 14:19, Michael Gmelin wrote:
>>>
>>> ig4iic_start is called, but iicbus_hinted_child, isl_probe, iicbus_probe and
>>> iicbus_attach are not.
>>
>> Thank you!
>> Now I think I see where I made a silly mistake.
>> Please try an updated version of the patch from here
>> https://people.freebsd.org/~avg/ig4-i2c.v3.diff
>> It contains a fix and some cosmetic changes on top of the previous patch.
>>
>
> Isl attaches cleanly on iicbus1 now, but it doesn't appear to function (all inputs, like dev.isl.ir etc, are stuck at 0).

At least some progress...
Anything interesting in logs?

Oh! and I've just spotted a typo in isl.c: the last call to isl_read_byte() in
isl_read_sensor() should have REG_DATA2 (not REG_DATA1 again).

Thank you for testing!

--
Andriy Gapon

[Andriy Gapon]

On 06/10/2016 10:25, Andriy Gapon wrote:
> On 06/10/2016 10:08, Michael Gmelin wrote:
>>
>>
>>> On 05 Oct 2016, at 15:01, Andriy Gapon <a...@FreeBSD.org> wrote:
>>>
>>>> On 05/10/2016 14:19, Michael Gmelin wrote:
>>>>
>>>> ig4iic_start is called, but iicbus_hinted_child, isl_probe, iicbus_probe and
>>>> iicbus_attach are not.
>>>
>>> Thank you!
>>> Now I think I see where I made a silly mistake.
>>> Please try an updated version of the patch from here
>>> https://people.freebsd.org/~avg/ig4-i2c.v3.diff
>>> It contains a fix and some cosmetic changes on top of the previous patch.
>>>
>>
>> Isl attaches cleanly on iicbus1 now, but it doesn't appear to function (all inputs, like dev.isl.ir etc, are stuck at 0).
>
> At least some progress...
> Anything interesting in logs?
>
> Oh! and I've just spotted a typo in isl.c: the last call to isl_read_byte() in
> isl_read_sensor() should have REG_DATA2 (not REG_DATA1 again).

And another, more severe typo :-(
In isl_read_byte we should pass both messages to the bus:
return (iicbus_transfer(dev, msgs, 2));
That is, s/1/2/.

[Andriy Gapon]

On 06/10/2016 08:37, Andriy Gapon wrote:
> The more testing the better!

Based on Michael's results I've uploaded a new version:
https://people.freebsd.org/~avg/ig4-i2c.v4.diff

[Michael Gmelin]

> On 06 Oct 2016, at 09:48, Andriy Gapon <a...@FreeBSD.org> wrote:
>
>> On 06/10/2016 08:37, Andriy Gapon wrote:
>> The more testing the better!
>
> Based on Michael's results I've uploaded a new version:
> https://people.freebsd.org/~avg/ig4-i2c.v4.diff
>
>

Good news. Applying the last two fixes manually, isl is working now.

I'll rebuild a kernel using the complete v4 patch on my second machine later today to test the modified cyapa driver.

-m

[Andriy Gapon]

On 06/10/2016 11:10, Michael Gmelin wrote:
>
>
>> On 06 Oct 2016, at 09:48, Andriy Gapon <a...@FreeBSD.org> wrote:
>>
>>> On 06/10/2016 08:37, Andriy Gapon wrote:
>>> The more testing the better!
>>
>> Based on Michael's results I've uploaded a new version:
>> https://people.freebsd.org/~avg/ig4-i2c.v4.diff
>>
>>
>
> Good news. Applying the last two fixes manually, isl is working now.

Great!

> I'll rebuild a kernel using the complete v4 patch on my second machine later today to test the modified cyapa driver.

Thank you again!

--
Andriy Gapon

[Michael Gmelin]

On Thu, 6 Oct 2016 11:12:27 +0300

Andriy Gapon <a...@FreeBSD.org> wrote:

> On 06/10/2016 11:10, Michael Gmelin wrote:
> >
> >
> >> On 06 Oct 2016, at 09:48, Andriy Gapon <a...@FreeBSD.org> wrote:
> >>
> >>> On 06/10/2016 08:37, Andriy Gapon wrote:
> >>> The more testing the better!
> >>
> >> Based on Michael's results I've uploaded a new version:
> >> https://people.freebsd.org/~avg/ig4-i2c.v4.diff
> >>
> >>
> >
> > Good news. Applying the last two fixes manually, isl is working
> > now.
>
> Great!
>
> > I'll rebuild a kernel using the complete v4 patch on my second
> > machine later today to test the modified cyapa driver.
>
> Thank you again!
>

Just tested, cyapa is working ok as well, cool.

Now, if we wanted to make touchpads like the Elantech (and probably
other increasingly popular devices work), I assume we'll need HID over
I2C support. OpenBSD got that recently (imt(4) and friends).

Anybody interested in porting/re-implementing?

-m

--
Michael Gmelin

[Matthias Apitz]

El día Thursday, October 06, 2016 a las 11:12:27AM +0300, Andriy Gapon escribió:

> On 06/10/2016 11:10, Michael Gmelin wrote:
> >
> >
> >> On 06 Oct 2016, at 09:48, Andriy Gapon <a...@FreeBSD.org> wrote:
> >>
> >>> On 06/10/2016 08:37, Andriy Gapon wrote:
> >>> The more testing the better!
> >>
> >> Based on Michael's results I've uploaded a new version:
> >> https://people.freebsd.org/~avg/ig4-i2c.v4.diff
> >>
> >>
> >
> > Good news. Applying the last two fixes manually, isl is working now.
>
> Great!
>
> > I'll rebuild a kernel using the complete v4 patch on my second machine later today to test the modified cyapa driver.

I have now produced a memstick with (unpatched) r306769 of October 6. It boots
fine in my Acer C720 Chromebook and the moused is working fine with the
cyapa(4) driver. I will apply tomorrow the above v4 patch or is there
anything newer? And will test/report.

matthias
--
Matthias Apitz, ✉ gu...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045

[Andriy Gapon]

On 08/10/2016 21:07, Matthias Apitz wrote:
> I have now produced a memstick with (unpatched) r306769 of October 6. It boots
> fine in my Acer C720 Chromebook and the moused is working fine with the
> cyapa(4) driver. I will apply tomorrow the above v4 patch or is there
> anything newer? And will test/report.

v4 is the latest. Thanks!

--
Andriy Gapon

[Warner Losh]

Speaking of Chromebooks, what's the best way to put FreeBSD onto one?

Warner

[Matthias Apitz]

On Saturday, 8 October 2016 23:54:27 CEST, Warner Losh <i...@bsdimp.com>
wrote:

> Speaking of Chromebooks, what's the best way to put FreeBSD onto one?
>

Set it to developer mode or Legacy boot, boot and install 11-C or 12-C from
USB.

matthias



--
Sent from my Ubuntu phone
http://www.unixarea.de/

[Michael Gmelin]

On Sat, 8 Oct 2016 15:54:27 -0600
Warner Losh <i...@bsdimp.com> wrote:

> Speaking of Chromebooks, what's the best way to put FreeBSD onto one?
>
> Warner
>
>

Depends on the Chromebook in question, when porting the drivers for the
c720, I wrote a blog post about it (quite a while ago):

https://blog.grem.de/pages/c720.html

Would I maybe make sense to have man pages for specific laptops (instead
of the "FreeBSD Laptop" page, blogs on the internet and Wiki pages).

Just thinking that after this change, people will need to know the
correct addresses for device.hints to make isl and cyapa work, and
putting things like that (and other hints, e.g. to route the Intel HDA
correctly) into a man page ("apropos c720") would be the next best
thing to having it work out of the box.

-m

--
Michael Gmelin

[Matthias Apitz]

El día Saturday, October 08, 2016 a las 10:17:07PM +0300, Andriy Gapon escribió:

> On 08/10/2016 21:07, Matthias Apitz wrote:
> > I have now produced a memstick with (unpatched) r306769 of October 6. It boots
> > fine in my Acer C720 Chromebook and the moused is working fine with the
> > cyapa(4) driver. I will apply tomorrow the above v4 patch or is there
> > anything newer? And will test/report.
>
> v4 is the latest. Thanks!

The patch applies cleanly, the 'make buildkernel' does fine and system
boots, but cyapa(4) can not bring the device out of bootstrap. The verbose dmesg
is here http://www.unixarea.de/dmesg-00.txt

And yes, I have in /boot/device.hints:

..
# The change moves the drivers from the SMBus to the I2C bus and as such some
# configuration changes are required.
# Namely, you will now need iicbus driver either in the kernel configuration or as
# a module. For now the smbus driver is also required.
# You also need to add some entries to /boot/device.hints:
#
hint.isl.0.at="iicbus0"
hint.isl.0.addr=0x88
hint.isl.1.at="iicbus1"
hint.isl.1.addr=0x88
hint.cyapa.0.at="iicbus0"
hint.cyapa.0.addr=0xce
hint.cyapa.1.at="iicbus1"
hint.cyapa.1.addr=0xce
#
# The hints are required because auto-probing (either via the bus enumeration or
# self-identification) is disabled for now for safety reason.
# Also, as I understand, the Intel chipset used in the supported Chromebooks
# provides to i2c buses (possibly in addition in an smbus) and I am not sure on
# which of the i2c buses the devices reside.

Please let me know what to check/debug.

matthias

--
Matthias Apitz, ✉ gu...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045

Einheitsfeier? Nein, danke! Kann ich bitte mein Land wiederhaben und am 7. Oktober feiern.

[Andriy Gapon]

On 09/10/2016 09:36, Matthias Apitz wrote:
> El día Saturday, October 08, 2016 a las 10:17:07PM +0300, Andriy Gapon escribió:
>
>> On 08/10/2016 21:07, Matthias Apitz wrote:
>>> I have now produced a memstick with (unpatched) r306769 of October 6. It boots
>>> fine in my Acer C720 Chromebook and the moused is working fine with the
>>> cyapa(4) driver. I will apply tomorrow the above v4 patch or is there
>>> anything newer? And will test/report.
>>
>> v4 is the latest. Thanks!
>
> The patch applies cleanly, the 'make buildkernel' does fine and system
> boots, but cyapa(4) can not bring the device out of bootstrap. The verbose dmesg
> is here http://www.unixarea.de/dmesg-00.txt
>
> And yes, I have in /boot/device.hints:

Well, comparing the hints and the boot message, you have exactly the problem
that I feared many people would have until we add auto-probing to isl and cyapa.

Basically it's easy to connect the dots once you know what they are. You hint
that isl and cyapa should be on iicbus0 or iicbus1. But iicbus0 is connected to
iicbb0 which is intel_iicbb0 on drmn0, which is a video card. That is clearly
wrong. And a similar thing with iicbus1: <Philips I2C bus> on intel_gmbus0.
But later you have:
iicbus14: <Philips I2C bus> on ig4iic0
iicbus15: <Philips I2C bus> on ig4iic1
So, in your case, and with that probing order (hopefully it not changes from
boot to boot), you should use those two buses to look for isl and cyapa.

Examining output of devinfo -v -r should be even easier than going through dmesg.
Hope this helps.

> ...

> # The change moves the drivers from the SMBus to the I2C bus and as such some
> # configuration changes are required.
> # Namely, you will now need iicbus driver either in the kernel configuration or as
> # a module. For now the smbus driver is also required.
> # You also need to add some entries to /boot/device.hints:
> #
> hint.isl.0.at="iicbus0"
> hint.isl.0.addr=0x88
> hint.isl.1.at="iicbus1"
> hint.isl.1.addr=0x88
> hint.cyapa.0.at="iicbus0"
> hint.cyapa.0.addr=0xce
> hint.cyapa.1.at="iicbus1"
> hint.cyapa.1.addr=0xce
> #
> # The hints are required because auto-probing (either via the bus enumeration or
> # self-identification) is disabled for now for safety reason.
> # Also, as I understand, the Intel chipset used in the supported Chromebooks
> # provides to i2c buses (possibly in addition in an smbus) and I am not sure on
> # which of the i2c buses the devices reside.
>
> Please let me know what to check/debug.
>
> matthias
>


--

Andriy Gapon

[Matthias Apitz]

El día Sunday, October 09, 2016 a las 01:53:24AM +0200, Michael Gmelin escribió:

> Would I maybe make sense to have man pages for specific laptops (instead
> of the "FreeBSD Laptop" page, blogs on the internet and Wiki pages).
>
> Just thinking that after this change, people will need to know the
> correct addresses for device.hints to make isl and cyapa work, and
> putting things like that (and other hints, e.g. to route the Intel HDA
> correctly) into a man page ("apropos c720") would be the next best
> thing to having it work out of the box.

Good idea. The problem with such an approach is, that new laptops get
only inserted into man pages when some maintainer/approver does so and
seldom if someone brings a new device to working (more or less) with
FreeBSD.

In the past (some 15 years ago) there was a database and a web frotnend
where people (everyone) could insert/update a new working device. It was
here: http://laptop.bsdgroup.de/freebsd/ but the site is offline for
many year. I even tried and contacted the provide of 'bsdgroup.de' to
get a copy of the database, w/o any luck.

matthias

--
Matthias Apitz, ✉ gu...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045

Einheitsfeier? Nein, danke! Kann ich bitte mein Land wiederhaben und am 7. Oktober feiern.

[Matthias Apitz]

Thanks. Changing device.hints to

iicbus14
iicbus15

makes cyapa(4) attaching and moused working fine. I will later install xorg
into this memstick.

matthias




--
Sent from my Ubuntu phone
http://www.unixarea.de/

[Warner Losh]

On Sun, Oct 9, 2016 at 12:54 AM, Matthias Apitz <gu...@unixarea.de> wrote:
> El día Sunday, October 09, 2016 a las 01:53:24AM +0200, Michael Gmelin escribió:
>
>> Would I maybe make sense to have man pages for specific laptops (instead
>> of the "FreeBSD Laptop" page, blogs on the internet and Wiki pages).
>>
>> Just thinking that after this change, people will need to know the
>> correct addresses for device.hints to make isl and cyapa work, and
>> putting things like that (and other hints, e.g. to route the Intel HDA
>> correctly) into a man page ("apropos c720") would be the next best
>> thing to having it work out of the box.
>
> Good idea. The problem with such an approach is, that new laptops get
> only inserted into man pages when some maintainer/approver does so and
> seldom if someone brings a new device to working (more or less) with
> FreeBSD.
>
> In the past (some 15 years ago) there was a database and a web frotnend
> where people (everyone) could insert/update a new working device. It was
> here: http://laptop.bsdgroup.de/freebsd/ but the site is offline for
> many year. I even tried and contacted the provide of 'bsdgroup.de' to
> get a copy of the database, w/o any luck.

There seems to be enough information present in the smbios data to
know what devices are at what addresses. Perhaps we should use it as
much as possible in well controlled situations to move this knowledge
into the OS.

Now, where did I put the power supply to my chromebook...

Warner

[Andriy Gapon]

On 09/10/2016 23:22, Warner Losh wrote:
> There seems to be enough information present in the smbios data to
> know what devices are at what addresses. Perhaps we should use it as
> much as possible in well controlled situations to move this knowledge
> into the OS.

So, I was thinking about maybe doing something like this to preserve the status
quo, to avoid requiring manual hints and to lay a foundation for the proper
Chromebook I2C slave discovery:


static struct {
uint32_t ctlrid,
const char *name;
uint_t addr;
} slaves[] = {
{ 0x9c628086, "isl", 0x88 },
{ 0x9c628086, "cyapa", 0xce },
}

static void
chromebook_i2c_identify(driver_t *driver, device_t bus)
{
device_t controller;
device_t child;
int i;

/*
* A stop gap approach to preserve the status quo.
* A more intelligent approach is required to correctly
* identify a machine model and hadrdware available on it.
* For instance, DMI could be used.
* See
http://lxr.free-electrons.com/source/drivers/platform/chrome/chromeos_laptop.c
*/
controller = device_get_parent(bus);
if (strcmp(device_get_name(controller), "ig4iic") != 0)
return;

for (i = 0; i < nitems(slaves); i++) {
if (device_find_child(bus, slave->name, -1) != NULL)
continue;
if (slave->ctlrid != pci_get_devid(controller))
continue;
child = BUS_ADD_CHILD(bus, 0, slave->name, -1);
if (child != NULL)
iicbus_set_addr(child, slave->addr);
}
}

static device_method_t chromebook_i2c_methods[] = {
DEVMETHOD(device_identify, chromebook_i2c_identify),
{ 0, 0 }
};

static driver_t chromebook_i2c_driver = {
"chromebook_i2c",
chromebook_i2c_methods,
0 /* no softc */
};

static devclass_t chromebook_i2c_devclass;

DRIVER_MODULE(chromebook_i2c, iicbus, chromebook_i2c_driver,
chromebook_i2c_devclass, 0, 0);
MODULE_DEPEND(chromebook_i2c, iicbus, IICBUS_MINVER, IICBUS_PREFVER,
IICBUS_MAXVER);
MODULE_VERSION(chromebook_i2c, 1);

The idea is that this is a driver that listens for new iicbus-es and adds isl
and cyapa devices to a bus if some criteria are met.

--
Andriy Gapon

[Michael Gmelin]

For the Acer c720, these criteria would be:

smbios.bios.vendor=="coreboot"
smbios.system.maker=="Acer"
smbios.system.product=="Peppy"

See also

boot/i386/libi386/biosmem.c
dev/atkbdc/atkbdc.c

- Michael

--
Michael Gmelin

[Warner Losh]

I see no reason not to start the table right away based on
smbios.sys.product and other criteria. I don't think we need all the
matches that Linux uses, but we can expand the table if we find it so.
Why have a stop gap that's a table that we kludge together when the
real table is of comparable difficulty and wouldn't need to be
reworked.

Warner

[Andriy Gapon]

On 10/10/2016 18:26, Warner Losh wrote:
> I see no reason not to start the table right away based on
> smbios.sys.product and other criteria. I don't think we need all the
> matches that Linux uses, but we can expand the table if we find it so.
> Why have a stop gap that's a table that we kludge together when the
> real table is of comparable difficulty and wouldn't need to be
> reworked.

One simple reason for me personally. I do not have the hardware and I am not
particularly interested in it. I am interested only in cleaning up the smbus
interface and moving ig4iic to iicbus. I want to get done with that as quickly
as possible and my goal is just that the result is not worse than the current code.
I am sure that people who are more interested than me can make the code much better.

> On Mon, Oct 10, 2016 at 5:46 AM, Michael Gmelin <gre...@freebsd.org> wrote:
>> On Mon, 10 Oct 2016 14:35:22 +0300
>> Andriy Gapon <a...@FreeBSD.org> wrote:
>>
>>> On 09/10/2016 23:22, Warner Losh wrote:
>>>> There seems to be enough information present in the smbios data to
>>>> know what devices are at what addresses. Perhaps we should use it as
>>>> much as possible in well controlled situations to move this
>>>> knowledge into the OS.
>>>
>>> So, I was thinking about maybe doing something like this to preserve
>>> the status quo, to avoid requiring manual hints and to lay a
>>> foundation for the proper Chromebook I2C slave discovery:
>>>

[snip]


--
Andriy Gapon

[Matthias Apitz]

El día Monday, October 10, 2016 a las 09:26:26AM -0600, Warner Losh escribió:

> I see no reason not to start the table right away based on
> smbios.sys.product and other criteria. I don't think we need all the
> matches that Linux uses, but we can expand the table if we find it so.
> Why have a stop gap that's a table that we kludge together when the
> real table is of comparable difficulty and wouldn't need to be
> reworked.

Please let us together concentrate on getting other i2c devices working,
like the Elan TouchPad, because I fear that newer Chromebooks are all
equipped with this and not with the Cyapa anymore.

matthias

--
Matthias Apitz, ✉ gu...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045
Einheitsfeier? Nein, danke! Kann ich bitte mein Land wiederhaben und am 7. Oktober feiern.

[Michael Gmelin]

> On 10 Oct 2016, at 20:27, Matthias Apitz <gu...@unixarea.de> wrote:
>
>> El día Monday, October 10, 2016 a las 09:26:26AM -0600, Warner Losh escribió:
>>
>> I see no reason not to start the table right away based on
>> smbios.sys.product and other criteria. I don't think we need all the
>> matches that Linux uses, but we can expand the table if we find it so.
>> Why have a stop gap that's a table that we kludge together when the
>> real table is of comparable difficulty and wouldn't need to be
>> reworked.
>
> Please let us together concentrate on getting other i2c devices working,
> like the Elan TouchPad, because I fear that newer Chromebooks are all
> equipped with this and not with the Cyapa anymore.
>

I see three tasks here:
- Andriy finishes his change, moving things from smbus to iicbus, adding some workaround to keep the user experience like it is
- Someone else implements the device table mechanism for auto detection
- Someone else ports HDI over I2C to allow implementing drivers for devices like the elan touchpad Matthias is referring to

Makes sense?

-m

[Andriy Gapon]

On 10/10/2016 21:45, Michael Gmelin wrote:
> I see three tasks here: - Andriy finishes his change, moving things from
> smbus to iicbus, adding some workaround to keep the user experience like it
> is - Someone else implements the device table mechanism for auto detection -
> Someone else ports HDI over I2C to allow implementing drivers for devices
> like the elan touchpad Matthias is referring to
>
> Makes sense?

It does to me.
Also, I can suggest another task related to SMBus / I2C.

Looking at the code in the Linux chromeos_laptop driver I see that on some
models some sensors are actually attached to SMBus rather that to I2C. And, for
example, cyapa can be attached to either bus. But there is a quirk. cyapa
won't work over a standard SMBus, it needs some extensions that are typically
provided by Intel chipsets. I specifically mean the so called "I2C Block Read"
and the transaction that results from the Block Write command when the I2C bit
is set in the SMBus controller's configuration register. Neither of these modes
is supported by our ichsmb(4) driver. But on Linux they are both supported and
exposed as I2C_SMBUS_I2C_BLOCK_DATA transaction type.

For one reference please see Mobile 4th Generation Intel® CoreTM
Processor Family I/O Datasheet, section 5.21.1.1.
And, just in case, ig4(4) is about the controllers described in section 5.22 of
that document.

Perhaps, I2C_SMBUS_I2C_BLOCK_DATA served as an inspiration (and perhaps a source
of confusion) for Matt when he added smbus_trans().

Right now I do not have any good suggestion on how to expose that 90% SMBus, 10%
I2C functionality in the FreeBSD model.

--
Andriy Gapon

[Warner Losh]

On Mon, Oct 10, 2016 at 12:45 PM, Michael Gmelin <gre...@freebsd.org> wrote:
>
>
>> On 10 Oct 2016, at 20:27, Matthias Apitz <gu...@unixarea.de> wrote:
>>
>>> El día Monday, October 10, 2016 a las 09:26:26AM -0600, Warner Losh escribió:
>>>
>>> I see no reason not to start the table right away based on
>>> smbios.sys.product and other criteria. I don't think we need all the
>>> matches that Linux uses, but we can expand the table if we find it so.
>>> Why have a stop gap that's a table that we kludge together when the
>>> real table is of comparable difficulty and wouldn't need to be
>>> reworked.
>>
>> Please let us together concentrate on getting other i2c devices working,
>> like the Elan TouchPad, because I fear that newer Chromebooks are all
>> equipped with this and not with the Cyapa anymore.
>>
>
> I see three tasks here:
> - Andriy finishes his change, moving things from smbus to iicbus, adding some workaround to keep the user experience like it is
> - Someone else implements the device table mechanism for auto detection
> - Someone else ports HDI over I2C to allow implementing drivers for devices like the elan touchpad Matthias is referring to

I think I can do the device table mechanism if Andriy isn't up for it.

Warner

[Andriy Gapon]

On 12/10/2016 07:03, Warner Losh wrote:
> I think I can do the device table mechanism if Andriy isn't up for it.

That would be great, thank you!

--
Andriy Gapon

[Andriy Gapon]

On 12/10/2016 09:21, Andriy Gapon wrote:
> On 12/10/2016 07:03, Warner Losh wrote:
>> I think I can do the device table mechanism if Andriy isn't up for it.
>
> That would be great, thank you!
>

Meanwhile, I've added a "stop-gap" version of 'chromebook_platform' driver here:
https://reviews.freebsd.org/D8172
A full patch can be downloaded from the review request.

Could you please test if it works?

All hints should be removed and the new module should be loaded in addition to
other modules. It should not matter in which order the modules are loaded.
Could you please test if loading chromebook_platform before and after isl and
cyapa works the same?
It's required to either reboot or reload iicbus between the tests, so that
previously added devices are not re-used.

Thanks!

P.S.
Not sure if the name is good, it's certainly verbose.