* Re: pci_pcie_cap invalid on AER/EEH enabled PPC?
From: Jon Mason @ 2011-07-05 16:18 UTC (permalink / raw)
To: Richard A Lary; +Cc: linux-pci, linuxppc-dev, Richard Lary, James Smart, davem
In-Reply-To: <4E1330A3.8080004@linux.vnet.ibm.com>
On Tue, Jul 5, 2011 at 10:41 AM, Richard A Lary
<rlary@linux.vnet.ibm.com> wrote:
> On 7/1/2011 1:00 PM, Richard A Lary wrote:
>>
>> On 7/1/2011 12:02 PM, Jon Mason wrote:
>>>
>>> On Fri, Jul 1, 2011 at 1:30 PM, Richard A Lary<rlary@linux.vnet.ibm.com=
>
>>> wrote:
>>>>
>>>> On 7/1/2011 8:24 AM, Jon Mason wrote:
>>>>>
>>>>> I recently sent out a number of patches to migrate drivers calling
>>>>> `pci_find_capability(pdef, PCI_CAP_ID_EXP)` to pci_pcie_cap. This
>>>>> function takes uses a PCI-E capability offset that was determined by
>>>>> calling pci_find_capability during the PCI bus walking. In response
>>>>> to one of the patches, James Smart posted:
>>>>>
>>>>> "The reason is due to an issue on PPC platforms whereby use of
>>>>> "pdev->is_pcie" and pci_is_pcie() will erroneously fail under some
>>>>> conditions, but explicit search for the capability struct via
>>>>> pci_find_capability() is always successful. I expect this to be due
>>>>> a shadowing of pci config space in the hal/platform that isn't
>>>>> sufficiently built up. We detected this issue while testing AER/EEH,
>>>>> and are functional only if the pci_find_capability() option is used."
>>>>>
>>>>> See http://marc.info/?l=3Dlinux-scsi&m=3D130946649427828&w=3D2 for th=
e whole
>>>>> post.
>>>>>
>>>>> Based on his description above pci_pcie_cap
>>>>> andpci_find_capability(pdef, PCI_CAP_ID_EXP) should be functionally
>>>>> equivalent. If this is not safe, then the PCI bus walking code is
>>>>> most likely busted on EEH enabled PPC systems (and that is a BIG
>>>>> problem). Can anyone confirm this is still an issue?
>>>>
>>>> Jon,
>>>>
>>>> I applied the following debug patch to lpfc driver in a 2.6.32 distro
>>>> kernel ( I had this one handy, I can try with mainline later today )
>>>>
>>>> ---
>>>> drivers/scsi/lpfc/lpfc_init.c | 10 10 + 0 - 0 !
>>>> 1 file changed, 10 insertions(+)
>>>>
>>>> Index: b/drivers/scsi/lpfc/lpfc_init.c
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>> --- a/drivers/scsi/lpfc/lpfc_init.c
>>>> +++ b/drivers/scsi/lpfc/lpfc_init.c
>>>> @@ -3958,6 +3958,16 @@ lpfc_enable_pci_dev(struct lpfc_hba *phb
>>>> pci_try_set_mwi(pdev);
>>>> pci_save_state(pdev);
>>>>
>>>> + printk(KERN_WARNING "pcicap: is_pcie=3D%x pci_cap=3D%x pcie_type=3D%=
x\n",
>>>> + pdev->is_pcie,
>>>> + pdev->pcie_cap,
>>>> + pdev->pcie_type);
>>>> +
>>>> + if (pci_is_pcie(pdev))
>>>> + printk(KERN_WARNING "pcicap: true\n");
>>>> + else
>>>> + printk(KERN_WARNING "pcicap: false\n");
>>>> +
>>>> /* PCIe EEH recovery on powerpc platforms needs fundamental reset */
>>>> if (pci_find_capability(pdev, PCI_CAP_ID_EXP))
>>>> pdev->needs_freset =3D 1;
>>>>
>>>> This is output upon driver load on an IBM Power 7 model 8233-E8B serve=
r.
>>>>
>>>> dmesg | grep pcicap
>>>> Linux version 2.6.32.42-pcicap-ppc64 (geeko@buildhost) (gcc version
>>>> 4.3.4
>>>> [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Fri Jul 1
>>>> 09:31:27
>>>> PDT 2011
>>>> pcicap: is_pcie=3D0 pci_cap=3D0 pcie_type=3D0
>>>> pcicap: false
>>>> pcicap: is_pcie=3D0 pci_cap=3D0 pcie_type=3D0
>>>> pcicap: false
>>>> pcicap: is_pcie=3D0 pci_cap=3D0 pcie_type=3D0
>>>> pcicap: false
>>>> pcicap: is_pcie=3D0 pci_cap=3D0 pcie_type=3D0
>>>> pcicap: false
>>>>
>>>> It would appear that the pcie information is not set in pci_dev
>>>> structure
>>>> for
>>>> this device at the time the driver is being initialized during boot.
>>>
>>> Thanks for trying this. Can you confirm that the other devices in the
>>> system have this issue as well (or show that it is isolated to the lpr
>>> device)? You can add printks in set_pcie_port_type() to verify what
>>> is being set on bus walking and to see when it is being called with
>>> respect to when it is being populated by firmware.
>>
>> Jon,
>>
>> I will give this suggestion a try and post results
>
> On Power PC platforms, set_pcie_port_type() is not called. =A0On Power PC=
,
> pci_dev structure is initialized by of_create_pci_dev(). =A0However, the
> structure member pcie_cap is NOT computed nor set in this function.
Yes, it is. of_create_pci_dev() calls set_pcie_port_type()
http://lxr.linux.no/linux+v2.6.39/arch/powerpc/kernel/pci_of_scan.c#L144
That function sets pdev->pcie_cap
http://lxr.linux.no/linux+v2.6.39/drivers/pci/probe.c#L896
So, it should be set. It looks like there is a bug in
of_create_pci_dev, as set_pcie_port_type is being called BEFORE the
BARs are setup. If you move set_pcie_port_type prior to
pci_device_add (perhaps even after), then I bet the issue is resolved.
Thanks,
Jon
> The information used to populate pci_dev comes from the Power PC
> device_tree passed to the OS by Open Firmware.
>
> Based upon standing Power PC design, we cannot support patches
> which replace pci_find_capability(pdef, PCI_CAP_ID_EXP) with
> pci_is_pcie(pdev) on Power PC platforms.
>
> -rich
>
>
^ permalink raw reply
* Re: pci_pcie_cap invalid on AER/EEH enabled PPC?
From: Richard A Lary @ 2011-07-05 15:41 UTC (permalink / raw)
To: Jon Mason; +Cc: linux-pci, linuxppc-dev, Richard Lary, James Smart, davem
In-Reply-To: <4E0E274C.4000402@linux.vnet.ibm.com>
On 7/1/2011 1:00 PM, Richard A Lary wrote:
> On 7/1/2011 12:02 PM, Jon Mason wrote:
>> On Fri, Jul 1, 2011 at 1:30 PM, Richard A Lary<rlary@linux.vnet.ibm.com> wrote:
>>> On 7/1/2011 8:24 AM, Jon Mason wrote:
>>>>
>>>> I recently sent out a number of patches to migrate drivers calling
>>>> `pci_find_capability(pdef, PCI_CAP_ID_EXP)` to pci_pcie_cap. This
>>>> function takes uses a PCI-E capability offset that was determined by
>>>> calling pci_find_capability during the PCI bus walking. In response
>>>> to one of the patches, James Smart posted:
>>>>
>>>> "The reason is due to an issue on PPC platforms whereby use of
>>>> "pdev->is_pcie" and pci_is_pcie() will erroneously fail under some
>>>> conditions, but explicit search for the capability struct via
>>>> pci_find_capability() is always successful. I expect this to be due
>>>> a shadowing of pci config space in the hal/platform that isn't
>>>> sufficiently built up. We detected this issue while testing AER/EEH,
>>>> and are functional only if the pci_find_capability() option is used."
>>>>
>>>> See http://marc.info/?l=linux-scsi&m=130946649427828&w=2 for the whole
>>>> post.
>>>>
>>>> Based on his description above pci_pcie_cap
>>>> andpci_find_capability(pdef, PCI_CAP_ID_EXP) should be functionally
>>>> equivalent. If this is not safe, then the PCI bus walking code is
>>>> most likely busted on EEH enabled PPC systems (and that is a BIG
>>>> problem). Can anyone confirm this is still an issue?
>>>
>>> Jon,
>>>
>>> I applied the following debug patch to lpfc driver in a 2.6.32 distro
>>> kernel ( I had this one handy, I can try with mainline later today )
>>>
>>> ---
>>> drivers/scsi/lpfc/lpfc_init.c | 10 10 + 0 - 0 !
>>> 1 file changed, 10 insertions(+)
>>>
>>> Index: b/drivers/scsi/lpfc/lpfc_init.c
>>> ===================================================================
>>> --- a/drivers/scsi/lpfc/lpfc_init.c
>>> +++ b/drivers/scsi/lpfc/lpfc_init.c
>>> @@ -3958,6 +3958,16 @@ lpfc_enable_pci_dev(struct lpfc_hba *phb
>>> pci_try_set_mwi(pdev);
>>> pci_save_state(pdev);
>>>
>>> + printk(KERN_WARNING "pcicap: is_pcie=%x pci_cap=%x pcie_type=%x\n",
>>> + pdev->is_pcie,
>>> + pdev->pcie_cap,
>>> + pdev->pcie_type);
>>> +
>>> + if (pci_is_pcie(pdev))
>>> + printk(KERN_WARNING "pcicap: true\n");
>>> + else
>>> + printk(KERN_WARNING "pcicap: false\n");
>>> +
>>> /* PCIe EEH recovery on powerpc platforms needs fundamental reset */
>>> if (pci_find_capability(pdev, PCI_CAP_ID_EXP))
>>> pdev->needs_freset = 1;
>>>
>>> This is output upon driver load on an IBM Power 7 model 8233-E8B server.
>>>
>>> dmesg | grep pcicap
>>> Linux version 2.6.32.42-pcicap-ppc64 (geeko@buildhost) (gcc version 4.3.4
>>> [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Fri Jul 1 09:31:27
>>> PDT 2011
>>> pcicap: is_pcie=0 pci_cap=0 pcie_type=0
>>> pcicap: false
>>> pcicap: is_pcie=0 pci_cap=0 pcie_type=0
>>> pcicap: false
>>> pcicap: is_pcie=0 pci_cap=0 pcie_type=0
>>> pcicap: false
>>> pcicap: is_pcie=0 pci_cap=0 pcie_type=0
>>> pcicap: false
>>>
>>> It would appear that the pcie information is not set in pci_dev structure
>>> for
>>> this device at the time the driver is being initialized during boot.
>>
>> Thanks for trying this. Can you confirm that the other devices in the
>> system have this issue as well (or show that it is isolated to the lpr
>> device)? You can add printks in set_pcie_port_type() to verify what
>> is being set on bus walking and to see when it is being called with
>> respect to when it is being populated by firmware.
>
> Jon,
>
> I will give this suggestion a try and post results
On Power PC platforms, set_pcie_port_type() is not called. On Power PC,
pci_dev structure is initialized by of_create_pci_dev(). However, the
structure member pcie_cap is NOT computed nor set in this function.
The information used to populate pci_dev comes from the Power PC
device_tree passed to the OS by Open Firmware.
Based upon standing Power PC design, we cannot support patches
which replace pci_find_capability(pdef, PCI_CAP_ID_EXP) with
pci_is_pcie(pdev) on Power PC platforms.
-rich
^ permalink raw reply
* Re: pci_pcie_cap invalid on AER/EEH enabled PPC?
From: Richard A Lary @ 2011-07-05 17:22 UTC (permalink / raw)
To: Jon Mason
Cc: James Smart, linux-pci, Anton Blanchard, Richard Lary,
linuxppc-dev, davem
In-Reply-To: <CAPoiz9wArpezPaovSwKVCX3whGRmbAcYjywKX_dUng7wSeW7KQ@mail.gmail.com>
On 7/5/2011 9:18 AM, Jon Mason wrote:
> On Tue, Jul 5, 2011 at 10:41 AM, Richard A Lary
> <rlary@linux.vnet.ibm.com> wrote:
>> On 7/1/2011 1:00 PM, Richard A Lary wrote:
>>>
>>> On 7/1/2011 12:02 PM, Jon Mason wrote:
>>>>
>>>> On Fri, Jul 1, 2011 at 1:30 PM, Richard A Lary<rlary@linux.vnet.ibm.com>
>>>> wrote:
>>>>>
>>>>> On 7/1/2011 8:24 AM, Jon Mason wrote:
>>>>>>
>>>>>> I recently sent out a number of patches to migrate drivers calling
>>>>>> `pci_find_capability(pdef, PCI_CAP_ID_EXP)` to pci_pcie_cap. This
>>>>>> function takes uses a PCI-E capability offset that was determined by
>>>>>> calling pci_find_capability during the PCI bus walking. In response
>>>>>> to one of the patches, James Smart posted:
>>>>>>
>>>>>> "The reason is due to an issue on PPC platforms whereby use of
>>>>>> "pdev->is_pcie" and pci_is_pcie() will erroneously fail under some
>>>>>> conditions, but explicit search for the capability struct via
>>>>>> pci_find_capability() is always successful. I expect this to be due
>>>>>> a shadowing of pci config space in the hal/platform that isn't
>>>>>> sufficiently built up. We detected this issue while testing AER/EEH,
>>>>>> and are functional only if the pci_find_capability() option is used."
>>>>>>
>>>>>> See http://marc.info/?l=linux-scsi&m=130946649427828&w=2 for the whole
>>>>>> post.
>>>>>>
>>>>>> Based on his description above pci_pcie_cap
>>>>>> andpci_find_capability(pdef, PCI_CAP_ID_EXP) should be functionally
>>>>>> equivalent. If this is not safe, then the PCI bus walking code is
>>>>>> most likely busted on EEH enabled PPC systems (and that is a BIG
>>>>>> problem). Can anyone confirm this is still an issue?
>>>>>
>>>>> Jon,
>>>>>
>>>>> I applied the following debug patch to lpfc driver in a 2.6.32 distro
>>>>> kernel ( I had this one handy, I can try with mainline later today )
>>>>>
>>>>> ---
>>>>> drivers/scsi/lpfc/lpfc_init.c | 10 10 + 0 - 0 !
>>>>> 1 file changed, 10 insertions(+)
>>>>>
>>>>> Index: b/drivers/scsi/lpfc/lpfc_init.c
>>>>> ===================================================================
>>>>> --- a/drivers/scsi/lpfc/lpfc_init.c
>>>>> +++ b/drivers/scsi/lpfc/lpfc_init.c
>>>>> @@ -3958,6 +3958,16 @@ lpfc_enable_pci_dev(struct lpfc_hba *phb
>>>>> pci_try_set_mwi(pdev);
>>>>> pci_save_state(pdev);
>>>>>
>>>>> + printk(KERN_WARNING "pcicap: is_pcie=%x pci_cap=%x pcie_type=%x\n",
>>>>> + pdev->is_pcie,
>>>>> + pdev->pcie_cap,
>>>>> + pdev->pcie_type);
>>>>> +
>>>>> + if (pci_is_pcie(pdev))
>>>>> + printk(KERN_WARNING "pcicap: true\n");
>>>>> + else
>>>>> + printk(KERN_WARNING "pcicap: false\n");
>>>>> +
>>>>> /* PCIe EEH recovery on powerpc platforms needs fundamental reset */
>>>>> if (pci_find_capability(pdev, PCI_CAP_ID_EXP))
>>>>> pdev->needs_freset = 1;
>>>>>
>>>>> This is output upon driver load on an IBM Power 7 model 8233-E8B server.
>>>>>
>>>>> dmesg | grep pcicap
>>>>> Linux version 2.6.32.42-pcicap-ppc64 (geeko@buildhost) (gcc version
>>>>> 4.3.4
>>>>> [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Fri Jul 1
>>>>> 09:31:27
>>>>> PDT 2011
>>>>> pcicap: is_pcie=0 pci_cap=0 pcie_type=0
>>>>> pcicap: false
>>>>> pcicap: is_pcie=0 pci_cap=0 pcie_type=0
>>>>> pcicap: false
>>>>> pcicap: is_pcie=0 pci_cap=0 pcie_type=0
>>>>> pcicap: false
>>>>> pcicap: is_pcie=0 pci_cap=0 pcie_type=0
>>>>> pcicap: false
>>>>>
>>>>> It would appear that the pcie information is not set in pci_dev
>>>>> structure
>>>>> for
>>>>> this device at the time the driver is being initialized during boot.
>>>>
>>>> Thanks for trying this. Can you confirm that the other devices in the
>>>> system have this issue as well (or show that it is isolated to the lpr
>>>> device)? You can add printks in set_pcie_port_type() to verify what
>>>> is being set on bus walking and to see when it is being called with
>>>> respect to when it is being populated by firmware.
>>>
>>> Jon,
>>>
>>> I will give this suggestion a try and post results
>>
>> On Power PC platforms, set_pcie_port_type() is not called. On Power PC,
>> pci_dev structure is initialized by of_create_pci_dev(). However, the
>> structure member pcie_cap is NOT computed nor set in this function.
>
> Yes, it is. of_create_pci_dev() calls set_pcie_port_type()
> http://lxr.linux.no/linux+v2.6.39/arch/powerpc/kernel/pci_of_scan.c#L144
>
> That function sets pdev->pcie_cap
> http://lxr.linux.no/linux+v2.6.39/drivers/pci/probe.c#L896
>
> So, it should be set. It looks like there is a bug in
> of_create_pci_dev, as set_pcie_port_type is being called BEFORE the
> BARs are setup. If you move set_pcie_port_type prior to
> pci_device_add (perhaps even after), then I bet the issue is resolved.
>
The claim above was based upon observation that with this patch applied
to a 2.6.32 kernel, the printk output did not appear in dmesg upon boot.
static void set_pcie_hotplug_bridge(struct pci_dev *pdev)
@@ -774,6 +780,8 @@ int pci_setup_device(struct pci_dev *dev
u8 hdr_type;
struct pci_slot *slot;
+ printk(KERN_WARNING "pcicap: setup_device %p\n", dev);
+
if (pci_read_config_byte(dev, PCI_HEADER_TYPE, &hdr_type))
return -EIO;
I can make no claim about my understanding of pci device initialization
on Power PC, so I have added Anton Blanchard to the cc list.
Perhaps Anton can explain why pcie_cap is always 0 on Power PC.
-rich
>
>> The information used to populate pci_dev comes from the Power PC
>> device_tree passed to the OS by Open Firmware.
>>
>> Based upon standing Power PC design, we cannot support patches
>> which replace pci_find_capability(pdef, PCI_CAP_ID_EXP) with
>> pci_is_pcie(pdev) on Power PC platforms.
>>
>> -rich
>>
>>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] spi/fsl_spi: fix CPM spi driver
From: Grant Likely @ 2011-07-05 18:00 UTC (permalink / raw)
To: Holger Brunck; +Cc: spi-devel-general, linuxppc-dev
In-Reply-To: <1308587517-20640-1-git-send-email-holger.brunck@keymile.com>
On Mon, Jun 20, 2011 at 06:31:57PM +0200, Holger Brunck wrote:
> This patch fixes the freescale spi driver for CPM. Without this
> patch SPI on CPM failed because cpm_muram_alloc_fixed tries to
> allocate muram in an preserved area. The error reported was:
>
> mpc8xxx_spi f0011a80.spi: can't allocate spi parameter ram
> mpc8xxx_spi: probe of f0011a80.spi failed with error -12
>
> Now the driver uses of_iomap to get access to this area
> similar to i2c driver driver in the i2c-cpm.c which has a
> similar device tree node. This is tested on a MPC8247 with CPM2.
>
> Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
> cc: Grant Likely <grant.likely@secretlab.ca>
> cc: spi-devel-general@lists.sourceforge.net
Applied, thanks.
g.
> ---
> This was the same problem reported and discussed on ppc-dev for CPM1:
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-September/085739.html
>
> drivers/spi/spi_fsl_spi.c | 28 +++++++++++-----------------
> 1 files changed, 11 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/spi/spi_fsl_spi.c b/drivers/spi/spi_fsl_spi.c
> index 7963c9b..ca57edf 100644
> --- a/drivers/spi/spi_fsl_spi.c
> +++ b/drivers/spi/spi_fsl_spi.c
> @@ -684,7 +684,7 @@ static unsigned long fsl_spi_cpm_get_pram(struct mpc8xxx_spi *mspi)
> struct device_node *np = dev->of_node;
> const u32 *iprop;
> int size;
> - unsigned long spi_base_ofs;
> + void __iomem *spi_base;
> unsigned long pram_ofs = -ENOMEM;
>
> /* Can't use of_address_to_resource(), QE muram isn't at 0. */
> @@ -702,33 +702,27 @@ static unsigned long fsl_spi_cpm_get_pram(struct mpc8xxx_spi *mspi)
> return pram_ofs;
> }
>
> - /* CPM1 and CPM2 pram must be at a fixed addr. */
> - if (!iprop || size != sizeof(*iprop) * 4)
> - return -ENOMEM;
> -
> - spi_base_ofs = cpm_muram_alloc_fixed(iprop[2], 2);
> - if (IS_ERR_VALUE(spi_base_ofs))
> - return -ENOMEM;
> + spi_base = of_iomap(np, 1);
> + if (spi_base == NULL)
> + return -EINVAL;
>
> if (mspi->flags & SPI_CPM2) {
> pram_ofs = cpm_muram_alloc(SPI_PRAM_SIZE, 64);
> - if (!IS_ERR_VALUE(pram_ofs)) {
> - u16 __iomem *spi_base = cpm_muram_addr(spi_base_ofs);
> -
> - out_be16(spi_base, pram_ofs);
> - }
> + out_be16(spi_base, pram_ofs);
> } else {
> - struct spi_pram __iomem *pram = cpm_muram_addr(spi_base_ofs);
> + struct spi_pram __iomem *pram = spi_base;
> u16 rpbase = in_be16(&pram->rpbase);
>
> /* Microcode relocation patch applied? */
> if (rpbase)
> pram_ofs = rpbase;
> - else
> - return spi_base_ofs;
> + else {
> + pram_ofs = cpm_muram_alloc(SPI_PRAM_SIZE, 64);
> + out_be16(spi_base, pram_ofs);
> + }
> }
>
> - cpm_muram_free(spi_base_ofs);
> + iounmap(spi_base);
> return pram_ofs;
> }
>
> --
> 1.7.1
>
^ permalink raw reply
* Re: [PATCH] spi/fsl_spi: fix CPM spi driver
From: Grant Likely @ 2011-07-05 18:00 UTC (permalink / raw)
To: Holger Brunck; +Cc: spi-devel-general, linuxppc-dev
In-Reply-To: <4E132056.4000301@keymile.com>
On Tue, Jul 05, 2011 at 04:31:50PM +0200, Holger Brunck wrote:
> Hi Grant,
> is this patch in your eyes ok to be scheduled for the next linux merge window or
> is something missing? Or should it go through the powerpc tree and not through
> your spi tree?
No, I just hadn't gotten to it yet. Sometimes I need to be pinged.
I've merged it.
g.
>
> Please let me know your opinion.
>
> Best regards
> Holger Brunck
>
> On 06/20/2011 06:31 PM, Holger Brunck wrote:
> > This patch fixes the freescale spi driver for CPM. Without this
> > patch SPI on CPM failed because cpm_muram_alloc_fixed tries to
> > allocate muram in an preserved area. The error reported was:
> >
> > mpc8xxx_spi f0011a80.spi: can't allocate spi parameter ram
> > mpc8xxx_spi: probe of f0011a80.spi failed with error -12
> >
> > Now the driver uses of_iomap to get access to this area
> > similar to i2c driver driver in the i2c-cpm.c which has a
> > similar device tree node. This is tested on a MPC8247 with CPM2.
> >
> > Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
> > cc: Grant Likely <grant.likely@secretlab.ca>
> > cc: spi-devel-general@lists.sourceforge.net
> > ---
> > This was the same problem reported and discussed on ppc-dev for CPM1:
> > http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-September/085739.html
> >
> > drivers/spi/spi_fsl_spi.c | 28 +++++++++++-----------------
> > 1 files changed, 11 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/spi/spi_fsl_spi.c b/drivers/spi/spi_fsl_spi.c
> > index 7963c9b..ca57edf 100644
> > --- a/drivers/spi/spi_fsl_spi.c
> > +++ b/drivers/spi/spi_fsl_spi.c
> > @@ -684,7 +684,7 @@ static unsigned long fsl_spi_cpm_get_pram(struct mpc8xxx_spi *mspi)
> > struct device_node *np = dev->of_node;
> > const u32 *iprop;
> > int size;
> > - unsigned long spi_base_ofs;
> > + void __iomem *spi_base;
> > unsigned long pram_ofs = -ENOMEM;
> >
> > /* Can't use of_address_to_resource(), QE muram isn't at 0. */
> > @@ -702,33 +702,27 @@ static unsigned long fsl_spi_cpm_get_pram(struct mpc8xxx_spi *mspi)
> > return pram_ofs;
> > }
> >
> > - /* CPM1 and CPM2 pram must be at a fixed addr. */
> > - if (!iprop || size != sizeof(*iprop) * 4)
> > - return -ENOMEM;
> > -
> > - spi_base_ofs = cpm_muram_alloc_fixed(iprop[2], 2);
> > - if (IS_ERR_VALUE(spi_base_ofs))
> > - return -ENOMEM;
> > + spi_base = of_iomap(np, 1);
> > + if (spi_base == NULL)
> > + return -EINVAL;
> >
> > if (mspi->flags & SPI_CPM2) {
> > pram_ofs = cpm_muram_alloc(SPI_PRAM_SIZE, 64);
> > - if (!IS_ERR_VALUE(pram_ofs)) {
> > - u16 __iomem *spi_base = cpm_muram_addr(spi_base_ofs);
> > -
> > - out_be16(spi_base, pram_ofs);
> > - }
> > + out_be16(spi_base, pram_ofs);
> > } else {
> > - struct spi_pram __iomem *pram = cpm_muram_addr(spi_base_ofs);
> > + struct spi_pram __iomem *pram = spi_base;
> > u16 rpbase = in_be16(&pram->rpbase);
> >
> > /* Microcode relocation patch applied? */
> > if (rpbase)
> > pram_ofs = rpbase;
> > - else
> > - return spi_base_ofs;
> > + else {
> > + pram_ofs = cpm_muram_alloc(SPI_PRAM_SIZE, 64);
> > + out_be16(spi_base, pram_ofs);
> > + }
> > }
> >
> > - cpm_muram_free(spi_base_ofs);
> > + iounmap(spi_base);
> > return pram_ofs;
> > }
> >
>
^ permalink raw reply
* Re: NAND BBT corruption on MPC83xx
From: Matthew L. Creech @ 2011-07-05 19:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linux-mtd, linuxppc-dev
In-Reply-To: <20110617163442.204348a0@schlenkerla.am.freescale.net>
On Fri, Jun 17, 2011 at 5:34 PM, Scott Wood <scottwood@freescale.com> wrote=
:
>
> It seems that the generic code always passes -1 with PAGEPROG, and only
> provides the actual page address on SEQIN.
>
> I don't think the ECC readback is needed, and the fact that it looks like
> it has always been broken would seem to confirm that. =A0It's broken in
> other ways, too -- it assumes a particular ECC layout. =A0Let's get rid o=
f it.
>
> As for the corruption, could it be degradation from repeated reads of tha=
t
> one page?
>
I modified nanddump to do repeated reads, and compare the data
obtained from the first iteration with that obtained later (to detect
bit-flips). I tried 3 different variations:
- one which reads the first page (2k) of the last block
- one which reads the second page (2k) of the last block
- one which reads the entire last block (128k), just for comparison
As I understand it, read-disturb would primarily come into play when
the second page is read, since it's adjacent to the first page (please
correct me if I'm wrong there). Anyway, all 3 of these tests were run
for at least 50 million read cycles, with no bit-flips detected. So
I'm somewhat doubtful that this is the cause of the BBT corruption
I've been seeing.
=3D=3D=3D=3D
Separately, I set up 2 test devices to run while I was away last week.
One of them contained 2 patches:
- Mike Hench's patch which eliminates this block of code in fsl_elbc_nand.c
- Adam Thomson's patch
(http://lists.infradead.org/pipermail/linux-mtd/2011-June/036427.html)
which initializes oob_poi correctly
Upon my return, the device with these patches saw no problems at all,
and had no additional bad blocks. The device without these patches
had some 200+ blocks which had been newly marked as bad in the BBT
over the course of 10 days. After rebooting, this latter device then
failed to boot, as shown here:
http://mcreech.com/work/bbt-ecc-error4.txt
I'm currently running another test to verify which of the two patches
actually fixed this problem (which might take a few days), but it
seems like removing that block of code in fsl_elbc_nand.c is a good
idea.
--=20
Matthew L. Creech
^ permalink raw reply
* [PATCH] mtd: eLBC NAND: remove bogus ECC read-back
From: Matthew L. Creech @ 2011-07-05 19:59 UTC (permalink / raw)
To: linux-mtd; +Cc: scottwood, linuxppc-dev, rick22, mhench
In-Reply-To: <CAPBSBxqRywJjCfk_iuDLxn1HbuqPjJRJS=SkRQ3-Ge7SinbSBg@mail.gmail.com>
From: Mike Hench <mhench@elutions.com>
The eLBC NAND driver currently follows up each program/write operation with a
read-back of the page, in order to [ostensibly] fill in ECC data for the
caller. However, the page address used for this read is always -1, so the read
will never work correctly. Remove this useless (and potentially problematic)
block of code.
Signed-off-by: Matthew L. Creech <mlcreech@gmail.com>
---
drivers/mtd/nand/fsl_elbc_nand.c | 17 -----------------
1 files changed, 0 insertions(+), 17 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 0bb254c..050a2fc 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -455,23 +455,6 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
fsl_elbc_run_command(mtd);
- /* Read back the page in order to fill in the ECC for the
- * caller. Is this really needed?
- */
- if (full_page && elbc_fcm_ctrl->oob_poi) {
- out_be32(&lbc->fbcr, 3);
- set_addr(mtd, 6, page_addr, 1);
-
- elbc_fcm_ctrl->read_bytes = mtd->writesize + 9;
-
- fsl_elbc_do_read(chip, 1);
- fsl_elbc_run_command(mtd);
-
- memcpy_fromio(elbc_fcm_ctrl->oob_poi + 6,
- &elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index], 3);
- elbc_fcm_ctrl->index += 3;
- }
-
elbc_fcm_ctrl->oob_poi = NULL;
return;
}
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] mtd: eLBC NAND: remove bogus ECC read-back
From: Scott Wood @ 2011-07-05 20:15 UTC (permalink / raw)
To: Matthew L. Creech; +Cc: linuxppc-dev, linux-mtd, mhench, rick22
In-Reply-To: <1309895997-29969-1-git-send-email-mlcreech@gmail.com>
On Tue, 5 Jul 2011 15:59:57 -0400
"Matthew L. Creech" <mlcreech@gmail.com> wrote:
> From: Mike Hench <mhench@elutions.com>
>
> The eLBC NAND driver currently follows up each program/write operation with a
> read-back of the page, in order to [ostensibly] fill in ECC data for the
> caller. However, the page address used for this read is always -1, so the read
> will never work correctly. Remove this useless (and potentially problematic)
> block of code.
>
> Signed-off-by: Matthew L. Creech <mlcreech@gmail.com>
> ---
> drivers/mtd/nand/fsl_elbc_nand.c | 17 -----------------
> 1 files changed, 0 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
> index 0bb254c..050a2fc 100644
> --- a/drivers/mtd/nand/fsl_elbc_nand.c
> +++ b/drivers/mtd/nand/fsl_elbc_nand.c
> @@ -455,23 +455,6 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
>
> fsl_elbc_run_command(mtd);
>
> - /* Read back the page in order to fill in the ECC for the
> - * caller. Is this really needed?
> - */
> - if (full_page && elbc_fcm_ctrl->oob_poi) {
> - out_be32(&lbc->fbcr, 3);
> - set_addr(mtd, 6, page_addr, 1);
> -
> - elbc_fcm_ctrl->read_bytes = mtd->writesize + 9;
> -
> - fsl_elbc_do_read(chip, 1);
> - fsl_elbc_run_command(mtd);
> -
> - memcpy_fromio(elbc_fcm_ctrl->oob_poi + 6,
> - &elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index], 3);
> - elbc_fcm_ctrl->index += 3;
> - }
> -
> elbc_fcm_ctrl->oob_poi = NULL;
> return;
> }
All references to elbc_fcm_ctrl->oob_poi (not chip->oob_poi) can be removed
now.
-Scott
^ permalink raw reply
* Re: pci_pcie_cap invalid on AER/EEH enabled PPC?
From: Richard A Lary @ 2011-07-05 20:34 UTC (permalink / raw)
To: Jon Mason
Cc: James Smart, linux-pci, Anton Blanchard, Richard Lary,
linuxppc-dev, davem
In-Reply-To: <4E13486C.3000409@linux.vnet.ibm.com>
On 7/5/2011 10:22 AM, Richard A Lary wrote:
> On 7/5/2011 9:18 AM, Jon Mason wrote:
>> On Tue, Jul 5, 2011 at 10:41 AM, Richard A Lary
>> <rlary@linux.vnet.ibm.com> wrote:
>>> On 7/1/2011 1:00 PM, Richard A Lary wrote:
>>>>
>>>> On 7/1/2011 12:02 PM, Jon Mason wrote:
>>>>>
>>>>> On Fri, Jul 1, 2011 at 1:30 PM, Richard A Lary<rlary@linux.vnet.ibm.com>
>>>>> wrote:
>>>>>>
>>>>>> On 7/1/2011 8:24 AM, Jon Mason wrote:
>>>>>>>
>>>>>>> I recently sent out a number of patches to migrate drivers calling
>>>>>>> `pci_find_capability(pdef, PCI_CAP_ID_EXP)` to pci_pcie_cap. This
>>>>>>> function takes uses a PCI-E capability offset that was determined by
>>>>>>> calling pci_find_capability during the PCI bus walking. In response
>>>>>>> to one of the patches, James Smart posted:
>>>>>>>
>>>>>>> "The reason is due to an issue on PPC platforms whereby use of
>>>>>>> "pdev->is_pcie" and pci_is_pcie() will erroneously fail under some
>>>>>>> conditions, but explicit search for the capability struct via
>>>>>>> pci_find_capability() is always successful. I expect this to be due
>>>>>>> a shadowing of pci config space in the hal/platform that isn't
>>>>>>> sufficiently built up. We detected this issue while testing AER/EEH,
>>>>>>> and are functional only if the pci_find_capability() option is used."
>>>>>>>
>>>>>>> See http://marc.info/?l=linux-scsi&m=130946649427828&w=2 for the whole
>>>>>>> post.
>>>>>>>
>>>>>>> Based on his description above pci_pcie_cap
>>>>>>> andpci_find_capability(pdef, PCI_CAP_ID_EXP) should be functionally
>>>>>>> equivalent. If this is not safe, then the PCI bus walking code is
>>>>>>> most likely busted on EEH enabled PPC systems (and that is a BIG
>>>>>>> problem). Can anyone confirm this is still an issue?
>>>>>>
>>>>>> Jon,
>>>>>>
>>>>>> I applied the following debug patch to lpfc driver in a 2.6.32 distro
>>>>>> kernel ( I had this one handy, I can try with mainline later today )
>>>>>>
>>>>>> ---
>>>>>> drivers/scsi/lpfc/lpfc_init.c | 10 10 + 0 - 0 !
>>>>>> 1 file changed, 10 insertions(+)
>>>>>>
>>>>>> Index: b/drivers/scsi/lpfc/lpfc_init.c
>>>>>> ===================================================================
>>>>>> --- a/drivers/scsi/lpfc/lpfc_init.c
>>>>>> +++ b/drivers/scsi/lpfc/lpfc_init.c
>>>>>> @@ -3958,6 +3958,16 @@ lpfc_enable_pci_dev(struct lpfc_hba *phb
>>>>>> pci_try_set_mwi(pdev);
>>>>>> pci_save_state(pdev);
>>>>>>
>>>>>> + printk(KERN_WARNING "pcicap: is_pcie=%x pci_cap=%x pcie_type=%x\n",
>>>>>> + pdev->is_pcie,
>>>>>> + pdev->pcie_cap,
>>>>>> + pdev->pcie_type);
>>>>>> +
>>>>>> + if (pci_is_pcie(pdev))
>>>>>> + printk(KERN_WARNING "pcicap: true\n");
>>>>>> + else
>>>>>> + printk(KERN_WARNING "pcicap: false\n");
>>>>>> +
>>>>>> /* PCIe EEH recovery on powerpc platforms needs fundamental reset */
>>>>>> if (pci_find_capability(pdev, PCI_CAP_ID_EXP))
>>>>>> pdev->needs_freset = 1;
>>>>>>
>>>>>> This is output upon driver load on an IBM Power 7 model 8233-E8B server.
>>>>>>
>>>>>> dmesg | grep pcicap
>>>>>> Linux version 2.6.32.42-pcicap-ppc64 (geeko@buildhost) (gcc version
>>>>>> 4.3.4
>>>>>> [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Fri Jul 1
>>>>>> 09:31:27
>>>>>> PDT 2011
>>>>>> pcicap: is_pcie=0 pci_cap=0 pcie_type=0
>>>>>> pcicap: false
>>>>>> pcicap: is_pcie=0 pci_cap=0 pcie_type=0
>>>>>> pcicap: false
>>>>>> pcicap: is_pcie=0 pci_cap=0 pcie_type=0
>>>>>> pcicap: false
>>>>>> pcicap: is_pcie=0 pci_cap=0 pcie_type=0
>>>>>> pcicap: false
>>>>>>
>>>>>> It would appear that the pcie information is not set in pci_dev
>>>>>> structure
>>>>>> for
>>>>>> this device at the time the driver is being initialized during boot.
>>>>>
>>>>> Thanks for trying this. Can you confirm that the other devices in the
>>>>> system have this issue as well (or show that it is isolated to the lpr
>>>>> device)? You can add printks in set_pcie_port_type() to verify what
>>>>> is being set on bus walking and to see when it is being called with
>>>>> respect to when it is being populated by firmware.
>>>>
>>>> Jon,
>>>>
>>>> I will give this suggestion a try and post results
>>>
>>> On Power PC platforms, set_pcie_port_type() is not called. On Power PC,
>>> pci_dev structure is initialized by of_create_pci_dev(). However, the
>>> structure member pcie_cap is NOT computed nor set in this function.
>>
>> Yes, it is. of_create_pci_dev() calls set_pcie_port_type()
>> http://lxr.linux.no/linux+v2.6.39/arch/powerpc/kernel/pci_of_scan.c#L144
>>
>> That function sets pdev->pcie_cap
>> http://lxr.linux.no/linux+v2.6.39/drivers/pci/probe.c#L896
>>
>> So, it should be set. It looks like there is a bug in
>> of_create_pci_dev, as set_pcie_port_type is being called BEFORE the
>> BARs are setup. If you move set_pcie_port_type prior to
>> pci_device_add (perhaps even after), then I bet the issue is resolved.
>>
>
> The claim above was based upon observation that with this patch applied
> to a 2.6.32 kernel, the printk output did not appear in dmesg upon boot.
>
> static void set_pcie_hotplug_bridge(struct pci_dev *pdev)
> @@ -774,6 +780,8 @@ int pci_setup_device(struct pci_dev *dev
> u8 hdr_type;
> struct pci_slot *slot;
>
> + printk(KERN_WARNING "pcicap: setup_device %p\n", dev);
> +
> if (pci_read_config_byte(dev, PCI_HEADER_TYPE, &hdr_type))
> return -EIO;
>
> I can make no claim about my understanding of pci device initialization
> on Power PC, so I have added Anton Blanchard to the cc list.
>
> Perhaps Anton can explain why pcie_cap is always 0 on Power PC.
I pulled down 3.0-rc6 kernel, I will build and test the pci_is_pcie(pdev)
patch in lpfc driver now that set_pcie_port_type() is called from
of_create_pci_dev().
-rich
>>
>>> The information used to populate pci_dev comes from the Power PC
>>> device_tree passed to the OS by Open Firmware.
>>>
>>> Based upon standing Power PC design, we cannot support patches
>>> which replace pci_find_capability(pdef, PCI_CAP_ID_EXP) with
>>> pci_is_pcie(pdev) on Power PC platforms.
>>>
>>> -rich
>>>
>>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH v2] mtd: eLBC NAND: remove elbc_fcm_ctrl->oob_poi
From: Matthew L. Creech @ 2011-07-05 22:35 UTC (permalink / raw)
To: linux-mtd; +Cc: scottwood, linuxppc-dev, rick22, mhench
In-Reply-To: <20110705151525.438e87dc@schlenkerla.am.freescale.net>
From: Mike Hench <mhench@elutions.com>
The eLBC NAND driver currently follows up each program/write operation with a
read-back of the page, in order to [ostensibly] fill in ECC data for the
caller. However, the page address used for this read is always -1, so the read
will never work correctly. Remove this useless (and potentially problematic)
block of code.
v2: elbc_fcm_ctrl->oob_poi is removed entirely, since this code block was the
only place it was actually used.
Signed-off-by: Matthew L. Creech <mlcreech@gmail.com>
---
drivers/mtd/nand/fsl_elbc_nand.c | 25 -------------------------
1 files changed, 0 insertions(+), 25 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 0bb254c..5e4fbf5 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -75,7 +75,6 @@ struct fsl_elbc_fcm_ctrl {
unsigned int use_mdr; /* Non zero if the MDR is to be set */
unsigned int oob; /* Non zero if operating on OOB data */
unsigned int counter; /* counter for the initializations */
- char *oob_poi; /* Place to write ECC after read back */
};
/* These map to the positions used by the FCM hardware ECC generator */
@@ -454,25 +453,6 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
}
fsl_elbc_run_command(mtd);
-
- /* Read back the page in order to fill in the ECC for the
- * caller. Is this really needed?
- */
- if (full_page && elbc_fcm_ctrl->oob_poi) {
- out_be32(&lbc->fbcr, 3);
- set_addr(mtd, 6, page_addr, 1);
-
- elbc_fcm_ctrl->read_bytes = mtd->writesize + 9;
-
- fsl_elbc_do_read(chip, 1);
- fsl_elbc_run_command(mtd);
-
- memcpy_fromio(elbc_fcm_ctrl->oob_poi + 6,
- &elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index], 3);
- elbc_fcm_ctrl->index += 3;
- }
-
- elbc_fcm_ctrl->oob_poi = NULL;
return;
}
@@ -752,13 +732,8 @@ static void fsl_elbc_write_page(struct mtd_info *mtd,
struct nand_chip *chip,
const uint8_t *buf)
{
- struct fsl_elbc_mtd *priv = chip->priv;
- struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = priv->ctrl->nand;
-
fsl_elbc_write_buf(mtd, buf, mtd->writesize);
fsl_elbc_write_buf(mtd, chip->oob_poi, mtd->oobsize);
-
- elbc_fcm_ctrl->oob_poi = chip->oob_poi;
}
static int fsl_elbc_chip_init(struct fsl_elbc_mtd *priv)
--
1.6.3.3
^ permalink raw reply related
* Re: [RFC] virtio: expose for non-virtualization users too
From: H. Peter Anvin @ 2011-07-05 22:35 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: Carsten Otte, linux-ia64, kvm, Michael S. Tsirkin, linux-mips,
Heiko Carstens, virtualization, Paul Mackerras, linux-s390,
linux-sh, x86, Alexander Graf, Christian Borntraeger, Ingo Molnar,
Avi Kivity, Russell King, Xiantao Zhang, Fenghua Yu,
Arnd Bergmann, Rusty Russell, Chris Metcalf, John Stultz, kvm-ppc,
Thomas Gleixner, linux-omap, linux-arm-kernel, Tony Luck,
kvm-ia64, Marcelo Tosatti, linux-kernel, Ralf Baechle, Paul Mundt,
Martin Schwidefsky, linux390, Andrew Morton, linuxppc-dev
In-Reply-To: <1309874774-31689-1-git-send-email-ohad@wizery.com>
On 07/05/2011 07:06 AM, Ohad Ben-Cohen wrote:
> virtio has been so far used only in the context of virtualization,
> and the virtio Kconfig was sourced directly by the relevant arch
> Kconfigs when VIRTUALIZATION was selected.
>
> Now that we start using virtio for inter-processor communications,
> we need to source the virtio Kconfig outside of the virtualization
> scope too.
>
Seems reasonable to me.
-hpa
^ permalink raw reply
* Re: [PATCH v2] mtd: eLBC NAND: remove elbc_fcm_ctrl->oob_poi
From: Scott Wood @ 2011-07-05 23:01 UTC (permalink / raw)
To: Matthew L. Creech; +Cc: linuxppc-dev, linux-mtd, rick22, mhench
In-Reply-To: <1309905302-1990-1-git-send-email-mlcreech@gmail.com>
On Tue, 5 Jul 2011 18:35:02 -0400
"Matthew L. Creech" <mlcreech@gmail.com> wrote:
> From: Mike Hench <mhench@elutions.com>
>
> The eLBC NAND driver currently follows up each program/write operation with a
> read-back of the page, in order to [ostensibly] fill in ECC data for the
> caller. However, the page address used for this read is always -1, so the read
> will never work correctly. Remove this useless (and potentially problematic)
> block of code.
>
> v2: elbc_fcm_ctrl->oob_poi is removed entirely, since this code block was the
> only place it was actually used.
Just noticed, full_page can come out as well.
Otherwise, ACK
-Scott
^ permalink raw reply
* Re: [PATCH v2] mtd: eLBC NAND: remove elbc_fcm_ctrl->oob_poi
From: Matthew L. Creech @ 2011-07-05 23:14 UTC (permalink / raw)
To: Scott Wood; +Cc: linux-mtd, linuxppc-dev, mhench, rick22
In-Reply-To: <20110705180138.469f34d1@schlenkerla.am.freescale.net>
On Tue, Jul 5, 2011 at 7:01 PM, Scott Wood <scottwood@freescale.com> wrote:
>
> Just noticed, full_page can come out as well.
>
> Otherwise, ACK
>
Oh right, didn't notice that - thanks.
--
Matthew L. Creech
^ permalink raw reply
* [PATCH v3] mtd: eLBC NAND: remove elbc_fcm_ctrl->oob_poi
From: Matthew L. Creech @ 2011-07-05 23:14 UTC (permalink / raw)
To: linux-mtd; +Cc: scottwood, linuxppc-dev, rick22, mhench
In-Reply-To: <1309905302-1990-1-git-send-email-mlcreech@gmail.com>
From: Mike Hench <mhench@elutions.com>
The eLBC NAND driver currently follows up each program/write operation with a
read-back of the page, in order to [ostensibly] fill in ECC data for the
caller. However, the page address used for this read is always -1, so the read
will never work correctly. Remove this useless (and potentially problematic)
block of code.
v2: elbc_fcm_ctrl->oob_poi is removed entirely, since this code block was the
only place it was actually used.
v3: local 'full_page' variable is no longer used either.
Signed-off-by: Matthew L. Creech <mlcreech@gmail.com>
---
drivers/mtd/nand/fsl_elbc_nand.c | 33 ++-------------------------------
1 files changed, 2 insertions(+), 31 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 0bb254c..b4d310f 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -75,7 +75,6 @@ struct fsl_elbc_fcm_ctrl {
unsigned int use_mdr; /* Non zero if the MDR is to be set */
unsigned int oob; /* Non zero if operating on OOB data */
unsigned int counter; /* counter for the initializations */
- char *oob_poi; /* Place to write ECC after read back */
};
/* These map to the positions used by the FCM hardware ECC generator */
@@ -435,7 +434,6 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
/* PAGEPROG reuses all of the setup from SEQIN and adds the length */
case NAND_CMD_PAGEPROG: {
- int full_page;
dev_vdbg(priv->dev,
"fsl_elbc_cmdfunc: NAND_CMD_PAGEPROG "
"writing %d bytes.\n", elbc_fcm_ctrl->index);
@@ -445,34 +443,12 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
* write so the HW generates the ECC.
*/
if (elbc_fcm_ctrl->oob || elbc_fcm_ctrl->column != 0 ||
- elbc_fcm_ctrl->index != mtd->writesize + mtd->oobsize) {
+ elbc_fcm_ctrl->index != mtd->writesize + mtd->oobsize)
out_be32(&lbc->fbcr, elbc_fcm_ctrl->index);
- full_page = 0;
- } else {
+ else
out_be32(&lbc->fbcr, 0);
- full_page = 1;
- }
fsl_elbc_run_command(mtd);
-
- /* Read back the page in order to fill in the ECC for the
- * caller. Is this really needed?
- */
- if (full_page && elbc_fcm_ctrl->oob_poi) {
- out_be32(&lbc->fbcr, 3);
- set_addr(mtd, 6, page_addr, 1);
-
- elbc_fcm_ctrl->read_bytes = mtd->writesize + 9;
-
- fsl_elbc_do_read(chip, 1);
- fsl_elbc_run_command(mtd);
-
- memcpy_fromio(elbc_fcm_ctrl->oob_poi + 6,
- &elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index], 3);
- elbc_fcm_ctrl->index += 3;
- }
-
- elbc_fcm_ctrl->oob_poi = NULL;
return;
}
@@ -752,13 +728,8 @@ static void fsl_elbc_write_page(struct mtd_info *mtd,
struct nand_chip *chip,
const uint8_t *buf)
{
- struct fsl_elbc_mtd *priv = chip->priv;
- struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = priv->ctrl->nand;
-
fsl_elbc_write_buf(mtd, buf, mtd->writesize);
fsl_elbc_write_buf(mtd, chip->oob_poi, mtd->oobsize);
-
- elbc_fcm_ctrl->oob_poi = chip->oob_poi;
}
static int fsl_elbc_chip_init(struct fsl_elbc_mtd *priv)
--
1.6.3.3
^ permalink raw reply related
* Re: pci_pcie_cap invalid on AER/EEH enabled PPC?
From: Richard A Lary @ 2011-07-06 0:14 UTC (permalink / raw)
To: Jon Mason
Cc: James Smart, linux-pci, Anton Blanchard, Richard Lary,
linuxppc-dev, davem
In-Reply-To: <4E137558.7030204@linux.vnet.ibm.com>
On 7/5/2011 1:34 PM, Richard A Lary wrote:
> On 7/5/2011 10:22 AM, Richard A Lary wrote:
>> On 7/5/2011 9:18 AM, Jon Mason wrote:
>>> On Tue, Jul 5, 2011 at 10:41 AM, Richard A Lary
>>> <rlary@linux.vnet.ibm.com> wrote:
>>>> On 7/1/2011 1:00 PM, Richard A Lary wrote:
>>>>>
>>>>> On 7/1/2011 12:02 PM, Jon Mason wrote:
>>>>>>
>>>>>> On Fri, Jul 1, 2011 at 1:30 PM, Richard A Lary<rlary@linux.vnet.ibm.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> On 7/1/2011 8:24 AM, Jon Mason wrote:
>>>>>>>>
>>>>>>>> I recently sent out a number of patches to migrate drivers calling
>>>>>>>> `pci_find_capability(pdef, PCI_CAP_ID_EXP)` to pci_pcie_cap. This
>>>>>>>> function takes uses a PCI-E capability offset that was determined by
>>>>>>>> calling pci_find_capability during the PCI bus walking. In response
>>>>>>>> to one of the patches, James Smart posted:
>>>>>>>>
>>>>>>>> "The reason is due to an issue on PPC platforms whereby use of
>>>>>>>> "pdev->is_pcie" and pci_is_pcie() will erroneously fail under some
>>>>>>>> conditions, but explicit search for the capability struct via
>>>>>>>> pci_find_capability() is always successful. I expect this to be due
>>>>>>>> a shadowing of pci config space in the hal/platform that isn't
>>>>>>>> sufficiently built up. We detected this issue while testing AER/EEH,
>>>>>>>> and are functional only if the pci_find_capability() option is used."
>>>>>>>>
>>>>>>>> See http://marc.info/?l=linux-scsi&m=130946649427828&w=2 for the whole
>>>>>>>> post.
>>>>>>>>
>>>>>>>> Based on his description above pci_pcie_cap
>>>>>>>> andpci_find_capability(pdef, PCI_CAP_ID_EXP) should be functionally
>>>>>>>> equivalent. If this is not safe, then the PCI bus walking code is
>>>>>>>> most likely busted on EEH enabled PPC systems (and that is a BIG
>>>>>>>> problem). Can anyone confirm this is still an issue?
>>>>>>>
>>>>>>> Jon,
>>>>>>>
>>>>>>> I applied the following debug patch to lpfc driver in a 2.6.32 distro
>>>>>>> kernel ( I had this one handy, I can try with mainline later today )
>>>>>>>
>>>>>>> ---
>>>>>>> drivers/scsi/lpfc/lpfc_init.c | 10 10 + 0 - 0 !
>>>>>>> 1 file changed, 10 insertions(+)
>>>>>>>
>>>>>>> Index: b/drivers/scsi/lpfc/lpfc_init.c
>>>>>>> ===================================================================
>>>>>>> --- a/drivers/scsi/lpfc/lpfc_init.c
>>>>>>> +++ b/drivers/scsi/lpfc/lpfc_init.c
>>>>>>> @@ -3958,6 +3958,16 @@ lpfc_enable_pci_dev(struct lpfc_hba *phb
>>>>>>> pci_try_set_mwi(pdev);
>>>>>>> pci_save_state(pdev);
>>>>>>>
>>>>>>> + printk(KERN_WARNING "pcicap: is_pcie=%x pci_cap=%x pcie_type=%x\n",
>>>>>>> + pdev->is_pcie,
>>>>>>> + pdev->pcie_cap,
>>>>>>> + pdev->pcie_type);
>>>>>>> +
>>>>>>> + if (pci_is_pcie(pdev))
>>>>>>> + printk(KERN_WARNING "pcicap: true\n");
>>>>>>> + else
>>>>>>> + printk(KERN_WARNING "pcicap: false\n");
>>>>>>> +
>>>>>>> /* PCIe EEH recovery on powerpc platforms needs fundamental reset */
>>>>>>> if (pci_find_capability(pdev, PCI_CAP_ID_EXP))
>>>>>>> pdev->needs_freset = 1;
>>>>>>>
>>>>>>> This is output upon driver load on an IBM Power 7 model 8233-E8B server.
>>>>>>>
>>>>>>> dmesg | grep pcicap
>>>>>>> Linux version 2.6.32.42-pcicap-ppc64 (geeko@buildhost) (gcc version
>>>>>>> 4.3.4
>>>>>>> [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Fri Jul 1
>>>>>>> 09:31:27
>>>>>>> PDT 2011
>>>>>>> pcicap: is_pcie=0 pci_cap=0 pcie_type=0
>>>>>>> pcicap: false
>>>>>>> pcicap: is_pcie=0 pci_cap=0 pcie_type=0
>>>>>>> pcicap: false
>>>>>>> pcicap: is_pcie=0 pci_cap=0 pcie_type=0
>>>>>>> pcicap: false
>>>>>>> pcicap: is_pcie=0 pci_cap=0 pcie_type=0
>>>>>>> pcicap: false
>>>>>>>
>>>>>>> It would appear that the pcie information is not set in pci_dev
>>>>>>> structure
>>>>>>> for
>>>>>>> this device at the time the driver is being initialized during boot.
>>>>>>
>>>>>> Thanks for trying this. Can you confirm that the other devices in the
>>>>>> system have this issue as well (or show that it is isolated to the lpr
>>>>>> device)? You can add printks in set_pcie_port_type() to verify what
>>>>>> is being set on bus walking and to see when it is being called with
>>>>>> respect to when it is being populated by firmware.
>>>>>
>>>>> Jon,
>>>>>
>>>>> I will give this suggestion a try and post results
>>>>
>>>> On Power PC platforms, set_pcie_port_type() is not called. On Power PC,
>>>> pci_dev structure is initialized by of_create_pci_dev(). However, the
>>>> structure member pcie_cap is NOT computed nor set in this function.
>>>
>>> Yes, it is. of_create_pci_dev() calls set_pcie_port_type()
>>> http://lxr.linux.no/linux+v2.6.39/arch/powerpc/kernel/pci_of_scan.c#L144
>>>
>>> That function sets pdev->pcie_cap
>>> http://lxr.linux.no/linux+v2.6.39/drivers/pci/probe.c#L896
>>>
>>> So, it should be set. It looks like there is a bug in
>>> of_create_pci_dev, as set_pcie_port_type is being called BEFORE the
>>> BARs are setup. If you move set_pcie_port_type prior to
>>> pci_device_add (perhaps even after), then I bet the issue is resolved.
>>>
>>
>> The claim above was based upon observation that with this patch applied
>> to a 2.6.32 kernel, the printk output did not appear in dmesg upon boot.
>>
>> static void set_pcie_hotplug_bridge(struct pci_dev *pdev)
>> @@ -774,6 +780,8 @@ int pci_setup_device(struct pci_dev *dev
>> u8 hdr_type;
>> struct pci_slot *slot;
>>
>> + printk(KERN_WARNING "pcicap: setup_device %p\n", dev);
>> +
>> if (pci_read_config_byte(dev, PCI_HEADER_TYPE, &hdr_type))
>> return -EIO;
>>
>> I can make no claim about my understanding of pci device initialization
>> on Power PC, so I have added Anton Blanchard to the cc list.
>>
>> Perhaps Anton can explain why pcie_cap is always 0 on Power PC.
>
> I pulled down 3.0-rc6 kernel, I will build and test the pci_is_pcie(pdev)
> patch in lpfc driver now that set_pcie_port_type() is called from
> of_create_pci_dev().
Jon,
I applied the debug patches mentioned above along with the lpfc patch
http://marc.info/?l=linux-scsi&m=130919648513685&w=2
to linux 3.0-rc6 kernel.
The debug patches show that pci_dev members "is_pcie, pci_cap and pcie_type" are
now all being set to correct values now that 'of_create_pci_dev()' calls
'set_pcie_port_type()'. I was not able to determine when this patch went in.
My tests show that lpfc driver now recovers from injected PCIe bus errors
using test the 'if (pci_is_pcie(pdev))' for PCIe adapter type.
I did not apply the test patch which changed the location of
set_pcie_port_type(dev) in of_create_pci_dev(). I can apply and test
this change if you think it is necessary?
Based upon these results, I will ACK the change to the lpfc driver for
"[PATCH 03/19] lpfc: remove unnecessary read of PCI_CAP_ID_EXP".
I suspect that other drivers which are modified to use 'if (pci_is_pcie(pdev))'
will work on Power PC as well, but I did not test any drivers other than lpfc.
-rich
^ permalink raw reply
* Re: pci_pcie_cap invalid on AER/EEH enabled PPC?
From: Benjamin Herrenschmidt @ 2011-07-06 2:42 UTC (permalink / raw)
To: Richard A Lary
Cc: James Smart, linux-pci, Richard Lary, Jon Mason, linuxppc-dev,
davem
In-Reply-To: <4E1330A3.8080004@linux.vnet.ibm.com>
> On Power PC platforms, set_pcie_port_type() is not called. On Power PC,
> pci_dev structure is initialized by of_create_pci_dev(). However, the
> structure member pcie_cap is NOT computed nor set in this function.
Just a quick correction here, please don't say "On Power PC platforms"
such generic statements that only apply to IBM pSeries platforms running
under pHyp :-)
There's plenty of other platforms supported in arch/powerpc that have
very different characteristics and use more "generic" code to build
their PCI layout.
> The information used to populate pci_dev comes from the Power PC
> device_tree passed to the OS by Open Firmware.
>
> Based upon standing Power PC design, we cannot support patches
> which replace pci_find_capability(pdef, PCI_CAP_ID_EXP) with
> pci_is_pcie(pdev) on Power PC platforms.
No, that isn't correct. We can (and should) fix our arch code to do the
right thing. There is no reason why those two wouldn't be equivalent.
If we are missing a call to set_pcie_port_type() then we should add it,
however if I look at our upstream code, pci_of_scan.c seems to be
calling that, so it could be a missing backport ?
Can you try with an upstream kernel ?
Cheers,
Ben.
^ permalink raw reply
* Re: pci_pcie_cap invalid on AER/EEH enabled PPC?
From: Benjamin Herrenschmidt @ 2011-07-06 2:47 UTC (permalink / raw)
To: Richard A Lary
Cc: James Smart, linux-pci, Anton Blanchard, Richard Lary, Jon Mason,
linuxppc-dev, davem
In-Reply-To: <4E13A8F0.80700@linux.vnet.ibm.com>
On Tue, 2011-07-05 at 17:14 -0700, Richard A Lary wrote:
> I applied the debug patches mentioned above along with the lpfc patch
> http://marc.info/?l=linux-scsi&m=130919648513685&w=2
> to linux 3.0-rc6 kernel.
>
> The debug patches show that pci_dev members "is_pcie, pci_cap and pcie_type" are
> now all being set to correct values now that 'of_create_pci_dev()' calls
> 'set_pcie_port_type()'. I was not able to determine when this patch went in.
git is good for that :-)
bb209c8287d2d55ec4a67e3933346e0a3ee0da76:
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org> 2010-01-27 04:10:03
Committer: Benjamin Herrenschmidt <benh@kernel.crashing.org> 2010-01-29 16:51:10
Parent: 4406c56d0a4da7a37b9180abeaece6cd00bcc874 (Merge branch 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6)
Child: 26b4a0ca46985ae9586c194f7859f3838b1230f8 (powerpc/pci: Add missing hookup to pci_slot)
Branches: many (38)
Follows: v2.6.33-rc5
Precedes: v2.6.33-rc7
powerpc/pci: Add calls to set_pcie_port_type() and set_pcie_hotplug_bridge()
We are missing these when building the pci_dev from scratch off
the Open Firmware device-tree
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
We should probably backport it to .32-stable. Any volunteer ?
You might also want to consider for backport:
26b4a0ca46985ae9586c194f7859f3838b1230f8 and
94afc008e1e6fbadfac0b75fcf193b6d7074b2f1
> My tests show that lpfc driver now recovers from injected PCIe bus errors
> using test the 'if (pci_is_pcie(pdev))' for PCIe adapter type.
>
> I did not apply the test patch which changed the location of
> set_pcie_port_type(dev) in of_create_pci_dev(). I can apply and test
> this change if you think it is necessary?
No I think we call it in the right place, which mirrors
pci_setup_device(), that is before the early quirk.
> Based upon these results, I will ACK the change to the lpfc driver for
> "[PATCH 03/19] lpfc: remove unnecessary read of PCI_CAP_ID_EXP".
> I suspect that other drivers which are modified to use 'if (pci_is_pcie(pdev))'
> will work on Power PC as well, but I did not test any drivers other than lpfc.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] sm501: When registering the GPIO, turn on the GPIO unit's power
From: Josh Triplett @ 2011-07-06 3:41 UTC (permalink / raw)
To: Samuel Ortiz, Paul Mundt, Ben Dooks
Cc: psas-avionics, linuxppc-dev, linux-kernel
When attempting to use GPIO via the sm501 unit on the TQM5200 board,
GPIO operations would only function if during the same boot u-boot's
"fkt led" command had initialized the sm501. Comparing the sm501's
registers with and without running the "fkt led" command turned up one
significant difference: u-boot had enabled the GPIO power gate.
Changing the Linux sm501 driver to enable the GPIO power gate allows
GPIO to work without first initializing it with u-boot.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
drivers/mfd/sm501.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c
index df3702c..d7a0ab9 100644
--- a/drivers/mfd/sm501.c
+++ b/drivers/mfd/sm501.c
@@ -1089,6 +1089,7 @@ static int __devinit sm501_register_gpio(struct sm501_devdata *sm)
goto err_low_chip;
}
+ sm501_unit_power(sm->dev, SM501_GATE_GPIO, 1);
gpio->registered = 1;
return 0;
@@ -1118,6 +1119,8 @@ static void sm501_gpio_remove(struct sm501_devdata *sm)
if (!sm->gpio.registered)
return;
+ sm501_unit_power(sm->dev, SM501_GATE_GPIO, 0);
+
ret = gpiochip_remove(&gpio->low.gpio);
if (ret)
dev_err(sm->dev, "cannot remove low chip, cannot tidy up\n");
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 1/2] mtd/nand : don't free the global data fsl_lbc_ctrl_dev->nand in fsl_elbc_chip_remove()
From: Artem Bityutskiy @ 2011-07-06 6:46 UTC (permalink / raw)
To: b35362; +Cc: linuxppc-dev, dwmw2, linux-mtd
In-Reply-To: <1309225852-1664-1-git-send-email-b35362@freescale.com>
On Tue, 2011-06-28 at 09:50 +0800, b35362@freescale.com wrote:
> From: Liu Shuo <b35362@freescale.com>
>
> The global data fsl_lbc_ctrl_dev->nand don't have to be freed in
> fsl_elbc_chip_remove(). The right place to do that is in fsl_elbc_nand_remove()
> if elbc_fcm_ctrl->counter is zero.
>
> Signed-off-by: Liu Shuo <b35362@freescale.com>
Changed the subject to something shorted and pushed to l2-mtd-2.6.git,
thanks.
--
Best Regards,
Artem Bityutskiy
^ permalink raw reply
* Re: [PATCH v3] mtd: eLBC NAND: remove elbc_fcm_ctrl->oob_poi
From: Artem Bityutskiy @ 2011-07-06 7:23 UTC (permalink / raw)
To: Matthew L. Creech; +Cc: scottwood, linuxppc-dev, linux-mtd, mhench, rick22
In-Reply-To: <1309907688-8235-1-git-send-email-mlcreech@gmail.com>
On Tue, 2011-07-05 at 19:14 -0400, Matthew L. Creech wrote:
> From: Mike Hench <mhench@elutions.com>
>
> The eLBC NAND driver currently follows up each program/write operation with a
> read-back of the page, in order to [ostensibly] fill in ECC data for the
> caller. However, the page address used for this read is always -1, so the read
> will never work correctly. Remove this useless (and potentially problematic)
> block of code.
Pushed to l2-mtd-2.6.git, thanks!
--
Best Regards,
Artem Bityutskiy
^ permalink raw reply
* Re: [RFC] [PATCH] hvc_console: improve tty/console put_chars handling
From: Anton Blanchard @ 2011-07-06 7:49 UTC (permalink / raw)
To: Hendrik Brueckner
Cc: Tabi Timur-B04825, linuxppc-dev@lists.ozlabs.org,
borntraeger@de.ibm.com
In-Reply-To: <20110705142844.GA2514@linux.vnet.ibm.com>
Hi Hendrik,
> So with the patch below, the backend can now indirectly control the
> way console output is handled for it. I still have to think if this
> solution is ok or if it is better to introduce a new callback to
> console output only (and might provide a default implemenatation
> similar to the patch below).
>
> NOTE: I did not yet test this patch but will do.. I just want to
> share it early to get feedback from you.
Thanks a lot for this. I added the pseries bits and tested it, patches
to follow.
Anton
^ permalink raw reply
* [PATCH 1/2]: hvc_console: improve tty/console put_chars handling
From: Anton Blanchard @ 2011-07-06 7:50 UTC (permalink / raw)
To: Hendrik Brueckner
Cc: Tabi Timur-B04825, linuxppc-dev@lists.ozlabs.org,
borntraeger@de.ibm.com
In-Reply-To: <20110705142844.GA2514@linux.vnet.ibm.com>
From: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Currently, the hvc_console_print() function drops console output if the
hvc backend's put_chars() returns 0. This patch changes this behavior
to allow a retry through returning -EAGAIN.
This change also affects the hvc_push() function. Both functions are
changed to handle -EAGAIN and to retry the put_chars() operation.
If a hvc backend returns -EAGAIN, the retry handling differs:
- hvc_console_print() spins to write the complete console output.
- hvc_push() behaves the same way as for returning 0.
Now hvc backends can indirectly control the way how console output is
handled through the hvc console layer.
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Acked-by: Anton Blanchard <anton@samba.org>
Cc: <stable@kernel.org>
---
Index: linux-powerpc/drivers/tty/hvc/hvc_console.c
===================================================================
--- linux-powerpc.orig/drivers/tty/hvc/hvc_console.c 2011-07-06 17:10:51.288360541 +1000
+++ linux-powerpc/drivers/tty/hvc/hvc_console.c 2011-07-06 17:11:16.398794913 +1000
@@ -163,8 +163,10 @@ static void hvc_console_print(struct con
} else {
r = cons_ops[index]->put_chars(vtermnos[index], c, i);
if (r <= 0) {
- /* throw away chars on error */
- i = 0;
+ /* throw away characters on error
+ * but spin in case of -EAGAIN */
+ if (r != -EAGAIN)
+ i = 0;
} else if (r > 0) {
i -= r;
if (i > 0)
@@ -448,7 +450,7 @@ static int hvc_push(struct hvc_struct *h
n = hp->ops->put_chars(hp->vtermno, hp->outbuf, hp->n_outbuf);
if (n <= 0) {
- if (n == 0) {
+ if (n == 0 || n == -EAGAIN) {
hp->do_wakeup = 1;
return 0;
}
^ permalink raw reply
* [PATCH 2/2]: powerpc/pseries/hvconsole: Fix dropped console output
From: Anton Blanchard @ 2011-07-06 7:51 UTC (permalink / raw)
To: Hendrik Brueckner
Cc: Tabi Timur-B04825, linuxppc-dev@lists.ozlabs.org,
borntraeger@de.ibm.com
In-Reply-To: <20110705142844.GA2514@linux.vnet.ibm.com>
Return -EAGAIN when we get H_BUSY back from the hypervisor. This
makes the hvc console driver retry, avoiding dropped printks.
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: <stable@kernel.org>
---
Index: linux-powerpc/arch/powerpc/platforms/pseries/hvconsole.c
===================================================================
--- linux-powerpc.orig/arch/powerpc/platforms/pseries/hvconsole.c 2011-07-06 17:11:33.799095935 +1000
+++ linux-powerpc/arch/powerpc/platforms/pseries/hvconsole.c 2011-07-06 17:11:47.499332962 +1000
@@ -73,7 +73,7 @@ int hvc_put_chars(uint32_t vtermno, cons
if (ret == H_SUCCESS)
return count;
if (ret == H_BUSY)
- return 0;
+ return -EAGAIN;
return -EIO;
}
^ permalink raw reply
* Re: [PATCH] powerpc/kdump: Fix timeout in crash_kexec_wait_realmode
From: Anton Blanchard @ 2011-07-06 7:55 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <29259.1309848010@neuling.org>
On Tue, 05 Jul 2011 16:40:10 +1000
Michael Neuling <mikey@neuling.org> wrote:
> The existing code it pretty ugly. How about we clean it up even more
> like this?
Looks good and it passed my kdump test cases.
Anton
> From: Anton Blanchard <anton@samba.org>
>
> We check for timeout expiry in the outer loop, but we also need to
> check it in the inner loop or we can lock up forever waiting for a
> CPU to hit real mode.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> Cc: <stable@kernel.org>
>
> diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
> index 4e6ee94..cc6a9d5 100644
> --- a/arch/powerpc/kernel/crash.c
> +++ b/arch/powerpc/kernel/crash.c
> @@ -242,12 +242,8 @@ static void crash_kexec_wait_realmode(int cpu)
>
> while (paca[i].kexec_state < KEXEC_STATE_REAL_MODE) {
> barrier();
> - if (!cpu_possible(i)) {
> + if (!cpu_possible(i) || !cpu_online(i) ||
> (msecs <= 0)) break;
> - }
> - if (!cpu_online(i)) {
> - break;
> - }
> msecs--;
> mdelay(1);
> }
>
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/5200: mpc5200b.dtsi: add spi node address- and size-cells properties
From: Anatolij Gustschin @ 2011-07-06 9:43 UTC (permalink / raw)
To: Grant Likely; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <1305561764-5942-1-git-send-email-agust@denx.de>
Hi Grant,
can you please pick these patches for 3.1 ?
On Mon, 16 May 2011 18:02:43 +0200
Anatolij Gustschin <agust@denx.de> wrote:
> Both, #address-cells and #size-cells properties are required
> for spi bus node, so add them.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> ---
> arch/powerpc/boot/dts/mpc5200b.dtsi | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc5200b.dtsi b/arch/powerpc/boot/dts/mpc5200b.dtsi
> index bc27548..7ab286a 100644
> --- a/arch/powerpc/boot/dts/mpc5200b.dtsi
> +++ b/arch/powerpc/boot/dts/mpc5200b.dtsi
> @@ -147,6 +147,8 @@
> };
>
> spi@f00 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
> reg = <0xf00 0x20>;
> interrupts = <2 13 0 2 14 0>;
Thanks,
Anatolij
^ 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