* [PATCH 3/4] ARM: davinci: dm355: Remove DMA resources for SPI
From: Peter Ujfalusi @ 2016-09-28 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160928103530.15291-1-peter.ujfalusi@ti.com>
The driver is converted to not use the DMA resource.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/mach-davinci/dm355.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index d33322ddedab..bd50367f654e 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -397,14 +397,6 @@ static struct resource dm355_spi0_resources[] = {
.start = IRQ_DM355_SPINT0_0,
.flags = IORESOURCE_IRQ,
},
- {
- .start = 17,
- .flags = IORESOURCE_DMA,
- },
- {
- .start = 16,
- .flags = IORESOURCE_DMA,
- },
};
static struct davinci_spi_platform_data dm355_spi0_pdata = {
--
2.10.0
^ permalink raw reply related
* [PATCH 2/4] ARM: davinci: devices: Remove DMA resources for MMC
From: Peter Ujfalusi @ 2016-09-28 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160928103530.15291-1-peter.ujfalusi@ti.com>
The driver is converted to not use the DMA resource.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/mach-davinci/devices.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 67d26c5bda0b..3ae70f2909b0 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -36,9 +36,6 @@
#define DM365_MMCSD0_BASE 0x01D11000
#define DM365_MMCSD1_BASE 0x01D00000
-#define DAVINCI_DMA_MMCRXEVT 26
-#define DAVINCI_DMA_MMCTXEVT 27
-
void __iomem *davinci_sysmod_base;
void davinci_map_sysmod(void)
--
2.10.0
^ permalink raw reply related
* [PATCH 1/4] ARM: davinci: devices-da8xx: Remove DMA resources for MMC and SPI
From: Peter Ujfalusi @ 2016-09-28 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160928103530.15291-1-peter.ujfalusi@ti.com>
The drivers are now converted to not use the DMA resource.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/mach-davinci/devices-da8xx.c | 29 -----------------------------
1 file changed, 29 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index add3771d38f6..dbdfe02b4174 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -57,15 +57,6 @@
#define DA8XX_EMAC_RAM_OFFSET 0x0000
#define DA8XX_EMAC_CTRL_RAM_SIZE SZ_8K
-#define DA8XX_DMA_SPI0_RX EDMA_CTLR_CHAN(0, 14)
-#define DA8XX_DMA_SPI0_TX EDMA_CTLR_CHAN(0, 15)
-#define DA8XX_DMA_MMCSD0_RX EDMA_CTLR_CHAN(0, 16)
-#define DA8XX_DMA_MMCSD0_TX EDMA_CTLR_CHAN(0, 17)
-#define DA8XX_DMA_SPI1_RX EDMA_CTLR_CHAN(0, 18)
-#define DA8XX_DMA_SPI1_TX EDMA_CTLR_CHAN(0, 19)
-#define DA850_DMA_MMCSD1_RX EDMA_CTLR_CHAN(1, 28)
-#define DA850_DMA_MMCSD1_TX EDMA_CTLR_CHAN(1, 29)
-
void __iomem *da8xx_syscfg0_base;
void __iomem *da8xx_syscfg1_base;
@@ -964,16 +955,6 @@ static struct resource da8xx_spi0_resources[] = {
.end = IRQ_DA8XX_SPINT0,
.flags = IORESOURCE_IRQ,
},
- [2] = {
- .start = DA8XX_DMA_SPI0_RX,
- .end = DA8XX_DMA_SPI0_RX,
- .flags = IORESOURCE_DMA,
- },
- [3] = {
- .start = DA8XX_DMA_SPI0_TX,
- .end = DA8XX_DMA_SPI0_TX,
- .flags = IORESOURCE_DMA,
- },
};
static struct resource da8xx_spi1_resources[] = {
@@ -987,16 +968,6 @@ static struct resource da8xx_spi1_resources[] = {
.end = IRQ_DA8XX_SPINT1,
.flags = IORESOURCE_IRQ,
},
- [2] = {
- .start = DA8XX_DMA_SPI1_RX,
- .end = DA8XX_DMA_SPI1_RX,
- .flags = IORESOURCE_DMA,
- },
- [3] = {
- .start = DA8XX_DMA_SPI1_TX,
- .end = DA8XX_DMA_SPI1_TX,
- .flags = IORESOURCE_DMA,
- },
};
static struct davinci_spi_platform_data da8xx_spi_pdata[] = {
--
2.10.0
^ permalink raw reply related
* [PATCH 0/4] ARM: davinci: Remove DMA resources for MMC/SPI
From: Peter Ujfalusi @ 2016-09-28 10:35 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The drivers for davinci MMC and SPI have been converted to the new DMAengine API
and no longer rely on the IORESOURCE_DMA.
This is the case for at least one release cycle so now we can remove the
IORESOURCE_DMA for these devices.
Regards,
Peter
---
Peter Ujfalusi (4):
ARM: davinci: devices-da8xx: Remove DMA resources for MMC and SPI
ARM: davinci: devices: Remove DMA resources for MMC
ARM: davinci: dm355: Remove DMA resources for SPI
ARM: davinci: dm365: Remove DMA resources for SPI
arch/arm/mach-davinci/devices-da8xx.c | 29 -----------------------------
arch/arm/mach-davinci/devices.c | 3 ---
arch/arm/mach-davinci/dm355.c | 8 --------
arch/arm/mach-davinci/dm365.c | 8 --------
4 files changed, 48 deletions(-)
--
2.10.0
^ permalink raw reply
* [PATCH] arm64: set path to Image.gz in the mkspec to avoid rpm build issue
From: Will Deacon @ 2016-09-28 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474991627-1743-1-git-send-email-Vadim.Lomovtsev@caviumnetworks.com>
[Adding Michal Marek]
On Tue, Sep 27, 2016 at 08:53:47AM -0700, Vadim Lomovtsev wrote:
> In addition to http://www.spinics.net/lists/arm-kernel/msg527466.html
>
> While building rpm-pkg target it fails to copy kernel image
> from default location to rpm buildroot directory.
>
> Since we have arch variable set to aarch64 while Image.gz
> is located at arch/arm64/boot it's necessary to specify
> correct path to cp command as it implemeted for ppc64 build.
>
> Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
> ---
> scripts/package/mkspec | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/scripts/package/mkspec b/scripts/package/mkspec
> index 57673ba..2f2bc7e 100755
> --- a/scripts/package/mkspec
> +++ b/scripts/package/mkspec
> @@ -101,9 +101,13 @@ echo "%ifarch ppc64"
> echo "cp vmlinux arch/powerpc/boot"
> echo "cp arch/powerpc/boot/"'$KBUILD_IMAGE $RPM_BUILD_ROOT'"/boot/vmlinuz-$KERNELRELEASE"
> echo "%else"
> +echo "%ifarch aarch64"
> +echo "cp arch/arm64/boot/"'$KBUILD_IMAGE $RPM_BUILD_ROOT'"/boot/vmlinuz-$KERNELRELEASE"
> +echo "%else"
> echo 'cp $KBUILD_IMAGE $RPM_BUILD_ROOT'"/boot/vmlinuz-$KERNELRELEASE"
> echo "%endif"
> echo "%endif"
> +echo "%endif"
>
> echo 'make %{?_smp_mflags} INSTALL_HDR_PATH=$RPM_BUILD_ROOT/usr KBUILD_SRC= headers_install'
> echo 'cp System.map $RPM_BUILD_ROOT'"/boot/System.map-$KERNELRELEASE"
> --
> 1.8.3.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 1/1] ARM: dma: fix dma_max_pfn()
From: Russell King - ARM Linux @ 2016-09-28 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <135ccf6f-ef3b-98a5-9d3d-4cd7f0967ceb@ti.com>
On Wed, Sep 28, 2016 at 10:53:49AM +0300, Roger Quadros wrote:
> Hi,
>
> On 12/09/16 14:38, Roger Quadros wrote:
> > Hi Santosh & Russell,
> >
> > On 19/08/16 19:38, Santosh Shilimkar wrote:
> >>
> >> On 8/19/2016 12:30 AM, Roger Quadros wrote:
> >>> Hi Santosh,
> >>>
> >>
> >>>>> So I'm 99.9% convinced that the proposed change is correct.
> >>>>>
> >>>> I will got with that then :-) and take my objection back. Just
> >>>> saying that if there other breakages which I can't recollect now,
> >>>> those drivers needs to be patched as well.
> >>>>
> >>> I was able to boot the Keystone2 Edison EVM over NFS with the $subject patch.
> >>> Boot log is below. Do you see anything suspicious?
> >>>
> >> Logs looks ok to me. Probably do some tests where DMA and bounce buffers etc gets tested. Running it through your internal regression
> >> suit will be good idea as well if thats possible.
> >>
> >
> > This has been running in our internal test suite for a week on various TI
> > platforms. There haven't been any surprises.
> >
> > Is it a good idea to at least put this in -next for a wider test audience?
>
> Gentle reminder.
Please put it in the patch system, thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 1/1] ARM: dma: fix dma_max_pfn()
From: Roger Quadros @ 2016-09-28 7:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c29290ee-9d74-73f9-7405-112357359f55@ti.com>
Hi,
On 12/09/16 14:38, Roger Quadros wrote:
> Hi Santosh & Russell,
>
> On 19/08/16 19:38, Santosh Shilimkar wrote:
>>
>> On 8/19/2016 12:30 AM, Roger Quadros wrote:
>>> Hi Santosh,
>>>
>>
>>>>> So I'm 99.9% convinced that the proposed change is correct.
>>>>>
>>>> I will got with that then :-) and take my objection back. Just
>>>> saying that if there other breakages which I can't recollect now,
>>>> those drivers needs to be patched as well.
>>>>
>>> I was able to boot the Keystone2 Edison EVM over NFS with the $subject patch.
>>> Boot log is below. Do you see anything suspicious?
>>>
>> Logs looks ok to me. Probably do some tests where DMA and bounce buffers etc gets tested. Running it through your internal regression
>> suit will be good idea as well if thats possible.
>>
>
> This has been running in our internal test suite for a week on various TI
> platforms. There haven't been any surprises.
>
> Is it a good idea to at least put this in -next for a wider test audience?
Gentle reminder.
regards,
-roger
^ permalink raw reply
* [RESEND PATCH v1] usb: ohci-at91: Use descriptor-based gpio APIs
From: Wenyou Yang @ 2016-09-28 7:44 UTC (permalink / raw)
To: linux-arm-kernel
Use the descriptor-based interface to manipulate GPIOs, instead of
the legacy integer-based interface.
In the meanwhile, remove unneeded vbus_pin_active_low[...] member.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
---
drivers/usb/host/ohci-at91.c | 120 ++++++++++---------------------------------
1 file changed, 28 insertions(+), 92 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index d177372..b0c7827 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -14,8 +14,8 @@
#include <linux/clk.h>
#include <linux/dma-mapping.h>
+#include <linux/gpio/consumer.h>
#include <linux/of_platform.h>
-#include <linux/of_gpio.h>
#include <linux/platform_device.h>
#include <linux/platform_data/atmel.h>
#include <linux/io.h>
@@ -36,11 +36,10 @@
#define AT91_MAX_USBH_PORTS 3
struct at91_usbh_data {
- int vbus_pin[AT91_MAX_USBH_PORTS]; /* port power-control pin */
- int overcurrent_pin[AT91_MAX_USBH_PORTS];
+ struct gpio_desc *vbus_pin[AT91_MAX_USBH_PORTS];
+ struct gpio_desc *overcurrent_pin[AT91_MAX_USBH_PORTS];
u8 ports; /* number of ports on root hub */
u8 overcurrent_supported;
- u8 vbus_pin_active_low[AT91_MAX_USBH_PORTS];
u8 overcurrent_status[AT91_MAX_USBH_PORTS];
u8 overcurrent_changed[AT91_MAX_USBH_PORTS];
};
@@ -243,11 +242,7 @@ static void ohci_at91_usb_set_power(struct at91_usbh_data *pdata, int port, int
if (!valid_port(port))
return;
- if (!gpio_is_valid(pdata->vbus_pin[port]))
- return;
-
- gpio_set_value(pdata->vbus_pin[port],
- pdata->vbus_pin_active_low[port] ^ enable);
+ gpiod_set_value(pdata->vbus_pin[port], enable);
}
static int ohci_at91_usb_get_power(struct at91_usbh_data *pdata, int port)
@@ -255,11 +250,7 @@ static int ohci_at91_usb_get_power(struct at91_usbh_data *pdata, int port)
if (!valid_port(port))
return -EINVAL;
- if (!gpio_is_valid(pdata->vbus_pin[port]))
- return -EINVAL;
-
- return gpio_get_value(pdata->vbus_pin[port]) ^
- pdata->vbus_pin_active_low[port];
+ return gpiod_get_value(pdata->vbus_pin[port]);
}
/*
@@ -406,16 +397,13 @@ static irqreturn_t ohci_hcd_at91_overcurrent_irq(int irq, void *data)
{
struct platform_device *pdev = data;
struct at91_usbh_data *pdata = dev_get_platdata(&pdev->dev);
- int val, gpio, port;
+ int val, port;
/* From the GPIO notifying the over-current situation, find
* out the corresponding port */
at91_for_each_port(port) {
- if (gpio_is_valid(pdata->overcurrent_pin[port]) &&
- gpio_to_irq(pdata->overcurrent_pin[port]) == irq) {
- gpio = pdata->overcurrent_pin[port];
+ if (gpiod_to_irq(pdata->overcurrent_pin[port]) == irq)
break;
- }
}
if (port == AT91_MAX_USBH_PORTS) {
@@ -423,7 +411,7 @@ static irqreturn_t ohci_hcd_at91_overcurrent_irq(int irq, void *data)
return IRQ_HANDLED;
}
- val = gpio_get_value(gpio);
+ val = gpiod_get_value(pdata->overcurrent_pin[port]);
/* When notified of an over-current situation, disable power
on the corresponding port, and mark this port in
@@ -454,9 +442,8 @@ static int ohci_hcd_at91_drv_probe(struct platform_device *pdev)
struct device_node *np = pdev->dev.of_node;
struct at91_usbh_data *pdata;
int i;
- int gpio;
int ret;
- enum of_gpio_flags flags;
+ int err;
u32 ports;
/* Right now device-tree probed devices don't get dma_mask set.
@@ -477,36 +464,12 @@ static int ohci_hcd_at91_drv_probe(struct platform_device *pdev)
pdata->ports = ports;
at91_for_each_port(i) {
- /*
- * do not configure PIO if not in relation with
- * real USB port on board
- */
- if (i >= pdata->ports) {
- pdata->vbus_pin[i] = -EINVAL;
- pdata->overcurrent_pin[i] = -EINVAL;
- continue;
- }
-
- gpio = of_get_named_gpio_flags(np, "atmel,vbus-gpio", i,
- &flags);
- pdata->vbus_pin[i] = gpio;
- if (!gpio_is_valid(gpio))
- continue;
- pdata->vbus_pin_active_low[i] = flags & OF_GPIO_ACTIVE_LOW;
-
- ret = gpio_request(gpio, "ohci_vbus");
- if (ret) {
- dev_err(&pdev->dev,
- "can't request vbus gpio %d\n", gpio);
- continue;
- }
- ret = gpio_direction_output(gpio,
- !pdata->vbus_pin_active_low[i]);
- if (ret) {
- dev_err(&pdev->dev,
- "can't put vbus gpio %d as output %d\n",
- gpio, !pdata->vbus_pin_active_low[i]);
- gpio_free(gpio);
+ pdata->vbus_pin[i] = devm_gpiod_get_optional(&pdev->dev,
+ "atmel,vbus-gpio",
+ GPIOD_IN);
+ if (IS_ERR(pdata->vbus_pin[i])) {
+ err = PTR_ERR(pdata->vbus_pin[i]);
+ dev_err(&pdev->dev, "unable to claim gpio \"vbus\": %d\n", err);
continue;
}
@@ -518,37 +481,21 @@ static int ohci_hcd_at91_drv_probe(struct platform_device *pdev)
break;
pdata->overcurrent_pin[i] =
- of_get_named_gpio_flags(np, "atmel,oc-gpio", i, &flags);
-
- if (!gpio_is_valid(pdata->overcurrent_pin[i]))
- continue;
- gpio = pdata->overcurrent_pin[i];
-
- ret = gpio_request(gpio, "ohci_overcurrent");
- if (ret) {
- dev_err(&pdev->dev,
- "can't request overcurrent gpio %d\n",
- gpio);
+ devm_gpiod_get_optional(&pdev->dev,
+ "atmel,oc-gpio", GPIOD_IN);
+ if (IS_ERR(pdata->overcurrent_pin[i])) {
+ err = PTR_ERR(pdata->overcurrent_pin[i]);
+ dev_err(&pdev->dev, "unable to claim gpio \"overcurrent\": %d\n", err);
continue;
}
- ret = gpio_direction_input(gpio);
- if (ret) {
- dev_err(&pdev->dev,
- "can't configure overcurrent gpio %d as input\n",
- gpio);
- gpio_free(gpio);
- continue;
- }
-
- ret = request_irq(gpio_to_irq(gpio),
- ohci_hcd_at91_overcurrent_irq,
- IRQF_SHARED, "ohci_overcurrent", pdev);
- if (ret) {
- gpio_free(gpio);
- dev_err(&pdev->dev,
- "can't get gpio IRQ for overcurrent\n");
- }
+ ret = devm_request_irq(&pdev->dev,
+ gpiod_to_irq(pdata->overcurrent_pin[i]),
+ ohci_hcd_at91_overcurrent_irq,
+ IRQF_SHARED,
+ "ohci_overcurrent", pdev);
+ if (ret)
+ dev_info(&pdev->dev, "failed to request gpio \"overcurrent\" IRQ\n");
}
device_init_wakeup(&pdev->dev, 1);
@@ -561,19 +508,8 @@ static int ohci_hcd_at91_drv_remove(struct platform_device *pdev)
int i;
if (pdata) {
- at91_for_each_port(i) {
- if (!gpio_is_valid(pdata->vbus_pin[i]))
- continue;
+ at91_for_each_port(i)
ohci_at91_usb_set_power(pdata, i, 0);
- gpio_free(pdata->vbus_pin[i]);
- }
-
- at91_for_each_port(i) {
- if (!gpio_is_valid(pdata->overcurrent_pin[i]))
- continue;
- free_irq(gpio_to_irq(pdata->overcurrent_pin[i]), pdev);
- gpio_free(pdata->overcurrent_pin[i]);
- }
}
device_init_wakeup(&pdev->dev, 0);
--
2.7.4
^ permalink raw reply related
* [PATCH v1] usb: ohci-at91: Use descriptor-based gpio APIs
From: Wenyou Yang @ 2016-09-28 7:43 UTC (permalink / raw)
To: linux-arm-kernel
Use the descriptor-based interface to manipulate GPIOs, instead of
the legacy integer-based interface.
In the meanwhile, remove unneeded vbus_pin_active_low[...] member.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
---
drivers/usb/host/ohci-at91.c | 120 ++++++++++---------------------------------
1 file changed, 28 insertions(+), 92 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index d177372..b0c7827 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -14,8 +14,8 @@
#include <linux/clk.h>
#include <linux/dma-mapping.h>
+#include <linux/gpio/consumer.h>
#include <linux/of_platform.h>
-#include <linux/of_gpio.h>
#include <linux/platform_device.h>
#include <linux/platform_data/atmel.h>
#include <linux/io.h>
@@ -36,11 +36,10 @@
#define AT91_MAX_USBH_PORTS 3
struct at91_usbh_data {
- int vbus_pin[AT91_MAX_USBH_PORTS]; /* port power-control pin */
- int overcurrent_pin[AT91_MAX_USBH_PORTS];
+ struct gpio_desc *vbus_pin[AT91_MAX_USBH_PORTS];
+ struct gpio_desc *overcurrent_pin[AT91_MAX_USBH_PORTS];
u8 ports; /* number of ports on root hub */
u8 overcurrent_supported;
- u8 vbus_pin_active_low[AT91_MAX_USBH_PORTS];
u8 overcurrent_status[AT91_MAX_USBH_PORTS];
u8 overcurrent_changed[AT91_MAX_USBH_PORTS];
};
@@ -243,11 +242,7 @@ static void ohci_at91_usb_set_power(struct at91_usbh_data *pdata, int port, int
if (!valid_port(port))
return;
- if (!gpio_is_valid(pdata->vbus_pin[port]))
- return;
-
- gpio_set_value(pdata->vbus_pin[port],
- pdata->vbus_pin_active_low[port] ^ enable);
+ gpiod_set_value(pdata->vbus_pin[port], enable);
}
static int ohci_at91_usb_get_power(struct at91_usbh_data *pdata, int port)
@@ -255,11 +250,7 @@ static int ohci_at91_usb_get_power(struct at91_usbh_data *pdata, int port)
if (!valid_port(port))
return -EINVAL;
- if (!gpio_is_valid(pdata->vbus_pin[port]))
- return -EINVAL;
-
- return gpio_get_value(pdata->vbus_pin[port]) ^
- pdata->vbus_pin_active_low[port];
+ return gpiod_get_value(pdata->vbus_pin[port]);
}
/*
@@ -406,16 +397,13 @@ static irqreturn_t ohci_hcd_at91_overcurrent_irq(int irq, void *data)
{
struct platform_device *pdev = data;
struct at91_usbh_data *pdata = dev_get_platdata(&pdev->dev);
- int val, gpio, port;
+ int val, port;
/* From the GPIO notifying the over-current situation, find
* out the corresponding port */
at91_for_each_port(port) {
- if (gpio_is_valid(pdata->overcurrent_pin[port]) &&
- gpio_to_irq(pdata->overcurrent_pin[port]) == irq) {
- gpio = pdata->overcurrent_pin[port];
+ if (gpiod_to_irq(pdata->overcurrent_pin[port]) == irq)
break;
- }
}
if (port == AT91_MAX_USBH_PORTS) {
@@ -423,7 +411,7 @@ static irqreturn_t ohci_hcd_at91_overcurrent_irq(int irq, void *data)
return IRQ_HANDLED;
}
- val = gpio_get_value(gpio);
+ val = gpiod_get_value(pdata->overcurrent_pin[port]);
/* When notified of an over-current situation, disable power
on the corresponding port, and mark this port in
@@ -454,9 +442,8 @@ static int ohci_hcd_at91_drv_probe(struct platform_device *pdev)
struct device_node *np = pdev->dev.of_node;
struct at91_usbh_data *pdata;
int i;
- int gpio;
int ret;
- enum of_gpio_flags flags;
+ int err;
u32 ports;
/* Right now device-tree probed devices don't get dma_mask set.
@@ -477,36 +464,12 @@ static int ohci_hcd_at91_drv_probe(struct platform_device *pdev)
pdata->ports = ports;
at91_for_each_port(i) {
- /*
- * do not configure PIO if not in relation with
- * real USB port on board
- */
- if (i >= pdata->ports) {
- pdata->vbus_pin[i] = -EINVAL;
- pdata->overcurrent_pin[i] = -EINVAL;
- continue;
- }
-
- gpio = of_get_named_gpio_flags(np, "atmel,vbus-gpio", i,
- &flags);
- pdata->vbus_pin[i] = gpio;
- if (!gpio_is_valid(gpio))
- continue;
- pdata->vbus_pin_active_low[i] = flags & OF_GPIO_ACTIVE_LOW;
-
- ret = gpio_request(gpio, "ohci_vbus");
- if (ret) {
- dev_err(&pdev->dev,
- "can't request vbus gpio %d\n", gpio);
- continue;
- }
- ret = gpio_direction_output(gpio,
- !pdata->vbus_pin_active_low[i]);
- if (ret) {
- dev_err(&pdev->dev,
- "can't put vbus gpio %d as output %d\n",
- gpio, !pdata->vbus_pin_active_low[i]);
- gpio_free(gpio);
+ pdata->vbus_pin[i] = devm_gpiod_get_optional(&pdev->dev,
+ "atmel,vbus-gpio",
+ GPIOD_IN);
+ if (IS_ERR(pdata->vbus_pin[i])) {
+ err = PTR_ERR(pdata->vbus_pin[i]);
+ dev_err(&pdev->dev, "unable to claim gpio \"vbus\": %d\n", err);
continue;
}
@@ -518,37 +481,21 @@ static int ohci_hcd_at91_drv_probe(struct platform_device *pdev)
break;
pdata->overcurrent_pin[i] =
- of_get_named_gpio_flags(np, "atmel,oc-gpio", i, &flags);
-
- if (!gpio_is_valid(pdata->overcurrent_pin[i]))
- continue;
- gpio = pdata->overcurrent_pin[i];
-
- ret = gpio_request(gpio, "ohci_overcurrent");
- if (ret) {
- dev_err(&pdev->dev,
- "can't request overcurrent gpio %d\n",
- gpio);
+ devm_gpiod_get_optional(&pdev->dev,
+ "atmel,oc-gpio", GPIOD_IN);
+ if (IS_ERR(pdata->overcurrent_pin[i])) {
+ err = PTR_ERR(pdata->overcurrent_pin[i]);
+ dev_err(&pdev->dev, "unable to claim gpio \"overcurrent\": %d\n", err);
continue;
}
- ret = gpio_direction_input(gpio);
- if (ret) {
- dev_err(&pdev->dev,
- "can't configure overcurrent gpio %d as input\n",
- gpio);
- gpio_free(gpio);
- continue;
- }
-
- ret = request_irq(gpio_to_irq(gpio),
- ohci_hcd_at91_overcurrent_irq,
- IRQF_SHARED, "ohci_overcurrent", pdev);
- if (ret) {
- gpio_free(gpio);
- dev_err(&pdev->dev,
- "can't get gpio IRQ for overcurrent\n");
- }
+ ret = devm_request_irq(&pdev->dev,
+ gpiod_to_irq(pdata->overcurrent_pin[i]),
+ ohci_hcd_at91_overcurrent_irq,
+ IRQF_SHARED,
+ "ohci_overcurrent", pdev);
+ if (ret)
+ dev_info(&pdev->dev, "failed to request gpio \"overcurrent\" IRQ\n");
}
device_init_wakeup(&pdev->dev, 1);
@@ -561,19 +508,8 @@ static int ohci_hcd_at91_drv_remove(struct platform_device *pdev)
int i;
if (pdata) {
- at91_for_each_port(i) {
- if (!gpio_is_valid(pdata->vbus_pin[i]))
- continue;
+ at91_for_each_port(i)
ohci_at91_usb_set_power(pdata, i, 0);
- gpio_free(pdata->vbus_pin[i]);
- }
-
- at91_for_each_port(i) {
- if (!gpio_is_valid(pdata->overcurrent_pin[i]))
- continue;
- free_irq(gpio_to_irq(pdata->overcurrent_pin[i]), pdev);
- gpio_free(pdata->overcurrent_pin[i]);
- }
}
device_init_wakeup(&pdev->dev, 0);
--
2.7.4
^ permalink raw reply related
* [PATCH v1] usb: ohci-at91: Use descriptor-based gpio APIs
From: Wenyou Yang @ 2016-09-28 7:41 UTC (permalink / raw)
To: linux-arm-kernel
Use the descriptor-based interface to manipulate GPIOs, instead of
the legacy integer-based interface.
In the meanwhile, remove unneeded vbus_pin_active_low[...] member.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
---
drivers/usb/host/ohci-at91.c | 120 ++++++++++---------------------------------
1 file changed, 28 insertions(+), 92 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index d177372..b0c7827 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -14,8 +14,8 @@
#include <linux/clk.h>
#include <linux/dma-mapping.h>
+#include <linux/gpio/consumer.h>
#include <linux/of_platform.h>
-#include <linux/of_gpio.h>
#include <linux/platform_device.h>
#include <linux/platform_data/atmel.h>
#include <linux/io.h>
@@ -36,11 +36,10 @@
#define AT91_MAX_USBH_PORTS 3
struct at91_usbh_data {
- int vbus_pin[AT91_MAX_USBH_PORTS]; /* port power-control pin */
- int overcurrent_pin[AT91_MAX_USBH_PORTS];
+ struct gpio_desc *vbus_pin[AT91_MAX_USBH_PORTS];
+ struct gpio_desc *overcurrent_pin[AT91_MAX_USBH_PORTS];
u8 ports; /* number of ports on root hub */
u8 overcurrent_supported;
- u8 vbus_pin_active_low[AT91_MAX_USBH_PORTS];
u8 overcurrent_status[AT91_MAX_USBH_PORTS];
u8 overcurrent_changed[AT91_MAX_USBH_PORTS];
};
@@ -243,11 +242,7 @@ static void ohci_at91_usb_set_power(struct at91_usbh_data *pdata, int port, int
if (!valid_port(port))
return;
- if (!gpio_is_valid(pdata->vbus_pin[port]))
- return;
-
- gpio_set_value(pdata->vbus_pin[port],
- pdata->vbus_pin_active_low[port] ^ enable);
+ gpiod_set_value(pdata->vbus_pin[port], enable);
}
static int ohci_at91_usb_get_power(struct at91_usbh_data *pdata, int port)
@@ -255,11 +250,7 @@ static int ohci_at91_usb_get_power(struct at91_usbh_data *pdata, int port)
if (!valid_port(port))
return -EINVAL;
- if (!gpio_is_valid(pdata->vbus_pin[port]))
- return -EINVAL;
-
- return gpio_get_value(pdata->vbus_pin[port]) ^
- pdata->vbus_pin_active_low[port];
+ return gpiod_get_value(pdata->vbus_pin[port]);
}
/*
@@ -406,16 +397,13 @@ static irqreturn_t ohci_hcd_at91_overcurrent_irq(int irq, void *data)
{
struct platform_device *pdev = data;
struct at91_usbh_data *pdata = dev_get_platdata(&pdev->dev);
- int val, gpio, port;
+ int val, port;
/* From the GPIO notifying the over-current situation, find
* out the corresponding port */
at91_for_each_port(port) {
- if (gpio_is_valid(pdata->overcurrent_pin[port]) &&
- gpio_to_irq(pdata->overcurrent_pin[port]) == irq) {
- gpio = pdata->overcurrent_pin[port];
+ if (gpiod_to_irq(pdata->overcurrent_pin[port]) == irq)
break;
- }
}
if (port == AT91_MAX_USBH_PORTS) {
@@ -423,7 +411,7 @@ static irqreturn_t ohci_hcd_at91_overcurrent_irq(int irq, void *data)
return IRQ_HANDLED;
}
- val = gpio_get_value(gpio);
+ val = gpiod_get_value(pdata->overcurrent_pin[port]);
/* When notified of an over-current situation, disable power
on the corresponding port, and mark this port in
@@ -454,9 +442,8 @@ static int ohci_hcd_at91_drv_probe(struct platform_device *pdev)
struct device_node *np = pdev->dev.of_node;
struct at91_usbh_data *pdata;
int i;
- int gpio;
int ret;
- enum of_gpio_flags flags;
+ int err;
u32 ports;
/* Right now device-tree probed devices don't get dma_mask set.
@@ -477,36 +464,12 @@ static int ohci_hcd_at91_drv_probe(struct platform_device *pdev)
pdata->ports = ports;
at91_for_each_port(i) {
- /*
- * do not configure PIO if not in relation with
- * real USB port on board
- */
- if (i >= pdata->ports) {
- pdata->vbus_pin[i] = -EINVAL;
- pdata->overcurrent_pin[i] = -EINVAL;
- continue;
- }
-
- gpio = of_get_named_gpio_flags(np, "atmel,vbus-gpio", i,
- &flags);
- pdata->vbus_pin[i] = gpio;
- if (!gpio_is_valid(gpio))
- continue;
- pdata->vbus_pin_active_low[i] = flags & OF_GPIO_ACTIVE_LOW;
-
- ret = gpio_request(gpio, "ohci_vbus");
- if (ret) {
- dev_err(&pdev->dev,
- "can't request vbus gpio %d\n", gpio);
- continue;
- }
- ret = gpio_direction_output(gpio,
- !pdata->vbus_pin_active_low[i]);
- if (ret) {
- dev_err(&pdev->dev,
- "can't put vbus gpio %d as output %d\n",
- gpio, !pdata->vbus_pin_active_low[i]);
- gpio_free(gpio);
+ pdata->vbus_pin[i] = devm_gpiod_get_optional(&pdev->dev,
+ "atmel,vbus-gpio",
+ GPIOD_IN);
+ if (IS_ERR(pdata->vbus_pin[i])) {
+ err = PTR_ERR(pdata->vbus_pin[i]);
+ dev_err(&pdev->dev, "unable to claim gpio \"vbus\": %d\n", err);
continue;
}
@@ -518,37 +481,21 @@ static int ohci_hcd_at91_drv_probe(struct platform_device *pdev)
break;
pdata->overcurrent_pin[i] =
- of_get_named_gpio_flags(np, "atmel,oc-gpio", i, &flags);
-
- if (!gpio_is_valid(pdata->overcurrent_pin[i]))
- continue;
- gpio = pdata->overcurrent_pin[i];
-
- ret = gpio_request(gpio, "ohci_overcurrent");
- if (ret) {
- dev_err(&pdev->dev,
- "can't request overcurrent gpio %d\n",
- gpio);
+ devm_gpiod_get_optional(&pdev->dev,
+ "atmel,oc-gpio", GPIOD_IN);
+ if (IS_ERR(pdata->overcurrent_pin[i])) {
+ err = PTR_ERR(pdata->overcurrent_pin[i]);
+ dev_err(&pdev->dev, "unable to claim gpio \"overcurrent\": %d\n", err);
continue;
}
- ret = gpio_direction_input(gpio);
- if (ret) {
- dev_err(&pdev->dev,
- "can't configure overcurrent gpio %d as input\n",
- gpio);
- gpio_free(gpio);
- continue;
- }
-
- ret = request_irq(gpio_to_irq(gpio),
- ohci_hcd_at91_overcurrent_irq,
- IRQF_SHARED, "ohci_overcurrent", pdev);
- if (ret) {
- gpio_free(gpio);
- dev_err(&pdev->dev,
- "can't get gpio IRQ for overcurrent\n");
- }
+ ret = devm_request_irq(&pdev->dev,
+ gpiod_to_irq(pdata->overcurrent_pin[i]),
+ ohci_hcd_at91_overcurrent_irq,
+ IRQF_SHARED,
+ "ohci_overcurrent", pdev);
+ if (ret)
+ dev_info(&pdev->dev, "failed to request gpio \"overcurrent\" IRQ\n");
}
device_init_wakeup(&pdev->dev, 1);
@@ -561,19 +508,8 @@ static int ohci_hcd_at91_drv_remove(struct platform_device *pdev)
int i;
if (pdata) {
- at91_for_each_port(i) {
- if (!gpio_is_valid(pdata->vbus_pin[i]))
- continue;
+ at91_for_each_port(i)
ohci_at91_usb_set_power(pdata, i, 0);
- gpio_free(pdata->vbus_pin[i]);
- }
-
- at91_for_each_port(i) {
- if (!gpio_is_valid(pdata->overcurrent_pin[i]))
- continue;
- free_irq(gpio_to_irq(pdata->overcurrent_pin[i]), pdev);
- gpio_free(pdata->overcurrent_pin[i]);
- }
}
device_init_wakeup(&pdev->dev, 0);
--
2.7.4
^ permalink raw reply related
* [PATCH v7 6/7] arm/arm64: vgic: Implement VGICv3 CPU interface access
From: Vijay Kilari @ 2016-09-28 7:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474645482-28131-7-git-send-email-vijay.kilari@gmail.com>
On Fri, Sep 23, 2016 at 9:14 PM, <vijay.kilari@gmail.com> wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>
> VGICv3 CPU interface registers are accessed using
> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
> as 64-bit. The cpu MPIDR value is passed along with register id.
> is used to identify the cpu for registers access.
>
> The version of VGIC v3 specification is define here
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>
> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> ---
> arch/arm64/include/uapi/asm/kvm.h | 3 +
> arch/arm64/kvm/Makefile | 1 +
> include/kvm/arm_vgic.h | 9 +
> virt/kvm/arm/vgic/vgic-kvm-device.c | 27 +++
> virt/kvm/arm/vgic/vgic-mmio-v3.c | 19 +++
> virt/kvm/arm/vgic/vgic-sys-reg-v3.c | 324 ++++++++++++++++++++++++++++++++++++
> virt/kvm/arm/vgic/vgic-v3.c | 8 +
> virt/kvm/arm/vgic/vgic.h | 4 +
> 8 files changed, 395 insertions(+)
>
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 56dc08d..91c7137 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -206,9 +206,12 @@ struct kvm_arch_memory_slot {
> (0xffffffffULL << KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT)
> #define KVM_DEV_ARM_VGIC_OFFSET_SHIFT 0
> #define KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
> +#define KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK (0xffff)
> #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
> #define KVM_DEV_ARM_VGIC_GRP_CTRL 4
> #define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
> +#define KVM_DEV_ARM_VGIC_CPU_SYSREGS 6
> +
> #define KVM_DEV_ARM_VGIC_CTRL_INIT 0
>
> /* Device Control API on vcpu fd */
> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
> index d50a82a..1a14e29 100644
> --- a/arch/arm64/kvm/Makefile
> +++ b/arch/arm64/kvm/Makefile
> @@ -32,5 +32,6 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-mmio-v3.o
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-kvm-device.o
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-its.o
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/irqchip.o
> +kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-sys-reg-v3.o
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/arch_timer.o
> kvm-$(CONFIG_KVM_ARM_PMU) += $(KVM)/arm/pmu.o
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index 002f092..730a18a 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -71,6 +71,9 @@ struct vgic_global {
>
> /* GIC system register CPU interface */
> struct static_key_false gicv3_cpuif;
> +
> + /* Cache ICH_VTR_EL2 reg value */
> + u32 ich_vtr_el2;
> };
>
> extern struct vgic_global kvm_vgic_global_state;
> @@ -269,6 +272,12 @@ struct vgic_cpu {
> u64 pendbaser;
>
> bool lpis_enabled;
> +
> + /* Cache guest priority bits */
> + u32 num_pri_bits;
> +
> + /* Cache guest interrupt ID bits */
> + u32 num_id_bits;
> };
>
> extern struct static_key_false vgic_v2_cpuif_trap;
> diff --git a/virt/kvm/arm/vgic/vgic-kvm-device.c b/virt/kvm/arm/vgic/vgic-kvm-device.c
> index 6c7d30c..da532d1 100644
> --- a/virt/kvm/arm/vgic/vgic-kvm-device.c
> +++ b/virt/kvm/arm/vgic/vgic-kvm-device.c
> @@ -504,6 +504,14 @@ static int vgic_v3_attr_regs_access(struct kvm_device *dev,
> if (!is_write)
> *reg = tmp32;
> break;
> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
> + u64 regid;
> +
> + regid = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK);
> + ret = vgic_v3_cpu_sysregs_uaccess(vcpu, is_write,
> + regid, reg);
> + break;
> + }
> default:
> ret = -EINVAL;
> break;
> @@ -537,6 +545,15 @@ static int vgic_v3_set_attr(struct kvm_device *dev,
> reg = tmp32;
> return vgic_v3_attr_regs_access(dev, attr, ®, true);
> }
> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
> + u64 __user *uaddr = (u64 __user *)(long)attr->addr;
> + u64 reg;
> +
> + if (get_user(reg, uaddr))
> + return -EFAULT;
> +
> + return vgic_v3_attr_regs_access(dev, attr, ®, true);
> + }
> }
> return -ENXIO;
> }
> @@ -563,6 +580,15 @@ static int vgic_v3_get_attr(struct kvm_device *dev,
> tmp32 = reg;
> return put_user(tmp32, uaddr);
> }
> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
> + u64 __user *uaddr = (u64 __user *)(long)attr->addr;
> + u64 reg;
> +
> + ret = vgic_v3_attr_regs_access(dev, attr, ®, false);
> + if (ret)
> + return ret;
> + return put_user(reg, uaddr);
> + }
> }
>
> return -ENXIO;
> @@ -581,6 +607,7 @@ static int vgic_v3_has_attr(struct kvm_device *dev,
> break;
> case KVM_DEV_ARM_VGIC_GRP_DIST_REGS:
> case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS:
> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS:
> return vgic_v3_has_attr_regs(dev, attr);
> case KVM_DEV_ARM_VGIC_GRP_NR_IRQS:
> return 0;
> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> index b35fb83..8f46e61 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> @@ -23,6 +23,7 @@
>
> #include "vgic.h"
> #include "vgic-mmio.h"
> +#include "sys_regs.h"
>
> /* extract @num bytes at @offset bytes offset in data */
> unsigned long extract_bytes(u64 data, unsigned int offset,
> @@ -639,6 +640,24 @@ int vgic_v3_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr)
> nr_regions = ARRAY_SIZE(vgic_v3_rdbase_registers);
> break;
> }
> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
> + u64 reg, id;
> + unsigned long vgic_mpidr, mpidr_reg;
> + struct kvm_vcpu *vcpu;
> +
> + vgic_mpidr = (attr->attr & KVM_DEV_ARM_VGIC_V3_MPIDR_MASK) >>
> + KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT;
> +
> + /* Convert plain mpidr value to MPIDR reg format */
> + mpidr_reg = VGIC_TO_MPIDR(mpidr_reg);
My bad, Wrong parameter. I will fix it.
^ permalink raw reply
* [PATCH] usb: Convert pr_warning to pr_warn
From: Nicolas Ferre @ 2016-09-28 7:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f86b512272987e0faeaccbe6466665175eaefe9a.1474992979.git.joe@perches.com>
Le 27/09/2016 ? 18:16, Joe Perches a ?crit :
> Use the more common logging mechanism.
>
> Miscellanea:
>
> o Realign multiline statements
> o Coalesce format
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/usb/gadget/function/rndis.c | 9 ++++-----
> drivers/usb/gadget/function/u_serial.c | 4 ++--
> drivers/usb/gadget/udc/at91_udc.h | 2 +-
> drivers/usb/gadget/udc/atmel_usba_udc.c | 4 ++--
For AT91 and Atmel parts:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks
> drivers/usb/gadget/udc/fsl_usb2_udc.h | 2 +-
> drivers/usb/gadget/udc/m66592-udc.c | 4 ++--
> drivers/usb/gadget/udc/omap_udc.h | 2 +-
> drivers/usb/gadget/udc/pxa25x_udc.h | 2 +-
> drivers/usb/host/isp1362-hcd.c | 27 ++++++++++++++-------------
> drivers/usb/isp1760/isp1760-if.c | 2 +-
> 10 files changed, 29 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/rndis.c b/drivers/usb/gadget/function/rndis.c
> index ab6ac1b74ac0..766c328c15c0 100644
> --- a/drivers/usb/gadget/function/rndis.c
> +++ b/drivers/usb/gadget/function/rndis.c
> @@ -474,8 +474,7 @@ static int gen_ndis_query_resp(struct rndis_params *params, u32 OID, u8 *buf,
> break;
>
> default:
> - pr_warning("%s: query unknown OID 0x%08X\n",
> - __func__, OID);
> + pr_warn("%s: query unknown OID 0x%08X\n", __func__, OID);
> }
> if (retval < 0)
> length = 0;
> @@ -546,8 +545,8 @@ static int gen_ndis_set_resp(struct rndis_params *params, u32 OID,
> break;
>
> default:
> - pr_warning("%s: set unknown OID 0x%08X, size %d\n",
> - __func__, OID, buf_len);
> + pr_warn("%s: set unknown OID 0x%08X, size %d\n",
> + __func__, OID, buf_len);
> }
>
> return retval;
> @@ -854,7 +853,7 @@ int rndis_msg_parser(struct rndis_params *params, u8 *buf)
> * In one case those messages seemed to relate to the host
> * suspending itself.
> */
> - pr_warning("%s: unknown RNDIS message 0x%08X len %d\n",
> + pr_warn("%s: unknown RNDIS message 0x%08X len %d\n",
> __func__, MsgType, MsgLength);
> print_hex_dump_bytes(__func__, DUMP_PREFIX_OFFSET,
> buf, MsgLength);
> diff --git a/drivers/usb/gadget/function/u_serial.c b/drivers/usb/gadget/function/u_serial.c
> index e0cd1e4c8892..62ec842874aa 100644
> --- a/drivers/usb/gadget/function/u_serial.c
> +++ b/drivers/usb/gadget/function/u_serial.c
> @@ -622,8 +622,8 @@ static void gs_write_complete(struct usb_ep *ep, struct usb_request *req)
> switch (req->status) {
> default:
> /* presumably a transient fault */
> - pr_warning("%s: unexpected %s status %d\n",
> - __func__, ep->name, req->status);
> + pr_warn("%s: unexpected %s status %d\n",
> + __func__, ep->name, req->status);
> /* FALL THROUGH */
> case 0:
> /* normal completion */
> diff --git a/drivers/usb/gadget/udc/at91_udc.h b/drivers/usb/gadget/udc/at91_udc.h
> index 0a433e6b346b..9bbe72764f31 100644
> --- a/drivers/usb/gadget/udc/at91_udc.h
> +++ b/drivers/usb/gadget/udc/at91_udc.h
> @@ -175,7 +175,7 @@ struct at91_request {
> #endif
>
> #define ERR(stuff...) pr_err("udc: " stuff)
> -#define WARNING(stuff...) pr_warning("udc: " stuff)
> +#define WARNING(stuff...) pr_warn("udc: " stuff)
> #define INFO(stuff...) pr_info("udc: " stuff)
> #define DBG(stuff...) pr_debug("udc: " stuff)
>
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index 45bc997d0711..1ef7a9a9d7f5 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -1464,8 +1464,8 @@ static void usba_control_irq(struct usba_udc *udc, struct usba_ep *ep)
> pkt_len = USBA_BFEXT(BYTE_COUNT, usba_ep_readl(ep, STA));
> DBG(DBG_HW, "Packet length: %u\n", pkt_len);
> if (pkt_len != sizeof(crq)) {
> - pr_warning("udc: Invalid packet length %u "
> - "(expected %zu)\n", pkt_len, sizeof(crq));
> + pr_warn("udc: Invalid packet length %u (expected %zu)\n",
> + pkt_len, sizeof(crq));
> set_protocol_stall(udc, ep);
> return;
> }
> diff --git a/drivers/usb/gadget/udc/fsl_usb2_udc.h b/drivers/usb/gadget/udc/fsl_usb2_udc.h
> index 84715625b2b3..e92b8408b6f6 100644
> --- a/drivers/usb/gadget/udc/fsl_usb2_udc.h
> +++ b/drivers/usb/gadget/udc/fsl_usb2_udc.h
> @@ -554,7 +554,7 @@ static void dump_msg(const char *label, const u8 * buf, unsigned int length)
> #endif
>
> #define ERR(stuff...) pr_err("udc: " stuff)
> -#define WARNING(stuff...) pr_warning("udc: " stuff)
> +#define WARNING(stuff...) pr_warn("udc: " stuff)
> #define INFO(stuff...) pr_info("udc: " stuff)
>
> /*-------------------------------------------------------------------------*/
> diff --git a/drivers/usb/gadget/udc/m66592-udc.c b/drivers/usb/gadget/udc/m66592-udc.c
> index 6e977dc22570..de3e03483659 100644
> --- a/drivers/usb/gadget/udc/m66592-udc.c
> +++ b/drivers/usb/gadget/udc/m66592-udc.c
> @@ -637,7 +637,7 @@ static void init_controller(struct m66592 *m66592)
> clock = M66592_XTAL48;
> break;
> default:
> - pr_warning("m66592-udc: xtal configuration error\n");
> + pr_warn("m66592-udc: xtal configuration error\n");
> clock = 0;
> }
>
> @@ -649,7 +649,7 @@ static void init_controller(struct m66592 *m66592)
> irq_sense = 0;
> break;
> default:
> - pr_warning("m66592-udc: irq trigger config error\n");
> + pr_warn("m66592-udc: irq trigger config error\n");
> irq_sense = 0;
> }
>
> diff --git a/drivers/usb/gadget/udc/omap_udc.h b/drivers/usb/gadget/udc/omap_udc.h
> index cfadeb5fc5de..26974196cf44 100644
> --- a/drivers/usb/gadget/udc/omap_udc.h
> +++ b/drivers/usb/gadget/udc/omap_udc.h
> @@ -187,7 +187,7 @@ struct omap_udc {
> #endif
>
> #define ERR(stuff...) pr_err("udc: " stuff)
> -#define WARNING(stuff...) pr_warning("udc: " stuff)
> +#define WARNING(stuff...) pr_warn("udc: " stuff)
> #define INFO(stuff...) pr_info("udc: " stuff)
> #define DBG(stuff...) pr_debug("udc: " stuff)
>
> diff --git a/drivers/usb/gadget/udc/pxa25x_udc.h b/drivers/usb/gadget/udc/pxa25x_udc.h
> index 4b8b72d7ab37..a458bec2536d 100644
> --- a/drivers/usb/gadget/udc/pxa25x_udc.h
> +++ b/drivers/usb/gadget/udc/pxa25x_udc.h
> @@ -248,7 +248,7 @@ dump_state(struct pxa25x_udc *dev)
> #define DBG(lvl, stuff...) do{if ((lvl) <= UDC_DEBUG) DMSG(stuff);}while(0)
>
> #define ERR(stuff...) pr_err("udc: " stuff)
> -#define WARNING(stuff...) pr_warning("udc: " stuff)
> +#define WARNING(stuff...) pr_warn("udc: " stuff)
> #define INFO(stuff...) pr_info("udc: " stuff)
>
>
> diff --git a/drivers/usb/host/isp1362-hcd.c b/drivers/usb/host/isp1362-hcd.c
> index 6cf82ee460a6..0f2b4b358e1a 100644
> --- a/drivers/usb/host/isp1362-hcd.c
> +++ b/drivers/usb/host/isp1362-hcd.c
> @@ -147,7 +147,7 @@ static inline struct isp1362_ep_queue *get_ptd_queue(struct isp1362_hcd *isp1362
> if (epq)
> DBG(1, "%s: PTD $%04x is on %s queue\n", __func__, offset, epq->name);
> else
> - pr_warning("%s: invalid PTD $%04x\n", __func__, offset);
> + pr_warn("%s: invalid PTD $%04x\n", __func__, offset);
>
> return epq;
> }
> @@ -157,8 +157,9 @@ static inline int get_ptd_offset(struct isp1362_ep_queue *epq, u8 index)
> int offset;
>
> if (index * epq->blk_size > epq->buf_size) {
> - pr_warning("%s: Bad %s index %d(%d)\n", __func__, epq->name, index,
> - epq->buf_size / epq->blk_size);
> + pr_warn("%s: Bad %s index %d(%d)\n",
> + __func__, epq->name, index,
> + epq->buf_size / epq->blk_size);
> return -EINVAL;
> }
> offset = epq->buf_start + index * epq->blk_size;
> @@ -902,8 +903,8 @@ static void start_iso_transfers(struct isp1362_hcd *isp1362_hcd)
>
> ptd_offset = next_ptd(epq, ep);
> if (ptd_offset < 0) {
> - pr_warning("%s: req %d No more %s PTD buffers available\n", __func__,
> - ep->num_req, epq->name);
> + pr_warn("%s: req %d No more %s PTD buffers available\n",
> + __func__, ep->num_req, epq->name);
> break;
> }
> }
> @@ -973,8 +974,8 @@ static void finish_transfers(struct isp1362_hcd *isp1362_hcd, unsigned long done
> break;
> }
> if (done_map)
> - pr_warning("%s: done_map not clear: %08lx:%08lx\n", __func__, done_map,
> - epq->skip_map);
> + pr_warn("%s: done_map not clear: %08lx:%08lx\n",
> + __func__, done_map, epq->skip_map);
> atomic_dec(&epq->finishing);
> }
>
> @@ -1433,7 +1434,7 @@ static int isp1362_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status)
> } else
> DBG(1, "%s: urb %p active; wait4irq\n", __func__, urb);
> } else {
> - pr_warning("%s: No EP in URB %p\n", __func__, urb);
> + pr_warn("%s: No EP in URB %p\n", __func__, urb);
> retval = -EINVAL;
> }
> done:
> @@ -1748,10 +1749,10 @@ static int isp1362_bus_suspend(struct usb_hcd *hcd)
> /* FALL THROUGH */
> case OHCI_USB_RESET:
> status = -EBUSY;
> - pr_warning("%s: needs reinit!\n", __func__);
> + pr_warn("%s: needs reinit!\n", __func__);
> goto done;
> case OHCI_USB_SUSPEND:
> - pr_warning("%s: already suspended?\n", __func__);
> + pr_warn("%s: already suspended?\n", __func__);
> goto done;
> }
> DBG(0, "%s: suspend root hub\n", __func__);
> @@ -1839,7 +1840,7 @@ static int isp1362_bus_resume(struct usb_hcd *hcd)
> isp1362_hcd->hc_control = isp1362_read_reg32(isp1362_hcd, HCCONTROL);
> pr_info("%s: HCCONTROL: %08x\n", __func__, isp1362_hcd->hc_control);
> if (hcd->state == HC_STATE_RESUMING) {
> - pr_warning("%s: duplicate resume\n", __func__);
> + pr_warn("%s: duplicate resume\n", __func__);
> status = 0;
> } else
> switch (isp1362_hcd->hc_control & OHCI_CTRL_HCFS) {
> @@ -2474,8 +2475,8 @@ static int isp1362_chip_test(struct isp1362_hcd *isp1362_hcd)
> __func__, offset);
> break;
> }
> - pr_warning("%s: memory check with offset %02x ok after second read\n",
> - __func__, offset);
> + pr_warn("%s: memory check with offset %02x ok after second read\n",
> + __func__, offset);
> }
> }
> kfree(ref);
> diff --git a/drivers/usb/isp1760/isp1760-if.c b/drivers/usb/isp1760/isp1760-if.c
> index 9535b2872183..79205b31e4a9 100644
> --- a/drivers/usb/isp1760/isp1760-if.c
> +++ b/drivers/usb/isp1760/isp1760-if.c
> @@ -197,7 +197,7 @@ static int isp1760_plat_probe(struct platform_device *pdev)
>
> irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> if (!irq_res) {
> - pr_warning("isp1760: IRQ resource not available\n");
> + pr_warn("isp1760: IRQ resource not available\n");
> return -ENODEV;
> }
> irqflags = irq_res->flags & IRQF_TRIGGER_MASK;
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v3 0/9] dmaengine: ti drivers: enable COMPILE_TESTing
From: Peter Ujfalusi @ 2016-09-28 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160928032605.GK2467@localhost>
Vinod,
On 09/28/16 06:26, Vinod Koul wrote:
> On Wed, Sep 21, 2016 at 03:41:26PM +0300, Peter Ujfalusi wrote:
>> Hi,
>>
>> Changes since v2:
>> - Instead of converting to use enum for the of_device_id data parameter the two
>> patch for edma and ti-dma-crossbar is using pointers to u32 variables to make
>> sure that the code compile (and in theory work) on all architectures.
>> - fixed issue in the ti-dma-crossbar driver I have made with the enum change to
>> not handle the DMA offset parameters correctly.
>>
>> Changes since v1:
>> - added the compiler warning message to ti-dma-crossbar enum type patch
>> - moved the Kconfig patches at the end of the seris
>>
>> The following series will enable unconditional COMPILE_TEST coverage for the
>> following drivers: omap-dma, edma and ti-dma-crossbar
>>
>> The series includes fixes noticed when compiling the drivers for x86_64 and
>> aarch64.
>
> I have applied the series after fixing code style nit-picks.
>
> Also applied the edma patch and reordered the series to have that come
> before compile test enable patch
>
> Please verify.
Looks good, thank you!
--
P?ter
^ permalink raw reply
* [PATCH] [media] atmel-isc: start dma in some scenario
From: Songjun Wu @ 2016-09-28 5:28 UTC (permalink / raw)
To: linux-arm-kernel
If a new vb buf is added to vb queue, the queue is
empty and steaming, dma should be started.
Signed-off-by: Songjun Wu <songjun.wu@microchip.com>
---
drivers/media/platform/atmel/atmel-isc.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c
index ccfe13b..8e25d3f 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -617,7 +617,13 @@ static void isc_buffer_queue(struct vb2_buffer *vb)
unsigned long flags;
spin_lock_irqsave(&isc->dma_queue_lock, flags);
- list_add_tail(&buf->list, &isc->dma_queue);
+ if (!isc->cur_frm && list_empty(&isc->dma_queue) &&
+ vb2_is_streaming(vb->vb2_queue)) {
+ isc->cur_frm = buf;
+ isc_start_dma(isc->regmap, isc->cur_frm,
+ isc->current_fmt->reg_dctrl_dview);
+ } else
+ list_add_tail(&buf->list, &isc->dma_queue);
spin_unlock_irqrestore(&isc->dma_queue_lock, flags);
}
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] bindings: add compatible "fsl, ls1043-ucc-hdlc" to bindings
From: Zhao Qiang @ 2016-09-28 3:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475034038-7217-1-git-send-email-qiang.zhao@nxp.com>
Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
---
Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
index 03c7416..325e3e2 100644
--- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
@@ -45,7 +45,7 @@ Example:
* HDLC
Currently defined compatibles:
-- fsl,ucc-hdlc
+- "fsl,ucc-hdlc", "fsl,ls1043-ucc-hdlc"
Properties for fsl,ucc-hdlc:
- rx-clock-name
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH 2/3] ls1043ardb: add ds26522 node to dts
From: Zhao Qiang @ 2016-09-28 3:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475034038-7217-1-git-send-email-qiang.zhao@nxp.com>
add ds26522 node to fsl-ls1043a-rdb.dts
Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
index 4fc60e7..206a8f5 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
@@ -122,6 +122,22 @@
reg = <0>;
spi-max-frequency = <1000000>; /* input clock */
};
+
+ slic at 2 {
+ compatible = "maxim,ds26522";
+ reg = <2>;
+ spi-max-frequency = <2000000>;
+ fsl,spi-cs-sck-delay = <100>;
+ fsl,spi-sck-cs-delay = <50>;
+ };
+
+ slic at 3 {
+ compatible = "maxim,ds26522";
+ reg = <3>;
+ spi-max-frequency = <2000000>;
+ fsl,spi-cs-sck-delay = <100>;
+ fsl,spi-sck-cs-delay = <50>;
+ };
};
&uqe {
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH 1/3] ls1043ardb: add qe node to ls1043ardb
From: Zhao Qiang @ 2016-09-28 3:40 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 ++++++
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 66 +++++++++++++++++++++++
2 files changed, 82 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
index 4084631..4fc60e7 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
@@ -124,6 +124,22 @@
};
};
+&uqe {
+ ucc_hdlc: ucc at 2000 {
+ compatible = "fsl,ls1043-ucc-hdlc", "fsl,ucc-hdlc";
+ rx-clock-name = "clk8";
+ tx-clock-name = "clk9";
+ fsl,rx-sync-clock = "rsync_pin";
+ fsl,tx-sync-clock = "tsync_pin";
+ fsl,tx-timeslot-mask = <0xfffffffe>;
+ fsl,rx-timeslot-mask = <0xfffffffe>;
+ fsl,tdm-framer-type = "e1";
+ fsl,tdm-id = <0>;
+ fsl,siram-entry-id = <0>;
+ fsl,tdm-interface;
+ };
+};
+
&duart0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index e669fbd..f6b6775 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -388,6 +388,72 @@
#interrupt-cells = <2>;
};
+ uqe: uqe at 2400000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "qe";
+ compatible = "fsl,qe", "simple-bus";
+ ranges = <0x0 0x0 0x2400000 0x40000>;
+ reg = <0x0 0x2400000 0x0 0x480>;
+ brg-frequency = <100000000>;
+ bus-frequency = <200000000>;
+
+ fsl,qe-num-riscs = <1>;
+ fsl,qe-num-snums = <28>;
+
+ qeic: qeic at 80 {
+ compatible = "fsl,qe-ic";
+ reg = <0x80 0x80>;
+ #address-cells = <0>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupts = <0 77 0x04 0 77 0x04>;
+ };
+
+ si1: si at 700 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,ls1043-qe-si",
+ "fsl,t1040-qe-si";
+ reg = <0x700 0x80>;
+ };
+
+ siram1: siram at 1000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,ls1043-qe-siram",
+ "fsl,t1040-qe-siram";
+ reg = <0x1000 0x800>;
+ };
+
+ ucc at 2000 {
+ cell-index = <1>;
+ reg = <0x2000 0x200>;
+ interrupts = <32>;
+ interrupt-parent = <&qeic>;
+ };
+
+ ucc at 2200 {
+ cell-index = <3>;
+ reg = <0x2200 0x200>;
+ interrupts = <34>;
+ interrupt-parent = <&qeic>;
+ };
+
+ muram at 10000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,qe-muram", "fsl,cpm-muram";
+ ranges = <0x0 0x10000 0x6000>;
+
+ data-only at 0 {
+ compatible = "fsl,qe-muram-data",
+ "fsl,cpm-muram-data";
+ reg = <0x0 0x6000>;
+ };
+ };
+ };
+
lpuart0: serial at 2950000 {
compatible = "fsl,ls1021a-lpuart";
reg = <0x0 0x2950000 0x0 0x1000>;
--
2.1.0.27.g96db324
^ permalink raw reply related
* ARM juno R2 board USB Issue (EHCI probe failed)
From: Sajjan, Vikas C @ 2016-09-28 3:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9b231601-2c6a-a5d7-471f-4fc0d8190d83@arm.com>
Hi All,
-----Original Message-----
From: Robin Murphy [mailto:robin.murphy at arm.com]
Sent: Tuesday, September 27, 2016 9:53 PM
To: Hanjun Guo <hanjun.guo@linaro.org>; Sudeep Holla <sudeep.holla@arm.com>; Sajjan, Vikas C <vikas.cha.sajjan@hpe.com>; Vikas Sajjan <sajjan.linux@gmail.com>; linux-usb at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org
Cc: mark.rutland at arm.com; lorenzo.pieralisi at arm.com
Subject: Re: ARM juno R2 board USB Issue (EHCI probe failed)
On 27/09/16 17:13, Hanjun Guo wrote:
> On 09/27/2016 05:07 PM, Sudeep Holla wrote:
>>
>>
>> On 27/09/16 09:55, Sajjan, Vikas C wrote:
>>> Hi Sudeep,
>>>
>>> -----Original Message-----
>>> From: Sudeep Holla [mailto:sudeep.holla at arm.com]
>>> Sent: Tuesday, September 27, 2016 2:21 PM
>>> To: Vikas Sajjan <sajjan.linux@gmail.com>;
>>> linux-usb at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
>>> linux-acpi at vger.kernel.org
>>> Cc: Sudeep Holla <sudeep.holla@arm.com>; mark.rutland at arm.com;
>>> lorenzo.pieralisi at arm.com; Sajjan, Vikas C
>>> <vikas.cha.sajjan@hpe.com>
>>> Subject: Re: ARM juno R2 board USB Issue (EHCI probe failed)
>>>
>>> Hi Vikas,
>>>
>>> On 27/09/16 09:14, Vikas Sajjan wrote:
>>>> Adding USB mailing list.
>>>>
>>>>
>>>> On Tue, Sep 27, 2016 at 12:33 PM, Sajjan, Vikas C
>>>> <vikas.cha.sajjan@hpe.com> wrote:
>>>>> Hi All,
>>>>>
>>>>> I working on ARM juno R2 board, with latest kernel 4.8.rc7 and I
>>>>> get below USB EHCI probe error while booting with acpi=force.
>>>>>
>>>
>>> Are you using the latest UEFI EDK2 ?
>>> No, I am still using the UEFI binary which came as part of the Juno
>>> board.
>>>
>>>
>>>>> [ 1.223662] VFIO - User Level meta-driver version: 0.3
>>>>> [ 1.229335] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI)
>>>>> Driver
>>>>> [ 1.235882] ehci-pci: EHCI PCI platform driver
>>>>> [ 1.240359] ehci-platform: EHCI generic platform driver
>>>>> [ 1.245619] ehci-platform ARMH0D20:00: Error: DMA mask
>>>>> configuration failed
>>>>> [ 1.272491] ehci-platform: probe of ARMH0D20:00 failed with
>>>>> error -5
>>>>> [ 1.278876] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
>>>>> [ 1.285071] ohci-pci: OHCI PCI platform driver
>>>>> [ 1.289548] ohci-platform: OHCI generic platform driver
>>>>> [ 1.294884] usbcore: registered new interface driver usb-storage
>>>>> [ 1.301231] mousedev: PS/2 mouse device common for all mice
>>>>> [ 1.307197] rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0
>>>>>
>>>>> But this error goes off, if I don't force ACPI booting, i.e., if I
>>>>> remove acpi=force from kernel command line , USB is detected and
>>>>> my RFS which is in the usb drive, gets mounted successfully.
>>>>>
>>>
>>> As I mentioned in private, I do get the same error if I drop _CCA in
>>> USB object of ACPI DSDT. Can you give it a spin with latest UEFI ?
>>>
>>> Sure, will try with latest UEFI.
>>>
>>
>> I bet that's 8-12 months old. It puts the banner during boot with the
>> build date. You can try to follow [1] or access it from [2]
>
> Agree.
>
> D03 is using the same IP (EHCI) and the USB works fine with _CCA in
> the device node.
_CCA is mandatory on arm64 (see CONFIG_ACPI_CCA_REQUIRED). Any devices without it are going to end up with the dummy DMA ops which intentionally fail if a driver tries to use them - i.e. the error seen above is by design.
Thank you for the clarification.
Thanks and Regards
Vikas Sajjan
Robin.
>
> Thanks
> Hanjun
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 0/9] dmaengine: ti drivers: enable COMPILE_TESTing
From: Vinod Koul @ 2016-09-28 3:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921124135.11849-1-peter.ujfalusi@ti.com>
On Wed, Sep 21, 2016 at 03:41:26PM +0300, Peter Ujfalusi wrote:
> Hi,
>
> Changes since v2:
> - Instead of converting to use enum for the of_device_id data parameter the two
> patch for edma and ti-dma-crossbar is using pointers to u32 variables to make
> sure that the code compile (and in theory work) on all architectures.
> - fixed issue in the ti-dma-crossbar driver I have made with the enum change to
> not handle the DMA offset parameters correctly.
>
> Changes since v1:
> - added the compiler warning message to ti-dma-crossbar enum type patch
> - moved the Kconfig patches at the end of the seris
>
> The following series will enable unconditional COMPILE_TEST coverage for the
> following drivers: omap-dma, edma and ti-dma-crossbar
>
> The series includes fixes noticed when compiling the drivers for x86_64 and
> aarch64.
I have applied the series after fixing code style nit-picks.
Also applied the edma patch and reordered the series to have that come
before compile test enable patch
Please verify.
Thanks
--
~Vinod
^ permalink raw reply
* [PATCH v3 6/9] dmaengine: ti-dma-crossbar: Fix of_device_id data parameter usage
From: Vinod Koul @ 2016-09-28 3:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921124135.11849-7-peter.ujfalusi@ti.com>
On Wed, Sep 21, 2016 at 03:41:32PM +0300, Peter Ujfalusi wrote:
> @@ -395,7 +403,7 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
>
> xbar->dmarouter.dev = &pdev->dev;
> xbar->dmarouter.route_free = ti_dra7_xbar_free;
> - xbar->dma_offset = (u32)match->data;
> + xbar->dma_offset = *(u32*)match->data;
^^^^
we need space between u32 and *
> mutex_init(&xbar->mutex);
> platform_set_drvdata(pdev, xbar);
> @@ -428,7 +436,7 @@ static int ti_dma_xbar_probe(struct platform_device *pdev)
> if (unlikely(!match))
> return -EINVAL;
>
> - switch ((u32)match->data) {
> + switch (*(u32*)match->data) {
here too please
--
~Vinod
^ permalink raw reply
* [PATCH] clocksource: arm_arch_timer: Don't assume clock runs in suspend
From: Brian Norris @ 2016-09-28 1:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E0E97B.5000106@arm.com>
Hi Marc,
Thanks again for the help. I was checking with Rockchip on the details.
On Tue, Sep 20, 2016 at 08:47:07AM +0100, Marc Zyngier wrote:
> The counter is allowed to be clocked at a different rate, as long as it
> is incremented by the frequency ratio on each tick of the new frequency.
> In your case, the counter should increment by 750 on each tick of the
> 32kHz clock. If the rk3399 implementation doesn't do this, then this is
> a bug, and we need a quirk to work around it.
I had hope that we could find a switch that would do the above for
rk3399, since other parts of the system (e.g., the PMU itself) support
switching from the 24MHz to 32KHz clock, but Rockchip confirmed that it
is indeed a HW quirk that the arch timer's counter does not support
clocking out ticks based on the 32KHz clock. So I'm planning to send a
v2 that adds a "arm,no-tick-in-suspend" property.
<Begin side note>
rk3288 (ARMv7 system widely used for our Chromebooks) has the same
issue, except the kernel we're using for production (based on v3.14)
doesn't have the following commit, which stopped utilizing the RTC:
commit 0fa88cb4b82b5cf7429bc1cef9db006ca035754e
Author: Xunlei Pang <pang.xunlei@linaro.org>
Date: Wed Apr 1 20:34:38 2015 -0700
time, drivers/rtc: Don't bother with rtc_resume() for the nonstop clocksource
And any mainline testing on rk3288 doesn't see the problem, because
mainline doesn't support its lowest-power sleep modes well enough (see
ROCKCHIP_ARM_OFF_LOGIC_DEEP in arch/arm/mach-rockchip/pm.c).
<End side note>
> Note that such a quirk will have some other impacts, such as the
> gettimeofday implementation in the VDSO (which relies on the counter
> making forward progress). There could be other issues in the timer
> subsystem as well... This doesn't look like a pleasant thing to fix.
How sure are you of these problems? I'm a bit new to the kernel
timekeeping subsystem, but doesn't this kind of code already have to
handle time adjustments like this when reprogramming the system time
(settimeofday())? And might we be covered for the suspend/resume case
when we allow the kernel to fall back to the RTC instead, which adjusts
the sleep delta with timekeeping_inject_sleeptime64()? And (weaker
evidence here) we haven't seen problems on rk3288 so far, at least
without the above referenced rtc commit 0fa88cb4b82. But admittedly
there are some differences between arch/{arm,arm64}/.
Regards,
Brian
^ permalink raw reply
* [PATCH v7 0/8] power: add power sequence library
From: Peter Chen @ 2016-09-27 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57EB0109.4070000@maciej.szmigiero.name>
On Wed, Sep 28, 2016 at 01:30:17AM +0200, Maciej S. Szmigiero wrote:
> On 20.09.2016 05:36, Peter Chen wrote:
> > Hi all,
> >
> > This is a follow-up for my last power sequence framework patch set [1].
> > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> > power sequence instances will be added at postcore_initcall, the match
> > criteria is compatible string first, if the compatible string is not
> > matched between dts and library, it will try to use generic power sequence.
> >
> > The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > if only one power sequence instance is needed, for more power sequences
> > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub driver).
> >
> > In future, if there are special power sequence requirements, the special
> > power sequence library can be created.
> >
> > This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> > two hot-plug devices to simulate this use case, the related binding
> > change is updated at patch [1/6], The udoo board changes were tested
> > using my last power sequence patch set.[3]
> >
> > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> > need to power on itself before it can be found by ULPI bus.
> >
> > [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> > [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> > [3] http://www.spinics.net/lists/linux-usb/msg142815.html
>
> Just tested this patch set on UDOO board again to make sure that it still
> works after all changes done since it was last tested there and can confirm
> that it does work correctly.
>
Thanks, Maciej.
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH v24 9/9] Documentation: dt: chosen properties for arm64 kdump
From: Mark Rutland @ 2016-09-27 23:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160819132641.GA12709@rob-hp-laptop>
Hi Rob,
Reviving an old thread -- "rock" and "hard place" come to mind.
On Fri, Aug 19, 2016 at 08:26:41AM -0500, Rob Herring wrote:
> On Tue, Aug 09, 2016 at 10:57:47AM +0900, AKASHI Takahiro wrote:
> > From: James Morse <james.morse@arm.com>
> > +linux,usable-memory-range
> > +-------------------------
> > +
> > +This property (currently used only on arm64) holds the memory range,
> > +the base address and the size, which can be used as system ram on
> > +the *current* kernel. Note that, if this property is present, any memory
> > +regions under "memory" nodes in DT blob or ones marked as "conventional
> > +memory" in EFI memory map should be ignored.
> > +e.g.
> > +
> > +/ {
> > + chosen {
> > + linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>;
> > + };
> > +};
>
> I've read the discussion on this. I think you should use the existing
> linux,usable-memory property in the memory nodes. If UEFI systems don't
> have memory nodes, then you can find an UEFI way to describe this. DT is
> not the dumping ground for what doesn't fit in UEFI. How do x86 systems
> work?
Having looked at the proposals, I'm personally much keener on the approach
above (modulo naming and wording) than trying to bolt memory nodes onto a UEFI
system, or using reserved-memory to describe the inverse of the allowable
range.
I completely agree that we want one solution for DT-only and DT+UEFI.
While those approaches reuse existing infrastructure, they end up creating more
work, and I believe that they create more scope for painful problems. As kdump
is already a constrained case, I think that it's reasonable to have a
linux-specific property as above.
I also think we need to figure out how we expect this to work for the
kexec_file_load case, as that has a criticial impact on the above (e.g. what's
preferable out of cmdline options vs dt properties).
Can we try to sync at connect to discuss this?
Thanks,
Mark.
^ permalink raw reply
* [PATCH v7 0/8] power: add power sequence library
From: Maciej S. Szmigiero @ 2016-09-27 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474342607-27512-1-git-send-email-peter.chen@nxp.com>
On 20.09.2016 05:36, Peter Chen wrote:
> Hi all,
>
> This is a follow-up for my last power sequence framework patch set [1].
> According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> power sequence instances will be added at postcore_initcall, the match
> criteria is compatible string first, if the compatible string is not
> matched between dts and library, it will try to use generic power sequence.
>
> The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> if only one power sequence instance is needed, for more power sequences
> are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub driver).
>
> In future, if there are special power sequence requirements, the special
> power sequence library can be created.
>
> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> two hot-plug devices to simulate this use case, the related binding
> change is updated at patch [1/6], The udoo board changes were tested
> using my last power sequence patch set.[3]
>
> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> need to power on itself before it can be found by ULPI bus.
>
> [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> [3] http://www.spinics.net/lists/linux-usb/msg142815.html
Just tested this patch set on UDOO board again to make sure that it still
works after all changes done since it was last tested there and can confirm
that it does work correctly.
Maciej
^ permalink raw reply
* [PATCH v2 4/4] PM / AVS: rockchip-cpu-avs: add driver handling Rockchip cpu avs
From: Stephen Boyd @ 2016-09-27 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20776501.pZ2NDOzLK3@phil>
On 09/26, Heiko Stuebner wrote:
> Am Montag, 26. September 2016, 09:25:11 CEST schrieb Viresh Kumar:
> > On 12-09-16, 14:55, Stephen Boyd wrote:
> > > On 08/29, Viresh Kumar wrote:
> > > > On 18-08-16, 16:52, Finlye Xiao wrote:
> > > > > +static int rockchip_adjust_opp_table(struct device *cpu_dev,
> > > > > + struct cpufreq_frequency_table *table,
> > > > > + int volt)
> > > > > +{
> > > > > + struct opp_table *opp_table;
> > > > > + struct cpufreq_frequency_table *pos;
> > > > > + struct dev_pm_opp *opp;
> > > > > +
> > > > > + if (!volt)
> > > > > + return 0;
> > > > > +
> > > > > + rcu_read_lock();
> > > > > +
> > > > > + opp_table = _find_opp_table(cpu_dev);
> > > > > + if (IS_ERR(opp_table)) {
> > > > > + rcu_read_unlock();
> > > > > + return PTR_ERR(opp_table);
> > > > > + }
> > > > > +
> > > > > + cpufreq_for_each_valid_entry(pos, table) {
> > > > > + opp = dev_pm_opp_find_freq_exact(cpu_dev, pos->frequency * 1000,
> > > > > + true);
> > > > > + if (IS_ERR(opp))
> > > > > + continue;
> > > > > +
> > > > > + opp->u_volt += volt;
> > > > > + opp->u_volt_min += volt;
> > > > > + opp->u_volt_max += volt;
> > > > > + }
> > > > > +
> > > > > + rcu_read_unlock();
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > >
> > > > I wouldn't prefer altering the opp tables from individual drivers at
> > > > all. At the least, it should be done via some helpers exposed by the
> > > > core.
> > > >
> > > > But before that I would like to hear from Stephen a bit as I recall he
> > > > was also working on something similar.
> > >
> > > I had a patch to modify the voltage at runtime for the "current"
> > > OPP. Now that we have regulator and clk control inside OPP that
> > > became a little easier to do without having to do some notifier
> > > from the OPP layer to the consumers. I haven't had time to revive
> > > those patches though. Should we do that?
> >
> > Perhaps yes, we should have a common place for doing all that.
> >
> > > Does this need to modify
> > > anything besides the OPP the device is currently running at?
> >
> > Finlye, can you please answer this ?
>
> If I understand it correctly, depending on the leakage value stored in an
> efuse, all opp voltages are reduced by a certain value. Right now the driver
> does it in one go for the full opp table, but of course could also do it for
> each new opp individually before it gets set.
Ok. Well either way that sounds fine. We could expose an API to
change each voltage and an API to change the current voltage and
update the table.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ 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