Hi Ian,
>>> One oddity I've spotted is that the chip tries to go back to 115200 baud
>>> after loading its firmware patch, which messes up the change to
>>> oper_speed. I've worked around this by not using the set_baudrate hook,
>>> just setting the operating speed after firmware loading in setup.
>>
>> I assume we addressed that in hci_uart. If not then we need to handle that there first.
>
>
> In hci_uart_setup() in hci_serdev.c, there is the following:
>
>
> if (hu->init_speed)
> speed = hu->init_speed;
> else if (hu->proto->init_speed)
> speed = hu->proto->init_speed;
> else
> speed = 0;
>
> if (speed)
> serdev_device_set_baudrate(hu->serdev, speed);
>
> /* Operational speed if any */
> if (hu->oper_speed)
> speed = hu->oper_speed;
> else if (hu->proto->oper_speed)
> speed = hu->proto->oper_speed;
> else
> speed = 0;
>
> if (hu->proto->set_baudrate && speed) {
> err = hu->proto->set_baudrate(hu, speed);
> if (err)
> BT_ERR("%s: failed to set baudrate", hdev->name);
> else
> serdev_device_set_baudrate(hu->serdev, speed);
> }
>
> if (hu->proto->setup)
> return hu->proto->setup(hu);
>
>
> The problem is that it attempts to set the baudrate to oper_speed
> *prior* to calling the driver's setup() hook.
>
> It *seems* simple enough that we could move the setup call to prior to
> the change to oper_speed, but I am unsure how this might affect other
> drivers.
>
> I can test this on my driver (and implement the set_baudrate command
> properly as a result.
>
> I can send a patch to this effect if you want?
the hci_bcm.c on ACPI based Baytrail platforms is capable of dealing with this. What is different here?
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
