Hi Ingo,
On 01/26/2017 03:22 PM, Ingo Molnar wrote:
> * Lu Baolu wrote:
>
>> Hi,
>>
>> On 01/25/2017 10:38 PM, Peter Zijlstra wrote:
>>> On Wed, Jan 25, 2017 at 08:27:38PM +0800, Lu Baolu wrote:
In my driver, udelay() is mostly used to handle time out.
Xdbc hides most USB things in
Hi Ingo,
On 01/26/2017 03:19 PM, Ingo Molnar wrote:
> * Lu Baolu wrote:
>
>> Fair enough.
>>
>> USB connection is stable enough, unless the user unplugs the
>> USB cable during debugging.
> What does the hardware do in this case? The XHCI registers are in the host
> hardware, so they won't disap
* Peter Zijlstra wrote:
> On Thu, Jan 26, 2017 at 05:01:05PM +0100, Ingo Molnar wrote:
> > > >
> > > > I.e. if there's any polling component then it would be reasonable to
> > > > add an error
> > > > component: poll the status and if it goes 'disconnected' then disable
> > > > early-printk
On Thu, Jan 26, 2017 at 05:01:05PM +0100, Ingo Molnar wrote:
> > >
> > > I.e. if there's any polling component then it would be reasonable to add
> > > an error
> > > component: poll the status and if it goes 'disconnected' then disable
> > > early-printk
> > > altogether in this case and trig
* Peter Zijlstra wrote:
> On Thu, Jan 26, 2017 at 08:19:37AM +0100, Ingo Molnar wrote:
> >
> > * Lu Baolu wrote:
> >
> > > Fair enough.
> > >
> > > USB connection is stable enough, unless the user unplugs the
> > > USB cable during debugging.
> >
> > What does the hardware do in this case?
On Thu, Jan 26, 2017 at 08:19:37AM +0100, Ingo Molnar wrote:
>
> * Lu Baolu wrote:
>
> > Fair enough.
> >
> > USB connection is stable enough, unless the user unplugs the
> > USB cable during debugging.
>
> What does the hardware do in this case? The XHCI registers are in the host
> hardware,
* Lu Baolu wrote:
> Hi Ingo,
>
> On 01/26/2017 03:19 PM, Ingo Molnar wrote:
> > * Lu Baolu wrote:
> >
> >> Fair enough.
> >>
> >> USB connection is stable enough, unless the user unplugs the
> >> USB cable during debugging.
> > What does the hardware do in this case? The XHCI registers are in
Hi Ingo,
On 01/26/2017 03:19 PM, Ingo Molnar wrote:
> * Lu Baolu wrote:
>
>> Fair enough.
>>
>> USB connection is stable enough, unless the user unplugs the
>> USB cable during debugging.
> What does the hardware do in this case? The XHCI registers are in the host
> hardware, so they won't disap
* Lu Baolu wrote:
>
> Hi,
>
> On 01/25/2017 10:38 PM, Peter Zijlstra wrote:
> > On Wed, Jan 25, 2017 at 08:27:38PM +0800, Lu Baolu wrote:
> >> In my driver, udelay() is mostly used to handle time out.
> >>
> >> Xdbc hides most USB things in its firmware. Early printk driver only needs
> >> to
* Lu Baolu wrote:
> Fair enough.
>
> USB connection is stable enough, unless the user unplugs the
> USB cable during debugging.
What does the hardware do in this case? The XHCI registers are in the host
hardware, so they won't disappear, right? Is there some cable connection status
bit we ca
Hi,
On 01/26/2017 12:16 AM, Peter Zijlstra wrote:
> On Wed, Jan 25, 2017 at 11:51:34PM +0800, Lu Baolu wrote:
>
>>> What is timeout and why?
>> Put it in simple:
>>
>> The driver sets the RUN bit in control register and polls READY
>> bit in status register for the successful USB device enumeratio
Hi Ingo,
On 01/25/2017 05:23 PM, Ingo Molnar wrote:
> * Lu Baolu wrote:
>
>>> Hiding essentially an early udelay() implementation in an early-printk
>>> driver is
>>> ugly and counterproductive.
>> Sure. How about below change?
>>
>> diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early
On Wed, Jan 25, 2017 at 11:51:34PM +0800, Lu Baolu wrote:
> > What is timeout and why?
>
> Put it in simple:
>
> The driver sets the RUN bit in control register and polls READY
> bit in status register for the successful USB device enumeration.
> As the USB device enumeration might fail and the
Hi,
On 01/25/2017 10:38 PM, Peter Zijlstra wrote:
> On Wed, Jan 25, 2017 at 08:27:38PM +0800, Lu Baolu wrote:
>> In my driver, udelay() is mostly used to handle time out.
>>
>> Xdbc hides most USB things in its firmware. Early printk driver only needs
>> to setup the registers/data structures and
On Wed, Jan 25, 2017 at 08:27:38PM +0800, Lu Baolu wrote:
> In my driver, udelay() is mostly used to handle time out.
>
> Xdbc hides most USB things in its firmware. Early printk driver only needs
> to setup the registers/data structures and wait until link ready or time out.
> Without udelay(), I
Hi,
On 01/25/2017 05:57 PM, Peter Zijlstra wrote:
> On Wed, Jan 25, 2017 at 10:23:55AM +0100, Ingo Molnar wrote:
>> * Lu Baolu wrote:
>>
Hiding essentially an early udelay() implementation in an early-printk
driver is
ugly and counterproductive.
>> Yeah - so could we do this in a
Hi,
On 01/25/2017 05:23 PM, Ingo Molnar wrote:
> * Lu Baolu wrote:
>
>>> Hiding essentially an early udelay() implementation in an early-printk
>>> driver is
>>> ugly and counterproductive.
>> Sure. How about below change?
>>
>> diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci
On Wed, Jan 25, 2017 at 10:23:55AM +0100, Ingo Molnar wrote:
>
> * Lu Baolu wrote:
>
> > > Hiding essentially an early udelay() implementation in an early-printk
> > > driver is
> > > ugly and counterproductive.
> Yeah - so could we do this in a more generic fashion, not in the early-printk
* Lu Baolu wrote:
> > Hiding essentially an early udelay() implementation in an early-printk
> > driver is
> > ugly and counterproductive.
>
> Sure. How about below change?
>
> diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
> index d3f0c84..940989e 100644
> --- a/dr
Hi Ingo,
On 01/24/2017 04:20 PM, Ingo Molnar wrote:
> * Lu Baolu wrote:
>
>> Hi Ingo,
>>
>> On 01/22/2017 05:04 PM, Ingo Molnar wrote:
>>> * Lu Baolu wrote:
>>>
>> +static void xdbc_runtime_delay(unsigned long count)
>> +{
>> +udelay(count);
>> +}
>> +static void (*xd
* Lu Baolu wrote:
> Hi Ingo,
>
> On 01/22/2017 05:04 PM, Ingo Molnar wrote:
> > * Lu Baolu wrote:
> >
> +static void xdbc_runtime_delay(unsigned long count)
> +{
> +udelay(count);
> +}
> +static void (*xdbc_delay)(unsigned long) = xdbc_early_delay;
> >>> Is thi
Hi Ingo,
On 01/22/2017 05:04 PM, Ingo Molnar wrote:
> * Lu Baolu wrote:
>
+static void xdbc_runtime_delay(unsigned long count)
+{
+ udelay(count);
+}
+static void (*xdbc_delay)(unsigned long) = xdbc_early_delay;
>>> Is this udelay() complication really necessary? udelay(
* Lu Baolu wrote:
> >
> >> +static void xdbc_runtime_delay(unsigned long count)
> >> +{
> >> + udelay(count);
> >> +}
> >> +static void (*xdbc_delay)(unsigned long) = xdbc_early_delay;
> > Is this udelay() complication really necessary? udelay() should work fine
> > even in
> > early code. It
Hi Ingo,
I'm very appreciated for your review comments. I've put my
replies in lines.
On 01/19/2017 05:37 PM, Ingo Molnar wrote:
> * Lu Baolu wrote:
>
>> xHCI debug capability (DbC) is an optional but standalone
>> functionality provided by an xHCI host controller. Software
>> learns this capabi
* Lu Baolu wrote:
> xHCI debug capability (DbC) is an optional but standalone
> functionality provided by an xHCI host controller. Software
> learns this capability by walking through the extended
> capability list of the host. xHCI specification describes
> DbC in section 7.6.
>
> This patch i
xHCI debug capability (DbC) is an optional but standalone
functionality provided by an xHCI host controller. Software
learns this capability by walking through the extended
capability list of the host. xHCI specification describes
DbC in section 7.6.
This patch introduces the code to probe and ini
26 matches
Mail list logo
