Hi,
On Fri, Dec 12, 2014 at 01:14:53PM +0100, Pavel Machek wrote:
> > > I have created provisional device tree binding, and the driver still
> > > works.
> >
> > I don't have time to look at the code now, but I have some comments
> > regarding the binding.
>
> > >
> > > &uart2 {
> > > +
Hi Pavel,
>> What needs to be done is the bring up of the device including the proper
>> UART settings and speed and then just run the firmware downloads. All
>> firmware files on the Nokia devices where just HCI commands with vendor
>> specific details. Some from CSR, some from
Hi!
> > I have created provisional device tree binding, and the driver still
> > works.
>
> I don't have time to look at the code now, but I have some comments
> regarding the binding.
> >
> > &uart2 {
> > +compatible = "brcm,uart,bcm2048";
>
> This does not look correct. The uart s
Hi!
> What needs to be done is the bring up of the device including the proper
> UART settings and speed and then just run the firmware downloads. All
> firmware files on the Nokia devices where just HCI commands with vendor
> specific details. Some from CSR, some from Broad
Hi,
On Thu, Dec 11, 2014 at 11:13:07PM +0100, Pavel Machek wrote:
> Hi!
>
> > > h4p changes uart speed again after load of the firmware, but I guess
> > > that's ok.
>
> > if you can do it the other way around it would result in a faster
> > init. Depending on how many patches are actually requ
Hi Pavel,
>>> h4p changes uart speed again after load of the firmware, but I guess
>>> that's ok.
>
>> if you can do it the other way around it would result in a faster
>> init. Depending on how many patches are actually required to be
>> loaded.
>
> IIRC driver does two speed changes, so it loo
Hi!
> > h4p changes uart speed again after load of the firmware, but I guess
> > that's ok.
> if you can do it the other way around it would result in a faster
> init. Depending on how many patches are actually required to be
> loaded.
IIRC driver does two speed changes, so it looks to me like
Hi Pavel,
>>> The TODO file says:
>>>
>>> # > +
>>> # > + skb_queue_tail(&info->txq, fw_skb);
>>> # > + spin_lock_irqsave(&info->lock, flags);
>>> # > + hci_h4p_outb(info, UART_IER, hci_h4p_inb(info, UART_IER) |
>>> # > + UART_IER_THRI);
>>> # > + spin_unlock_i
Hi!
> > The TODO file says:
> >
> > # > +
> > # > + skb_queue_tail(&info->txq, fw_skb);
> > # > + spin_lock_irqsave(&info->lock, flags);
> > # > + hci_h4p_outb(info, UART_IER, hci_h4p_inb(info, UART_IER) |
> > # > + UART_IER_THRI);
> > # > + spin_unlock_irqrest
Hi Pavel,
>>> Major problem with Nokia H4P driver was, that it uses custom functions
>>> instead of __hci_cmd_sync().
>
>> the __hci_cmd_sync is for sending HCI commands and not low-level
>> protocol transports like H:4 or similar. So you want to separate the
>> actual transport of HCI from the f
Hi!
> > Major problem with Nokia H4P driver was, that it uses custom functions
> > instead of __hci_cmd_sync().
> the __hci_cmd_sync is for sending HCI commands and not low-level
> protocol transports like H:4 or similar. So you want to separate the
> actual transport of HCI from the firmware lo
Hi Pavel,
> Major problem with Nokia H4P driver was, that it uses custom functions
> instead of __hci_cmd_sync().
the __hci_cmd_sync is for sending HCI commands and not low-level protocol
transports like H:4 or similar. So you want to separate the actual transport of
HCI from the firmware loadi
12 matches
Mail list logo
