> -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:
>
> 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
> >
> > 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
>
> 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
> >
>
> 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,
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
>
> -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,
> 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
>
> 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 th
> > 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 deriv
> 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
>
> >
> > > +/* 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.
>
> Dat
>
> > +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 stat
>
> > +/* 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_
> > + 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",
> > +
> > + 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_ch
>
> > 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 of
>
> > >
> > > > > 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;
> > > > > +
> >
> > > > 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;
> > > > + str
> 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;
>
> A
> >
> > 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
>
> 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
> > +
> > > 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 properl
> >@@ -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, a
> 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 yo
> >
> > +#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;
> > +
>
> > 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.
> > Sinc
> > >
> > > - 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 {
> > > + /*
> > >
> > -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_gpi
> 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
>
> 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
> > Reviewed-by: Shevchenko, Andriy
>
> I have to recall my reviwed-by tag s
> >>
> >> 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;
>
>
> > +#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
> > 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 likw
>
> > --- 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 t
> > +/* 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;
> > +
> >
> > 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/
>
> 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 b
> 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: Bi
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: [PAT
nal 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
>
&
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 Quar
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: 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 transa
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 transa
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 performanc
> >
> > /*
> > -*/
> > +#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 &&
> > + pd
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 performanc
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 transa
> > 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
> > cont
> -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 US
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 h
> > 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
> >
> > 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.
>
> Please add more detailed description. For example, why is it necessary to
> -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
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:
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);
> > +
> >
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
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: 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 PCI_DEVICE_ID_INTEL_QRK_
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
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 chang
67 matches
Mail list logo
