* Re: pci node question
From: Scott Wood @ 2012-04-20 20:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <EDA55B32-FD14-4B5C-90AF-7FC5F77898E0@kernel.crashing.org>
On 04/20/2012 03:37 PM, Kumar Gala wrote:
>
> On Apr 20, 2012, at 2:04 PM, Scott Wood wrote:
>
>> On 04/20/2012 01:53 PM, Kumar Gala wrote:
>>>
>>> On Apr 20, 2012, at 1:37 PM, Yoder Stuart-B08248 wrote:
>>>
>>>> There was refactoring change a while back that moved
>>>> the interrupt map down into the virtual pci bridge.
>>>>
>>>> example:
>>>> 42 /* controller at 0x200000 */
>>>> 43 &pci0 {
>>>> 44 compatible = "fsl,p2041-pcie", "fsl,qoriq-pcie-v2.2";
>>>> 45 device_type = "pci";
>>>> 46 #size-cells = <2>;
>>>> 47 #address-cells = <3>;
>>>> 48 bus-range = <0x0 0xff>;
>>>> 49 clock-frequency = <33333333>;
>>>> 50 interrupts = <16 2 1 15>;
>>>> 51 pcie@0 {
>>>> 52 reg = <0 0 0 0 0>;
>>>> 53 #interrupt-cells = <1>;
>>>> 54 #size-cells = <2>;
>>>> 55 #address-cells = <3>;
>>>> 56 device_type = "pci";
>>>> 57 interrupts = <16 2 1 15>;
>>>> 58 interrupt-map-mask = <0xf800 0 0 7>;
>>>> 59 interrupt-map = <
>>>> 60 /* IDSEL 0x0 */
>>>> 61 0000 0 0 1 &mpic 40 1 0 0
>>>> 62 0000 0 0 2 &mpic 1 1 0 0
>>>> 63 0000 0 0 3 &mpic 2 1 0 0
>>>> 64 0000 0 0 4 &mpic 3 1 0 0
>>>> 65 >;
>>>> 66 };
>>>> 67 };
>>>>
>>>> Why was the interrupt-map moved here?
>>>
>>> Its been a while, but I think i moved it down because of which node is used for interrupt handling in linux.
>>
>> That's not supposed to be how device tree bindings are determined.
>>
>> It's causing us problems with virtualization device assignment, because
>> if we just assign the parent bus we don't get the interrupt map, but if
>> we assign the child we need to deal with what it means to assign an
>> individual PCI device (e.g. on our internal KVM stuff we get an error on
>> that reg property).
>>
>> What does this node represent in the first place? Is there really a
>> PCI-to-PCI bridge? Are all other PCI devices underneath it?
>
> PCIe has this concept of a "virtual" bridge between the root-comples,
Between the root complex and whatever's plugged in?
> so that is what the node represents. Its always been a bit confusing to me as its not 100% standardized by PCI sig.
Is it documented anywhere (e.g. in the chip manual)? Is it common (even
if 100% standardized), or a Freescale-ism?
Is there an actual PCIe-to-PCIe bridge that shows up in the root
complex's config space (not talking about the host bridge PCI device
that has always been there on FSL PCI controllers, which we didn't
represent in the device tree on non-express PCI)? Why does this bridge
need to be represented in the device tree (assuming no ISA devices need
to be represented), when other PCI devices (including bridges) don't?
> Maybe Ben's got some comments to add here from a generic PCIe point of view.
>
>>>> Do we really need the error interrupt specified twice?
>>>
>>> I put it twice because it has multiple purposes, one has to do with interrupts defined by the PCI spec vs ones defined via FSL controller.
>>
>> There are PCI-defined error conditions that cause a host controller
>> interrupt. What does this have to do with the bridge node?
>
> Think of the "error" IRQ as shared between to classes of interrupts. One set are controller errors defined by FSL, the other are errors defined by PCI sig / bus point of view.
>
> I'd expect controller errors to be handled by something like EDAC would bind at "fsl,qoriq-pcie-v2.2" level node. The PCI bus code would looks at the virtual bridge down.
This shouldn't be about where a specific piece of Linux code looks.
I don't see why the split of PCI-defined errors versus FSL-defined
errors maps to bridge node versus controller node. What if we didn't
have the bridge? We'd still have PCI-defined errors, right?
-Scott
^ permalink raw reply
* Re: pci node question
From: Kumar Gala @ 2012-04-20 20:37 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4F91B335.4010501@freescale.com>
On Apr 20, 2012, at 2:04 PM, Scott Wood wrote:
> On 04/20/2012 01:53 PM, Kumar Gala wrote:
>>=20
>> On Apr 20, 2012, at 1:37 PM, Yoder Stuart-B08248 wrote:
>>=20
>>> There was refactoring change a while back that moved=20
>>> the interrupt map down into the virtual pci bridge.
>>>=20
>>> example:=20
>>> 42 /* controller at 0x200000 */
>>> 43 &pci0 {
>>> 44 compatible =3D "fsl,p2041-pcie", "fsl,qoriq-pcie-v2.2";
>>> 45 device_type =3D "pci";
>>> 46 #size-cells =3D <2>;
>>> 47 #address-cells =3D <3>;
>>> 48 bus-range =3D <0x0 0xff>;
>>> 49 clock-frequency =3D <33333333>;
>>> 50 interrupts =3D <16 2 1 15>;
>>> 51 pcie@0 {
>>> 52 reg =3D <0 0 0 0 0>;
>>> 53 #interrupt-cells =3D <1>;
>>> 54 #size-cells =3D <2>;
>>> 55 #address-cells =3D <3>;
>>> 56 device_type =3D "pci";
>>> 57 interrupts =3D <16 2 1 15>;
>>> 58 interrupt-map-mask =3D <0xf800 0 0 7>;
>>> 59 interrupt-map =3D <
>>> 60 /* IDSEL 0x0 */
>>> 61 0000 0 0 1 &mpic 40 1 0 0
>>> 62 0000 0 0 2 &mpic 1 1 0 0
>>> 63 0000 0 0 3 &mpic 2 1 0 0
>>> 64 0000 0 0 4 &mpic 3 1 0 0
>>> 65 >;
>>> 66 };
>>> 67 };
>>>=20
>>> Why was the interrupt-map moved here?
>>=20
>> Its been a while, but I think i moved it down because of which node =
is used for interrupt handling in linux.
>=20
> That's not supposed to be how device tree bindings are determined.
>=20
> It's causing us problems with virtualization device assignment, =
because
> if we just assign the parent bus we don't get the interrupt map, but =
if
> we assign the child we need to deal with what it means to assign an
> individual PCI device (e.g. on our internal KVM stuff we get an error =
on
> that reg property).
>=20
> What does this node represent in the first place? Is there really a
> PCI-to-PCI bridge? Are all other PCI devices underneath it?
PCIe has this concept of a "virtual" bridge between the root-comples, so =
that is what the node represents. Its always been a bit confusing to me =
as its not 100% standardized by PCI sig.
Maybe Ben's got some comments to add here from a generic PCIe point of =
view.
>>> Do we really need the error interrupt specified twice?
>>=20
>> I put it twice because it has multiple purposes, one has to do with =
interrupts defined by the PCI spec vs ones defined via FSL controller.
>=20
> There are PCI-defined error conditions that cause a host controller
> interrupt. What does this have to do with the bridge node?
Think of the "error" IRQ as shared between to classes of interrupts. =
One set are controller errors defined by FSL, the other are errors =
defined by PCI sig / bus point of view.
I'd expect controller errors to be handled by something like EDAC would =
bind at "fsl,qoriq-pcie-v2.2" level node. The PCI bus code would looks =
at the virtual bridge down.
>=20
>>> Why is there a zeroed out reg property: reg =3D <0 0 0 0 0> ??
>>=20
>> scratching my head, what happens if you remove it?
>=20
> Sigh.
:)
- k=
^ permalink raw reply
* RE: pci node question
From: Yoder Stuart-B08248 @ 2012-04-20 19:50 UTC (permalink / raw)
To: Kumar Gala; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <D04C6167-5286-4675-A6D8-32BA63305424@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Friday, April 20, 2012 1:54 PM
> To: Yoder Stuart-B08248
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: Re: pci node question
>=20
>=20
> On Apr 20, 2012, at 1:37 PM, Yoder Stuart-B08248 wrote:
>=20
> > There was refactoring change a while back that moved
> > the interrupt map down into the virtual pci bridge.
> >
> > example:
> > 42 /* controller at 0x200000 */
> > 43 &pci0 {
> > 44 compatible =3D "fsl,p2041-pcie", "fsl,qoriq-pcie-v2.2";
> > 45 device_type =3D "pci";
> > 46 #size-cells =3D <2>;
> > 47 #address-cells =3D <3>;
> > 48 bus-range =3D <0x0 0xff>;
> > 49 clock-frequency =3D <33333333>;
> > 50 interrupts =3D <16 2 1 15>;
> > 51 pcie@0 {
> > 52 reg =3D <0 0 0 0 0>;
> > 53 #interrupt-cells =3D <1>;
> > 54 #size-cells =3D <2>;
> > 55 #address-cells =3D <3>;
> > 56 device_type =3D "pci";
> > 57 interrupts =3D <16 2 1 15>;
> > 58 interrupt-map-mask =3D <0xf800 0 0 7>;
> > 59 interrupt-map =3D <
> > 60 /* IDSEL 0x0 */
> > 61 0000 0 0 1 &mpic 40 1 0 0
> > 62 0000 0 0 2 &mpic 1 1 0 0
> > 63 0000 0 0 3 &mpic 2 1 0 0
> > 64 0000 0 0 4 &mpic 3 1 0 0
> > 65 >;
> > 66 };
> > 67 };
> >
> > Why was the interrupt-map moved here?
>=20
> Its been a while, but I think i moved it down because of which node is us=
ed for interrupt handling in
> linux.
>=20
> > Do we really need the error interrupt specified twice?
>=20
> I put it twice because it has multiple purposes, one has to do with inter=
rupts defined by the PCI spec
> vs ones defined via FSL controller.
>=20
> > Why is there a zeroed out reg property: reg =3D <0 0 0 0 0> ??
>=20
> scratching my head, what happens if you remove it?
Tried removing the zeroed reg, and get this error when bringing
up an e1000 interface:
[root@kvmtst1 root]# ifconfig eth0 192.168.1.20
e1000e 0000:01:00.0: eth0: Unable to allocate interrupt, Error: -22
SIOCSIFFLAGS: Invalid argument
Stuart
^ permalink raw reply
* Re: pci node question
From: Scott Wood @ 2012-04-20 19:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <D04C6167-5286-4675-A6D8-32BA63305424@kernel.crashing.org>
On 04/20/2012 01:53 PM, Kumar Gala wrote:
>
> On Apr 20, 2012, at 1:37 PM, Yoder Stuart-B08248 wrote:
>
>> There was refactoring change a while back that moved
>> the interrupt map down into the virtual pci bridge.
>>
>> example:
>> 42 /* controller at 0x200000 */
>> 43 &pci0 {
>> 44 compatible = "fsl,p2041-pcie", "fsl,qoriq-pcie-v2.2";
>> 45 device_type = "pci";
>> 46 #size-cells = <2>;
>> 47 #address-cells = <3>;
>> 48 bus-range = <0x0 0xff>;
>> 49 clock-frequency = <33333333>;
>> 50 interrupts = <16 2 1 15>;
>> 51 pcie@0 {
>> 52 reg = <0 0 0 0 0>;
>> 53 #interrupt-cells = <1>;
>> 54 #size-cells = <2>;
>> 55 #address-cells = <3>;
>> 56 device_type = "pci";
>> 57 interrupts = <16 2 1 15>;
>> 58 interrupt-map-mask = <0xf800 0 0 7>;
>> 59 interrupt-map = <
>> 60 /* IDSEL 0x0 */
>> 61 0000 0 0 1 &mpic 40 1 0 0
>> 62 0000 0 0 2 &mpic 1 1 0 0
>> 63 0000 0 0 3 &mpic 2 1 0 0
>> 64 0000 0 0 4 &mpic 3 1 0 0
>> 65 >;
>> 66 };
>> 67 };
>>
>> Why was the interrupt-map moved here?
>
> Its been a while, but I think i moved it down because of which node is used for interrupt handling in linux.
That's not supposed to be how device tree bindings are determined.
It's causing us problems with virtualization device assignment, because
if we just assign the parent bus we don't get the interrupt map, but if
we assign the child we need to deal with what it means to assign an
individual PCI device (e.g. on our internal KVM stuff we get an error on
that reg property).
What does this node represent in the first place? Is there really a
PCI-to-PCI bridge? Are all other PCI devices underneath it?
>> Do we really need the error interrupt specified twice?
>
> I put it twice because it has multiple purposes, one has to do with interrupts defined by the PCI spec vs ones defined via FSL controller.
There are PCI-defined error conditions that cause a host controller
interrupt. What does this have to do with the bridge node?
>> Why is there a zeroed out reg property: reg = <0 0 0 0 0> ??
>
> scratching my head, what happens if you remove it?
Sigh.
-Scott
^ permalink raw reply
* Re: pci node question
From: Kumar Gala @ 2012-04-20 18:53 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <9F6FE96B71CF29479FF1CDC8046E1503346013@039-SN1MPN1-002.039d.mgd.msft.net>
On Apr 20, 2012, at 1:37 PM, Yoder Stuart-B08248 wrote:
> There was refactoring change a while back that moved=20
> the interrupt map down into the virtual pci bridge.
>=20
> example:=20
> 42 /* controller at 0x200000 */
> 43 &pci0 {
> 44 compatible =3D "fsl,p2041-pcie", "fsl,qoriq-pcie-v2.2";
> 45 device_type =3D "pci";
> 46 #size-cells =3D <2>;
> 47 #address-cells =3D <3>;
> 48 bus-range =3D <0x0 0xff>;
> 49 clock-frequency =3D <33333333>;
> 50 interrupts =3D <16 2 1 15>;
> 51 pcie@0 {
> 52 reg =3D <0 0 0 0 0>;
> 53 #interrupt-cells =3D <1>;
> 54 #size-cells =3D <2>;
> 55 #address-cells =3D <3>;
> 56 device_type =3D "pci";
> 57 interrupts =3D <16 2 1 15>;
> 58 interrupt-map-mask =3D <0xf800 0 0 7>;
> 59 interrupt-map =3D <
> 60 /* IDSEL 0x0 */
> 61 0000 0 0 1 &mpic 40 1 0 0
> 62 0000 0 0 2 &mpic 1 1 0 0
> 63 0000 0 0 3 &mpic 2 1 0 0
> 64 0000 0 0 4 &mpic 3 1 0 0
> 65 >;
> 66 };
> 67 };
>=20
> Why was the interrupt-map moved here?
Its been a while, but I think i moved it down because of which node is =
used for interrupt handling in linux.
> Do we really need the error interrupt specified twice?
I put it twice because it has multiple purposes, one has to do with =
interrupts defined by the PCI spec vs ones defined via FSL controller.
> Why is there a zeroed out reg property: reg =3D <0 0 0 0 0> ??
scratching my head, what happens if you remove it?
- k
^ permalink raw reply
* pci node question
From: Yoder Stuart-B08248 @ 2012-04-20 18:37 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev@lists.ozlabs.org
There was refactoring change a while back that moved=20
the interrupt map down into the virtual pci bridge.
example:=20
42 /* controller at 0x200000 */
43 &pci0 {
44 compatible =3D "fsl,p2041-pcie", "fsl,qoriq-pcie-v2.2";
45 device_type =3D "pci";
46 #size-cells =3D <2>;
47 #address-cells =3D <3>;
48 bus-range =3D <0x0 0xff>;
49 clock-frequency =3D <33333333>;
50 interrupts =3D <16 2 1 15>;
51 pcie@0 {
52 reg =3D <0 0 0 0 0>;
53 #interrupt-cells =3D <1>;
54 #size-cells =3D <2>;
55 #address-cells =3D <3>;
56 device_type =3D "pci";
57 interrupts =3D <16 2 1 15>;
58 interrupt-map-mask =3D <0xf800 0 0 7>;
59 interrupt-map =3D <
60 /* IDSEL 0x0 */
61 0000 0 0 1 &mpic 40 1 0 0
62 0000 0 0 2 &mpic 1 1 0 0
63 0000 0 0 3 &mpic 2 1 0 0
64 0000 0 0 4 &mpic 3 1 0 0
65 >;
66 };
67 };
Why was the interrupt-map moved here?
Do we really need the error interrupt specified twice?
Why is there a zeroed out reg property: reg =3D <0 0 0 0 0> ??
Thanks,
Stuart
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Gerhard Pircher @ 2012-04-20 16:14 UTC (permalink / raw)
To: "Michel Dänzer"; +Cc: linuxppc-dev
In-Reply-To: <1334927896.5989.463.camel@thor.local>
-------- Original-Nachricht --------
> Datum: Fri, 20 Apr 2012 15:18:16 +0200
> Von: "Michel Dänzer" <michel@daenzer.net>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@lists.ozlabs.org
> Betreff: Re: PowerPC radeon KMS - is it possible?
> On Fre, 2012-04-20 at 13:15 +0200, Gerhard Pircher wrote:
> > > Von: "Michel Dänzer" <michel@daenzer.net>
> > > On Don, 2012-04-19 at 13:48 +0200, Gerhard Pircher wrote:
> > > >
> > > > The "former case" is an explanation, why I see data corruption
> > > > with my< AGPGART driver (more or less a copy of the uninorth
> > > > driver) on my non-coherent platform. There are no cache flushes
> > > > done for writes to already mapped pages.
> > >
> > > As I said, the radeon driver always maps AGP memory uncacheable for
> > > the CPU, so no such CPU cache flushes should be necessary.
> > I know. We also discussed this topic over two years ago. :-)
> >
> > What I didn't understand yet is how this uncacheable memory is
> > allocated (well, I never took the time to look at this again). The
> > functions in ttm_page_alloc.c seem to allocate normal cacheable
> > memory and try to set the page flags with set_pages_array_uc(),
> > which is more or less a no-op on powerpc. ttm_page_alloc_dma.c on
> > the other side is only used with SWIOTLB!?
> [...]
> > Could it be that the memory is finally mapped uncacheable by
> radeon_bo_kmap()/
> > ttm_bo_kmap()/..some other TTM functions../vmap()?
>
> Yeah, AFAICT, basically ttm_io_prot() defines the mapping attributes,
> and vmap() is used to enforce them for kernel mappings.
Okay, that sounds like the approach used by arch/powerpc/mm/dma-
noncoherent.c in my ("green") ears. What about the PCIGART mode?
Is the driver free to use cached memory in this mode?
> > Here is an excerpt of the 2.6.39 kernel log. IIRC the testing code
> > changed in the meantime so I guess it would make sense to repeat it
> > with a newer kernel version.
>
> I was going to suggest that. :)
As expected. :-)
> > [ 5.490569] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326160 (GTT map 0xf1326000-0xf1426000)
> > [ 5.503397] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf1326164 (GTT map 0xf1326000-0xf1426000)
> > [ 5.516202] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326168 (GTT map 0xf1326000-0xf1426000)
> > [ 5.528993] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf132616c (GTT map 0xf1326000-0xf1426000)
> [...]
> > [ 5.878809] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ec0, expected 0xf1570ec0 (VRAM map 0xf1480000-0xf1580000)
>
> > For the GTT->VRAM copy it looks like the AGPGART driver at least
> > gets the graphics aperture translation table right, as both the
> > returned and expected values are within a page. But the page offset
> > of the returned values (0x8c0, 0x8c4) makes me wonder whether I'm
> > fooled by a hardware bug or a cache coherency problem.
>
> Hard to say... at least it managed to transfer the first 352 bytes
> correctly. ;)
Better than nothing! :-)
> > The VRAM->GTT copy totally puzzles me, as it returns a wrong page
> > address, but the offset is fine!?
>
> Maybe it's still the values from the GTT->VRAM test, i.e. either the GPU
> writes didn't make it to the memory mapped into the AGP GART (some AGP
Good point. Maybe I should explicitly clear the gtt_map before the
VRAM->GTT copy test is executed.
> bridges are known to have issues with that) or the CPU doesn't see it.
What is the workaround for such an AGP bridge? If there is one at all...
> BTW, does your driver set cant_use_aperture, or is the linear aperture
> accessible by the CPU?
The driver sets cant_use_aperture. I couldn't get it working at all
without it.
regards,
Gerhard
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Michel Dänzer @ 2012-04-20 13:18 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20120420111527.190290@gmx.net>
On Fre, 2012-04-20 at 13:15 +0200, Gerhard Pircher wrote:=20
> > Von: "Michel D=C3=A4nzer" <michel@daenzer.net>
> > On Don, 2012-04-19 at 13:48 +0200, Gerhard Pircher wrote:=20
> > >=20
> > > The "former case" is an explanation, why I see data corruption with m=
y
> > > AGPGART driver (more or less a copy of the uninorth driver) on my
> > > non-coherent platform. There are no cache flushes done for writes to
> > > already mapped pages.
> >=20
> > As I said, the radeon driver always maps AGP memory uncacheable for the
> > CPU, so no such CPU cache flushes should be necessary.
> I know. We also discussed this topic over two years ago. :-)
>=20
> What I didn't understand yet is how this uncacheable memory is allocated
> (well, I never took the time to look at this again). The functions in
> ttm_page_alloc.c seem to allocate normal cacheable memory and try to set
> the page flags with set_pages_array_uc(), which is more or less a no-op
> on powerpc.
> ttm_page_alloc_dma.c on the other side is only used with SWIOTLB!?
[...]=20
> Could it be that the memory is finally mapped uncacheable by radeon_bo_km=
ap()/
> ttm_bo_kmap()/..some other TTM functions../vmap()?
Yeah, AFAICT, basically ttm_io_prot() defines the mapping attributes,
and vmap() is used to enforce them for kernel mappings.
> Here is an excerpt of the 2.6.39 kernel log. IIRC the testing code change=
d
> in the meantime so I guess it would make sense to repeat it with a newer
> kernel version.
I was going to suggest that. :)
> [ 5.490569] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0=
: Got 0xf13268c0, expected 0xf1326160 (GTT map 0xf1326000-0xf1426000)
> [ 5.503397] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0=
: Got 0xf13268c4, expected 0xf1326164 (GTT map 0xf1326000-0xf1426000)
> [ 5.516202] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0=
: Got 0xf13268c0, expected 0xf1326168 (GTT map 0xf1326000-0xf1426000)
> [ 5.528993] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0=
: Got 0xf13268c4, expected 0xf132616c (GTT map 0xf1326000-0xf1426000)
[...]=20
> [ 5.878809] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0=
: Got 0xf1416ec0, expected 0xf1570ec0 (VRAM map 0xf1480000-0xf1580000)
> For the GTT->VRAM copy it looks like the AGPGART driver at least
> gets the graphics aperture translation table right, as both the
> returned and expected values are within a page. But the page offset
> of the returned values (0x8c0, 0x8c4) makes me wonder whether I'm
> fooled by a hardware bug or a cache coherency problem.
Hard to say... at least it managed to transfer the first 352 bytes
correctly. ;)
> The VRAM->GTT copy totally puzzles me, as it returns a wrong page
> address, but the offset is fine!?
Maybe it's still the values from the GTT->VRAM test, i.e. either the GPU
writes didn't make it to the memory mapped into the AGP GART (some AGP
bridges are known to have issues with that) or the CPU doesn't see it.
BTW, does your driver set cant_use_aperture, or is the linear aperture
accessible by the CPU?
--=20
Earthling Michel D=C3=A4nzer | http://www.amd.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: PowerPC radeon KMS - is it possible?
From: Gerhard Pircher @ 2012-04-20 11:15 UTC (permalink / raw)
To: "Michel Dänzer"; +Cc: linuxppc-dev
-------- Original-Nachricht --------
> Datum: Thu, 19 Apr 2012 14:41:16 +0200
> Von: "Michel Dänzer" <michel@daenzer.net>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@lists.ozlabs.org, schwab@linux-m68k.org, ojordan12345@hotmail.co.uk
> Betreff: Re: PowerPC radeon KMS - is it possible?
> On Don, 2012-04-19 at 13:48 +0200, Gerhard Pircher wrote:
> > > Von: "Michel Dänzer" <michel@daenzer.net>
> > > On Mit, 2012-04-18 at 18:23 +0200, Gerhard Pircher wrote:
> > > > > Von: "Michel Dänzer" <michel@daenzer.net>
> > > > > On Mit, 2012-04-18 at 17:49 +0200, Gerhard Pircher wrote:
> > > > > >
> > > > > > That may be a stupid question, but is it allowed (for a DRM
> > > > > > client or whatever does the mapping) to change the content of
> > > > > > a page mapped into the AGP GART or is it necessary to
> > > > > > explicitly unmap the page, change its content and map it again?
> > > > >
> > > > > The former.
> > > > I know that the uninorth AGPGART driver does a cache flushing for
> > > > newly mapped pages, but is there any code in the driver that
> > > > handles the former case (or isn't this necessary on PPC Macs)?
> > >
> > > If by 'former case' you mean userspace modifying memory mapped into
> > > the AGP GART, then no, this generally doesn't require special
> > > treatment on PowerMacs. (Ignoring the potential issue mentioned by
> > > Ben in this thread)
> > I guess you refer to the ordering issue here.
>
> Yeah.
>
> > The "former case" is an explanation, why I see data corruption with my
> > AGPGART driver (more or less a copy of the uninorth driver) on my
> > non-coherent platform. There are no cache flushes done for writes to
> > already mapped pages.
>
> As I said, the radeon driver always maps AGP memory uncacheable for the
> CPU, so no such CPU cache flushes should be necessary.
I know. We also discussed this topic over two years ago. :-)
What I didn't understand yet is how this uncacheable memory is allocated
(well, I never took the time to look at this again). The functions in
ttm_page_alloc.c seem to allocate normal cacheable memory and try to set
the page flags with set_pages_array_uc(), which is more or less a no-op
on powerpc. ttm_page_alloc_dma.c on the other side is only used with
SWIOTLB!?
> > I tested this with radeon.test=1, but I'm not even sure if this code
> > changes already mapped pages [...]
>
> It does. radeon_bo_pin(..., RADEON_GEM_DOMAIN_GTT, ...) binds the buffer
> memory into the AGP GART, and the test only maps it to the CPU after
> that.
Could it be that the memory is finally mapped uncacheable by radeon_bo_kmap()/
ttm_bo_kmap()/..some other TTM functions../vmap()?
> I take it the test fails for you? How exactly?
I didn't work on the driver for a long time. It looks like I did the last
tests with a 2.6.39 kernel, where I changed the radeon test routine to not
stop on a failed copy. This way I could check for a pattern in the failed
copies.
Here is an excerpt of the 2.6.39 kernel log. IIRC the testing code changed
in the meantime so I guess it would make sense to repeat it with a newer
kernel version.
[ 5.185619] calling agp_init+0x0/0x5c @ 1
[ 5.189816] Linux agpgart interface v0.103
[ 5.193993] initcall agp_init+0x0/0x5c returned 0 after 4076 usecs
[ 5.200359] calling agp_articias_init+0x0/0x58 @ 1
[ 5.205411] agpgart-articias 0000:00:00.0: MAI Logic Articia S chipset
[ 5.213555] agpgart-articias 0000:00:00.0: configuring for size idx: 6
[ 5.220996] agpgart-articias 0000:00:00.0: AGP aperture is 128M @ 0xc0000000
[ 5.228557] initcall agp_articias_init+0x0/0x58 returned 0 after 22629 usecs
[ 5.235791] calling drm_core_init+0x0/0x16c @ 1
[ 5.240839] [drm] Initialized drm 1.1.0 20060810
[ 5.245623] initcall drm_core_init+0x0/0x16c returned 0 after 4937 usecs
[ 5.252510] calling ttm_init+0x0/0x8c @ 1
[ 5.256908] initcall ttm_init+0x0/0x8c returned 0 after 197 usecs
[ 5.263172] calling radeon_init+0x0/0x11c @ 1
[ 5.267731] [drm] radeon kernel modesetting enabled.
[ 5.274683] [drm] initializing kernel modesetting (RV280 0x1002:0x5960).
[ 5.281657] [drm] register mmio base: 0x88000000
[ 5.286397] [drm] register mmio size: 65536
[ 5.327510] [drm] AGP mode requested: 1
[ 5.331485] agpgart-articias 0000:00:00.0: AGP 1.0 bridge
[ 5.337071] agpgart-articias 0000:00:00.0: putting AGP V2 device into 1x mode
[ 5.344440] radeon 0000:01:00.0: putting AGP V2 device into 1x mode
[ 5.350865] radeon 0000:01:00.0: GTT: 128M 0xC0000000 - 0xC7FFFFFF
[ 5.357197] [drm] Generation 2 PCI interface, using max accessible memory
[ 5.364111] radeon 0000:01:00.0: VRAM: 256M 0x0000000080000000 - 0x000000008FFFFFFF (256M used)
[ 5.373060] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 5.379815] [drm] Driver supports precise vblank timestamp query.
[ 5.386068] [drm] radeon: irq initialized.
[ 5.390264] [drm] Detected VRAM RAM=256M, BAR=128M
[ 5.395177] [drm] RAM width 128bits DDR
[ 5.399322] [TTM] Zone kernel: Available graphics memory: 380684 kiB.
[ 5.406047] [TTM] Zone highmem: Available graphics memory: 773900 kiB.
[ 5.412725] [TTM] Initializing pool allocator.
[ 5.417395] [drm] radeon: 256M of VRAM memory ready
[ 5.422442] [drm] radeon: 128M of GTT memory ready.
[ 5.428527] agpgart-articias 0000:00:00.0: TLB flush!
[ 5.433785] radeon 0000:01:00.0: WB disabled
[ 5.438671] [drm] Loading R200 Microcode
[ 5.444292] agpgart-articias 0000:00:00.0: TLB flush!
[ 5.449629] [drm] radeon: ring at 0x00000000C0001000
[ 5.454761] [drm] ring test succeeded in 0 usecs
[ 5.460620] agpgart-articias 0000:00:00.0: TLB flush!
[ 5.465889] [drm] radeon: ib pool ready.
[ 5.470212] [drm] ib test succeeded in 0 usecs
[ 5.475939] agpgart-articias 0000:00:00.0: TLB flush!
[ 5.490569] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326160 (GTT map 0xf1326000-0xf1426000)
[ 5.503397] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf1326164 (GTT map 0xf1326000-0xf1426000)
[ 5.516202] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326168 (GTT map 0xf1326000-0xf1426000)
[ 5.528993] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf132616c (GTT map 0xf1326000-0xf1426000)
[ 5.541777] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326170 (GTT map 0xf1326000-0xf1426000)
[ 5.554535] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf1326174 (GTT map 0xf1326000-0xf1426000)
[ 5.567303] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326178 (GTT map 0xf1326000-0xf1426000)
[ 5.580049] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf132617c (GTT map 0xf1326000-0xf1426000)
[ 5.592843] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326180 (GTT map 0xf1326000-0xf1426000)
[ 5.605652] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf1326184 (GTT map 0xf1326000-0xf1426000)
[ 5.618392] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326188 (GTT map 0xf1326000-0xf1426000)
[ 5.631178] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf132618c (GTT map 0xf1326000-0xf1426000)
[ 5.643970] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326190 (GTT map 0xf1326000-0xf1426000)
[ 5.656769] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf1326194 (GTT map 0xf1326000-0xf1426000)
[ 5.669494] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c0, expected 0xf1326198 (GTT map 0xf1326000-0xf1426000)
[ 5.682293] [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got 0xf13268c4, expected 0xf132619c (GTT map 0xf1326000-0xf1426000)
[ 5.878809] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ec0, expected 0xf1570ec0 (VRAM map 0xf1480000-0xf1580000)
[ 5.891734] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ec4, expected 0xf1570ec4 (VRAM map 0xf1480000-0xf1580000)
[ 5.904616] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ec8, expected 0xf1570ec8 (VRAM map 0xf1480000-0xf1580000)
[ 5.917460] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ecc, expected 0xf1570ecc (VRAM map 0xf1480000-0xf1580000)
[ 5.930286] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ed0, expected 0xf1570ed0 (VRAM map 0xf1480000-0xf1580000)
[ 5.943164] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ed4, expected 0xf1570ed4 (VRAM map 0xf1480000-0xf1580000)
[ 5.956052] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ed8, expected 0xf1570ed8 (VRAM map 0xf1480000-0xf1580000)
[ 5.968898] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416edc, expected 0xf1570edc (VRAM map 0xf1480000-0xf1580000)
[ 5.981758] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ee0, expected 0xf1570ee0 (VRAM map 0xf1480000-0xf1580000)
[ 5.994593] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ee4, expected 0xf1570ee4 (VRAM map 0xf1480000-0xf1580000)
[ 6.007455] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ee8, expected 0xf1570ee8 (VRAM map 0xf1480000-0xf1580000)
[ 6.020309] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416eec, expected 0xf1570eec (VRAM map 0xf1480000-0xf1580000)
[ 6.033208] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ef0, expected 0xf1570ef0 (VRAM map 0xf1480000-0xf1580000)
[ 6.046077] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ef4, expected 0xf1570ef4 (VRAM map 0xf1480000-0xf1580000)
[ 6.058964] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416ef8, expected 0xf1570ef8 (VRAM map 0xf1480000-0xf1580000)
[ 6.071850] [drm:radeon_test_moves] *ERROR* Incorrect VRAM->GTT copy 0: Got 0xf1416efc, expected 0xf1570efc (VRAM map 0xf1480000-0xf1580000)
For the GTT->VRAM copy it looks like the AGPGART driver at least
gets the graphics aperture translation table right, as both the
returned and expected values are within a page. But the page offset
of the returned values (0x8c0, 0x8c4) makes me wonder whether I'm
fooled by a hardware bug or a cache coherency problem.
The VRAM->GTT copy totally puzzles me, as it returns a wrong page
address, but the offset is fine!?
br,
Gerhard
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
^ permalink raw reply
* Re: [PATCH v4] KVM: PPC Use clockevent multiplier and shifter for decrementer
From: Alexander Graf @ 2012-04-20 10:24 UTC (permalink / raw)
To: Bharat Bhushan; +Cc: Bharat Bhushan, linuxppc-dev, kvm, kvm-ppc, bharatb.yadav
In-Reply-To: <1334764879-18020-1-git-send-email-bharat.bhushan@freescale.com>
On 18.04.2012, at 18:01, Bharat Bhushan wrote:
> Time for which the hrtimer is started for decrementer emulation is =
calculated using tb_ticks_per_usec. While hrtimer uses the clockevent =
for DEC reprogramming (if needed) and which calculate timebase ticks =
using the multiplier and shifter mechanism implemented within clockevent =
layer. It was observed that this conversion (timebase->time->timebase) =
are not correct because the mechanism are not consistent. In our setup =
it adds 2% jitter.
>=20
> With this patch clockevent multiplier and shifter mechanism are used =
when starting hrtimer for decrementer emulation. Now the jitter is < =
0.5%.
>=20
> Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
Thanks, applied to kvm-ppc-next with fixed commit message and fixed =
trailing whitespace :).
Alex
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/mpic: Properly set default triggers
From: Andreas Schwab @ 2012-04-20 9:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Thomas Gleixner, linuxppc-dev
In-Reply-To: <1334892657.31646.2.camel__44318.4292679236$1334892821$gmane$org@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> This gets rid of the unused default senses array, and replaces the
> incorrect use of IRQ_TYPE_NONE with the new IRQ_TYPE_DEFAULT for
> the initial set_trigger() call when mapping an interrupt.
>
> This in turn makes us read the HW state and update the irq desc
> accordingly.
That fixes the interrupt problem for me. The only regression left is
the spurious interrupts.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH] gianfar: add GRO support
From: Jiajun Wu @ 2012-04-20 8:54 UTC (permalink / raw)
To: netdev, davem; +Cc: Jiajun Wu, linuxppc-dev
Replace netif_receive_skb with napi_gro_receive.
Signed-off-by: Jiajun Wu <b06378@freescale.com>
---
drivers/net/ethernet/freescale/gianfar.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index e7bed53..1adb024 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -136,7 +136,7 @@ static void gfar_netpoll(struct net_device *dev);
int gfar_clean_rx_ring(struct gfar_priv_rx_q *rx_queue, int rx_work_limit);
static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue);
static int gfar_process_frame(struct net_device *dev, struct sk_buff *skb,
- int amount_pull);
+ int amount_pull, struct napi_struct *napi);
void gfar_halt(struct net_device *dev);
static void gfar_halt_nodisable(struct net_device *dev);
void gfar_start(struct net_device *dev);
@@ -2675,12 +2675,12 @@ static inline void gfar_rx_checksum(struct sk_buff *skb, struct rxfcb *fcb)
/* gfar_process_frame() -- handle one incoming packet if skb
* isn't NULL. */
static int gfar_process_frame(struct net_device *dev, struct sk_buff *skb,
- int amount_pull)
+ int amount_pull, struct napi_struct *napi)
{
struct gfar_private *priv = netdev_priv(dev);
struct rxfcb *fcb = NULL;
- int ret;
+ gro_result_t ret;
/* fcb is at the beginning if exists */
fcb = (struct rxfcb *)skb->data;
@@ -2719,9 +2719,9 @@ static int gfar_process_frame(struct net_device *dev, struct sk_buff *skb,
__vlan_hwaccel_put_tag(skb, fcb->vlctl);
/* Send the packet up the stack */
- ret = netif_receive_skb(skb);
+ ret = napi_gro_receive(napi, skb);
- if (NET_RX_DROP == ret)
+ if (GRO_DROP == ret)
priv->extra_stats.kernel_dropped++;
return 0;
@@ -2783,7 +2783,8 @@ int gfar_clean_rx_ring(struct gfar_priv_rx_q *rx_queue, int rx_work_limit)
skb_put(skb, pkt_len);
rx_queue->stats.rx_bytes += pkt_len;
skb_record_rx_queue(skb, rx_queue->qindex);
- gfar_process_frame(dev, skb, amount_pull);
+ gfar_process_frame(dev, skb, amount_pull,
+ &rx_queue->grp->napi);
} else {
netif_warn(priv, rx_err, dev, "Missing skb!\n");
--
1.5.6.5
^ permalink raw reply related
* [PATCH 3/3] powerpc/mpic: Properly set default triggers
From: Benjamin Herrenschmidt @ 2012-04-20 3:30 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Thomas Gleixner
This gets rid of the unused default senses array, and replaces the
incorrect use of IRQ_TYPE_NONE with the new IRQ_TYPE_DEFAULT for
the initial set_trigger() call when mapping an interrupt.
This in turn makes us read the HW state and update the irq desc
accordingly.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/mpic.h | 18 -----------------
arch/powerpc/sysdev/mpic.c | 42 ++++++++++++++++++++++++++++-----------
2 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index c65b929..c9f698a 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -275,9 +275,6 @@ struct mpic
unsigned int isu_mask;
/* Number of sources */
unsigned int num_sources;
- /* default senses array */
- unsigned char *senses;
- unsigned int senses_count;
/* vector numbers used for internal sources (ipi/timers) */
unsigned int ipi_vecs[4];
@@ -415,21 +412,6 @@ extern struct mpic *mpic_alloc(struct device_node *node,
extern void mpic_assign_isu(struct mpic *mpic, unsigned int isu_num,
phys_addr_t phys_addr);
-/* Set default sense codes
- *
- * @mpic: controller
- * @senses: array of sense codes
- * @count: size of above array
- *
- * Optionally provide an array (indexed on hardware interrupt numbers
- * for this MPIC) of default sense codes for the chip. Those are linux
- * sense codes IRQ_TYPE_*
- *
- * The driver gets ownership of the pointer, don't dispose of it or
- * anything like that. __init only.
- */
-extern void mpic_set_default_senses(struct mpic *mpic, u8 *senses, int count);
-
/* Initialize the controller. After this has been called, none of the above
* should be called again for this mpic
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 665b0f8..395af13 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -872,21 +872,45 @@ int mpic_set_irq_type(struct irq_data *d, unsigned int flow_type)
if (src >= mpic->num_sources)
return -EINVAL;
+ vold = mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI));
+
+ /* We don't support "none" type */
if (flow_type == IRQ_TYPE_NONE)
- if (mpic->senses && src < mpic->senses_count)
- flow_type = mpic->senses[src];
- if (flow_type == IRQ_TYPE_NONE)
- flow_type = IRQ_TYPE_LEVEL_LOW;
+ flow_type = IRQ_TYPE_DEFAULT;
+
+ /* Default: read HW settings */
+ if (flow_type == IRQ_TYPE_DEFAULT) {
+ switch(vold & (MPIC_INFO(VECPRI_POLARITY_MASK) |
+ MPIC_INFO(VECPRI_SENSE_MASK))) {
+ case MPIC_INFO(VECPRI_SENSE_EDGE) |
+ MPIC_INFO(VECPRI_POLARITY_POSITIVE):
+ flow_type = IRQ_TYPE_EDGE_RISING;
+ break;
+ case MPIC_INFO(VECPRI_SENSE_EDGE) |
+ MPIC_INFO(VECPRI_POLARITY_NEGATIVE):
+ flow_type = IRQ_TYPE_EDGE_FALLING;
+ break;
+ case MPIC_INFO(VECPRI_SENSE_LEVEL) |
+ MPIC_INFO(VECPRI_POLARITY_POSITIVE):
+ flow_type = IRQ_TYPE_LEVEL_HIGH;
+ break;
+ case MPIC_INFO(VECPRI_SENSE_LEVEL) |
+ MPIC_INFO(VECPRI_POLARITY_NEGATIVE):
+ flow_type = IRQ_TYPE_LEVEL_LOW;
+ break;
+ }
+ }
+ /* Apply to irq desc */
irqd_set_trigger_type(d, flow_type);
+ /* Apply to HW */
if (mpic_is_ht_interrupt(mpic, src))
vecpri = MPIC_VECPRI_POLARITY_POSITIVE |
MPIC_VECPRI_SENSE_EDGE;
else
vecpri = mpic_type_to_vecpri(mpic, flow_type);
- vold = mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI));
vnew = vold & ~(MPIC_INFO(VECPRI_POLARITY_MASK) |
MPIC_INFO(VECPRI_SENSE_MASK));
vnew |= vecpri;
@@ -1022,7 +1046,7 @@ static int mpic_host_map(struct irq_domain *h, unsigned int virq,
irq_set_chip_and_handler(virq, chip, handle_fasteoi_irq);
/* Set default irq type */
- irq_set_irq_type(virq, IRQ_TYPE_NONE);
+ irq_set_irq_type(virq, IRQ_TYPE_DEFAULT);
/* If the MPIC was reset, then all vectors have already been
* initialized. Otherwise, a per source lazy initialization
@@ -1413,12 +1437,6 @@ void __init mpic_assign_isu(struct mpic *mpic, unsigned int isu_num,
mpic->num_sources = isu_first + mpic->isu_size;
}
-void __init mpic_set_default_senses(struct mpic *mpic, u8 *senses, int count)
-{
- mpic->senses = senses;
- mpic->senses_count = count;
-}
-
void __init mpic_init(struct mpic *mpic)
{
int i, cpu;
^ permalink raw reply related
* [PATCH 2/3] irq: Add IRQ_TYPE_DEFAULT for use by PIC drivers
From: Benjamin Herrenschmidt @ 2012-04-20 3:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Thomas Gleixner
This is meant typically to allow a PIC driver's irq domain map() callback
to establish sane defaults for the interrupt (and make sure that the HW
and the irq_desc are in sync as far as the trigger is concerned).
The irq core may not call the set_trigger callback if it thinks the
trigger is already set to the right setting, so we need to ensure new
descriptors are properly synchronized with the hardware.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
include/linux/irq.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 7810406..b27cfcf 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -49,6 +49,12 @@ typedef void (*irq_preflow_handler_t)(struct irq_data *data);
* IRQ_TYPE_LEVEL_LOW - low level triggered
* IRQ_TYPE_LEVEL_MASK - Mask to filter out the level bits
* IRQ_TYPE_SENSE_MASK - Mask for all the above bits
+ * IRQ_TYPE_DEFAULT - For use by some PICs to ask irq_set_type
+ * to setup the HW to a sane default (used
+ * by irqdomain map() callbacks to synchronize
+ * the HW state and SW flags for a newly
+ * allocated descriptor).
+ *
* IRQ_TYPE_PROBE - Special flag for probing in progress
*
* Bits which can be modified via irq_set/clear/modify_status_flags()
@@ -77,6 +83,7 @@ enum {
IRQ_TYPE_LEVEL_LOW = 0x00000008,
IRQ_TYPE_LEVEL_MASK = (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_LEVEL_HIGH),
IRQ_TYPE_SENSE_MASK = 0x0000000f,
+ IRQ_TYPE_DEFAULT = IRQ_TYPE_SENSE_MASK,
IRQ_TYPE_PROBE = 0x00000010,
^ permalink raw reply related
* [PATCH 1/3] powerpc/mpic: Fix confusion between hw_irq and virq
From: Benjamin Herrenschmidt @ 2012-04-20 3:29 UTC (permalink / raw)
To: linuxppc-dev
mpic_is_ipi() takes a virq and immediately converts it to a hw_irq.
However, one of the two call sites calls it with a ... hw_irq. The
other call site also happens to have the hw_irq at hand, so let's
change it to just take that as an argument. Also change mpic_is_tm()
for consistency.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/sysdev/mpic.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 9ac71eb..665b0f8 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -604,18 +604,14 @@ static struct mpic *mpic_find(unsigned int irq)
}
/* Determine if the linux irq is an IPI */
-static unsigned int mpic_is_ipi(struct mpic *mpic, unsigned int irq)
+static unsigned int mpic_is_ipi(struct mpic *mpic, unsigned int src)
{
- unsigned int src = virq_to_hw(irq);
-
return (src >= mpic->ipi_vecs[0] && src <= mpic->ipi_vecs[3]);
}
/* Determine if the linux irq is a timer */
-static unsigned int mpic_is_tm(struct mpic *mpic, unsigned int irq)
+static unsigned int mpic_is_tm(struct mpic *mpic, unsigned int src)
{
- unsigned int src = virq_to_hw(irq);
-
return (src >= mpic->timer_vecs[0] && src <= mpic->timer_vecs[7]);
}
@@ -1555,12 +1551,12 @@ void mpic_irq_set_priority(unsigned int irq, unsigned int pri)
return;
raw_spin_lock_irqsave(&mpic_lock, flags);
- if (mpic_is_ipi(mpic, irq)) {
+ if (mpic_is_ipi(mpic, src)) {
reg = mpic_ipi_read(src - mpic->ipi_vecs[0]) &
~MPIC_VECPRI_PRIORITY_MASK;
mpic_ipi_write(src - mpic->ipi_vecs[0],
reg | (pri << MPIC_VECPRI_PRIORITY_SHIFT));
- } else if (mpic_is_tm(mpic, irq)) {
+ } else if (mpic_is_tm(mpic, src)) {
reg = mpic_tm_read(src - mpic->timer_vecs[0]) &
~MPIC_VECPRI_PRIORITY_MASK;
mpic_tm_write(src - mpic->timer_vecs[0],
^ permalink raw reply related
* [PATCH 1/3] powerpc/mpic: Fix confusion between hw_irq and virq
From: Benjamin Herrenschmidt @ 2012-04-20 3:28 UTC (permalink / raw)
To: linuxppc-dev
mpic_is_ipi() takes a virq and immediately converts it to a hw_irq.
However, one of the two call sites calls it with a ... hw_irq. The
other call site also happens to have the hw_irq at hand, so let's
change it to just take that as an argument. Also change mpic_is_tm()
for consistency.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/sysdev/mpic.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 9ac71eb..665b0f8 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -604,18 +604,14 @@ static struct mpic *mpic_find(unsigned int irq)
}
/* Determine if the linux irq is an IPI */
-static unsigned int mpic_is_ipi(struct mpic *mpic, unsigned int irq)
+static unsigned int mpic_is_ipi(struct mpic *mpic, unsigned int src)
{
- unsigned int src = virq_to_hw(irq);
-
return (src >= mpic->ipi_vecs[0] && src <= mpic->ipi_vecs[3]);
}
/* Determine if the linux irq is a timer */
-static unsigned int mpic_is_tm(struct mpic *mpic, unsigned int irq)
+static unsigned int mpic_is_tm(struct mpic *mpic, unsigned int src)
{
- unsigned int src = virq_to_hw(irq);
-
return (src >= mpic->timer_vecs[0] && src <= mpic->timer_vecs[7]);
}
@@ -1555,12 +1551,12 @@ void mpic_irq_set_priority(unsigned int irq, unsigned int pri)
return;
raw_spin_lock_irqsave(&mpic_lock, flags);
- if (mpic_is_ipi(mpic, irq)) {
+ if (mpic_is_ipi(mpic, src)) {
reg = mpic_ipi_read(src - mpic->ipi_vecs[0]) &
~MPIC_VECPRI_PRIORITY_MASK;
mpic_ipi_write(src - mpic->ipi_vecs[0],
reg | (pri << MPIC_VECPRI_PRIORITY_SHIFT));
- } else if (mpic_is_tm(mpic, irq)) {
+ } else if (mpic_is_tm(mpic, src)) {
reg = mpic_tm_read(src - mpic->timer_vecs[0]) &
~MPIC_VECPRI_PRIORITY_MASK;
mpic_tm_write(src - mpic->timer_vecs[0],
^ permalink raw reply related
* [git pull] Please pull powerpc.git merge branch
From: Kumar Gala @ 2012-04-20 0:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Ben,
Some bug fix patches for v3.4.
- k
The following changes since commit fae2e0fb24c61ca68c98d854a34732549ebc1854:
powerpc: Fix typo in runlatch code (2012-04-11 10:42:15 +1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git merge
Baruch Siach (1):
powerpc: fix build when CONFIG_BOOKE_WDT is enabled
Mingkai Hu (4):
powerpc/mpic_msgr: fix compile error when SMP disabled
powerpc/mpic_msgr: add lock for MPIC message global variable
powerpc/mpic_msgr: fix offset error when setting mer register
powerpc/mpc85xx: add MPIC message dts node
Timur Tabi (1):
powerpc/85xx: don't call of_platform_bus_probe() twice
arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi | 43 +++++++++++++++++++++
arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi | 10 +++++
arch/powerpc/include/asm/mpic_msgr.h | 1 +
arch/powerpc/include/asm/reg_booke.h | 5 --
arch/powerpc/kernel/setup_32.c | 3 +
arch/powerpc/platforms/85xx/common.c | 6 +++
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 11 +-----
arch/powerpc/platforms/85xx/p1022_ds.c | 13 +------
arch/powerpc/sysdev/mpic_msgr.c | 12 +++---
9 files changed, 71 insertions(+), 33 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi
^ permalink raw reply
* Re: [PATCH 00/15] PowerMac i2c API conversions & windfarm updates
From: Benjamin Herrenschmidt @ 2012-04-19 20:59 UTC (permalink / raw)
To: Jean Delvare; +Cc: Christian Kujau, linuxppc-dev
In-Reply-To: <20120419113723.03a24d46@endymion.delvare>
On Thu, 2012-04-19 at 11:37 +0200, Jean Delvare wrote:
> Benjamin, thanks a lot for doing this! These drivers were the last ones
> blocking the removal of the legacy binding model in i2c-core.
There's a couple left :-) I haven't done therm_windtunnel.c (here too, I
need testers when I'm done) and our sound drivers are still using the
old API afaik, that's next on my list.
> Testers
> are very welcome. The earliest we can get these changes upstream, the
> better.
>
> Christian, can you please test this series? I'm sure Benjamin can send
> the patches to you directly if needed.
The main problem is that I don't have a Xserve G5 anymore to test,
that's one driver that largely rewritten and totally untested...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/mpc85xx: add MPIC message dts node
From: Kumar Gala @ 2012-04-19 20:15 UTC (permalink / raw)
To: Mingkai Hu; +Cc: linuxppc-dev
In-Reply-To: <1334541908-19331-4-git-send-email-Mingkai.hu@freescale.com>
On Apr 15, 2012, at 9:05 PM, Mingkai Hu wrote:
> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi | 43 =
+++++++++++++++++++++
> arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi | 10 +++++
> 2 files changed, 53 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi
applied to merge
- k=
^ permalink raw reply
* Re: [PATCH 3/4] powerpc/mpic_msgr: fix offset error when setting mer register
From: Kumar Gala @ 2012-04-19 20:15 UTC (permalink / raw)
To: Mingkai Hu; +Cc: linuxppc-dev
In-Reply-To: <1334541908-19331-3-git-send-email-Mingkai.hu@freescale.com>
On Apr 15, 2012, at 9:05 PM, Mingkai Hu wrote:
> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
> ---
> arch/powerpc/sysdev/mpic_msgr.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied to merge
- k
^ permalink raw reply
* Re: [PATCH 2/4] powerpc/mpic_msgr: add lock for MPIC message global variable
From: Kumar Gala @ 2012-04-19 20:15 UTC (permalink / raw)
To: Mingkai Hu; +Cc: linuxppc-dev
In-Reply-To: <1334541908-19331-2-git-send-email-Mingkai.hu@freescale.com>
On Apr 15, 2012, at 9:05 PM, Mingkai Hu wrote:
> Also fix issue of accessing invalid msgr pointer issue. The local
> msgr pointer in fucntion mpic_msgr_get will be accessed before
> getting a valid address which will cause kernel crash.
>
> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
> ---
> arch/powerpc/sysdev/mpic_msgr.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
applied to merge
- k
^ permalink raw reply
* Re: [PATCH 1/4] powerpc/mpic_msgr: fix compile error when SMP disabled
From: Kumar Gala @ 2012-04-19 20:15 UTC (permalink / raw)
To: Mingkai Hu; +Cc: linuxppc-dev
In-Reply-To: <1334541908-19331-1-git-send-email-Mingkai.hu@freescale.com>
On Apr 15, 2012, at 9:05 PM, Mingkai Hu wrote:
> In file included from arch/powerpc/sysdev/mpic_msgr.c:20:0:
> ~/arch/powerpc/include/asm/mpic_msgr.h: In function =
'mpic_msgr_set_destination':
> ~/arch/powerpc/include/asm/mpic_msgr.h:117:2:
> error: implicit declaration of function 'get_hard_smp_processor_id'
> make[1]: *** [arch/powerpc/sysdev/mpic_msgr.o] Error 1
>=20
> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
> ---
> arch/powerpc/include/asm/mpic_msgr.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
applied to merge
- k=
^ permalink raw reply
* Re: [PATCH] powerpc: fix build when CONFIG_BOOKE_WDT is enabled
From: Kumar Gala @ 2012-04-19 20:15 UTC (permalink / raw)
To: Baruch Siach; +Cc: David Howells, linuxppc-dev
In-Reply-To: <4c2709df9123c32681503972be3707026c9dab74.1334816894.git.baruch@tkos.co.il>
On Apr 19, 2012, at 1:32 AM, Baruch Siach wrote:
> Commit ae3a197e (Disintegrate asm/system.h for PowerPC) broke build of
> assembly files when CONFIG_BOOKE_WDT is enabled as follows:
>=20
> AS arch/powerpc/lib/string.o
> /home/baruch/git/stable/arch/powerpc/include/asm/reg_booke.h: =
Assembler messages:
> /home/baruch/git/stable/arch/powerpc/include/asm/reg_booke.h:19: =
Error: Unrecognized opcode: `extern'
> /home/baruch/git/stable/arch/powerpc/include/asm/reg_booke.h:20: =
Error: Unrecognized opcode: `extern'
>=20
> Since setup_32.c is the only user of the booke_wdt configuration =
variables, move
> the declarations there.
>=20
> Cc: David Howells <dhowells@redhat.com>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> arch/powerpc/include/asm/reg_booke.h | 5 -----
> arch/powerpc/kernel/setup_32.c | 5 +++++
> 2 files changed, 5 insertions(+), 5 deletions(-)
applied to merge, minor moving of the externs to be in same ifdef in =
setup_32.c
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: don't call of_platform_bus_probe() twice
From: Kumar Gala @ 2012-04-19 20:15 UTC (permalink / raw)
To: Timur Tabi; +Cc: scottwood, dbaryshkov, linuxppc-dev
In-Reply-To: <1322669957-8259-1-git-send-email-timur@freescale.com>
On Nov 30, 2011, at 10:19 AM, Timur Tabi wrote:
> Commit 46d026ac ("powerpc/85xx: consolidate of_platform_bus_probe calls")
> replaced platform-specific of_device_id tables with a single function
> that probes the most of the busses in 85xx device trees. If a specific
> platform needed additional busses probed, then it could call
> of_platform_bus_probe() again. Typically, the additional platform-specific
> busses are children of existing busses that have already been probed.
> of_platform_bus_probe() does not handle those child busses automatically.
>
> Unfortunately, this doesn't actually work. The second (platform-specific)
> call to of_platform_bus_probe() never finds any of the busses it's asked
> to find.
>
> To remedy this, the platform-specific of_device_id tables are eliminated,
> and their entries are merged into mpc85xx_common_ids[], so that all busses
> are probed at once.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> arch/powerpc/platforms/85xx/common.c | 6 ++++++
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 11 +----------
> arch/powerpc/platforms/85xx/p1022_ds.c | 13 +------------
> 3 files changed, 8 insertions(+), 22 deletions(-)
applied to merge
- k
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Grant Likely @ 2012-04-19 18:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Russell King - ARM Linux, devicetree-discuss, linux-kernel,
Rob Herring, Andreas Schwab, Milton Miller, Thomas Gleixner,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <1334180248.2984.39.camel@pasglop>
On Thu, 12 Apr 2012 07:37:28 +1000, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Wed, 2012-04-11 at 14:57 -0600, Grant Likely wrote:
> >
> > Yeah, I've got a different way to fix it though. There is exactly one
> > user of irq_virq_count in-tree right now: PS3. Also, irq_virq_count
> > is only useful for the NOMAP mapping. So, instead of having a single
> > global irq_virq_count values, I've dropped it entirely and added a
> > max_irq argument to irq_domain_add_nomap(). That makes it a property
> > of an individual nomap irq domain instead of a global system settting.
> >
> > Hopefully I'll have a draft patch ready today.
>
> That works for me. I'll send patches for cleanup MPIC as well.
Okay, I'll wait on these. The MPIC fixes will need to be applied
before I can apply the automatic revmapping and hint removal patches.
Those patches will also need testing before I apply to linux-next.
g.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox