On 10/05/16 17:28, Darren Hart wrote:
On 5/10/16 9:21 AM, Tony Makkiel wrote:
On 10/05/16 16:03, Darren Hart wrote:
On 5/10/16 5:39 AM, Tony Makkiel wrote:
Hi,
Where can I find minnowboard board files? According to
http://events.linuxfoundation.org/sites/events/files/slides/x86-platform.pdf
they should be at
drivers/platform/x85/minnowboard* .
Well.... that wasn't quite the point of that presentation :-) If you
haven't watched the video that goes with it, I'd recommend doing that.
I found the link from Google. Did not know there was a video file. Do
you have a link for it please?
https://www.youtube.com/watch?v=IZuNCN7wkqs
Thank you. That is a good presentation.
Ultimately, the Minnowboard v1 patches were not accepted to the mainline
Linux kernel because they were board files, and the proper solution is
to provide the platform information via the firmware. We have been
working on the ACPI specification to enable this feature (see ACPI _DSD
which was added for this purpose), and are still working on a standard
mechanism to provide user-created ACPI DSDT overlays. That work is not
yet complete.
What is the name used by firmware in minnowboard? Probably , I can use
the same name for my driver in ACPI initialization to verify probe works.
Sorry, I don't understand the question. Name for what?
I am not sure whether I understand ACPI correctly. But I am assuming
based on https://www.kernel.org/doc/Documentation/acpi/enumeration.txt,
ACPI tries to match "__u8 id[ACPI_ID_LEN];" to probe the appropriate
driver (Eg: "MPU3050" in section I2C serial bus support of the document,
Or "MNW0003" in the presentation page 30). So it should be matching the
string with what it gets from the firmware's ACPI table. So if I put the
same string in the driver, as that used by firmware for i2c id 0, I am
hoping it should call the probe.
I know it is not ideal. But atleast I can verify the probe will work on
hosts, with the appropriate ACPI data.
The method of adding the name in acpi_platform_device_ids
(drivers/acpi/acpi_platform.c) would have been ideal, the file does not
have the acpi_device_id structure anymore.
There are some workarounds in place, perhaps John H. can comment on the
current state of those.
I am on kernel 4.5 and cant see any similar files. I am writing an
i2c driver using minnowboard as host. But not sure where to register the
device so that the device driver gets probed. I would prefer ACPI. But I
think I would need to modify the firmware to do that (Do I? If I have to
access to firmware might be a problem).
At present, I am using i2c_new_device within the driver
module_init.
But am not sure what the proper way to do it is?
I suggest having a look at the example i2c driver in the minnowboard
extras repository.
https://github.com/MinnowBoard/minnow-max-extras/tree/master/modules/i2c
The example also use i2c_new_device. But the problem is, it assumes the
driver know the i2c id (i2c_get_adapter(0)). I want the driver to be
generic, so that if I use it on another platform with a different bus
id, it still gets probed.
Right, and what you describe is the right way to do it, but does require
you do one of the following:
1) Rebuild the firmware with your updated ACPI tables.
2) Use one of the workarounds mentioned above
3) Wholesale replace the DSDT per the Linux kernel development initramfs
mechanism
1-3 likely also require you to update some of the drivers to understand
that description, or use the new "device_properties" Linux kernel interface.
This is for the MinnowBoard MAX and Turbot boards, not the MinnowBoard
v1, but conceptually it applies equally.
_______________________________________________
elinux-MinnowBoard mailing list
[email protected]
http://lists.elinux.org/mailman/listinfo/elinux-minnowboard
_______________________________________________
elinux-MinnowBoard mailing list
[email protected]
http://lists.elinux.org/mailman/listinfo/elinux-minnowboard
