Hi,
On 22-01-18 20:57, Marcel Holtmann wrote:
Hi Hans,
Andy, I see that you added support for bcm bluetooth over a tty
using
platform_data instead of ACPI enumeration. Can you change the code
instantiating the device to instead instantiate a serdev, so that
we
kill the platform device support in hci_bcm.c and so that users
don't
need to do a btattach, but instead the kernel will do the attach
itself
and things will just work ?
I'm sorry, I can't do this soon, other more priority tasks in a
pocket.
The instantiation of the driver is happened in
arch/x86/platform/intel-
mid/device_libs/platform_bt.c
I would help with review of any patches till I would able to look at
it
myself.
If I manage to come up with patches do you have hardware and time to
test?
Yes and I would find half an hour for sure.
That is great, thank you, but ...
First point of order to get this working as serdev I think is to
modify drivers/tty/serdev/core.c a and then the
serdev_controller_add()
function to somehow recognize the serial port in question, so
something akin to the of_serdev_register_devices(ctrl) /
acpi_serdev_register_devices(ctrl) functions for platform_devs,
assuming
the tty-parent-dev on the Edison SOM is a platform_dev ?
tty parent is PCI device there.
Anyways it looks like this will be really hard to do without access
to the hardware.
I can do a BAT.
Right, sorry I was not clear, when I was talking about hardware
access I was not (not only) referring to testing.
The problem is that to figure out how to hook all this together
will require poking around on the hardware, looking in sysfs, finding
some id we can use in a pci_serdev_register_devices() to add to
drivers/tty/serdev/core.c so that it only turns the serial port on
the Edison into a serdev and not somewhere else, etc.
But thinking about this more, I too have higher priority items on
my TODO list, so as much as I would like to see this cleaned up,
lets shelf this for now until you have time to look into this.
When you do find time, if you've any questions I'm happy to help.
so the serial port is driven by drivers/tty/serial/8250/8250_mid.c and using PCI_DEVICE_ID_INTEL_TNG_UART 0x1191 to match the driver. So it is exposed as PCI device. While of course more than one UART port uses 0x1191. This one seems to be mapped to pci_get_domain_bus_and_slot(0, 0, PCI_DEVFN(4, 1)) actually.
What I think is that we need to do is some sort of x86_match_cpu like arch/x86/platform/intel-mid/device_libs/platform_bt.c does. But then again, that is also what the Apple Broadcom support does to choose the different ACPI procedures.
I have an Edison board on my desk and can quickly boot any patch you want me to test. Or grab data from sysfs or dmesg.
I'm sorry, I started looking at removing the platform code because
I already spend a lot of time looking at the hci_bcm code to make
the power-management work with serdev devices instantiated from
ACPI, when writing the patch-set for that I added removing the
remaining cruft to my todo list...
But I don't have time / don't want to make time given other priorities
to also look into the Edison stuff, which seems non-trivial to fix.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
