Hi Simon,
On Wed, Jul 29, 2015 at 9:08 AM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Wed, Jul 29, 2015 at 8:48 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 28 July 2015 at 18:46, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Wed, Jul 29, 2015 at 8:42 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 28 July 2015 at 18:40, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Tue, Jul 28, 2015 at 7:58 PM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 28 July 2015 at 01:50, Bin Meng bmeng.cn@gmail.com wrote: > > Hi Simon, > > On Tue, Jul 28, 2015 at 5:47 AM, Simon Glass sjg@chromium.org wrote: > > At present minnowmax does not correct set up PCI interrupts. This should be > > done in U-Boot so that devices work correctly in Linux. > > > > Note: This code needs to make use of the recent pirq_routing work. It does > > not seem to support all the required features, so this RFC will hopefully > > What features are missing in the existing PIRQ codes? When I did the > PIRQ support, I checked both TunnelCreek and BayTrail chipset > datasheet, and found the only difference seems to be the pci > configuration space vs. memory-mapped IBASE where the pci irq routing > registers reside.
I see that each PCI device can be assigned four routes, making up a 16-bit register. But the code I see in pirq_assign_req() only assigns a single one, using a byte register.
No, the pci irq routing register is still a 8-bit register on BayTrail, where pirq_assign_irq() programs. The 16-bit register you mentioned should be done in the platform codes. See arch/x86/cpu/queensbay/tnc.c::cpu_irq_init(). By the way actually we can leave those register programmed as they have the optimized default values for all pci devices after power up, unless we intentionally want to change them.
What do you mean by 'leave those register programmed'?
I mean their default value is normally OK, like INTA maps PIRQA, INTB maps PIRQB, INTC maps PIRQC and INTD maps PIRQD.
OK, so drop writing to the pirq registers?
You might need check if BayTrail FSP does any programming on these registers. On Intel Crown Bay, I checked those values are the same values as documented in the TunnelCreek datasheet.
Should I program the 16-bit registers? If so, I will need to extend the device tree binding, won't I?
When I did the device tree binding changes, I did not convert these registers to use device tree, because their offsets, not like the routing registers as programmed in pirq_assign_irq(), is really platform specific thing and does not seem to have a good formula to calculate its offset (it varies from platform to platform). I previously wanted to create some device bindings like below, but I think they are really ugly so I did not go that way:
irq-router@1f,0 { reg = <0x0000f800 0 0 0 0>; compatible = "intel,irq-router"; ...... dev0-intx-offset = <0x2040>; dev0-intx-value = <PIRQA PIRQB PIRQC PIRQD>; dev2-intx-offset = <0x2048>; dev2-intx-value = <PIRQA PIRQB PIRQC PIRQD>; dev4-intx-offset = <0x2060>; dev4-intx-value = <PIRQA PIRQB PIRQC PIRQD>; dev26-intx-offset = <0x20a0>; dev26-intx-value = <PIRQA PIRQB PIRQC PIRQD>; dev31-intx-offset = <0x20c0>; dev31-intx-value = <PIRQA PIRQB PIRQC PIRQD>; ......
Sorry I cannot find a better way to describe this in device tree, so I chose to implement directly in the cpu_irq_init() to program these registers.
Sorry my understanding is limited on this - and I'd like to use your generic code if possible.
Yes, let's try to use the existing codes. If needed, we can have some patches to support new platforms.
I just managed to get a BayTrail board (not MinnowMax) and will try to first port U-Boot (assume it won't take much time) then see how PIRQ looks like on this platform.
Regards, Bin