From: Derek Browne derek.bro...@intel.com
This patch is to enable SDIO host controller for Intel Quark X1000.
Signed-off-by: Derek Browne derek.bro...@intel.com
Signed-off-by: Alvin (Weike) Chen alvin.c...@intel.com
---
changelog v2:
*Delete '#define PCI_DEVICE_ID_INTEL_QUARK_ILB 0x095E' from
From: Alvin (Weike) Chen alvin.c...@intel.com
Hi,
Intel Quark X1000 consists of one SDIO host controller which can be PCI
enumerated.
SDHCI-PCI layer doesn't support it. Thus, we add support for Intel Quark X1000
SDIO as well.
Derek Browne (1):
Quark SDIO host controller
From: Bryan O'Donoghue bryan.odonog...@intel.com
This patch is to enable USB host controller for Intel Quark X1000. Add pci
quirks
to adjust the packet buffer in/out threshold value, and ensure EHCI packet
buffer
i/o threshold value is reconfigured to half.
Signed-off-by: Bryan O'Donoghue
From: Alvin (Weike) Chen alvin.c...@intel.com
Hi,
Intel Quark X1000 consists of one USB host controller which can be PCI
enumerated.
But the exsiting EHCI-PCI framework doesn't support it. Thus, we enable it to
support
Intel Quark X1000 USB host controller by adding pci quirks to configure
See my comments below:
+ /* Reset the threshold limit */
+ if(unlikely(usb_is_intel_qrk(pdev)))
Please run your patch thru scripts/checkpatch.pl -- space needed after
*if*.
OK, I will improve it in the PATCH v2.
+ usb_set_qrk_bulk_thresh(pdev);
+
return 0;
See my comments below:
-Original Message-
From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
Sent: Tuesday, June 24, 2014 9:25 PM
To: Chen, Alvin
Cc: Alan Stern; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Ong,
Boon Leong
Subject: Re: [PATCH] USB: ehci-pci
-Original Message-
From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
Sent: Tuesday, June 24, 2014 9:25 PM
To: Chen, Alvin
Cc: Alan Stern; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Ong,
Boon Leong
Subject: Re: [PATCH] USB: ehci-pci: USB host controller
This patch is to enable USB host controller for Intel Quark X1000. Add
pci quirks to adjust the packet buffer in/out threshold value, and
ensure EHCI packet buffer i/o threshold value is reconfigured to half.
Please add more detailed description. For example, why is it necessary to
OK, I will change ' usb_is_intel_qrk ' to ' usb_is_intel_quark'.
Or even usb_is_intel_quark_x1000() ?
OK, I will change the function name as your suggestion to make it more specific.
David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
This patch is to enable USB host controller for Intel Quark X1000. Add
pci quirks to adjust the packet buffer in/out threshold value, and
ensure EHCI packet buffer i/o threshold value is reconfigured to half
What is the packet buffer in/out threshold value and why does it need to be
From: Derek Browne derek.bro...@intel.com
On Intel Quark, there is a SDIO host controller. This patch is added to
enable the SDIO host controller.
Signed-off-by: Derek Browne derek.bro...@intel.com
Signed-off-by: Alvin (Weike) Chen alvin.c...@intel.com
---
drivers/mmc/host/sdhci-pci.c | 12
From: Alvin (Weike) Chen alvin.c...@intel.com
Hi,
Intel Quark consists of one SDIO host controller which can be PCI enumerated.
SDHCI-PCI layer doesn't support it. Thus, we add support for Intel Quark SDIO
as well.
Derek Browne (1):
Quark SDIO host controller
drivers/mmc/host/sdhci-pci.c |
From: Alvin (Weike) Chen alvin.c...@intel.com
Hi,
Intel Quark X1000 consists of one USB host controller which can be PCI
enumerated.
And the exsiting EHCI-PCI framework supports it with the default packet buffer
in/out
threshold. We reconfigure the in/out threshold as maximal as possible.
From: Bryan O'Donoghue bryan.odonog...@intel.com
The EHCI packet buffer in/out threshold is programmable for Intel Quark X1000
USB host
controller, and the default value is 0x20 dwords. The in/out threshold can be
programmed
to 0x80 dwords, but only when isochronous/interrupt transactions are
The EHCI packet buffer in/out threshold is programmable for Intel
Quark X1000 USB host controller, and the default value is 0x20
dwords. The in/out threshold can be programmed to 0x80 dwords, but
only when isochronous/interrupt transactions are not initiated by
the USB host
-Original Message-
From: David Laight [mailto:david.lai...@aculab.com]
Sent: Friday, June 27, 2014 4:08 PM
...
/* The maximal threshold value is 0x80, which means 512 bytes */
#define EHCI_THRESHOLD_512BYTES 0x80
#define EHCI_THRESHOLD_508BYTES 0x79
The EHCI packet buffer in/out threshold is programmable for Intel
Quark X1000 USB host controller, and the default value is 0x20 dwords.
The in/out threshold can be programmed to 0x80 dwords, but only when
isochronous/interrupt transactions are not initiated by the USB host
controller.
From: Bryan O'Donoghue bryan.odonog...@intel.com
The EHCI packet buffer in/out threshold is programmable for Intel Quark X1000
USB host controller, and the default value is 0x20 dwords. The in/out threshold
can be programmed to 0x80 dwords (512 Bytes) to maximize the perfomrance,
but only when
From: Alvin (Weike) Chen alvin.c...@intel.com
Hi,
Intel Quark X1000 consists of one USB host controller which can be PCI
enumerated. And the exsiting EHCI-PCI framework supports it with the
default packet buffer in/out threshold. We reconfigure the in/out threshold
as maximal as possible to
/*
-*/
+#define PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC0x0939
+static inline bool is_intel_quark_x1000(struct pci_dev *pdev) {
+ return pdev-vendor == PCI_VENDOR_ID_INTEL
+ pdev-device ==
/*
-*/
+#define PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC0x0939
+static inline bool is_intel_quark_x1000(struct pci_dev *pdev) {
+ return pdev-vendor == PCI_VENDOR_ID_INTEL
+ pdev-device ==
From: Bryan O'Donoghue bryan.odonog...@intel.com
The EHCI packet buffer in/out threshold is programmable for Intel Quark X1000
USB host controller, and the default value is 0x20 dwords. The in/out threshold
can be programmed to 0x80 dwords (512 Bytes) to maximize the perfomrance,
but only when
From: Alvin (Weike) Chen alvin.c...@intel.com
Hi,
Intel Quark X1000 consists of one USB host controller which can be PCI
enumerated. And the exsiting EHCI-PCI framework supports it with the
default packet buffer in/out threshold. We reconfigure the in/out threshold
as maximal as possible to
From: Bryan O'Donoghue bryan.odonog...@intel.com
The EHCI packet buffer in/out threshold is programmable for Intel Quark X1000
USB host controller, and the default value is 0x20 dwords. The in/out threshold
can be programmed to 0x80 dwords (512 Bytes) to maximize the perfomrance,
but only when
From: Bryan O'Donoghue bryan.odonog...@intel.com
This patch is to enable the USB gadget device for Intel Quark X1000
Signed-off-by: Bryan O'Donoghue bryan.odonog...@intel.com
Signed-off-by: Bing Niu bing@intel.com
Signed-off-by: Alvin (Weike) Chen alvin.c...@intel.com
---
From: Alvin (Weike) Chen alvin.c...@intel.com
Hi,
Intel Quark X1000 consists of one USB gadget device which can be PCI
enumerated.
pch_udc layer doesn't support it. Thus, we add support for Intel Quark X1000 USB
gadget device as well.
Bryan O'Donoghue (1):
USB: pch_udc: USB gadget device
Hi,
On Mon, Aug 04, 2014 at 10:22:54AM -0700, Chen, Alvin wrote:
From: Bryan O'Donoghue bryan.odonog...@intel.com
This patch is to enable the USB gadget device for Intel Quark X1000
Signed-off-by: Bryan O'Donoghue bryan.odonog...@intel.com
Signed-off-by: Bing Niu bing
Message-
From: Ong, Boon Leong
Sent: Wednesday, August 6, 2014 3:32 PM
To: Ulf Hansson
Cc: Chris Ball; linux-mmc; linux-kernel@vger.kernel.org; Chen, Alvin
Subject: RE: [PATCH v2] mmc: sdhci-pci: SDIO host controller support for Intel
Quark X1000
-Original Message-
From: Ulf
Hi Felipe,
Any update for this patch? Just want to follow-up.
-Original Message-
From: Chen, Alvin
Sent: Tuesday, August 05, 2014 1:23 AM
To: Felipe Balbi
Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Ong, Boon
Leong
Subject: [PATCH] USB: pch_udc: USB gadget
-Original Message-
From: Chen, Alvin
Sent: Wednesday, October 8, 2014 11:50 PM
To: Eric Miao; Russell King; Haojian Zhuang; Mark Brown
Cc: linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org;
linux-kernel@vger.kernel.org; Westerberg, Mika; Kweh, Hock Leong; Ong, Boon
Leong; Tan
+#if defined CONFIG_PM_SLEEP
I wonder whether it's worth #ifdef:in out such things, it clutters the place.
OK. I will use '#ifdef'.
+/* Store GPIO context across system-wide suspend/resume transitions
+*/ static struct gpio_saved_regs {
Call the struct:
struct dwapb_context
Insert this into the dynamically allocated per-port or chip struct instead.
How about the following?
static struct dwapb_context {
u32 data[DWAPB_MAX_PORTS];
u32 dir[DWAPB_MAX_PORTS];
u32 ext[DWAPB_MAX_PORTS];
u32 int_en;
u32 int_mask;
On Fri, 2014-09-05 at 07:53 -0700, Weike Chen wrote:
This patch enables suspend and resume mode for the power management,
and it is based on Josef Ahmad's previous work.
Reviewed-by: Hock Leong Kweh hock.leong.k...@intel.com
Reviewed-by: Shevchenko, Andriy andriy.shevche...@intel.com
Subject: Re: [PATCH 2/3 v2] GPIO: gpio-dwapb: Support Debounce
On Fri, 2014-09-05 at 07:53 -0700, Weike Chen wrote:
This patch enables 'debounce' for the designware GPIO, and it is based
on Josef Ahmad's previous work.
Can we split dwapb_read/write introducing and changing from this
-static void dwapb_irq_handler(u32 irq, struct irq_desc *desc)
+static u32 _dwapb_irq_handler(struct dwapb_gpio *gpio)
What about dwapb_do_irq() ?
OK, I will improve it.
+static irqreturn_t dwapb_irq_handler_mfd(int irq, void *dev_id) {
+ u32 worked;
+ struct dwapb_gpio *gpio =
- irq_set_chained_handler(irq, dwapb_irq_handler);
- irq_set_handler_data(irq, gpio);
+ if (!pp-irq_shared) {
+ irq_set_chained_handler(pp-irq, dwapb_irq_handler);
+ irq_set_handler_data(pp-irq, gpio);
+ } else {
+ /*
+ * Request a shared
Since the 'debounce' feature also needs read/write, if we splite this
patch, then for 'debounce', One patch use readl/writel, and another
patch change to dwapb_read/write. It seems duplicate since the previous
patch use readl/writel and the fllowing one change it immediately.
Since this
+#ifdef CONFIG_OF_GPIO
+
+static struct dwapb_platform_data *
+dwapb_gpio_get_pdata_of(struct device *dev) {
+ struct device_node *node, *port_np;
+ struct dwapb_platform_data *pdata;
+ struct dwapb_port_property *pp;
+ int nports;
+ int i;
+
+ node =
On Friday 05 September 2014 12:02:01 Shevchenko, Andriy wrote:
irq = irq_of_parse_and_map(node, 0); If (!irq) {
pp-irq = -1;
return;
} else {
pp-irq = irq;
}
Then the code looks strange.
How do you think?
If I understood correctly you messed up with hwirq vs. virq.
Hi Weike,
I tried out these patches on the current master branch (v3.17-rc2-9-g68e3702)
with a socfpga cyclone5 board.
If I apply all 3 patches, the kernel doesn't boot.
If I rebuild with only the first patch, I get only one gpio block showing up
(should
have 3 for this board) and
I don't understand the reason for adding dwapb_read and dwapb_write here.
The rest of the driver is using readl and writel. I'd rather not see
two different methods being used in the same driver for register access.
Maybe I'm missing something, but if we need to add dwapb_read/write,
+/* Store GPIO context across system-wide suspend/resume transitions
+*/ static struct gpio_saved_regs {
+ unsigned long data;
+ unsigned long dir;
+ unsigned long int_en;
+ unsigned long int_mask;
+ unsigned long int_type;
+ unsigned long int_pol;
+ unsigned long
On Tue, 9 Sep 2014, Weike Chen wrote:
struct dwapb_gpio;
+struct dwapb_context;
struct dwapb_gpio_port {
struct bgpio_chip bgc;
boolis_registered;
struct dwapb_gpio *gpio;
+ struct dwapb_context*ctx;
Alvin,
Will this
static int dwapb_gpio_probe(struct platform_device *pdev) {
+ int i;
struct resource *res;
struct dwapb_gpio *gpio;
- struct device_node *np;
int err;
- unsigned int offs = 0;
+ struct device *dev = pdev-dev;
+
I'm okay with the current version, though I have few minor comments below.
Introduce helper functions to access the 'SSCR0' and 'SSCR1'.
Like you said in the summary there are many accessors to many registers, not
only cr1/cr0. Perhaps, you may extend your commit message.
OK.
In
The SPI memory mapped I/O registers supported by Quark are different
from the current implementation, and Quark only supports the registers
of 'SSCR0', 'SSCR1', 'SSSR', 'SSDR', and 'DDS_RATE'. This patch is to
enable the SPI for Intel Quark X1000.
This piece of work is derived from Dan
On 29/09/14 15:22, Weike Chen wrote:
+ .num_chipselect = 4,
How is this right ?
There's only one physical chip-select line per SPI master...
It's a 1:1 mapping.
Now, we have another board which can support 4 slave spi per master, but not
only Galileo. Since that board
Message-
From: Chen, Alvin
Sent: Wednesday, October 8, 2014 11:50 PM
To: Eric Miao; Russell King; Haojian Zhuang; Mark Brown
Cc: linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org;
linux-kernel@vger.kernel.org; Westerberg, Mika; Kweh, Hock Leong; Ong, Boon
Leong; Tan, Raymond; Chen
Hi Alvin, Weike.
I'm not clear if these patches apply to the current tip-of-tree.
I thought the action required here, was for a resend of patches to ensure they
applied to tip-of-tree ?
As I said before, it is based on the slave-dma tree (git.infraded.org)
for-linus branch, which
On Thu, 2014-10-30 at 01:02 +, Chen, Alvin wrote:
Hi Alvin, Weike.
I'm not clear if these patches apply to the current tip-of-tree.
I thought the action required here, was for a resend of patches to
ensure they applied to tip-of-tree ?
As I said before
All of those patches are in v3.18-rc1, so you may rebase on top of
3.18-rcX safely I guess.
Andy, I remember you ask me to rebase on the slave-dma tree (git.infraded.org)
for-linus branch, and the slave-dma for-linus branch will be reapplied on top
of
v3.19-rc1.
Just to confirm,
+/* Store GPIO context across system-wide suspend/resume transitions
+*/ static struct dwapb_context {
+ u32 data[DWAPB_MAX_PORTS];
+ u32 dir[DWAPB_MAX_PORTS];
+ u32 ext[DWAPB_MAX_PORTS];
+ u32 int_en;
+ u32 int_mask;
+ u32 int_type;
+
@@ -136,7 +136,6 @@ config GPIO_DWAPB
tristate Synopsys DesignWare APB GPIO driver
select GPIO_GENERIC
select GENERIC_IRQ_CHIP
-depends on OF_GPIO
You cover this specific dependencies with inline ifdefs, but you lose the
CONFIG_OF depends by dropping it, and there are
You cover this specific dependencies with inline ifdefs, but you
lose the CONFIG_OF depends by dropping it, and there are no such
checks in the probe routine. Assumptions of OF are not limited to probe in
this driver.
While I would like to see this assumption properly abstracted,
Hi Alvin,
I did a quick test and this looks like it works for me (with device tree).
I had a couple of small fixes below.
It is very appreciated to help testing.
Alan
- port-bgc.gc.ngpio = ngpio;
- port-bgc.gc.of_node = port_np;
+#ifdef CONFIG_OF_GPIO
+
Hi Alvin,
I did a quick test and this looks like it works for me (with device tree).
I had a couple of small fixes below.
It is very appreciated to help testing.
Alan
- port-bgc.gc.ngpio = ngpio;
- port-bgc.gc.of_node = port_np;
+#ifdef CONFIG_OF_GPIO
+
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -136,7 +136,6 @@ config GPIO_DWAPB
tristate Synopsys DesignWare APB GPIO driver
select GPIO_GENERIC
select GENERIC_IRQ_CHIP
- depends on OF_GPIO
you need either OF_GPIO or PCI
Since we enable this module not
Since we enable this module not only support OF devices, but also support
MFD devices, so we remove OF_GPIO dependenc
For 'PCI', the original code is also not depended on PCI, and this patch
also
not, do you think it is necessary?
if not PCI then you should add something likwe
static int dwapb_gpio_probe(struct platform_device *pdev) {
+ int i;
struct resource *res;
struct dwapb_gpio *gpio;
- struct device_node *np;
int err;
- unsigned int offs = 0;
+ struct device *dev = pdev-dev;
+
Reviewed-by: Hock Leong Kweh hock.leong.k...@intel.com
You still keep that guy as reviewer in a whole series, however I didn't see a
word from him here. How is it possible?
In our internal review, he gave me a lot of suggestions.
+ for (i = 0; i gpio-nr_ports; i++) {
+
+ struct bgpio_chip *bgc = to_bgpio_chip(gc);
+ struct dwapb_gpio_port *port =
+ container_of(bgc, struct dwapb_gpio_port, bgc);
Does it make sense to introduce an inline helper like
static inline struct dwapb_gpio_port *to_dwapb_gpio_port(struct bgpio_chip
*gc)
+ if (pp-idx == 0
+ of_property_read_bool(port_np, interrupt-controller)) {
+ pp-irq = irq_of_parse_and_map(port_np, 0);
+ if (!pp-irq) {
+ dev_warn(dev, no irq for bank %s\n,
+
+static u32 pxa2xx_spi_get_ssrc1_change_mask(const struct driver_data
+*drv_data) {
+ if (!is_quark_x1000_ssp(drv_data))
+ return SSCR1_CHANGE_MASK;
+
+ return QUARK_X1000_SSCR1_CHANGE_MASK; }
These functions would be much better written as switch statements - think
+/* see Quark SPI data sheet for implementation rationale */ static
+u32 quark_x1000_set_clk_regvals(u32 rate, u32 *dds, u32 *clk_div) {
Please document this in the driver - I don't know if this datasheet is
public but even if it is it may not stay that way.
Datasheet is
On 03/11/14 07:39, Raymond Tan wrote:
+ pdata-properties-irq = pdev-irq;
+ pdata-properties-irq_shared = true;
OK I see it.
Thanks.
My question is. How extensively have edge triggered interrupts been tested on
the GPIO block ?
The BSP reference code is quite explicit
-Original Message-
From: Chen, Alvin
Sent: Tuesday, November 4, 2014 8:46 AM
To: 'Bryan O'Donoghue'; Tan, Raymond; Lee Jones; Samuel Ortiz
Cc: linux-kernel@vger.kernel.org; Shevchenko, Andriy
Subject: RE: [PATCH 1/1] mfd: intel_quark_i2c_gpio: Add Intel Quark X1000
I2C-GPIO MFD
Hi Alvin,
Doesn't apply.
Applying: SPI: spi-pxa2xx: SPI support for Intel Quark X1000
error: patch failed: drivers/spi/spi-pxa2xx-pci.c:19
error: drivers/spi/spi-pxa2xx-pci.c: patch does not apply Patch failed at
0002 SPI:
spi-pxa2xx: SPI support for Intel Quark X1000
It is based on
From: Derek Browne
On Intel Quark, there is a SDIO host controller. This patch is added to
enable the SDIO host controller.
Signed-off-by: Derek Browne
Signed-off-by: Alvin (Weike) Chen
---
drivers/mmc/host/sdhci-pci.c | 12
include/linux/pci_ids.h |2 ++
2 files
From: "Alvin (Weike) Chen"
Hi,
Intel Quark consists of one SDIO host controller which can be PCI enumerated.
SDHCI-PCI layer doesn't support it. Thus, we add support for Intel Quark SDIO
as well.
Derek Browne (1):
Quark SDIO host controller
drivers/mmc/host/sdhci-pci.c | 12
From: Derek Browne
This patch is to enable SDIO host controller for Intel Quark X1000.
Signed-off-by: Derek Browne
Signed-off-by: Alvin (Weike) Chen
---
changelog v2:
*Delete '#define PCI_DEVICE_ID_INTEL_QUARK_ILB 0x095E' from
'include/linux/pci_ids.h'.
*Move '#define
From: "Alvin (Weike) Chen"
Hi,
Intel Quark X1000 consists of one SDIO host controller which can be PCI
enumerated.
SDHCI-PCI layer doesn't support it. Thus, we add support for Intel Quark X1000
SDIO as well.
Derek Browne (1):
Quark SDIO host controller
drivers/mmc/host/sdhci-pci.c | 12
From: Bryan O'Donoghue
This patch is to enable USB host controller for Intel Quark X1000. Add pci
quirks
to adjust the packet buffer in/out threshold value, and ensure EHCI packet
buffer
i/o threshold value is reconfigured to half.
Signed-off-by: Bryan O'Donoghue
Signed-off-by: Alvin (Weike)
From: "Alvin (Weike) Chen"
Hi,
Intel Quark X1000 consists of one USB host controller which can be PCI
enumerated.
But the exsiting EHCI-PCI framework doesn't support it. Thus, we enable it to
support
Intel Quark X1000 USB host controller by adding pci quirks to configure buffer
i/o threshold
See my comments below:
> > + /* Reset the threshold limit */
> > + if(unlikely(usb_is_intel_qrk(pdev)))
>
> Please run your patch thru scripts/checkpatch.pl -- space needed after
> *if*.
OK, I will improve it in the PATCH v2.
>
> > + usb_set_qrk_bulk_thresh(pdev);
> > +
> >
See my comments below:
> -Original Message-
> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> Sent: Tuesday, June 24, 2014 9:25 PM
> To: Chen, Alvin
> Cc: Alan Stern; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Ong,
> Boon Leong
> Subject:
> -Original Message-
> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> Sent: Tuesday, June 24, 2014 9:25 PM
> To: Chen, Alvin
> Cc: Alan Stern; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Ong,
> Boon Leong
> Subject: Re: [PATCH] US
> > This patch is to enable USB host controller for Intel Quark X1000. Add
> > pci quirks to adjust the packet buffer in/out threshold value, and
> > ensure EHCI packet buffer i/o threshold value is reconfigured to half.
>
> Please add more detailed description. For example, why is it necessary
> >
> > OK, I will change ' usb_is_intel_qrk ' to ' usb_is_intel_quark'.
>
> Or even usb_is_intel_quark_x1000() ?
>
OK, I will change the function name as your suggestion to make it more specific.
> David
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > This patch is to enable USB host controller for Intel Quark X1000. Add
>> pci quirks to adjust the packet buffer in/out threshold value, and
> >ensure EHCI packet buffer i/o threshold value is reconfigured to half
>
>
> What is the packet buffer in/out threshold value and why does it need to
From: Bryan O'Donoghue
The EHCI packet buffer in/out threshold is programmable for Intel Quark X1000
USB host controller, and the default value is 0x20 dwords. The in/out threshold
can be programmed to 0x80 dwords (512 Bytes) to maximize the perfomrance,
but only when isochronous/interrupt
From: "Alvin (Weike) Chen"
Hi,
Intel Quark X1000 consists of one USB host controller which can be PCI
enumerated.
And the exsiting EHCI-PCI framework supports it with the default packet buffer
in/out
threshold. We reconfigure the in/out threshold as maximal as possible.
Bryan O'Donoghue (1):
From: Bryan O'Donoghue
The EHCI packet buffer in/out threshold is programmable for Intel Quark X1000
USB host
controller, and the default value is 0x20 dwords. The in/out threshold can be
programmed
to 0x80 dwords, but only when isochronous/interrupt transactions are not
initiated by
the USB
> > > The EHCI packet buffer in/out threshold is programmable for Intel
> > > Quark X1000 USB host controller, and the default value is 0x20
> > > dwords. The in/out threshold can be programmed to 0x80 dwords, but
> > > only when isochronous/interrupt transactions are not initiated by
> > > the
> -Original Message-
> From: David Laight [mailto:david.lai...@aculab.com]
> Sent: Friday, June 27, 2014 4:08 PM
> ...
> > /* The maximal threshold value is 0x80, which means 512 bytes */
> > #define EHCI_THRESHOLD_512BYTES 0x80
> > #define EHCI_THRESHOLD_508BYTES
> > The EHCI packet buffer in/out threshold is programmable for Intel
> > Quark X1000 USB host controller, and the default value is 0x20 dwords.
> > The in/out threshold can be programmed to 0x80 dwords, but only when
> > isochronous/interrupt transactions are not initiated by the USB host
> >
From: Bryan O'Donoghue
The EHCI packet buffer in/out threshold is programmable for Intel Quark X1000
USB host controller, and the default value is 0x20 dwords. The in/out threshold
can be programmed to 0x80 dwords (512 Bytes) to maximize the perfomrance,
but only when isochronous/interrupt
From: "Alvin (Weike) Chen"
Hi,
Intel Quark X1000 consists of one USB host controller which can be PCI
enumerated. And the exsiting EHCI-PCI framework supports it with the
default packet buffer in/out threshold. We reconfigure the in/out threshold
as maximal as possible to maximize the
> > /*
> > -*/
> > +#define PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC0x0939
> > +static inline bool is_intel_quark_x1000(struct pci_dev *pdev) {
> > + return pdev->vendor == PCI_VENDOR_ID_INTEL &&
> > +
> >
> > /*
> > -*/
> > +#define PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC0x0939
> > +static inline bool is_intel_quark_x1000(struct pci_dev *pdev) {
> > + return pdev->vendor == PCI_VENDOR_ID_INTEL &&
> > +
From: Bryan O'Donoghue
The EHCI packet buffer in/out threshold is programmable for Intel Quark X1000
USB host controller, and the default value is 0x20 dwords. The in/out threshold
can be programmed to 0x80 dwords (512 Bytes) to maximize the perfomrance,
but only when isochronous/interrupt
From: "Alvin (Weike) Chen"
Hi,
Intel Quark X1000 consists of one USB host controller which can be PCI
enumerated. And the exsiting EHCI-PCI framework supports it with the
default packet buffer in/out threshold. We reconfigure the in/out threshold
as maximal as possible to maximize the
From: Bryan O'Donoghue
This patch is to enable the USB gadget device for Intel Quark X1000
Signed-off-by: Bryan O'Donoghue
Signed-off-by: Bing Niu
Signed-off-by: Alvin (Weike) Chen
---
drivers/usb/gadget/udc/Kconfig |3 ++-
drivers/usb/gadget/udc/pch_udc.c | 22
From: "Alvin (Weike) Chen"
Hi,
Intel Quark X1000 consists of one USB gadget device which can be PCI
enumerated.
pch_udc layer doesn't support it. Thus, we add support for Intel Quark X1000 USB
gadget device as well.
Bryan O'Donoghue (1):
USB: pch_udc: USB gadget device support for Intel
> Hi,
>
> On Mon, Aug 04, 2014 at 10:22:54AM -0700, Chen, Alvin wrote:
> > From: Bryan O'Donoghue
> >
> > This patch is to enable the USB gadget device for Intel Quark X1000
> >
> > Signed-off-by: Bryan O'Donoghue
> > Signed-off-by: Bing Niu
&g
nal Message-
> From: Chen, Alvin
> Sent: Wednesday, October 8, 2014 11:50 PM
> To: Eric Miao; Russell King; Haojian Zhuang; Mark Brown
> Cc: linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Westerberg, Mika; Kweh, Hock Leong; Ong, Boon
>
> >
>
> Hi Alvin, Weike.
>
> I'm not clear if these patches apply to the current tip-of-tree.
>
> I thought the action required here, was for a resend of patches to ensure they
> applied to tip-of-tree ?
>
As I said before, it is based on the slave-dma tree (git.infraded.org)
for-linus
>
> > +static u32 pxa2xx_spi_get_ssrc1_change_mask(const struct driver_data
> > +*drv_data) {
> > + if (!is_quark_x1000_ssp(drv_data))
> > + return SSCR1_CHANGE_MASK;
> > +
> > + return QUARK_X1000_SSCR1_CHANGE_MASK; }
>
> These functions would be much better written as switch
>
> >
> > > +/* see Quark SPI data sheet for implementation rationale */ static
> > > +u32 quark_x1000_set_clk_regvals(u32 rate, u32 *dds, u32 *clk_div) {
> >
> > Please document this in the driver - I don't know if this datasheet is
> > public but even if it is it may not stay that way.
>
>
>
> > Reviewed-by: Hock Leong Kweh
>
> You still keep that guy as reviewer in a whole series, however I didn't see a
> word from him here. How is it possible?
In our internal review, he gave me a lot of suggestions.
> > + for (i = 0; i < gpio->nr_ports; i++) {
> > + unsigned int
> > + struct bgpio_chip *bgc = to_bgpio_chip(gc);
> > + struct dwapb_gpio_port *port =
> > + container_of(bgc, struct dwapb_gpio_port, bgc);
>
> Does it make sense to introduce an inline helper like
>
> static inline struct dwapb_gpio_port *to_dwapb_gpio_port(struct
1 - 100 of 134 matches
Mail list logo
