Hi to all,
Às 10:38 AM de 7/4/2017, Ard Biesheuvel escreveu:
> On 4 July 2017 at 09:19, Jisheng Zhang wrote:
>> On Tue, 4 Jul 2017 09:02:06 +0100 Ard Biesheuvel wrote:
>>
>>> On 4 July 2017 at 07:58, Jisheng Zhang wrote:
On Mon, 3 Jul 2017 08:27:04
Hi to all,
Às 10:38 AM de 7/4/2017, Ard Biesheuvel escreveu:
> On 4 July 2017 at 09:19, Jisheng Zhang wrote:
>> On Tue, 4 Jul 2017 09:02:06 +0100 Ard Biesheuvel wrote:
>>
>>> On 4 July 2017 at 07:58, Jisheng Zhang wrote:
On Mon, 3 Jul 2017 08:27:04 -0500 wrote:
> [+cc Jingoo,
On Wed, Jul 05, 2017 at 01:59:55AM +0200, Mason wrote:
> Do larger SoC vendors have HW devs working closely with
> Linux devs, to avoid these design bloopers?
Yes, or just internal software teams in general - hardware designs tend
to be a lot more usable if there's good dialogue with users about
On Wed, Jul 05, 2017 at 01:59:55AM +0200, Mason wrote:
> Do larger SoC vendors have HW devs working closely with
> Linux devs, to avoid these design bloopers?
Yes, or just internal software teams in general - hardware designs tend
to be a lot more usable if there's good dialogue with users about
On Wed, Jul 05, 2017 at 01:59:55AM +0200, Mason wrote:
> Do larger SoC vendors have HW devs working closely with
> Linux devs, to avoid these design bloopers?
Yes they generally do, as they have learned from their prior mistakes :)
good luck!
greg k-h
On Wed, Jul 05, 2017 at 01:59:55AM +0200, Mason wrote:
> Do larger SoC vendors have HW devs working closely with
> Linux devs, to avoid these design bloopers?
Yes they generally do, as they have learned from their prior mistakes :)
good luck!
greg k-h
On 03/07/2017 20:11, Russell King - ARM Linux wrote:
> I don't think there's an easy solution to this problem - and I'm not
> sure that stop_machine() can be made to work in this path (which
> needs a process context). I have a suspicion that the Sigma Designs
> PCI implementation is just soo
On 03/07/2017 20:11, Russell King - ARM Linux wrote:
> I don't think there's an easy solution to this problem - and I'm not
> sure that stop_machine() can be made to work in this path (which
> needs a process context). I have a suspicion that the Sigma Designs
> PCI implementation is just soo
On 04/07/2017 17:58, Bjorn Helgaas wrote:
> It's definitely a hassle to support chips with different register
> layouts. Your hardware guys are really making your life hard :)
Now where did I put my foam bat...
> If the chips are fundamentally different, i.e., if they *operate*
> differently
On 04/07/2017 17:58, Bjorn Helgaas wrote:
> It's definitely a hassle to support chips with different register
> layouts. Your hardware guys are really making your life hard :)
Now where did I put my foam bat...
> If the chips are fundamentally different, i.e., if they *operate*
> differently
On Tue, Jul 04, 2017 at 10:15:02AM -0500, Bjorn Helgaas wrote:
> On Mon, Jul 03, 2017 at 07:11:28PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Jul 03, 2017 at 08:40:31AM -0500, Bjorn Helgaas wrote:
> > > The problem is serializing vs. memory accesses, since they don't use
> > > any
On Tue, Jul 04, 2017 at 10:15:02AM -0500, Bjorn Helgaas wrote:
> On Mon, Jul 03, 2017 at 07:11:28PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Jul 03, 2017 at 08:40:31AM -0500, Bjorn Helgaas wrote:
> > > The problem is serializing vs. memory accesses, since they don't use
> > > any
On Mon, Jul 03, 2017 at 04:34:29PM +0200, Marc Gonzalez wrote:
> Bjorn Helgaas wrote:
>
> > Marc Gonzalez wrote:
> >
> >> On 03/07/2017 01:18, Bjorn Helgaas wrote:
> >>
> >>> On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez wrote:
> >>>
> +static int tango_check_pcie_link(void __iomem
On Mon, Jul 03, 2017 at 04:34:29PM +0200, Marc Gonzalez wrote:
> Bjorn Helgaas wrote:
>
> > Marc Gonzalez wrote:
> >
> >> On 03/07/2017 01:18, Bjorn Helgaas wrote:
> >>
> >>> On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez wrote:
> >>>
> +static int tango_check_pcie_link(void __iomem
On 04/07/2017 16:27, Peter Zijlstra wrote:
> Mason wrote:
>
>> if (IS_ENABLED(CONFIG_DEBUG_PREEMPT) && in_atomic_preempt_off()) {
>> pr_err("Preemption disabled at:");
>> print_ip_sym(preempt_disable_ip);
>> pr_cont("\n");
>> }
>>
>> BTW, why
On 04/07/2017 16:27, Peter Zijlstra wrote:
> Mason wrote:
>
>> if (IS_ENABLED(CONFIG_DEBUG_PREEMPT) && in_atomic_preempt_off()) {
>> pr_err("Preemption disabled at:");
>> print_ip_sym(preempt_disable_ip);
>> pr_cont("\n");
>> }
>>
>> BTW, why
On Mon, Jul 03, 2017 at 07:11:28PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 03, 2017 at 08:40:31AM -0500, Bjorn Helgaas wrote:
> > The problem is serializing vs. memory accesses, since they don't use
> > any wrappers. However, they are ioremapped(), so it's at least
> > conceivable
On Mon, Jul 03, 2017 at 07:11:28PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 03, 2017 at 08:40:31AM -0500, Bjorn Helgaas wrote:
> > The problem is serializing vs. memory accesses, since they don't use
> > any wrappers. However, they are ioremapped(), so it's at least
> > conceivable
On Tue, Jul 04, 2017 at 03:08:43PM +0200, Mason wrote:
> On 04/07/2017 09:09, Peter Zijlstra wrote:
>
> > On Mon, Jul 03, 2017 at 05:30:28PM +0200, Marc Gonzalez wrote:
> >
> >> And at the end of smp8759_config_read:
> >>
> >>printk("in_atomic_preempt_off = %d\n", in_atomic_preempt_off());
>
On Tue, Jul 04, 2017 at 03:08:43PM +0200, Mason wrote:
> On 04/07/2017 09:09, Peter Zijlstra wrote:
>
> > On Mon, Jul 03, 2017 at 05:30:28PM +0200, Marc Gonzalez wrote:
> >
> >> And at the end of smp8759_config_read:
> >>
> >>printk("in_atomic_preempt_off = %d\n", in_atomic_preempt_off());
>
On 04/07/2017 09:09, Peter Zijlstra wrote:
> On Mon, Jul 03, 2017 at 05:30:28PM +0200, Marc Gonzalez wrote:
>
>> And at the end of smp8759_config_read:
>>
>> printk("in_atomic_preempt_off = %d\n", in_atomic_preempt_off());
>
> That's confused...
That much is certain. I am indeed grasping
On 04/07/2017 09:09, Peter Zijlstra wrote:
> On Mon, Jul 03, 2017 at 05:30:28PM +0200, Marc Gonzalez wrote:
>
>> And at the end of smp8759_config_read:
>>
>> printk("in_atomic_preempt_off = %d\n", in_atomic_preempt_off());
>
> That's confused...
That much is certain. I am indeed grasping
On 4 July 2017 at 09:19, Jisheng Zhang wrote:
> On Tue, 4 Jul 2017 09:02:06 +0100 Ard Biesheuvel wrote:
>
>> On 4 July 2017 at 07:58, Jisheng Zhang wrote:
>> > On Mon, 3 Jul 2017 08:27:04 -0500 wrote:
>> >
>> >> [+cc Jingoo, Joao]
>> >>
>> >> On Mon, Jul
On 4 July 2017 at 09:19, Jisheng Zhang wrote:
> On Tue, 4 Jul 2017 09:02:06 +0100 Ard Biesheuvel wrote:
>
>> On 4 July 2017 at 07:58, Jisheng Zhang wrote:
>> > On Mon, 3 Jul 2017 08:27:04 -0500 wrote:
>> >
>> >> [+cc Jingoo, Joao]
>> >>
>> >> On Mon, Jul 03, 2017 at 10:35:50AM +0100, Ard
On Tue, 4 Jul 2017 09:02:06 +0100 Ard Biesheuvel wrote:
> On 4 July 2017 at 07:58, Jisheng Zhang wrote:
> > On Mon, 3 Jul 2017 08:27:04 -0500 wrote:
> >
> >> [+cc Jingoo, Joao]
> >>
> >> On Mon, Jul 03, 2017 at 10:35:50AM +0100, Ard Biesheuvel wrote:
> >> > On 3 July
On Tue, 4 Jul 2017 09:02:06 +0100 Ard Biesheuvel wrote:
> On 4 July 2017 at 07:58, Jisheng Zhang wrote:
> > On Mon, 3 Jul 2017 08:27:04 -0500 wrote:
> >
> >> [+cc Jingoo, Joao]
> >>
> >> On Mon, Jul 03, 2017 at 10:35:50AM +0100, Ard Biesheuvel wrote:
> >> > On 3 July 2017 at 00:18, Bjorn
On 4 July 2017 at 07:58, Jisheng Zhang wrote:
> On Mon, 3 Jul 2017 08:27:04 -0500 wrote:
>
>> [+cc Jingoo, Joao]
>>
>> On Mon, Jul 03, 2017 at 10:35:50AM +0100, Ard Biesheuvel wrote:
>> > On 3 July 2017 at 00:18, Bjorn Helgaas wrote:
>> > > On Tue, Jun
On 4 July 2017 at 07:58, Jisheng Zhang wrote:
> On Mon, 3 Jul 2017 08:27:04 -0500 wrote:
>
>> [+cc Jingoo, Joao]
>>
>> On Mon, Jul 03, 2017 at 10:35:50AM +0100, Ard Biesheuvel wrote:
>> > On 3 July 2017 at 00:18, Bjorn Helgaas wrote:
>> > > On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez
On Tue, 4 Jul 2017 14:58:40 +0800 Jisheng Zhang wrote:
> On Mon, 3 Jul 2017 08:27:04 -0500 wrote:
>
> > [+cc Jingoo, Joao]
> >
> > On Mon, Jul 03, 2017 at 10:35:50AM +0100, Ard Biesheuvel wrote:
> > > On 3 July 2017 at 00:18, Bjorn Helgaas wrote:
> > > > On Tue, Jun
On Tue, 4 Jul 2017 14:58:40 +0800 Jisheng Zhang wrote:
> On Mon, 3 Jul 2017 08:27:04 -0500 wrote:
>
> > [+cc Jingoo, Joao]
> >
> > On Mon, Jul 03, 2017 at 10:35:50AM +0100, Ard Biesheuvel wrote:
> > > On 3 July 2017 at 00:18, Bjorn Helgaas wrote:
> > > > On Tue, Jun 20, 2017 at
On Mon, Jul 03, 2017 at 05:30:28PM +0200, Marc Gonzalez wrote:
> And at the end of smp8759_config_read:
>
> printk("in_atomic_preempt_off = %d\n", in_atomic_preempt_off());
That's confused...
> stop_machine(do_nothing, NULL, NULL);
> panic("STOP HERE FOR NOW\n");
>
> The
On Mon, Jul 03, 2017 at 05:30:28PM +0200, Marc Gonzalez wrote:
> And at the end of smp8759_config_read:
>
> printk("in_atomic_preempt_off = %d\n", in_atomic_preempt_off());
That's confused...
> stop_machine(do_nothing, NULL, NULL);
> panic("STOP HERE FOR NOW\n");
>
> The
On Mon, 3 Jul 2017 08:27:04 -0500 wrote:
> [+cc Jingoo, Joao]
>
> On Mon, Jul 03, 2017 at 10:35:50AM +0100, Ard Biesheuvel wrote:
> > On 3 July 2017 at 00:18, Bjorn Helgaas wrote:
> > > On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez wrote:
> > >> This driver is
On Mon, 3 Jul 2017 08:27:04 -0500 wrote:
> [+cc Jingoo, Joao]
>
> On Mon, Jul 03, 2017 at 10:35:50AM +0100, Ard Biesheuvel wrote:
> > On 3 July 2017 at 00:18, Bjorn Helgaas wrote:
> > > On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez wrote:
> > >> This driver is required to work
On 3 July 2017 at 19:11, Russell King - ARM Linux wrote:
> On Mon, Jul 03, 2017 at 08:40:31AM -0500, Bjorn Helgaas wrote:
>> The problem is serializing vs. memory accesses, since they don't use
>> any wrappers. However, they are ioremapped(), so it's at least
>>
On 3 July 2017 at 19:11, Russell King - ARM Linux wrote:
> On Mon, Jul 03, 2017 at 08:40:31AM -0500, Bjorn Helgaas wrote:
>> The problem is serializing vs. memory accesses, since they don't use
>> any wrappers. However, they are ioremapped(), so it's at least
>> conceivable that another solution
On Mon, Jul 03, 2017 at 08:40:31AM -0500, Bjorn Helgaas wrote:
> The problem is serializing vs. memory accesses, since they don't use
> any wrappers. However, they are ioremapped(), so it's at least
> conceivable that another solution would be to use VM to trap those
> accesses. I'm not a VM
On Mon, Jul 03, 2017 at 08:40:31AM -0500, Bjorn Helgaas wrote:
> The problem is serializing vs. memory accesses, since they don't use
> any wrappers. However, they are ioremapped(), so it's at least
> conceivable that another solution would be to use VM to trap those
> accesses. I'm not a VM
On 03/07/2017 15:13, Marc Gonzalez wrote:
> On 03/07/2017 11:54, Marc Gonzalez wrote:
>
>> Mark Rutland points out stop_machine. I will test this solution.
>
> I must be misunderstanding some of the requirements for
> calling stop_machine() because my kernel panics, after
> many warnings.
On 03/07/2017 15:13, Marc Gonzalez wrote:
> On 03/07/2017 11:54, Marc Gonzalez wrote:
>
>> Mark Rutland points out stop_machine. I will test this solution.
>
> I must be misunderstanding some of the requirements for
> calling stop_machine() because my kernel panics, after
> many warnings.
Bjorn Helgaas wrote:
> Marc Gonzalez wrote:
>
>> On 03/07/2017 01:18, Bjorn Helgaas wrote:
>>
>>> On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez wrote:
>>>
+static int tango_check_pcie_link(void __iomem *test_out)
>>>
>>> I think this is checking for link up. Rename to
Bjorn Helgaas wrote:
> Marc Gonzalez wrote:
>
>> On 03/07/2017 01:18, Bjorn Helgaas wrote:
>>
>>> On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez wrote:
>>>
+static int tango_check_pcie_link(void __iomem *test_out)
>>>
>>> I think this is checking for link up. Rename to
On Mon, Jul 03, 2017 at 11:54:20AM +0200, Marc Gonzalez wrote:
> Hello Bjorn,
>
> On 03/07/2017 01:18, Bjorn Helgaas wrote:
>
> > On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez wrote:
> >
> >> This driver is required to work around several hardware bugs
> >> in the PCIe controller.
> >
On Mon, Jul 03, 2017 at 11:54:20AM +0200, Marc Gonzalez wrote:
> Hello Bjorn,
>
> On 03/07/2017 01:18, Bjorn Helgaas wrote:
>
> > On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez wrote:
> >
> >> This driver is required to work around several hardware bugs
> >> in the PCIe controller.
> >
[+cc Jingoo, Joao]
On Mon, Jul 03, 2017 at 10:35:50AM +0100, Ard Biesheuvel wrote:
> On 3 July 2017 at 00:18, Bjorn Helgaas wrote:
> > On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez wrote:
> >> This driver is required to work around several hardware bugs
> >> in the
[+cc Jingoo, Joao]
On Mon, Jul 03, 2017 at 10:35:50AM +0100, Ard Biesheuvel wrote:
> On 3 July 2017 at 00:18, Bjorn Helgaas wrote:
> > On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez wrote:
> >> This driver is required to work around several hardware bugs
> >> in the PCIe controller.
>
On 03/07/2017 11:54, Marc Gonzalez wrote:
> Mark Rutland points out stop_machine. I will test this solution.
I must be misunderstanding some of the requirements for
calling stop_machine() because my kernel panics, after
many warnings.
I made the following changes, which call stop_machine() at
On 03/07/2017 11:54, Marc Gonzalez wrote:
> Mark Rutland points out stop_machine. I will test this solution.
I must be misunderstanding some of the requirements for
calling stop_machine() because my kernel panics, after
many warnings.
I made the following changes, which call stop_machine() at
Hello Bjorn,
On 03/07/2017 01:18, Bjorn Helgaas wrote:
> On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez wrote:
>
>> This driver is required to work around several hardware bugs
>> in the PCIe controller.
>
> [ Snip style issues ]
I wish you had pointed these out in your May 23 review,
Hello Bjorn,
On 03/07/2017 01:18, Bjorn Helgaas wrote:
> On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez wrote:
>
>> This driver is required to work around several hardware bugs
>> in the PCIe controller.
>
> [ Snip style issues ]
I wish you had pointed these out in your May 23 review,
On 3 July 2017 at 00:18, Bjorn Helgaas wrote:
> On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez wrote:
>> This driver is required to work around several hardware bugs
>> in the PCIe controller.
>>
>> NB: Revision 1 does not support legacy interrupts, or IO space.
>
> I
On 3 July 2017 at 00:18, Bjorn Helgaas wrote:
> On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez wrote:
>> This driver is required to work around several hardware bugs
>> in the PCIe controller.
>>
>> NB: Revision 1 does not support legacy interrupts, or IO space.
>
> I had to apply these
On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez wrote:
> This driver is required to work around several hardware bugs
> in the PCIe controller.
>
> NB: Revision 1 does not support legacy interrupts, or IO space.
I had to apply these manually because of conflicts in Kconfig and
Makefile.
On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez wrote:
> This driver is required to work around several hardware bugs
> in the PCIe controller.
>
> NB: Revision 1 does not support legacy interrupts, or IO space.
I had to apply these manually because of conflicts in Kconfig and
Makefile.
This driver is required to work around several hardware bugs
in the PCIe controller.
NB: Revision 1 does not support legacy interrupts, or IO space.
Signed-off-by: Marc Gonzalez
---
drivers/pci/host/Kconfig | 8 +++
drivers/pci/host/Makefile | 1 +
This driver is required to work around several hardware bugs
in the PCIe controller.
NB: Revision 1 does not support legacy interrupts, or IO space.
Signed-off-by: Marc Gonzalez
---
drivers/pci/host/Kconfig | 8 +++
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pcie-tango.c |
56 matches
Mail list logo