[patch] ALSA: snd-aoa: two copy and paste bugs
These functions were cut and paste and the tests for NULL weren't
updated properly.
Signed-off-by: Dan Carpenter
diff --git a/sound/aoa/fabrics/layout.c b/sound/aoa/fabrics/layout.c
index 61ab640..9dc5806 100644
--- a/sound/aoa/fabrics/layout.c
+++ b/sound/aoa/fabrics/layout.c
@@ -644,7 +644,7 @@ static int n##_control_put(struct snd_kcontrol *kcontrol,
\
struct snd_ctl_elem_value *ucontrol) \
{ \
struct gpio_runtime *gpio = snd_kcontrol_chip(kcontrol);\
- if (gpio->methods && gpio->methods->get_##n)\
+ if (gpio->methods && gpio->methods->set_##n)\
gpio->methods->set_##n(gpio,\
!!ucontrol->value.integer.value[0]);\
return 1; \
@@ -1135,7 +1135,7 @@ static int aoa_fabric_layout_resume(struct soundbus_dev
*sdev)
{
struct layout_dev *ldev = dev_get_drvdata(&sdev->ofdev.dev);
- if (ldev->gpio.methods && ldev->gpio.methods->all_amps_off)
+ if (ldev->gpio.methods && ldev->gpio.methods->all_amps_restore)
ldev->gpio.methods->all_amps_restore(&ldev->gpio);
return 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch] ALSA: snd-aoa: two copy and paste bugs
At Wed, 13 Nov 2013 10:45:20 +0300,
Dan Carpenter wrote:
>
> These functions were cut and paste and the tests for NULL weren't
> updated properly.
>
> Signed-off-by: Dan Carpenter
Thanks, applied.
Takashi
>
> diff --git a/sound/aoa/fabrics/layout.c b/sound/aoa/fabrics/layout.c
> index 61ab640..9dc5806 100644
> --- a/sound/aoa/fabrics/layout.c
> +++ b/sound/aoa/fabrics/layout.c
> @@ -644,7 +644,7 @@ static int n##_control_put(struct snd_kcontrol *kcontrol,
> \
> struct snd_ctl_elem_value *ucontrol) \
> {\
> struct gpio_runtime *gpio = snd_kcontrol_chip(kcontrol);\
> - if (gpio->methods && gpio->methods->get_##n)\
> + if (gpio->methods && gpio->methods->set_##n)\
> gpio->methods->set_##n(gpio,\
> !!ucontrol->value.integer.value[0]);\
> return 1; \
> @@ -1135,7 +1135,7 @@ static int aoa_fabric_layout_resume(struct soundbus_dev
> *sdev)
> {
> struct layout_dev *ldev = dev_get_drvdata(&sdev->ofdev.dev);
>
> - if (ldev->gpio.methods && ldev->gpio.methods->all_amps_off)
> + if (ldev->gpio.methods && ldev->gpio.methods->all_amps_restore)
> ldev->gpio.methods->all_amps_restore(&ldev->gpio);
>
> return 0;
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch] ALSA: snd-aoa: two copy and paste bugs
On Wed, 2013-11-13 at 09:29 +0100, Takashi Iwai wrote: > At Wed, 13 Nov 2013 10:45:20 +0300, > Dan Carpenter wrote: > > > > These functions were cut and paste and the tests for NULL weren't > > updated properly. > > > > Signed-off-by: Dan Carpenter > > Thanks, applied. FWIW, looks fine to me - I wonder how long this has been broken though, must be practically forever. I guess we never got it wrong and missed adding some pointers? :-) johannes ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v9] PPC: POWERNV: move iommu_add_device earlier
> -Original Message-
> From: Alexey Kardashevskiy [mailto:a...@ozlabs.ru]
> Sent: Wednesday, November 13, 2013 12:00 PM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Alexey Kardashevskiy; Benjamin Herrenschmidt; Bhushan Bharat-R65777; Alex
> Graf; linux-ker...@vger.kernel.org
> Subject: [PATCH v9] PPC: POWERNV: move iommu_add_device earlier
>
> The current implementation of IOMMU on sPAPR does not use iommu_ops
> and therefore does not call IOMMU API's bus_set_iommu() which
> 1) sets iommu_ops for a bus
> 2) registers a bus notifier
> Instead, PCI devices are added to IOMMU groups from
> subsys_initcall_sync(tce_iommu_init) which does basically the same
> thing without using iommu_ops callbacks.
>
> However Freescale PAMU driver (https://lkml.org/lkml/2013/7/1/158)
> implements iommu_ops and when tce_iommu_init is called, every PCI device
> is already added to some group so there is a conflict.
>
> This patch does 2 things:
> 1. removes the loop in which PCI devices were added to groups and
> adds explicit iommu_add_device() calls to add devices as soon as they get
> the iommu_table pointer assigned to them.
> 2. moves a bus notifier to powernv code in order to avoid conflict with
> the notifier from Freescale driver.
>
> iommu_add_device() and iommu_del_device() are public now.
>
> Signed-off-by: Alexey Kardashevskiy
Tested-by: Bharat Bhushan
> ---
> Changes:
> v9:
> * removed "KVM" from the subject as it is not really a KVM patch so
> PPC mainainter (hi Ben!) can review/include it into his tree
>
> v8:
> * added the check for iommu_group!=NULL before removing device from a group
> as suggested by Wei Yang
>
> v2:
> * added a helper - set_iommu_table_base_and_group - which does
> set_iommu_table_base() and iommu_add_device()
> ---
> arch/powerpc/include/asm/iommu.h| 9 +++
> arch/powerpc/kernel/iommu.c | 41
> +++--
> arch/powerpc/platforms/powernv/pci-ioda.c | 8 +++---
> arch/powerpc/platforms/powernv/pci-p5ioc2.c | 2 +-
> arch/powerpc/platforms/powernv/pci.c| 33 ++-
> arch/powerpc/platforms/pseries/iommu.c | 8 +++---
> 6 files changed, 55 insertions(+), 46 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/iommu.h
> b/arch/powerpc/include/asm/iommu.h
> index c34656a..19ad77f 100644
> --- a/arch/powerpc/include/asm/iommu.h
> +++ b/arch/powerpc/include/asm/iommu.h
> @@ -103,6 +103,15 @@ extern struct iommu_table *iommu_init_table(struct
> iommu_table * tbl,
> int nid);
> extern void iommu_register_group(struct iommu_table *tbl,
>int pci_domain_number, unsigned long pe_num);
> +extern int iommu_add_device(struct device *dev);
> +extern void iommu_del_device(struct device *dev);
> +
> +static inline void set_iommu_table_base_and_group(struct device *dev,
> + void *base)
> +{
> + set_iommu_table_base(dev, base);
> + iommu_add_device(dev);
> +}
>
> extern int iommu_map_sg(struct device *dev, struct iommu_table *tbl,
> struct scatterlist *sglist, int nelems,
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index 572bb5b..ecbf468 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -1105,7 +1105,7 @@ void iommu_release_ownership(struct iommu_table *tbl)
> }
> EXPORT_SYMBOL_GPL(iommu_release_ownership);
>
> -static int iommu_add_device(struct device *dev)
> +int iommu_add_device(struct device *dev)
> {
> struct iommu_table *tbl;
> int ret = 0;
> @@ -1134,46 +1134,13 @@ static int iommu_add_device(struct device *dev)
>
> return ret;
> }
> +EXPORT_SYMBOL_GPL(iommu_add_device);
>
> -static void iommu_del_device(struct device *dev)
> +void iommu_del_device(struct device *dev)
> {
> iommu_group_remove_device(dev);
> }
> -
> -static int iommu_bus_notifier(struct notifier_block *nb,
> - unsigned long action, void *data)
> -{
> - struct device *dev = data;
> -
> - switch (action) {
> - case BUS_NOTIFY_ADD_DEVICE:
> - return iommu_add_device(dev);
> - case BUS_NOTIFY_DEL_DEVICE:
> - iommu_del_device(dev);
> - return 0;
> - default:
> - return 0;
> - }
> -}
> -
> -static struct notifier_block tce_iommu_bus_nb = {
> - .notifier_call = iommu_bus_notifier,
> -};
> -
> -static int __init tce_iommu_init(void)
> -{
> - struct pci_dev *pdev = NULL;
> -
> - BUILD_BUG_ON(PAGE_SIZE < IOMMU_PAGE_SIZE);
> -
> - for_each_pci_dev(pdev)
> - iommu_add_device(&pdev->dev);
> -
> - bus_register_notifier(&pci_bus_type, &tce_iommu_bus_nb);
> - return 0;
> -}
> -
> -subsys_initcall_sync(tce_iommu_init);
> +EXPORT_SYMBOL_GPL(iommu_del_device);
>
> #else
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> b/arch/powerpc/platforms/powernv/pci
Re: [PATCH v11 0/3] DMA: Freescale: Add support for 8-channel DMA engine
On Thu, Sep 26, 2013 at 05:33:40PM +0800, hongbo.zh...@freescale.com wrote: > From: Hongbo Zhang > > Hi DMA and DT maintainers, please have a look at these V11 patches. > > Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set > adds support this DMA engine. > Applied all Thanks ~Vinod ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v11 0/3] DMA: Freescale: Add support for 8-channel DMA engine
On 11/13/2013 04:57 PM, Vinod Koul wrote: On Thu, Sep 26, 2013 at 05:33:40PM +0800, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang Hi DMA and DT maintainers, please have a look at these V11 patches. Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set adds support this DMA engine. Applied all Thanks. Thanks ~Vinod ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/4] phylib: Add generic 10G driver
Hello, Florian,
Thank you for reviewing the patches!
Please see my comments inline.
Best Regards,
Shaohui Xie
> -Original Message-
> From: Florian Fainelli [mailto:f.faine...@gmail.com]
> Sent: Wednesday, November 13, 2013 1:54 AM
> To: shh@gmail.com
> Cc: linuxppc-dev; linux-ker...@vger.kernel.org; Bucur Madalin-Cristian-
> B32716; Kanetkar Shruti-B44454; Xie Shaohui-B21989
> Subject: Re: [PATCH 2/4] phylib: Add generic 10G driver
>
> Hello Shaohui,
>
> 2013/11/11 :
> > From: Andy Fleming
> >
> > Very incomplete, but will allow for binding an ethernet controller to
> > it.
> >
> > Also, Add XGMII interface type
>
> So that should be two separate patches, and
> drivers/of/of_net.c::of_get_phy_mode() must be updated to know about
> XMGII.
>
> >
> > Signed-off-by: Andy Fleming
>
> Missing Andy's Signed-off-by tag.
[S.H] Will add in next version, I removed it to make git work since Andy's
e-mail address is not valid.
>
> > Signed-off-by: Shaohui Xie
> > ---
> > drivers/net/phy/phy_device.c | 101
> ++-
> > include/linux/phy.h | 1 +
> > 2 files changed, 101 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/phy/phy_device.c
> > b/drivers/net/phy/phy_device.c index 74630e9..30bf2d5 100644
> > --- a/drivers/net/phy/phy_device.c
> > +++ b/drivers/net/phy/phy_device.c
> > @@ -32,6 +32,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include
> > @@ -689,6 +690,13 @@ static int genphy_config_advert(struct phy_device
> *phydev)
> > return changed;
> > }
> >
> > +int gen10g_config_advert(struct phy_device *dev) {
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(gen10g_config_advert);
> > +
> > +
> > /**
> > * genphy_setup_forced - configures/forces speed/duplex from @phydev
> > * @phydev: target phy_device struct
> > @@ -742,6 +750,12 @@ int genphy_restart_aneg(struct phy_device
> > *phydev) } EXPORT_SYMBOL(genphy_restart_aneg);
> >
> > +int gen10g_restart_aneg(struct phy_device *phydev) {
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(gen10g_restart_aneg);
> > +
> >
> > /**
> > * genphy_config_aneg - restart auto-negotiation or write BMCR @@
> > -784,6 +798,13 @@ int genphy_config_aneg(struct phy_device *phydev) }
> > EXPORT_SYMBOL(genphy_config_aneg);
> >
> > +int gen10g_config_aneg(struct phy_device *phydev) {
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(gen10g_config_aneg);
> > +
> > +
> > /**
> > * genphy_update_link - update link status in @phydev
> > * @phydev: target phy_device struct
> > @@ -913,6 +934,35 @@ int genphy_read_status(struct phy_device *phydev)
> > } EXPORT_SYMBOL(genphy_read_status);
> >
> > +int gen10g_read_status(struct phy_device *phydev) {
> > + int devad, reg;
> > + u32 mmd_mask = phydev->c45_ids.devices_in_package;
> > +
> > + phydev->link = 1;
> > +
> > + /* For now just lie and say it's 10G all the time */
> > + phydev->speed = 1;
>
> Can you at least make this a little more proof? Something along:
>
> if (phydev->supported & (SUPPORTED_1baseT_Full))
> phydev->speed = SPEED_1; else if (phydev->supported &
> (SUPPORTED_1000baseT_Full)
> phydev->speed = SPEED_1000;
[S.H] some 10G PHY only support 10G speed.
>
> Although ideally we should be reading the relevant registers to figure
> out what to do.
[S.H] Yes, code below will try to read the mmds to get status.
>
> > + phydev->duplex = DUPLEX_FULL;
> > +
> > + for (devad = 0; mmd_mask; devad++, mmd_mask = mmd_mask >> 1) {
> > + if (!(mmd_mask & 1))
> > + continue;
> > +
> > + /* Read twice because link state is latched and a
> > +* read moves the current state into the register
> > +*/
> > + phy_read_mmd(phydev, devad, MDIO_STAT1);
> > + reg = phy_read_mmd(phydev, devad, MDIO_STAT1);
> > + if (reg < 0 || !(reg & MDIO_STAT1_LSTATUS))
> > + phydev->link = 0;
> > + }
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(gen10g_read_status);
> > +
> > +
> > static int genphy_config_init(struct phy_device *phydev) {
> > int val;
> > @@ -959,6 +1009,15 @@ static int genphy_config_init(struct phy_device
> > *phydev)
> >
> > return 0;
> > }
> > +
> > +static int gen10g_config_init(struct phy_device *phydev) {
> > + /* Temporarily just say we support everything */
> > + phydev->supported = phydev->advertising =
> > +SUPPORTED_1baseT_Full;
>
> For consistency you should set SUPPORTED_TP, 1000baseT_Full does not make
> sense for anything but twisted pairs AFAIR.
[S.H] OK.
>
> > +
> > + return 0;
> > +}
> > +
> > int genphy_suspend(struct phy_device *phydev) {
> > int value;
> > @@ -974,6 +1033,13 @@ int genphy_suspend(struct phy_device *phydev) }
> > EXPORT_SYMBOL(genphy_suspend);
> >
> > +int gen10g_suspen
Re: Problem reading and programming memory location...
Yes, that is a device on the lpb via an fpga. We have tried to configure the chip select 4 configuration register at address MBAR + 0x0310, and it seems to be ok. what do you mean with “chip select parameters”? We have been able to edit it in U-BOOT, and the board (that chip) now works… The strange thing, is that when we read in linux, at that address, we see other content value… Suggestions? Thanks Lorenzo On 13/nov/2013, at 08:32 AM, Anatolij Gustschin wrote: > On Tue, 12 Nov 2013 20:23:20 +0100 > neorf3k wrote: > >> we have tried to read and program an 8bit register with 32bit address. >> we have mapped it with: ioremap, kmalloc etc… and then using: outb, >> iowrite8 etc.. but when we write to it, the value doesn’t change… >> with other memory location is ok. >> That is an 8 bit register, located at 0x1002 in a mpc5200b >> architecture. we are using kernel 2.6.33. >> what could be? > > 0x1002 is not in the internal register memory map, so it > is probably a device on the LocalPlus bus. Did you configure > the chip select parameters for this device and did you enable > the associated chip select? > > HTH, > > Anatolij > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v7 0/4] Add dual-fifo mode support of i.MX ssi
* ! This series of patches has a direct dependency between them. When * ! applying them, we need to apply to one single branch. Otherwise, * ! it would break currect branches. Changelog v7: * Appended missing Acked-by to all four patches. * Sorry that I didn't add them at the first place. v6: * PATCH-1: Use goto err_firmware instead of return directly. * * Nothing changes for the other three ack-ed patches v5: * PATCH-3: Add period size constraint when using dual fifo mode * * Nothing changes for the other three patches v4: * PATCH-3: Drop useless register configuration. * * Nothing changes for the other three patches v3: * PATCH-1: Add comments to indicate the end of v1 and v2 array. * PATCH-3: Use better way to keep watermark as even number. * * Nothing changes for PATCH-2 and PATCH-4 v2: * Instead of adding rogue scripts to current SDMA driver based on firmware * V1, we define the new SDMA firmware as version 2 and bisect the PATCH-1 * to two patches: The first is to add version check code to the SDMA driver; * And the second is to add SSI dual FIFO DMATYPE. * * Nothing changes for the last two patches. v1: * SSI can reduce hardware overrun/underrun possibility when using dual * fifo mode. To support this mode, we need to first update sdma sciprt * list, and then enable dual fifo BIT in SSI driver, and last update DT * bindings of i.MX series. Nicolin Chen (4): dma: imx-sdma: Add sdma firmware version 2 support dma: imx-sdma: Add new dma type for ssi dual fifo script ASoC: fsl_ssi: Add dual fifo mode support ARM: dts: imx: use dual-fifo sdma script for ssi .../devicetree/bindings/dma/fsl-imx-sdma.txt | 1 + arch/arm/boot/dts/imx51.dtsi | 4 ++-- arch/arm/boot/dts/imx53.dtsi | 4 ++-- arch/arm/boot/dts/imx6qdl.dtsi | 12 +- arch/arm/boot/dts/imx6sl.dtsi | 12 +- drivers/dma/imx-sdma.c | 19 ++- include/linux/platform_data/dma-imx-sdma.h | 5 include/linux/platform_data/dma-imx.h | 1 + sound/soc/fsl/fsl_ssi.c| 27 +- 9 files changed, 67 insertions(+), 18 deletions(-) -- 1.8.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v7 1/4] dma: imx-sdma: Add sdma firmware version 2 support
On i.MX5/6 series, SDMA is using new version firmware to support SSI
dual FIFO feature and HDMI Audio (i.MX6Q/DL only). Thus add it.
Signed-off-by: Nicolin Chen
Acked-by: Sascha Hauer
---
drivers/dma/imx-sdma.c | 15 ++-
include/linux/platform_data/dma-imx-sdma.h | 5 +
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index fc43603..43a8441 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -323,6 +323,7 @@ struct sdma_engine {
struct clk *clk_ipg;
struct clk *clk_ahb;
spinlock_t channel_0_lock;
+ u32 script_number;
struct sdma_script_start_addrs *script_addrs;
const struct sdma_driver_data *drvdata;
};
@@ -1238,6 +1239,7 @@ static void sdma_issue_pending(struct dma_chan *chan)
}
#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V134
+#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V238
static void sdma_add_scripts(struct sdma_engine *sdma,
const struct sdma_script_start_addrs *addr)
@@ -1246,7 +1248,7 @@ static void sdma_add_scripts(struct sdma_engine *sdma,
s32 *saddr_arr = (u32 *)sdma->script_addrs;
int i;
- for (i = 0; i < SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1; i++)
+ for (i = 0; i < sdma->script_number; i++)
if (addr_arr[i] > 0)
saddr_arr[i] = addr_arr[i];
}
@@ -1272,6 +1274,17 @@ static void sdma_load_firmware(const struct firmware
*fw, void *context)
goto err_firmware;
if (header->ram_code_start + header->ram_code_size > fw->size)
goto err_firmware;
+ switch (header->version_major) {
+ case 1:
+ sdma->script_number = SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1;
+ break;
+ case 2:
+ sdma->script_number = SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V2;
+ break;
+ default:
+ dev_err(sdma->dev, "unknown firmware version\n");
+ goto err_firmware;
+ }
addr = (void *)header + header->script_addrs_start;
ram_code = (void *)header + header->ram_code_start;
diff --git a/include/linux/platform_data/dma-imx-sdma.h
b/include/linux/platform_data/dma-imx-sdma.h
index 3a39428..eabac4e 100644
--- a/include/linux/platform_data/dma-imx-sdma.h
+++ b/include/linux/platform_data/dma-imx-sdma.h
@@ -43,6 +43,11 @@ struct sdma_script_start_addrs {
s32 dptc_dvfs_addr;
s32 utra_addr;
s32 ram_code_start_addr;
+ /* End of v1 array */
+ s32 mcu_2_ssish_addr;
+ s32 ssish_2_mcu_addr;
+ s32 hdmi_dma_addr;
+ /* End of v2 array */
};
/**
--
1.8.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v7 2/4] dma: imx-sdma: Add new dma type for ssi dual fifo script
This patch adds a new DMA_TYPE for SSI dual FIFO script, included
in SDMA firmware version 2. This script would allow SSI use dual
fifo mode to transimit/receive data without occasional hardware
underrun/overrun.
Signed-off-by: Nicolin Chen
Acked-by: Kumar Gala
Acked-by: Sascha Hauer
---
Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 1 +
drivers/dma/imx-sdma.c | 4
include/linux/platform_data/dma-imx.h | 1 +
3 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
index 4fa814d..68b83ec 100644
--- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
@@ -42,6 +42,7 @@ The full ID of peripheral types can be found below.
19 IPU Memory
20 ASRC
21 ESAI
+ 22 SSI Dual FIFO (needs firmware ver >= 2)
The third cell specifies the transfer priority as below.
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 43a8441..efe9d6a 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -725,6 +725,10 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
per_2_emi = sdma->script_addrs->app_2_mcu_addr;
emi_2_per = sdma->script_addrs->mcu_2_app_addr;
break;
+ case IMX_DMATYPE_SSI_DUAL:
+ per_2_emi = sdma->script_addrs->ssish_2_mcu_addr;
+ emi_2_per = sdma->script_addrs->mcu_2_ssish_addr;
+ break;
case IMX_DMATYPE_SSI_SP:
case IMX_DMATYPE_MMC:
case IMX_DMATYPE_SDHC:
diff --git a/include/linux/platform_data/dma-imx.h
b/include/linux/platform_data/dma-imx.h
index beac6b8..bcbc6c3 100644
--- a/include/linux/platform_data/dma-imx.h
+++ b/include/linux/platform_data/dma-imx.h
@@ -39,6 +39,7 @@ enum sdma_peripheral_type {
IMX_DMATYPE_IPU_MEMORY, /* IPU Memory */
IMX_DMATYPE_ASRC, /* ASRC */
IMX_DMATYPE_ESAI, /* ESAI */
+ IMX_DMATYPE_SSI_DUAL, /* SSI Dual FIFO */
};
enum imx_dma_prio {
--
1.8.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v7 3/4] ASoC: fsl_ssi: Add dual fifo mode support
By enabling dual fifo mode, it would allow SSI enter a better performance
to transimit/receive data without occasional hardware underrun/overrun.
Signed-off-by: Nicolin Chen
Acked-by: Timur Tabi
Acked-by: Mark Brown
---
sound/soc/fsl/fsl_ssi.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 35e2773..f43be6d 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -143,6 +143,7 @@ struct fsl_ssi_private {
bool ssi_on_imx;
bool imx_ac97;
bool use_dma;
+ bool use_dual_fifo;
struct clk *clk;
struct snd_dmaengine_dai_dma_data dma_params_tx;
struct snd_dmaengine_dai_dma_data dma_params_rx;
@@ -413,6 +414,12 @@ static int fsl_ssi_setup(struct fsl_ssi_private
*ssi_private)
write_ssi(CCSR_SSI_SOR_WAIT(3), &ssi->sor);
}
+ if (ssi_private->use_dual_fifo) {
+ write_ssi_mask(&ssi->srcr, 0, CCSR_SSI_SRCR_RFEN1);
+ write_ssi_mask(&ssi->stcr, 0, CCSR_SSI_STCR_TFEN1);
+ write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_TCH_EN);
+ }
+
return 0;
}
@@ -480,6 +487,15 @@ static int fsl_ssi_startup(struct snd_pcm_substream
*substream,
ssi_private->second_stream = substream;
}
+ /* When using dual fifo mode, it is safer to ensure an even period
+* size. If appearing to an odd number while DMA always starts its
+* task from fifo0, fifo1 would be neglected at the end of each
+* period. But SSI would still access fifo1 with an invalid data.
+*/
+ if (ssi_private->use_dual_fifo)
+ snd_pcm_hw_constraint_step(substream->runtime, 0,
+ SNDRV_PCM_HW_PARAM_PERIOD_SIZE, 2);
+
return 0;
}
@@ -947,7 +963,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
ssi_private->fifo_depth = 8;
if (of_device_is_compatible(pdev->dev.of_node, "fsl,imx21-ssi")) {
- u32 dma_events[2];
+ u32 dma_events[2], dmas[4];
ssi_private->ssi_on_imx = true;
ssi_private->clk = devm_clk_get(&pdev->dev, NULL);
@@ -1001,6 +1017,15 @@ static int fsl_ssi_probe(struct platform_device *pdev)
dma_events[0], shared ? IMX_DMATYPE_SSI_SP :
IMX_DMATYPE_SSI);
imx_pcm_dma_params_init_data(&ssi_private->filter_data_rx,
dma_events[1], shared ? IMX_DMATYPE_SSI_SP :
IMX_DMATYPE_SSI);
+ if (!of_property_read_u32_array(pdev->dev.of_node, "dmas",
dmas, 4)
+ && dmas[2] == IMX_DMATYPE_SSI_DUAL) {
+ ssi_private->use_dual_fifo = true;
+ /* When using dual fifo mode, we need to keep watermark
+* as even numbers due to dma script limitation.
+*/
+ ssi_private->dma_params_tx.maxburst &= ~0x1;
+ ssi_private->dma_params_rx.maxburst &= ~0x1;
+ }
} else if (ssi_private->use_dma) {
/* The 'name' should not have any slashes in it. */
ret = devm_request_irq(&pdev->dev, ssi_private->irq,
--
1.8.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v7 4/4] ARM: dts: imx: use dual-fifo sdma script for ssi
Use dual-fifo sdma scripts instead of shared scripts for ssi on i.MX series. Signed-off-by: Nicolin Chen Acked-by: Shawn Guo --- arch/arm/boot/dts/imx51.dtsi | 4 ++-- arch/arm/boot/dts/imx53.dtsi | 4 ++-- arch/arm/boot/dts/imx6qdl.dtsi | 12 ++-- arch/arm/boot/dts/imx6sl.dtsi | 12 ++-- 4 files changed, 16 insertions(+), 16 deletions(-) diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi index 54cee65..1a71eac 100644 --- a/arch/arm/boot/dts/imx51.dtsi +++ b/arch/arm/boot/dts/imx51.dtsi @@ -154,8 +154,8 @@ reg = <0x70014000 0x4000>; interrupts = <30>; clocks = <&clks 49>; - dmas = <&sdma 24 1 0>, - <&sdma 25 1 0>; + dmas = <&sdma 24 22 0>, + <&sdma 25 22 0>; dma-names = "rx", "tx"; fsl,fifo-depth = <15>; fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */ diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi index 4307e80..7208fde 100644 --- a/arch/arm/boot/dts/imx53.dtsi +++ b/arch/arm/boot/dts/imx53.dtsi @@ -153,8 +153,8 @@ reg = <0x50014000 0x4000>; interrupts = <30>; clocks = <&clks 49>; - dmas = <&sdma 24 1 0>, - <&sdma 25 1 0>; + dmas = <&sdma 24 22 0>, + <&sdma 25 22 0>; dma-names = "rx", "tx"; fsl,fifo-depth = <15>; fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */ diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi index 57e9c38..6e096ca 100644 --- a/arch/arm/boot/dts/imx6qdl.dtsi +++ b/arch/arm/boot/dts/imx6qdl.dtsi @@ -223,8 +223,8 @@ reg = <0x02028000 0x4000>; interrupts = <0 46 0x04>; clocks = <&clks 178>; - dmas = <&sdma 37 1 0>, - <&sdma 38 1 0>; + dmas = <&sdma 37 22 0>, + <&sdma 38 22 0>; dma-names = "rx", "tx"; fsl,fifo-depth = <15>; fsl,ssi-dma-events = <38 37>; @@ -236,8 +236,8 @@ reg = <0x0202c000 0x4000>; interrupts = <0 47 0x04>; clocks = <&clks 179>; - dmas = <&sdma 41 1 0>, - <&sdma 42 1 0>; + dmas = <&sdma 41 22 0>, + <&sdma 42 22 0>; dma-names = "rx", "tx"; fsl,fifo-depth = <15>; fsl,ssi-dma-events = <42 41>; @@ -249,8 +249,8 @@ reg = <0x0203 0x4000>; interrupts = <0 48 0x04>; clocks = <&clks 180>; - dmas = <&sdma 45 1 0>, - <&sdma 46 1 0>; + dmas = <&sdma 45 22 0>, + <&sdma 46 22 0>; dma-names = "rx", "tx"; fsl,fifo-depth = <15>; fsl,ssi-dma-events = <46 45>; diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi index c46651e..b32ba99 100644 --- a/arch/arm/boot/dts/imx6sl.dtsi +++ b/arch/arm/boot/dts/imx6sl.dtsi @@ -195,8 +195,8 @@ reg = <0x02028000 0x4000>; interrupts = <0 46 0x04>; clocks = <&clks IMX6SL_CLK_SSI1>; - dmas = <&sdma 37 1 0>, - <&sdma 38 1 0>; + dmas = <&sdma 37 22 0>, + <&sdma 38 22 0>; dma-names = "rx", "tx";
Re: BookE "branch taken" behavior vis-a-vis updating the NIP register
On Tue, 12 Nov 2013, pegasus wrote: > So, off I went and downloaded the latest version of > arch/powerpc/kernel/traps.c hoping to see those very changes in > them. However it didn't match one on one with what was written in > that thread. Ditto for the other files in your patch. Looks like > your patch didn't make it to upstream but it looks exactly like what > I need here. The patches were posted RFC -- request for comment. Thank you for posting your comments. > So requesting PTRACE_CONT has to happen inside the SIGTRAP signal > handler right? After you get the SIGTRAP from the branch, yeah. > Now as for the second patch, as far as I can see, implements the > same functionality. However it makes the change permanent and any > tool which is used to the NIP pointing to the branch target will be > broken. The second patch places the burden of determining if you are BookE or server on the tool. I feel this is important because the Server and Book-E branch exceptions are fundamentally incompatible, and the behavior of PTRACE_SINGLEBLOCK can not be made to be identical by the kernel for both subarch, so a tool will have to adjust accordingly. > Anyways, for me either of them will work. But I think the first patch makes > everyone happy by using the 'addr' field of ptrace. This also means I will > have to make my (broken) ptrace working which, it seems is not as easy > adding an enum field as you suggested. May be theres a check somewhere in > the actual ptrace code which checks for illegal values and hence even after > adding an enum, it is being reported as illegal in my case. However getting > that to work is another story. Actually, I provided the first patch to show why it probably should not be done even though technically possible, since it requires ptrace API to be extended to now recognize addr field, needs a TIF flag, etc. The second patch seems to me more reasonable to support, since nobody has come forth to say that there are actually any tools that rely upon the existing hack for BookE or even PTRACE_SINGLEBLOCK. And the existing hack's behavior makes things somewhat useless on BookE, as you and I have confirmed. > Please confirm my understanding of your patches and since these > patches have not made their way to the upstream kernel, will have to > use them myself directly. By the way, I'm using 2.6.32.10 (you > know..the long-term kernel) and I couldn't find any of your changes > in them but then again I couldn't find it in the latest 3.12 version > either. You will have to backport the patches to your kernel if you want to use them. Both patches change the behavior of existing API, and I guess we are still waiting to hear if anyone cares which way it should be fixed. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add a vga alias node for P1022
On Wed, 2013-11-13 at 00:28 -0600, Jin Zhengxiong-R64188 wrote: > > -Original Message- > > From: Jin Zhengxiong-R64188 > > Sent: Friday, September 06, 2013 5:33 PM > > To: Wood Scott-B07421 > > Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org; Jin > > Zhengxiong-R64188 > > Subject: [PATCH] Add a vga alias node for P1022 > > > > From: Jason Jin > > > > When the vga was set as the stdout and stderr in u-boot, the stdout fixup > > code in u-boot need to find out the vga alias node in dtb. > > > > Signed-off-by: Jason Jin > > --- > > arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 2 +- > > arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi | 1 + > > 2 files changed, 2 insertions(+), 1 deletion(-) > > [Jason Jin-R64188] Any comments about this patch? Thanks. This isn't a VGA-compatible device. If this is needed by U-Boot, please provide a comment explaining the compatibility issue, and ideally also provide a display alias so that no other components grow dependencies on the vga alias. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem reading and programming memory location...
On Wed, 13 Nov 2013 14:48:24 +0100 neorf3k wrote: > Yes, that is a device on the lpb via an fpga. We have tried to configure > the chip select 4 configuration register at address MBAR + 0x0310, and it > seems to be ok. what do you mean with “chip select parameters”? I meant the settings you can set up in the Chip Select 1–7 Configuration Registers, like address and data bus size, wait-states, etc. > We have been able to edit it in U-BOOT, and the board (that chip) now works… > The strange thing, is that when we read in linux, at that address, we see > other content value… > Suggestions? if you can access the register under U-Boot and read out the expected values, then the access should work under Linux too, assuming the chip select config is not overwritten somewhere while booting and the register address range is mapped correctly. I don't know your code, so I would first check if the register mapping is done correctly, i.e. check the return value of ioremap() for errors, then check if the chip select configuration is still valid when the kernel is up. Also verify that your fpga is not in the reset state when Linux is running. thanks, Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
On Tue, 2013-11-12 at 20:34 -0600, Emil Medve wrote: > Hello Scott, > > > On 11/12/2013 07:46 PM, Scott Wood wrote: > > On Tue, 2013-11-12 at 16:57 -0600, Emil Medve wrote: > >> Hello Scott, > >> > >> > >> On 11/12/2013 04:04 PM, Scott Wood wrote: > >>> On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote: > mpc85xx_smp_defconfig and mpc85xx_defconfig already have > CONFIG_P1023RDS=y. > Merge CONFIG_P1023RDB=y and other relevant configurations into > mpc85xx_smp_defconfig and mpc85_defconfig. > > Signed-off-by: Lijun Pan > --- > arch/powerpc/configs/85xx/p1023_defconfig | 188 > > arch/powerpc/configs/mpc85xx_defconfig | 18 +++ > arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++ > 3 files changed, 35 insertions(+), 188 deletions(-) > delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig > >>> > >>> Are we still going to want to have one defconfig if and when we finally > >>> get datapath support upstream? That's a lot of code to add to the 85xx > >>> config just for this one chip. > >> > >> Yes. But for mpc85xx_/smp_defconfig the datapath support shouldn't be > >> enabled by default given that just one SoC in that family has the > >> datapath (and we don't plan to put it in another e500v2 based SoC). For > >> regression/automation purposes config fragments should be used > > > > Is there any way to specify a meta-config for p1023 (or e500v2-dpaa or > > whatever) that says to combine mpc85xx_smp_defconfig with a dpaa > > fragment? > > Not aware of it Then it's not yet a substitute for having a defconfig. > > Do we have any config fragments in the tree so far? > > Nope. However, just to make sure, the fragment was my secondary point > and not necessarily as a candidate for upstreaming. My main point was > that the datapath support should simply not be enabled by default in the > mpc85xx_[smp_]defconfig I think we should get numbers on how big the datapath code is (in its eventual upstream form) before deciding that, but if we do end up deciding not to enable it in mpc85xx_smp_defconfig, then there should be a separate defconfig for p1023 (possibly with a more generic name as discussed earlier). If and when there's support for defconfigs that direct fragments to be included, then we can change the p1023 defconfig to use that, but I don't want to just leave it up to the user to enable manually. If there's any way we can get the datapath code down to a reasonable size for inclusion in mpc85xx_smp_defconfig, that would be ideal. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
Hello Scott, On 11/13/2013 12:19 PM, Scott Wood wrote: > On Tue, 2013-11-12 at 20:34 -0600, Emil Medve wrote: >> Hello Scott, >> >> >> On 11/12/2013 07:46 PM, Scott Wood wrote: >>> On Tue, 2013-11-12 at 16:57 -0600, Emil Medve wrote: Hello Scott, On 11/12/2013 04:04 PM, Scott Wood wrote: > On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote: >> mpc85xx_smp_defconfig and mpc85xx_defconfig already have >> CONFIG_P1023RDS=y. >> Merge CONFIG_P1023RDB=y and other relevant configurations into >> mpc85xx_smp_defconfig and mpc85_defconfig. >> >> Signed-off-by: Lijun Pan >> --- >> arch/powerpc/configs/85xx/p1023_defconfig | 188 >> >> arch/powerpc/configs/mpc85xx_defconfig | 18 +++ >> arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++ >> 3 files changed, 35 insertions(+), 188 deletions(-) >> delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig > > Are we still going to want to have one defconfig if and when we finally > get datapath support upstream? That's a lot of code to add to the 85xx > config just for this one chip. Yes. But for mpc85xx_/smp_defconfig the datapath support shouldn't be enabled by default given that just one SoC in that family has the datapath (and we don't plan to put it in another e500v2 based SoC). For regression/automation purposes config fragments should be used >>> >>> Is there any way to specify a meta-config for p1023 (or e500v2-dpaa or >>> whatever) that says to combine mpc85xx_smp_defconfig with a dpaa >>> fragment? >> >> Not aware of it > > Then it's not yet a substitute for having a defconfig. > >>> Do we have any config fragments in the tree so far? >> >> Nope. However, just to make sure, the fragment was my secondary point >> and not necessarily as a candidate for upstreaming. My main point was >> that the datapath support should simply not be enabled by default in the >> mpc85xx_[smp_]defconfig > > I think we should get numbers on how big the datapath code is (in its > eventual upstream form) before deciding that, but if we do end up > deciding not to enable it in mpc85xx_smp_defconfig, then there should be > a separate defconfig for p1023 (possibly with a more generic name as > discussed earlier). If and when there's support for defconfigs that > direct fragments to be included, then we can change the p1023 defconfig > to use that, but I don't want to just leave it up to the user to enable > manually. > > If there's any way we can get the datapath code down to a reasonable > size for inclusion in mpc85xx_smp_defconfig, that would be ideal. Somebody gratuitously added a P1023 defconfig more then two years ago with the notion that P1023 is special due to its datapath and we're still one year out before we'll have the (P1023) datapath driver upstream. As of now this defconfig is just bit-rotting in the tree creating confusion. Let's just remove it for now and we'll deal with the entire e500v2_dpaa business when the datapath support will be upstreamed Cheers, ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
On Wed, 2013-11-13 at 12:29 -0600, Emil Medve wrote: > Somebody gratuitously added a P1023 defconfig more then two years ago > with the notion that P1023 is special due to its datapath and we're > still one year out before we'll have the (P1023) datapath driver > upstream. As of now this defconfig is just bit-rotting in the tree > creating confusion. Let's just remove it for now and we'll deal with the > entire e500v2_dpaa business when the datapath support will be upstreamed Sure. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y. Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig. Signed-off-by: Lijun Pan --- arch/powerpc/configs/85xx/p1023_defconfig | 188 arch/powerpc/configs/mpc85xx_defconfig |3 + arch/powerpc/configs/mpc85xx_smp_defconfig |3 + 3 files changed, 6 insertions(+), 188 deletions(-) delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig diff --git a/arch/powerpc/configs/85xx/p1023_defconfig b/arch/powerpc/configs/85xx/p1023_defconfig deleted file mode 100644 index b06d37d..000 --- a/arch/powerpc/configs/85xx/p1023_defconfig +++ /dev/null @@ -1,188 +0,0 @@ -CONFIG_PPC_85xx=y -CONFIG_SMP=y -CONFIG_NR_CPUS=2 -CONFIG_SYSVIPC=y -CONFIG_POSIX_MQUEUE=y -CONFIG_BSD_PROCESS_ACCT=y -CONFIG_AUDIT=y -CONFIG_NO_HZ=y -CONFIG_HIGH_RES_TIMERS=y -CONFIG_RCU_FANOUT=32 -CONFIG_IKCONFIG=y -CONFIG_IKCONFIG_PROC=y -CONFIG_LOG_BUF_SHIFT=14 -CONFIG_BLK_DEV_INITRD=y -CONFIG_KALLSYMS_ALL=y -CONFIG_EMBEDDED=y -CONFIG_MODULES=y -CONFIG_MODULE_UNLOAD=y -CONFIG_MODULE_FORCE_UNLOAD=y -CONFIG_MODVERSIONS=y -# CONFIG_BLK_DEV_BSG is not set -CONFIG_PARTITION_ADVANCED=y -CONFIG_MAC_PARTITION=y -CONFIG_PHYSICAL_START=0x -CONFIG_P1023_RDB=y -CONFIG_P1023_RDS=y -CONFIG_QUICC_ENGINE=y -CONFIG_QE_GPIO=y -CONFIG_CPM2=y -CONFIG_HIGHMEM=y -# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set -CONFIG_BINFMT_MISC=m -CONFIG_MATH_EMULATION=y -CONFIG_SWIOTLB=y -CONFIG_PCI=y -CONFIG_PCIEPORTBUS=y -# CONFIG_PCIEAER is not set -# CONFIG_PCIEASPM is not set -CONFIG_PCI_MSI=y -CONFIG_NET=y -CONFIG_PACKET=y -CONFIG_UNIX=y -CONFIG_XFRM_USER=y -CONFIG_NET_KEY=y -CONFIG_INET=y -CONFIG_IP_MULTICAST=y -CONFIG_IP_ADVANCED_ROUTER=y -CONFIG_IP_MULTIPLE_TABLES=y -CONFIG_IP_ROUTE_MULTIPATH=y -CONFIG_IP_ROUTE_VERBOSE=y -CONFIG_IP_PNP=y -CONFIG_IP_PNP_DHCP=y -CONFIG_IP_PNP_BOOTP=y -CONFIG_IP_PNP_RARP=y -CONFIG_NET_IPIP=y -CONFIG_IP_MROUTE=y -CONFIG_IP_PIMSM_V1=y -CONFIG_IP_PIMSM_V2=y -CONFIG_ARPD=y -CONFIG_INET_ESP=y -# CONFIG_INET_XFRM_MODE_BEET is not set -# CONFIG_INET_LRO is not set -CONFIG_IPV6=y -CONFIG_IP_SCTP=m -CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" -CONFIG_DEVTMPFS=y -CONFIG_DEVTMPFS_MOUNT=y -CONFIG_MTD=y -CONFIG_MTD_CMDLINE_PARTS=y -CONFIG_MTD_CHAR=y -CONFIG_MTD_BLOCK=y -CONFIG_MTD_CFI=y -CONFIG_MTD_CFI_AMDSTD=y -CONFIG_MTD_PHYSMAP_OF=y -CONFIG_MTD_NAND=y -CONFIG_MTD_NAND_FSL_ELBC=y -CONFIG_PROC_DEVICETREE=y -CONFIG_BLK_DEV_LOOP=y -CONFIG_BLK_DEV_RAM=y -CONFIG_BLK_DEV_RAM_SIZE=131072 -CONFIG_EEPROM_AT24=y -CONFIG_EEPROM_LEGACY=y -CONFIG_BLK_DEV_SD=y -CONFIG_CHR_DEV_ST=y -CONFIG_BLK_DEV_SR=y -CONFIG_CHR_DEV_SG=y -CONFIG_SCSI_MULTI_LUN=y -CONFIG_SCSI_LOGGING=y -CONFIG_ATA=y -CONFIG_SATA_FSL=y -CONFIG_SATA_SIL24=y -CONFIG_NETDEVICES=y -CONFIG_DUMMY=y -CONFIG_FS_ENET=y -CONFIG_FSL_PQ_MDIO=y -CONFIG_E1000E=y -CONFIG_PHYLIB=y -CONFIG_AT803X_PHY=y -CONFIG_MARVELL_PHY=y -CONFIG_DAVICOM_PHY=y -CONFIG_CICADA_PHY=y -CONFIG_VITESSE_PHY=y -CONFIG_FIXED_PHY=y -CONFIG_INPUT_FF_MEMLESS=m -# CONFIG_INPUT_MOUSEDEV is not set -# CONFIG_INPUT_KEYBOARD is not set -# CONFIG_INPUT_MOUSE is not set -CONFIG_SERIO_LIBPS2=y -CONFIG_SERIAL_8250=y -CONFIG_SERIAL_8250_CONSOLE=y -CONFIG_SERIAL_8250_NR_UARTS=2 -CONFIG_SERIAL_8250_RUNTIME_UARTS=2 -CONFIG_SERIAL_8250_EXTENDED=y -CONFIG_SERIAL_8250_MANY_PORTS=y -CONFIG_SERIAL_8250_SHARE_IRQ=y -CONFIG_SERIAL_8250_DETECT_IRQ=y -CONFIG_SERIAL_8250_RSA=y -CONFIG_HW_RANDOM=y -CONFIG_NVRAM=y -CONFIG_I2C=y -CONFIG_I2C_CHARDEV=y -CONFIG_I2C_CPM=m -CONFIG_I2C_MPC=y -CONFIG_GPIO_MPC8XXX=y -# CONFIG_HWMON is not set -CONFIG_VIDEO_OUTPUT_CONTROL=y -CONFIG_SOUND=y -CONFIG_SND=y -CONFIG_SND_MIXER_OSS=y -CONFIG_SND_PCM_OSS=y -# CONFIG_SND_SUPPORT_OLD_API is not set -CONFIG_USB=y -CONFIG_USB_DEVICEFS=y -CONFIG_USB_MON=y -CONFIG_USB_EHCI_HCD=y -CONFIG_USB_EHCI_FSL=y -CONFIG_USB_STORAGE=y -CONFIG_EDAC=y -CONFIG_EDAC_MM_EDAC=y -CONFIG_RTC_CLASS=y -CONFIG_RTC_DRV_DS1307=y -CONFIG_RTC_DRV_CMOS=y -CONFIG_DMADEVICES=y -CONFIG_FSL_DMA=y -# CONFIG_NET_DMA is not set -CONFIG_STAGING=y -CONFIG_EXT2_FS=y -CONFIG_EXT3_FS=y -# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set -CONFIG_ISO9660_FS=m -CONFIG_JOLIET=y -CONFIG_ZISOFS=y -CONFIG_UDF_FS=m -CONFIG_MSDOS_FS=m -CONFIG_VFAT_FS=y -CONFIG_NTFS_FS=y -CONFIG_PROC_KCORE=y -CONFIG_TMPFS=y -CONFIG_ADFS_FS=m -CONFIG_AFFS_FS=m -CONFIG_HFS_FS=m -CONFIG_HFSPLUS_FS=m -CONFIG_BEFS_FS=m -CONFIG_BFS_FS=m -CONFIG_EFS_FS=m -CONFIG_CRAMFS=y -CONFIG_VXFS_FS=m -CONFIG_HPFS_FS=m -CONFIG_QNX4FS_FS=m -CONFIG_SYSV_FS=m -CONFIG_UFS_FS=m -CONFIG_NFS_FS=y -CONFIG_NFS_V4=y -CONFIG_ROOT_NFS=y -CONFIG_NFSD=y -CONFIG_CRC_T10DIF=y -CONFIG_FRAME_WARN=8092 -CONFIG_DEBUG_FS=y -CONFIG_DETECT_HUNG_TASK=y -# CONFIG_DEBUG_BUGVERBOSE is not set -CONFIG_DEBUG_INFO=y -CONFIG_STRICT_DEVMEM=y -CONFIG_CRYPTO_PCBC=m -CONFIG_CRYPTO_SHA256=y -CONFIG_CRYPTO_SHA512=y -CONFIG_CRYPTO_AES=y -# CONFIG_CRYPTO_ANSI_CPRNG is not set -CONFIG_CRYPTO_DEV_FSL_CAAM=y diff --git a/arch/powerpc/configs/m
[PATCH] powerpc: fix __get_user_pages_fast() irq handling
From: Heiko Carstens
__get_user_pages_fast() may be called with interrupts disabled (see e.g.
get_futex_key() in kernel/futex.c) and therefore should use local_irq_save()
and local_irq_restore() instead of local_irq_disable()/enable().
Signed-off-by: Heiko Carstens
---
(Was originally sent to lkml only, sending to linuxppc-dev so patchwork gets it)
arch/powerpc/mm/gup.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/gup.c b/arch/powerpc/mm/gup.c
index 6936547..c5f734e 100644
--- a/arch/powerpc/mm/gup.c
+++ b/arch/powerpc/mm/gup.c
@@ -123,6 +123,7 @@ int __get_user_pages_fast(unsigned long start, int
nr_pages, int write,
struct mm_struct *mm = current->mm;
unsigned long addr, len, end;
unsigned long next;
+ unsigned long flags;
pgd_t *pgdp;
int nr = 0;
@@ -156,7 +157,7 @@ int __get_user_pages_fast(unsigned long start, int
nr_pages, int write,
* So long as we atomically load page table pointers versus teardown,
* we can follow the address down to the the page and take a ref on it.
*/
- local_irq_disable();
+ local_irq_save(flags);
pgdp = pgd_offset(mm, addr);
do {
@@ -179,7 +180,7 @@ int __get_user_pages_fast(unsigned long start, int
nr_pages, int write,
break;
} while (pgdp++, addr = next, addr != end);
- local_irq_enable();
+ local_irq_restore(flags);
return nr;
}
--
1.8.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] Add a vga alias node for P1022
> > > > > > When the vga was set as the stdout and stderr in u-boot, the stdout > > > fixup code in u-boot need to find out the vga alias node in dtb. > > > > > > Signed-off-by: Jason Jin > > > --- > > > arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 2 +- > > > arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi | 1 + > > > 2 files changed, 2 insertions(+), 1 deletion(-) > > > > [Jason Jin-R64188] Any comments about this patch? Thanks. > > This isn't a VGA-compatible device. If this is needed by U-Boot, please > provide a comment explaining the compatibility issue, and ideally also > provide a display alias so that no other components grow dependencies on > the vga alias. > > -Scott > [Jason Jin-R64188] Thanks, will add description for why the vga alias node is needed by u-boot, and add another display alias node. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
