[MinnowBoard] Board file

Darren Hart dvhart at linux.intel.com
Wed May 11 17:25:37 UTC 2016



On 5/11/16 9:44 AM, Tony Makkiel wrote:
> 
> 
> 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 I2C bus (if ACPI enumerated) will be handled by the i2c bus driver,
you can't reuse it for the leaf-node device.

> 
> 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.

You would need to add an ACPI device to the DSDT with either a new ACPI
HID, or using the PRP0001 ID with the "compatible" DSD property with the
value matching that of the driver to be matched, and populate the DSD
with the required properties. This will work with drivers already using
the device_properties API, but those are being converted one at a time
from a pure OF interface.

> 
>>>> 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
>>> elinux-MinnowBoard at lists.elinux.org
>>> http://lists.elinux.org/mailman/listinfo/elinux-minnowboard
>>
> _______________________________________________
> elinux-MinnowBoard mailing list
> elinux-MinnowBoard at lists.elinux.org
> http://lists.elinux.org/mailman/listinfo/elinux-minnowboard

-- 
Darren Hart
Intel Open Source Technology Center


More information about the elinux-MinnowBoard mailing list