Re: [PATCH v4 4/9] usb: dwc3: core: Adapt to named interrupts

2015-09-04 Thread Roger Quadros 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 03/09/15 18:48, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Sep 03, 2015 at 03:46:43PM +0300, Roger Quadros wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 02/09/15 17:34, Felipe Balbi wrote:
>>> On Wed, Sep 02, 2015 at 05:24:19PM +0300, Roger Quadros wrote:
 From: Felipe Balbi 

 Add support to use interrupt names,

 Following are the interrupt names

 Peripheral Interrupt - peripheral
 HOST Interrupt - host
 OTG Interrupt - otg

 [Roger Q]
 - If any of these are missing we use the
 first available IRQ resource so that we don't
 break with older DTBs.
>>>
>>> this is what original commit did:
>>>
>>> commit ecd5f71cfd663bcd4efd2f29824acd8b2ba9715d
>>> Author: Felipe Balbi 
>>> Date:   Fri Jan 3 13:49:38 2014 -0600
>>>
>>> usb: dwc3: cleanup IRQ resources
>>> 
>>> In order to make it easier for the driver to
>>> figure out which modes of operation it has,
>>> and because some dwc3 integrations have rather
>>> fuzzy IRQ routing, we now require three different
>>> IRQ numbers (peripheral, host, otg).
>>> 
>>> In order to do that and maintain backwards compatibility,
>>> we still maintain support for the old IRQ resource name,
>>> but if you *really* want to have proper peripheral/host/otg
>>> support, you should make sure your resources are correct.
>>> 
>>> Signed-off-by: Felipe Balbi 
>>
>> This is better since we request the resource only if needed and bail out
>> if it is not present.
>>
>>>
>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>> index 60580a01cdd2..1f01031873b7 100644
>>> --- a/drivers/usb/dwc3/core.c
>>> +++ b/drivers/usb/dwc3/core.c
>>> @@ -556,10 +556,22 @@ static int dwc3_core_get_phy(struct dwc3 *dwc)
>>>  static int dwc3_core_init_mode(struct dwc3 *dwc)
>>>  {
>>> struct device *dev = dwc->dev;
>>> +   struct platform_device *pdev = to_platform_device(dev);
>>> int ret;
>>>  
>>> switch (dwc->dr_mode) {
>>> case USB_DR_MODE_PERIPHERAL:
>>> +   dwc->gadget_irq = platform_get_irq_byname(pdev, 
>>> "dwc3_peripheral");
>>
>> Shall we just name it just "peripheral"?
> 
> sure, why not :-)
> 
>>> +   if (dwc->gadget_irq < 0) {
>>> +   dwc->gadget_irq = platform_get_irq_byname(pdev, 
>>> "dwc_usb3");
>>
>> How will this work? Currently we don't have a name for the IRQ in the DT.
> 
> we can just add interrupt-names, right ? Or, the fallback could be what
> is already done today: just fetch it by index.
> 
>>
>>> +   if (dwc->gadget_irq < 0) {
>>> +   dev_err(dev, "missing IRQ\n");
>>> +   return dwc->gadget_irq;
>>> +   } else {
>>> +   dev_warn(dev, "dwc_usb3 resource is 
>>> deprecated\n");
>>
>> Do we want to warn about legacy nodes?
> 
> Sure :-)
> 
> Now, do you want me to update it, or will you do it ? BTW, if you decide
> to do it, we need to patch all users :-)

Would appreciate if you can do it. It is independent of dual-role support and 
can go in early.
BTW omap users are already using the named interrupt property.

> 
>>> @@ -576,6 +604,28 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
>>> }
>>> break;
>>> case USB_DR_MODE_OTG:
>>> +   dwc->gadget_irq = platform_get_irq_byname(pdev, 
>>> "dwc3_peripheral");
>>> +   if (dwc->gadget_irq < 0) {
>>> +   dwc->gadget_irq = platform_get_irq_byname(pdev, 
>>> "dwc_usb3");
>>> +   if (dwc->gadget_irq < 0) {
>>> +   dev_err(dev, "missing IRQ\n");
>>> +   return dwc->gadget_irq;
>>> +   } else {
>>> +   dev_warn(dev, "dwc_usb3 resource is 
>>> deprecated\n");
>>> +   }
>>> +
>>> +   dwc->xhci_irq = dwc->gadget_irq;
>>> +   dwc->otg_irq = dwc->gadget_irq;
>>> +   } else {
>>> +   dwc->xhci_irq = platform_get_irq_byname(pdev, 
>>> "dwc3_host");
>>> +   if (dwc->xhci_irq < 0) {
>>> +   dev_err(dev, "missing Host IRQ\n");
>>> +   return dwc->xhci_irq;
>>> +   }
>>> +
>>> +   dwc->otg_irq = platform_get_irq_byname(pdev, 
>>> "dwc3_otg");
>>
>> need to check if error?
> 
> right
> 
>>> +   }
>>
>> Need to setup xhci_resource[1]?
> 
> isn't it done above ?
> 

It is done in the USB_DR_MODE_HOST case, but that won't be executed for 
USB_DR_MODE_OTG case, no?
I'm talking about this part

+   dwc->xhci_resources[1].start = dwc->xhci_irq;
+   dwc->xhci_resources[1].end = dwc->xhci_irq;
+   dwc->xhci_resources[1].flags = IORESOURCE_IRQ;
+

Re: [PATCH 1/5] spi: introduce mmap read support for spi flash devices

2015-09-04 Thread Jagan Teki 
On 4 September 2015 at 13:59, Vignesh R  wrote:
> In addition to providing direct access to SPI bus, some spi controller
> hardwares (like ti-qspi) provide special memory mapped port
> to accesses SPI flash devices in order to increase read performance.
> This means the controller can automatically send the SPI signals
> required to read data from the SPI flash device.
> For this, spi controller needs to know flash specific information like
> read command to use, dummy bytes and address width. Once these settings
> are populated in hardware registers, any read accesses to flash's memory
> map region(SoC specific) through memcpy or mem-to-mem DMA copy will be
> handled by controller hardware. The hardware will automatically generate
> spi signals required to read data from flash and present it to CPU or
> DMA engine.
>
> Introduce spi_mtd_mmap_read() method to support memory mapped read
> over SPI flash devices. SPI master drivers can implement this method to
> support memory mapped read interfaces. m25p80 flash driver and other
> flash drivers can call this to request memory mapped read. The interface
> should only be used mtd flashes and cannot be used with other spi devices.
>
> Signed-off-by: Vignesh R 
> ---
>  include/linux/spi/spi.h | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
> index d673072346f2..b74a3f169fc2 100644
> --- a/include/linux/spi/spi.h
> +++ b/include/linux/spi/spi.h
> @@ -293,6 +293,23 @@ static inline void spi_unregister_driver(struct 
> spi_driver *sdrv)
>   * @handle_err: the subsystem calls the driver to handle an error that occurs
>   * in the generic implementation of transfer_one_message().
>   * @unprepare_message: undo any work done by prepare_message().
> + * @spi_mtd_mmap_read: some spi-controller hardwares provide memory
> + * mapped interface to communicate with mtd flashes.
> + * For this, spi  controller needs to know flash
> + * memory settings like read command to use, dummy
> + * bytes and address width. Once these settings are
> + * populated in hardware registers, any read
> + * accesses to flash's memory map region(as defined
> + * by SoC) through memcpy or mem-to-mem DMA copy
> + * will be handled by controller hardware. The
> + * hardware will automatically generate spi signals
> + * required to read data from flash and present it
> + * to CPU or DMA. SPI master drivers can use this
> + * callback to implement memory mapped read
> + * interface. Flash driver (like m25p80) requests
> + * memory mapped read via this method. The interface
> + * should  only be used mtd flashes and cannot be
> + * used with other spi devices.
>   * @cs_gpios: Array of GPIOs to use as chip select lines; one per CS
>   * number. Any individual value may be -ENOENT for CS lines that
>   * are not GPIOs (driven by the SPI controller itself).
> @@ -438,6 +455,10 @@ struct spi_master {
>struct spi_message *message);
> int (*unprepare_message)(struct spi_master *master,
>  struct spi_message *message);
> +   int (*spi_mtd_mmap_read)(struct  spi_device *spi,
> +loff_t from, size_t len, size_t *retlen,
> +u_char *buf, u8 read_opcode,
> +u8 addr_width, u8 dummy_bytes);

This looks un-manageable to know spi core or master knows what are the
command or opcode used by spi-nor flash and also I think mmap support
seems to be flash related or any justification this is spi bus
master/controller feature?

thanks!
-- 
Jagan | openedev.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/2] regulator: Fix pbias regulator enable

2015-09-04 Thread Kishon Vijay Abraham I 
vsel_reg and enable_reg of the pbias regulator descriptor should actually
have the offset from syscon.

However after
"ARM: dts: : add minimal l4 bus layout with control module
support"
vsel_reg and enable_reg started to have the absolute address because
of address translation that happens due to pbias node made as the
child node of syscon. This breaks the pbias regulator enable.

This series adds the 'offset' to be populated in vsel_reg and enable_reg
in the pbias driver itself.

Changes from v2:
*) Squashed all the dt patches into a single patch

Changes from v1:
*) Fixed Tony's review comments on adding a 'comment' for adding offset in
   the driver and adding a warning for using platform_get_resource.
*) Added Tony's Acked-by.

Tested these patches against mmc -next in omap4 panda, omap3 beagle xm,
dra72 and omap5 uevm

Kishon Vijay Abraham I (2):
  regulator: pbias: program pbias register offset in pbias driver
  ARM: dts: : use "ti,pbias-" compatible
string for pbias

 .../bindings/regulator/pbias-regulator.txt |7 ++-
 arch/arm/boot/dts/dra7.dtsi|2 +-
 arch/arm/boot/dts/omap2430.dtsi|2 +-
 arch/arm/boot/dts/omap3.dtsi   |2 +-
 arch/arm/boot/dts/omap4.dtsi   |2 +-
 arch/arm/boot/dts/omap5.dtsi   |2 +-
 drivers/regulator/pbias-regulator.c|   56 +---
 7 files changed, 61 insertions(+), 12 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCH] ARM: multi_v7_defconfig: Enable PBIAS regulator

2015-09-04 Thread Kishon Vijay Abraham I 
PBIAS regulator is required for MMC module in OMAP2, OMAP3, OMAP4,
OMAP5 and DRA7 SoCs. Enable it here.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/configs/multi_v7_defconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 5fd8df6..f497c96 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -403,6 +403,7 @@ CONFIG_REGULATOR_MAX8973=y
 CONFIG_REGULATOR_MAX77686=y
 CONFIG_REGULATOR_MAX77693=m
 CONFIG_REGULATOR_PALMAS=y
+CONFIG_REGULATOR_PBIAS=y
 CONFIG_REGULATOR_S2MPS11=y
 CONFIG_REGULATOR_S5M8767=y
 CONFIG_REGULATOR_TPS51632=y
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/9] usb: dwc3: add dual-role support

2015-09-04 Thread Roger Quadros 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Felipe,

On 03/09/15 18:44, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Sep 03, 2015 at 03:21:48PM +0300, Roger Quadros wrote:
 +  dwc->fsm->id = id;
 +  dwc->fsm->b_sess_vld = vbus;
 +  usb_otg_sync_inputs(dwc->fsm);
 +}
 +
 +static int dwc3_drd_start_host(struct otg_fsm *fsm, int on)
 +{
 +  struct device *dev = usb_otg_fsm_to_dev(fsm);
 +  struct dwc3 *dwc = dev_get_drvdata(dev);
>>>
>>> how about adding a usb_otg_get_drvdata(fsm) ?
>>
>> You meant for otg core? That can be done.
> 
> yeah. BTW, I think otg core needs quite a few changes to become actually
> useful. Currently it's just too much pointer ping-pong going back and
> forth between phy, otg core, udc and hcd.

Sure, any inputs for improvement appreciated.

> 
> Also, I caught a ton of issues with it and suspend/resume. You might
> want to fix them before adding more users to it.

OK.

> 
> It's also rather racy and that needs fixing too. On top of all that, I
> think there's too much being added to UDC just to get Dual-Role, let's
> see if we can improve that too.

Would appreciate if you could give all your inputs on the otg core thread
as early as you can :)

> 
 @@ -843,6 +998,16 @@ static int dwc3_probe(struct platform_device *pdev)
hird_threshold = 12;
  
if (node) {
 +  if (of_property_read_bool(node, "extcon"))
 +  dwc->edev = extcon_get_edev_by_phandle(dev, 0);
 +  else if (of_property_read_bool(dev->parent->of_node, "extcon"))
 +  dwc->edev = extcon_get_edev_by_phandle(dev->parent, 0);
>>>
>>> why do you need to check the parent ? Why isn't that done on the glue
>>> layer ?
>>
>> On DRA7-evm, the extcon device is defined in the glue layer node. But
>> we need the device both at the glue layer and at the core layer.
> 
> why do you need extcon here ? Glue updates core via UTMI about the
> states, right ? So you should get proper VBUS and ID status via OTG IRQ.
> Is that not working ?

I didn't even expect that would work. Let me give that a try.

> 
>> We do get the extcon device in dwc3-omap.c
>>
>> Any suggestion how to pass the extcon device from glue layer to core.c?
>> Or should I add the extcon property to dwc3 USB node as well in the DT?
> 
> GPIO toggles
>   dwc3-omap extcon event
> update status via UTMI STATUS register
>   OTG IRQ on core
> Horray!
> 
> :-)

That's great. Thanks :)

> 
 +
 +  if (IS_ERR(dwc->edev)) {
 +  dev_vdbg(dev, "couldn't get extcon device\n");
>>>
>>> dev_err() ??
>>
>> Is it ok to print it even in EPROBE_DEFER case?
> 
> hmm, probably pointless, indeed.
> 

cheers,
- -roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV6V8UAAoJENJaa9O+djCToUwP/1SRrcUG/1KG54c1loxKFvYG
51x17TiVuQc68xtrp56HYJNRpZzZIwBqlfa3LU19bd/p6alYGaaY6jOqW+gFWWt8
tJd+7lyjVuCWkrJBQ6obK4yDPK4r6ZLcFlCTLGsfnd6SSBdsGxNrpcNCwz2rhhE/
uTPQdU4wvgxDFnGFVtTMhM+/ehtJtkKB4dppoFA5Vw86vsKinJ7o5EJMwho/PwJu
4D+mQVi17kQDBx1wkQPBxyVHD6RXfjMBLK+zg46T6lsg1eUodkv22Grf9Xy4i4wT
9Pr3g6SFnczkKiU1Bp7q4TV048SY0KedA7oe1U7K9B+hjHK4Fc2/vxtb3kGyNK7x
VPkN3NbvqSZalcgmdoDnv6VvU5NdnZUyKasVeJQDp9Fzaom9rUmNvic0ZLx9TOTP
4e4R2ovyCFnU1nODDUccYDInPiJ3EUo6D7CX3L7rfud5h6qAXcqC6vzZ3oHcSnBu
S1PXPTjLyk/a+den4gf41ReF5xKXzNocH21cXe7oFwKDaCJ9VgEn4+E5tX0vK778
KGHz3qFEQGkM6Eib0tEZEdHUEgeO8H99rNAELFNTrtS0FPZIEtQPHr2lmFDM/iYC
sEECc/HFP+LvmAzuJLA4XRUeNh6xo0K/ZDOtX1YOCCqnjy/UHNKvB4gUDzVaNti+
DB0wWXP+/A9Qz1PBK1dG
=rFBL
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/2] regulator: pbias: program pbias register offset in pbias driver

2015-09-04 Thread Kishon Vijay Abraham I 
Add separate compatible strings for every platform and populate the
pbias register offset in the driver data.
This helps avoid depending on the dt for pbias register offset.

Also update the dt binding documentation with the new compatible
strings.

Suggested-by: Tony Lindgren 
Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Tony Lindgren 
---
 .../bindings/regulator/pbias-regulator.txt |7 ++-
 drivers/regulator/pbias-regulator.c|   56 +---
 2 files changed, 56 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt 
b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
index 32aa26f..acbcb45 100644
--- a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
@@ -2,7 +2,12 @@ PBIAS internal regulator for SD card dual voltage i/o pads on 
OMAP SoCs.
 
 Required properties:
 - compatible:
-  - "ti,pbias-omap" for OMAP2, OMAP3, OMAP4, OMAP5, DRA7.
+  - should be "ti,pbias-dra7" for DRA7
+  - should be "ti,pbias-omap2" for OMAP2
+  - should be "ti,pbias-omap3" for OMAP3
+  - should be "ti,pbias-omap4" for OMAP4
+  - should be "ti,pbias-omap5" for OMAP5
+  - "ti,pbias-omap" is deprecated
 - reg: pbias register offset from syscon base and size of pbias register.
 - syscon : phandle of the system control module
 - regulator-name : should be
diff --git a/drivers/regulator/pbias-regulator.c 
b/drivers/regulator/pbias-regulator.c
index bd2b75c..c21cedb 100644
--- a/drivers/regulator/pbias-regulator.c
+++ b/drivers/regulator/pbias-regulator.c
@@ -44,6 +44,10 @@ struct pbias_regulator_data {
int voltage;
 };
 
+struct pbias_of_data {
+   unsigned int offset;
+};
+
 static const unsigned int pbias_volt_table[] = {
180,
300
@@ -98,8 +102,35 @@ static struct of_regulator_match pbias_matches[] = {
 };
 #define PBIAS_NUM_REGS ARRAY_SIZE(pbias_matches)
 
+/* Offset from SCM general area (and syscon) base */
+
+static const struct pbias_of_data pbias_of_data_omap2 = {
+   .offset = 0x230,
+};
+
+static const struct pbias_of_data pbias_of_data_omap3 = {
+   .offset = 0x2b0,
+};
+
+static const struct pbias_of_data pbias_of_data_omap4 = {
+   .offset = 0x60,
+};
+
+static const struct pbias_of_data pbias_of_data_omap5 = {
+   .offset = 0x60,
+};
+
+static const struct pbias_of_data pbias_of_data_dra7 = {
+   .offset = 0xe00,
+};
+
 static const struct of_device_id pbias_of_match[] = {
{ .compatible = "ti,pbias-omap", },
+   { .compatible = "ti,pbias-omap2", .data = _of_data_omap2, },
+   { .compatible = "ti,pbias-omap3", .data = _of_data_omap3, },
+   { .compatible = "ti,pbias-omap4", .data = _of_data_omap4, },
+   { .compatible = "ti,pbias-omap5", .data = _of_data_omap5, },
+   { .compatible = "ti,pbias-dra7", .data = _of_data_dra7, },
{},
 };
 MODULE_DEVICE_TABLE(of, pbias_of_match);
@@ -114,6 +145,9 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
const struct pbias_reg_info *info;
int ret = 0;
int count, idx, data_idx = 0;
+   const struct of_device_id *match;
+   const struct pbias_of_data *data;
+   unsigned int offset;
 
count = of_regulator_match(>dev, np, pbias_matches,
PBIAS_NUM_REGS);
@@ -129,6 +163,20 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
if (IS_ERR(syscon))
return PTR_ERR(syscon);
 
+   match = of_match_device(of_match_ptr(pbias_of_match), >dev);
+   if (match && match->data) {
+   data = match->data;
+   offset = data->offset;
+   } else {
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res)
+   return -EINVAL;
+
+   offset = res->start;
+   dev_WARN(>dev,
+"using legacy dt data for pbias offset\n");
+   }
+
cfg.regmap = syscon;
cfg.dev = >dev;
 
@@ -141,10 +189,6 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
if (!info)
return -ENODEV;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res)
-   return -EINVAL;
-
drvdata[data_idx].syscon = syscon;
drvdata[data_idx].info = info;
drvdata[data_idx].desc.name = info->name;
@@ -154,9 +198,9 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
drvdata[data_idx].desc.volt_table = pbias_volt_table;
drvdata[data_idx].desc.n_voltages = 2;
drvdata[data_idx].desc.enable_time = info->enable_time;
-   drvdata[data_idx].desc.vsel_reg = res->start;
+

[PATCH v3 2/2] ARM: dts: : use "ti,pbias-" compatible string for pbias

2015-09-04 Thread Kishon Vijay Abraham I 
Use platform specific compatible strings instead of the common
"ti,pbias-omap" compatible string.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Tony Lindgren 
---
 arch/arm/boot/dts/dra7.dtsi |2 +-
 arch/arm/boot/dts/omap2430.dtsi |2 +-
 arch/arm/boot/dts/omap3.dtsi|2 +-
 arch/arm/boot/dts/omap4.dtsi|2 +-
 arch/arm/boot/dts/omap5.dtsi|2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1e29ccf..d6bc6db 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -122,7 +122,7 @@
#size-cells = <1>;
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-dra7", 
"ti,pbias-omap";
reg = <0xe00 0x4>;
syscon = <_conf>;
pbias_mmc_reg: pbias_mmc_omap5 {
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 2390f38..3961a6f 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -63,7 +63,7 @@
};
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap2", 
"ti,pbias-omap";
reg = <0x230 0x4>;
syscon = <_conf>;
pbias_mmc_reg: 
pbias_mmc_omap2430 {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 69a40cf..9af9ae1 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -203,7 +203,7 @@
};
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap3", "ti,pbias-omap";
reg = <0x2b0 0x4>;
syscon = <_conf>;
pbias_mmc_reg: pbias_mmc_omap2430 {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index abc4473..5aad7f3 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -198,7 +198,7 @@
#size-cells = <1>;
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap4", 
"ti,pbias-omap";
reg = <0x60 0x4>;
syscon = 
<_padconf_global>;
pbias_mmc_reg: pbias_mmc_omap4 {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index b1a1263..76ef595 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -187,7 +187,7 @@
#size-cells = <1>;
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap5", 
"ti,pbias-omap";
reg = <0x60 0x4>;
syscon = 
<_padconf_global>;
pbias_mmc_reg: pbias_mmc_omap5 {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gpio: omap: Fix GPIO numbering for deferred probe

2015-09-04 Thread Grygorii Strashko 

On 09/03/2015 08:31 PM, Tony Lindgren wrote:

If gpio-omap probe fails with -EPROBE_DEFER, the GPIO numbering
keeps increasing. Only increase the gpio count if gpiochip_add()
was successful as otherwise the numbers will increase for each
probe attempt.

Cc: Grygorii Strashko 
Cc: Javier Martinez Canillas 
Cc: Kevin Hilman 
Cc: Santosh Shilimkar 
Signed-off-by: Tony Lindgren 
---
  drivers/gpio/gpio-omap.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1095,7 +1095,6 @@ static int omap_gpio_chip_init(struct gpio_bank *bank, 
struct irq_chip *irqc)
} else {
bank->chip.label = "gpio";
bank->chip.base = gpio;
-   gpio += bank->width;
}
bank->chip.ngpio = bank->width;

@@ -1105,6 +1104,9 @@ static int omap_gpio_chip_init(struct gpio_bank *bank, 
struct irq_chip *irqc)
return ret;
}

+   if (!bank->is_mpuio)
+   gpio += bank->width;
+
  #ifdef CONFIG_ARCH_OMAP1
/*
 * REVISIT: Once we have OMAP1 supporting SPARSE_IRQ, we can drop



Reviewed-by: Grygorii Strashko 

With hope that only GPIO0 will be deferred, otherwise
there will be total mess in gpios enumeration ;)

--
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] omap: Fix broken address translation for pbias

2015-09-04 Thread Kishon Vijay Abraham I 
Hi Tony,

On Thursday 03 September 2015 08:40 PM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I  [150903 04:31]:
>> pbias device stopped having memory resource after
>> "ARM: dts: : add minimal l4 bus layout with control module
>> support" got merged. This results in platform_get_resource returning
>> -EINVAL in pbias driver. This is because address translation fails
>> while trying to convert the address to resource which happens
>> during the device creation process during boot up.
>>
>> Even though after [1], reg property in pbias dt node is un-used,
>> it might be an issue if we plan to use it at a later point of time.
>>
>> Patch series is created on top of [1].
>>
>> [1] -> https://lkml.org/lkml/2015/9/3/51
>>
>> Verified the address in omap4 panda, omap5 uevm and dra72 boards.
> 
> Your other series is obviously needed for v4.3.. But seems these
> are also needed for stable? If so, which versions, v4.2+?

Both the series are needed from v4.1+. However since the 'reg' property
is not going to be used, I'm not sure if this series has to be marked
for stable.
> 
> Can you please just do a single patch with multiple Fixes tags
> as they fix regression for multiple commits? Doing tons of one
> liner patches for the same thing just creates commit log noise..

Sure.
> 
> Remember to not Cc stable when posting, I'll add that tag when
> committing if needed.

Sure.

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 5/9] usb: dwc3: core: make dual-role work with OTG irq

2015-09-04 Thread Roger Quadros 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/09/15 18:51, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Sep 03, 2015 at 04:52:02PM +0300, Roger Quadros wrote:
if (on) {
 -  dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
 +  /* OCTL.PeriMode = 0 */
 +  reg = dwc3_readl(dwc->regs, DWC3_OCTL);
 +  reg &= ~DWC3_OCTL_PERIMODE;
 +  dwc3_writel(dwc->regs, DWC3_OCTL, reg);
 +  /* unconditionally turn on VBUS */
 +  reg |= DWC3_OCTL_PRTPWRCTL;
 +  dwc3_writel(dwc->regs, DWC3_OCTL, reg);
/* start the HCD */
usb_otg_start_host(fsm, true);
} else {
/* stop the HCD */
usb_otg_start_host(fsm, false);
 +  /* turn off VBUS */
 +  reg = dwc3_readl(dwc->regs, DWC3_OCTL);
 +  reg &= ~DWC3_OCTL_PRTPWRCTL;
 +  dwc3_writel(dwc->regs, DWC3_OCTL, reg);
 +  /* OCTL.PeriMode = 1 */
 +  reg = dwc3_readl(dwc->regs, DWC3_OCTL);
 +  reg |= DWC3_OCTL_PERIMODE;
 +  dwc3_writel(dwc->regs, DWC3_OCTL, reg);
}
>>>
>>> it looks like you're not really following the fluxchart from SNPS
>>> documentation, see Figure 11-4 on section 11.1.4.5
>>
>> Did you mean that I'm ignoring all OTG bits (HNP/SRP/ADP)?
> 
> yes and no :-)  There's a rather complex flux chart which details how we
> switch from host to peripheral and vice versa. We need to follow that to
> the smallest details since that's what IP provider considers to be
> correct. If we deviate from that we should have very strong reasons for
> doing so and we also want big, fat, long comments in source code
> detailing why and how we're deviating :-)
> 
Understood. I'll update this accordingly.

- --
cheers,
- -roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV6WC4AAoJENJaa9O+djCTWSEP/jq0jX2KJVjqKeSk60wyDIEH
AIGXpaupz4XCFRsLFHlEomAoWHEzmbdwQlcI5gyB4N6IgF6xfxX71AZnytw4k4ja
sFxQq/qNSPWa4yiEY9MFbIPuiRMFcLOB5VbemGpcZq4n31yaKlbLtHMDEC8zPmdY
yfnUz7raY2tID/+wOASAM+nDXVS6nFztWXCrz+4TxwDaH0dgwl9OAoD7nvTil3MT
UTuR34GbWcb9rCxJVYgneht1sLbkKGCkwjLRcqzhOajg87GuW38irqD9OOF+pLCm
srhYsntQyBJlvArDQKMZIyGEYHvjICWzJUo/IPA8DFS/qOrRLyrLvVHskb6pr9/y
KZL/1N+5Nbh0N0XGWKwxzVh69DqmQPuY32SN2r1xqCDzzZAnvrl9cz6ixsRq1JGK
9EvYNJlRWsdypfA8tdhPtCgXua+wYSLNewgHQSko10qeAgiaIU5/bQ/9Eb2Ys9QV
6wkhr0Gulf/hnMKXHupErhUsvSBJk2MGaaDIfUSt3mWMTRsthp2NedRE9li9bWW9
gSXcTxs8785Y7FgxFDvvqQ05rbGWNqfxkeq54ziMtH3mZ93inE7me1HbqL1jgEuh
NFrNsAKYc000syvnqunzl8uZMRMsICaY1aKC0riQTdpgagHgGMfadKtWXb8OdcVa
gICj2/o8MpPpv3FEniDz
=L39b
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] ARM: dts: >: fix address translation for pbias

2015-09-04 Thread Kishon Vijay Abraham I 
"ARM: dts: : add minimal l4 bus
layout with control module support" moved pbias_regulator dt node
from being a child node of ocp to be the child node of
'syscon'. Since 'syscon' doesn't have the 'ranges' property,
address translation fails while trying to convert the address
to resource. Fix it here by populating 'ranges' property in
syscon dt node.

Fixes: 72b10ac00eb1 ("ARM: dts: omap24xx: add minimal l4 bus
layout with control module support")

Fixes: 7415b0b4c645 ("ARM: dts: omap4: add minimal l4 bus layout
with control module support")

Fixes: ed8509edddeb ("ARM: dts: omap5: add minimal l4 bus
layout with control module support")

Fixes: d919501feffa ("ARM: dts: dra7: add minimal l4 bus
layout with control module support")

Signed-off-by: Kishon Vijay Abraham I 
---
Changes from v1:
*) squashed [1] to a single patch
[1] -> https://lkml.org/lkml/2015/9/3/166

 arch/arm/boot/dts/dra7.dtsi |1 +
 arch/arm/boot/dts/omap2430.dtsi |1 +
 arch/arm/boot/dts/omap4.dtsi|1 +
 arch/arm/boot/dts/omap5.dtsi|1 +
 4 files changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d6bc6db..5896896 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -120,6 +120,7 @@
reg = <0x0 0x1400>;
#address-cells = <1>;
#size-cells = <1>;
+   ranges = <0 0x0 0x1400>;
 
pbias_regulator: pbias_regulator {
compatible = "ti,pbias-dra7", 
"ti,pbias-omap";
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 3961a6f..798dda0 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -56,6 +56,7 @@
reg = <0x270 0x240>;
#address-cells = <1>;
#size-cells = <1>;
+   ranges = <0 0x270 0x240>;
 
scm_clocks: clocks {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 5aad7f3..5a206c1 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -196,6 +196,7 @@
reg = <0x5a0 0x170>;
#address-cells = <1>;
#size-cells = <1>;
+   ranges = <0 0x5a0 0x170>;
 
pbias_regulator: pbias_regulator {
compatible = "ti,pbias-omap4", 
"ti,pbias-omap";
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 76ef595..dd7a0e8 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -185,6 +185,7 @@
reg = <0x5a0 0xec>;
#address-cells = <1>;
#size-cells = <1>;
+   ranges = <0 0x5a0 0xec>;
 
pbias_regulator: pbias_regulator {
compatible = "ti,pbias-omap5", 
"ti,pbias-omap";
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: multi_v7_defconfig: Enable PBIAS regulator

2015-09-04 Thread Kishon Vijay Abraham I 
Hi,

On Thursday 03 September 2015 08:53 PM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I  [150903 02:58]:
>> PBIAS regulator is required for MMC module in OMAP2, OMAP3, OMAP4,
>> OMAP5 and DRA7 SoCs. Enable it here.
>>
>> Signed-off-by: Kishon Vijay Abraham I 
> 
> For the multi_v7_defconfig changes you need to resend this
> to a...@kernel.org. This is to avoid conflicts with other
> patches.

for some reason mail to a...@kernel.org bounced :-( Should I subscribe to
it before sending patches?

Thanks
Kishon

> 
> Regards,
> 
> Tony
> 
>>  arch/arm/configs/multi_v7_defconfig |1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/configs/multi_v7_defconfig 
>> b/arch/arm/configs/multi_v7_defconfig
>> index 5fd8df6..f497c96 100644
>> --- a/arch/arm/configs/multi_v7_defconfig
>> +++ b/arch/arm/configs/multi_v7_defconfig
>> @@ -403,6 +403,7 @@ CONFIG_REGULATOR_MAX8973=y
>>  CONFIG_REGULATOR_MAX77686=y
>>  CONFIG_REGULATOR_MAX77693=m
>>  CONFIG_REGULATOR_PALMAS=y
>> +CONFIG_REGULATOR_PBIAS=y
>>  CONFIG_REGULATOR_S2MPS11=y
>>  CONFIG_REGULATOR_S5M8767=y
>>  CONFIG_REGULATOR_TPS51632=y
>> -- 
>> 1.7.9.5
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/2] regulator: Fix pbias regulator enable

2015-09-04 Thread Ulf Hansson 
On 4 September 2015 at 14:00, Kishon Vijay Abraham I  wrote:
> vsel_reg and enable_reg of the pbias regulator descriptor should actually
> have the offset from syscon.
>
> However after
> "ARM: dts: : add minimal l4 bus layout with control module
> support"
> vsel_reg and enable_reg started to have the absolute address because
> of address translation that happens due to pbias node made as the
> child node of syscon. This breaks the pbias regulator enable.
>
> This series adds the 'offset' to be populated in vsel_reg and enable_reg
> in the pbias driver itself.
>
> Changes from v2:
> *) Squashed all the dt patches into a single patch
>
> Changes from v1:
> *) Fixed Tony's review comments on adding a 'comment' for adding offset in
>the driver and adding a warning for using platform_get_resource.
> *) Added Tony's Acked-by.
>
> Tested these patches against mmc -next in omap4 panda, omap3 beagle xm,
> dra72 and omap5 uevm
>
> Kishon Vijay Abraham I (2):
>   regulator: pbias: program pbias register offset in pbias driver
>   ARM: dts: : use "ti,pbias-" compatible
> string for pbias
>
>  .../bindings/regulator/pbias-regulator.txt |7 ++-
>  arch/arm/boot/dts/dra7.dtsi|2 +-
>  arch/arm/boot/dts/omap2430.dtsi|2 +-
>  arch/arm/boot/dts/omap3.dtsi   |2 +-
>  arch/arm/boot/dts/omap4.dtsi   |2 +-
>  arch/arm/boot/dts/omap5.dtsi   |2 +-
>  drivers/regulator/pbias-regulator.c|   56 
> +---
>  7 files changed, 61 insertions(+), 12 deletions(-)
>
> --
> 1.7.9.5
>

Okay, just to be clear on the way forward. I spoked with Mark Brown
offlist, and he will/has picked up the regulator patch and will send
it as fix for the 4.3 rc[n].

Regarding the ARM patch here, I guess Tony might as well handle it and
send through arm-soc, especially since the regression won't be fixed
within my mmc tree anyway.

So, I am going to leave my next branch as is - and thus relying on
that the regression for OMAP will be fixed in some the 4.3 rc[n].

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] twl4030_charger: fix another compile error

2015-09-04 Thread Grazvydas Ignotas 
When CONFIG_CHARGER_TWL4030=y and CONFIG_TWL4030_MADC=m we get a
compile error:

drivers/built-in.o: In function `twl4030_charger_update_current':
twl4030_charger.c:(.text+0x504681): undefined reference to
`twl4030_get_madc_conversion'

Use IS_REACHABLE to fix it.

Cc: NeilBrown 
Reported-by: Randy Dunlap 
Signed-off-by: Grazvydas Ignotas 
---
 drivers/power/twl4030_charger.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index f4f2c1f..5bcc76f 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -91,7 +91,7 @@
 #define TWL4030_MSTATEC_COMPLETE1  0x0b
 #define TWL4030_MSTATEC_COMPLETE4  0x0e
 
-#if IS_ENABLED(CONFIG_TWL4030_MADC)
+#if IS_REACHABLE(CONFIG_TWL4030_MADC)
 /*
  * If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
  * then AC is available.
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gpio: omap: Fix GPIO numbering for deferred probe

2015-09-04 Thread Tony Lindgren 
* Grygorii Strashko  [150904 03:04]:
> On 09/03/2015 08:31 PM, Tony Lindgren wrote:
> >If gpio-omap probe fails with -EPROBE_DEFER, the GPIO numbering
> >keeps increasing. Only increase the gpio count if gpiochip_add()
> >was successful as otherwise the numbers will increase for each
> >probe attempt.
> >
> >Cc: Grygorii Strashko 
> >Cc: Javier Martinez Canillas 
> >Cc: Kevin Hilman 
> >Cc: Santosh Shilimkar 
> >Signed-off-by: Tony Lindgren 
> >---
> >  drivers/gpio/gpio-omap.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> >--- a/drivers/gpio/gpio-omap.c
> >+++ b/drivers/gpio/gpio-omap.c
> >@@ -1095,7 +1095,6 @@ static int omap_gpio_chip_init(struct gpio_bank *bank, 
> >struct irq_chip *irqc)
> > } else {
> > bank->chip.label = "gpio";
> > bank->chip.base = gpio;
> >-gpio += bank->width;
> > }
> > bank->chip.ngpio = bank->width;
> >
> >@@ -1105,6 +1104,9 @@ static int omap_gpio_chip_init(struct gpio_bank *bank, 
> >struct irq_chip *irqc)
> > return ret;
> > }
> >
> >+if (!bank->is_mpuio)
> >+gpio += bank->width;
> >+
> >  #ifdef CONFIG_ARCH_OMAP1
> > /*
> >  * REVISIT: Once we have OMAP1 supporting SPARSE_IRQ, we can drop
> >
> 
> Reviewed-by: Grygorii Strashko 
> 
> With hope that only GPIO0 will be deferred, otherwise
> there will be total mess in gpios enumeration ;)

Heh nope :) If pinctrl currently ever causes deferred probe
things will get totally messed up.. Works fine after $subject
patch.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] twl4030_charger: fix another compile error

2015-09-04 Thread Tony Lindgren 
* Grazvydas Ignotas  [150904 16:36]:
> When CONFIG_CHARGER_TWL4030=y and CONFIG_TWL4030_MADC=m we get a
> compile error:
> 
> drivers/built-in.o: In function `twl4030_charger_update_current':
> twl4030_charger.c:(.text+0x504681): undefined reference to
> `twl4030_get_madc_conversion'
> 
> Use IS_REACHABLE to fix it.
> 
> Cc: NeilBrown 
> Reported-by: Randy Dunlap 
> Signed-off-by: Grazvydas Ignotas 

Looks OK to me:

Acked-by: Tony Lindgren 

> ---
>  drivers/power/twl4030_charger.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
> index f4f2c1f..5bcc76f 100644
> --- a/drivers/power/twl4030_charger.c
> +++ b/drivers/power/twl4030_charger.c
> @@ -91,7 +91,7 @@
>  #define TWL4030_MSTATEC_COMPLETE10x0b
>  #define TWL4030_MSTATEC_COMPLETE40x0e
>  
> -#if IS_ENABLED(CONFIG_TWL4030_MADC)
> +#if IS_REACHABLE(CONFIG_TWL4030_MADC)
>  /*
>   * If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
>   * then AC is available.
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/2] regulator: pbias: program pbias register offset in pbias driver

2015-09-04 Thread Mark Brown 
On Fri, Sep 04, 2015 at 05:30:24PM +0530, Kishon Vijay Abraham I wrote:
> Add separate compatible strings for every platform and populate the
> pbias register offset in the driver data.
> This helps avoid depending on the dt for pbias register offset.

If there are any changes from the already applied patch for this please
send an incremental patch.  Please don't resend already applied patches.


signature.asc
Description: Digital signature

Re: [PATCH] arm:irqchip: IRQCHIP_DECLARE macro is now accessible

2015-09-04 Thread Joel Porquet 
On Monday, July 13, 2015 11:20:35 PM Shawn Guo wrote:
> On Tue, Jul 07, 2015 at 04:02:53PM -0400, Joel Porquet wrote:
> > The IRQCHIP_DECLARE macro migrated to 'include/linux/irqchip.h', making it
> > globally accessible.
> > 
> > See commit 91e20b5040c67c51aad88cf87db4305c5bd7f79d
> > ("irqchip: Move IRQCHIP_DECLARE macro to include/linux/irqchip.h").
> > 
> > This patch adds inclusions of 'include/linux/irqchip.h' and replaces uses
> > of macro OF_DECLARE_2 with IRQCHIP_DECLARE.
> > 
> > Signed-off-by: Joel Porquet 
> > ---
> 
> ...
> 
> >  arch/arm/mach-imx/gpc.c  | 7 ++-
> 
> Acked-by: Shawn Guo 
> 
> How will this patch be sent to upstream?

If it's more convenient for the different maintainers affected by this patch, 
I can probably resubmit it into a series of patches that modify each file 
separately... Let me know quickly so we don't miss the merge window!

Joël
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/5] ARM: dts: AM4372: add entry for qspi mmap region

2015-09-04 Thread Vignesh R 
Add qspi memory mapped region entries for AM43xx based SoCs. Also,
update the binding documents for the controller to document this change.

Signed-off-by: Vignesh R 
---
 Documentation/devicetree/bindings/spi/ti_qspi.txt | 5 +++--
 arch/arm/boot/dts/am4372.dtsi | 4 +++-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt 
b/Documentation/devicetree/bindings/spi/ti_qspi.txt
index f05dd631bef1..05488970060b 100644
--- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
+++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -17,9 +17,10 @@ Recommended properties:
 
 Example:
 
+For am4372:
 qspi: qspi@4b30 {
-   compatible = "ti,dra7xxx-qspi";
-   reg = <0x4790 0x100>, <0x3000 0x3ff>;
+   compatible = "ti,am4372-qspi";
+   reg = <0x4790 0x100>, <0x3000 0x400>;
reg-names = "qspi_base", "qspi_mmap";
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ade28c790f4b..52cf4846b8e1 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -902,7 +902,9 @@
 
qspi: qspi@4790 {
compatible = "ti,am4372-qspi";
-   reg = <0x4790 0x100>;
+   reg = <0x4790 0x100>,
+ <0x3000 0x400>;
+   reg-names = "qspi_base", "qspi_mmap";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "qspi";
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/5] mtd: devices: m25p80: add support for mmap read request

2015-09-04 Thread Vignesh R 
Certain spi controllers may support memory mapped interface to read from
m25p80 type flash devices. This interface provides better read
performance than regular SPI interface.
Call spi_mtd_mmap_read() function, if available, to make use of
memory-mapped interface.

Signed-off-by: Vignesh R 
---
 drivers/mtd/devices/m25p80.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index d313f948b96c..b8b391aab331 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -133,6 +133,14 @@ static int m25p80_read(struct spi_nor *nor, loff_t from, 
size_t len,
/* convert the dummy cycles to the number of bytes */
dummy /= 8;
 
+   if (spi->master->spi_mtd_mmap_read) {
+   return  spi->master->spi_mtd_mmap_read(spi, from, len,
+  retlen, buf,
+  nor->read_opcode,
+  nor->addr_width,
+  dummy);
+   }
+
spi_message_init();
memset(t, 0, (sizeof t));
 
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/5] ARM: dts: DRA7: add entry for qspi mmap region

2015-09-04 Thread Vignesh R 
Add qspi memory mapped region entries for DRA7xx based SoCs. Also,
update the binding documents for the controller to document this change.

Signed-off-by: Vignesh R 
---
 Documentation/devicetree/bindings/spi/ti_qspi.txt | 13 +
 arch/arm/boot/dts/dra7.dtsi   |  6 --
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt 
b/Documentation/devicetree/bindings/spi/ti_qspi.txt
index 601a360531a5..f05dd631bef1 100644
--- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
+++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -26,3 +26,16 @@ qspi: qspi@4b30 {
spi-max-frequency = <2500>;
ti,hwmods = "qspi";
 };
+
+For dra7xx:
+qspi: qspi@4b30 {
+   compatible = "ti,dra7xxx-qspi";
+   reg = <0x4b30 0x100>, <0x4a002558 0x4>,
+ <0x5c00 0x400>;
+   reg-names = "qspi_base", "qspi_ctrlmod",
+   "qspi_mmap";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   spi-max-frequency = <4800>;
+   ti,hwmods = "qspi";
+};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1e29ccf77ea2..f6798d6ecd60 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1103,8 +1103,10 @@
 
qspi: qspi@4b30 {
compatible = "ti,dra7xxx-qspi";
-   reg = <0x4b30 0x100>;
-   reg-names = "qspi_base";
+   reg = <0x4b30 0x100>, <0x4a002558 0x4>,
+ <0x5c00 0x400>;
+   reg-names = "qspi_base", "qspi_ctrlmod",
+   "qspi_mmap";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "qspi";
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/5] spi: introduce mmap read support for spi flash devices

2015-09-04 Thread Vignesh R 
In addition to providing direct access to SPI bus, some spi controller
hardwares (like ti-qspi) provide special memory mapped port
to accesses SPI flash devices in order to increase read performance.
This means the controller can automatically send the SPI signals
required to read data from the SPI flash device.
For this, spi controller needs to know flash specific information like
read command to use, dummy bytes and address width. Once these settings
are populated in hardware registers, any read accesses to flash's memory
map region(SoC specific) through memcpy or mem-to-mem DMA copy will be
handled by controller hardware. The hardware will automatically generate
spi signals required to read data from flash and present it to CPU or
DMA engine.

Introduce spi_mtd_mmap_read() method to support memory mapped read
over SPI flash devices. SPI master drivers can implement this method to
support memory mapped read interfaces. m25p80 flash driver and other
flash drivers can call this to request memory mapped read. The interface
should only be used mtd flashes and cannot be used with other spi devices.

Signed-off-by: Vignesh R 
---
 include/linux/spi/spi.h | 21 +
 1 file changed, 21 insertions(+)

diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index d673072346f2..b74a3f169fc2 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -293,6 +293,23 @@ static inline void spi_unregister_driver(struct spi_driver 
*sdrv)
  * @handle_err: the subsystem calls the driver to handle an error that occurs
  * in the generic implementation of transfer_one_message().
  * @unprepare_message: undo any work done by prepare_message().
+ * @spi_mtd_mmap_read: some spi-controller hardwares provide memory
+ * mapped interface to communicate with mtd flashes.
+ * For this, spi  controller needs to know flash
+ * memory settings like read command to use, dummy
+ * bytes and address width. Once these settings are
+ * populated in hardware registers, any read
+ * accesses to flash's memory map region(as defined
+ * by SoC) through memcpy or mem-to-mem DMA copy
+ * will be handled by controller hardware. The
+ * hardware will automatically generate spi signals
+ * required to read data from flash and present it
+ * to CPU or DMA. SPI master drivers can use this
+ * callback to implement memory mapped read
+ * interface. Flash driver (like m25p80) requests
+ * memory mapped read via this method. The interface
+ * should  only be used mtd flashes and cannot be
+ * used with other spi devices.
  * @cs_gpios: Array of GPIOs to use as chip select lines; one per CS
  * number. Any individual value may be -ENOENT for CS lines that
  * are not GPIOs (driven by the SPI controller itself).
@@ -438,6 +455,10 @@ struct spi_master {
   struct spi_message *message);
int (*unprepare_message)(struct spi_master *master,
 struct spi_message *message);
+   int (*spi_mtd_mmap_read)(struct  spi_device *spi,
+loff_t from, size_t len, size_t *retlen,
+u_char *buf, u8 read_opcode,
+u8 addr_width, u8 dummy_bytes);
 
/*
 * These hooks are for drivers that use a generic implementation
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/5] spi: spi-ti-qspi: add mmap mode read support

2015-09-04 Thread Vignesh R 
ti-qspi controller provides mmap port to read data from SPI flashes.
mmap port is enabled in QSPI_SPI_SWITCH_REG (ctrl module bits may
also need to be updated for some SoCs). The QSPI_SPI_SETUP_REGx needs to
be populated with flash specific information like read opcode, read
mode(quad, dual, normal), address width and dummy bytes. Once,
controller is in mmap mode, the whole flash memory is available as a
memory region at SoC specific address. This region can be accessed using
normal memcpy() or mem-to-mem dma copy. The ti-qspi controller hardware
will internally communicate with SPI flash over SPI bus and get the
requested data.

Implement spi_mtd_mmap_read() method to support mmap read over SPI
flash devices. With this, the read throughput increases from ~100kB/s to
~2.5 MB/s.

Signed-off-by: Vignesh R 
---
 drivers/spi/spi-ti-qspi.c | 106 --
 1 file changed, 102 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index aa6d284131e0..a07610b84bc9 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -71,11 +71,8 @@ struct ti_qspi {
 #define QSPI_SPI_CMD_REG   (0x48)
 #define QSPI_SPI_STATUS_REG(0x4c)
 #define QSPI_SPI_DATA_REG  (0x50)
-#define QSPI_SPI_SETUP0_REG(0x54)
+#define QSPI_SPI_SETUP_REG(n)  ((0x54 + 4 * n))
 #define QSPI_SPI_SWITCH_REG(0x64)
-#define QSPI_SPI_SETUP1_REG(0x58)
-#define QSPI_SPI_SETUP2_REG(0x5c)
-#define QSPI_SPI_SETUP3_REG(0x60)
 #define QSPI_SPI_DATA_REG_1(0x68)
 #define QSPI_SPI_DATA_REG_2(0x6c)
 #define QSPI_SPI_DATA_REG_3(0x70)
@@ -120,6 +117,16 @@ struct ti_qspi {
 
 #define QSPI_AUTOSUSPEND_TIMEOUT 2000
 
+#define MEM_CS_EN(n)   ((n + 1) << 8)
+
+#define MM_SWITCH  0x1
+
+#define QSPI_SETUP_RD_NORMAL   (0x0 << 12)
+#define QSPI_SETUP_RD_DUAL (0x1 << 12)
+#define QSPI_SETUP_RD_QUAD (0x3 << 12)
+#define QSPI_SETUP_ADDR_SHIFT  8
+#define QSPI_SETUP_DUMMY_SHIFT 10
+
 static inline unsigned long ti_qspi_read(struct ti_qspi *qspi,
unsigned long reg)
 {
@@ -361,6 +368,96 @@ static int qspi_transfer_msg(struct ti_qspi *qspi, struct 
spi_transfer *t)
return 0;
 }
 
+static void ti_qspi_enable_memory_map(struct spi_device *spi)
+{
+   struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
+   u32 val;
+
+   ti_qspi_write(qspi, MM_SWITCH, QSPI_SPI_SWITCH_REG);
+   if (qspi->ctrl_mod) {
+   val = readl(qspi->ctrl_base);
+   val |= MEM_CS_EN(spi->chip_select);
+   writel(val, qspi->ctrl_base);
+   }
+}
+
+static void ti_qspi_disable_memory_map(struct spi_device *spi)
+{
+   struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
+   u32 val;
+
+   ti_qspi_write(qspi, 0, QSPI_SPI_SWITCH_REG);
+   if (qspi->ctrl_mod) {
+   val = readl(qspi->ctrl_base);
+   val &= ~MEM_CS_EN(spi->chip_select);
+   writel(val, qspi->ctrl_base);
+   }
+}
+
+static void ti_qspi_setup_mmap_read(struct spi_device *spi,
+   u8 read_opcode, u8 addr_width,
+   u8 dummy_bytes)
+{
+   struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
+   u32 mode = spi->mode & (SPI_RX_DUAL | SPI_RX_QUAD);
+   u32 memval = read_opcode;
+
+   switch (mode) {
+   case SPI_RX_QUAD:
+   memval |= QSPI_SETUP_RD_QUAD;
+   break;
+   case SPI_RX_DUAL:
+   memval |= QSPI_SETUP_RD_DUAL;
+   break;
+   default:
+   memval |= QSPI_SETUP_RD_NORMAL;
+   break;
+   }
+   memval |= ((addr_width - 1) << QSPI_SETUP_ADDR_SHIFT |
+  dummy_bytes << QSPI_SETUP_DUMMY_SHIFT);
+   ti_qspi_write(qspi, memval,
+ QSPI_SPI_SETUP_REG(spi->chip_select));
+}
+
+static int ti_qspi_spi_mtd_mmap_read(struct  spi_device *spi,
+loff_t from, size_t len,
+size_t *retlen, u_char *buf,
+u8 read_opcode, u8 addr_width,
+u8 dummy_bytes)
+{
+   struct ti_qspi *qspi = spi_master_get_devdata(spi->master);
+   int ret = 0;
+
+   spi_bus_lock(qspi->master);
+   mutex_lock(>list_lock);
+   ret = pm_runtime_get_sync(qspi->dev);
+   if (ret < 0) {
+   dev_err(qspi->dev, "pm_runtime_get_sync() failed\n");
+   return ret;
+   }
+
+   /* disable WC interrupt during memcpy */
+   ti_qspi_write(qspi, QSPI_WC_INT_DISABLE, QSPI_INTR_ENABLE_CLEAR_REG);
+   ti_qspi_enable_memory_map(spi);
+   ti_qspi_setup_mmap_read(spi, read_opcode, addr_width,
+

[PATCH 0/5] Add memory mapped read support for ti-qspi

2015-09-04 Thread Vignesh R 

Hi,

This patch series adds support for memory mapped read port of ti-qspi.
ti-qspi has a special memory mapped port through which SPI flash
memories can be accessed directly via SoC specific memory region.

First patch adds a method to pass flash specific information like read
opcode, dummy bytes etc and to request mmap read. Second patch
implements mmap read method in ti-qspi driver. Patch 3 adapts m25p80 to
use mmap read method before trying normal SPI transfer. Patch 4 and 5
add memory map region DT entries for DRA7xx and AM43xx SoCs.

This patch series is based on the discussions here:
http://www.spinics.net/lists/linux-spi/msg04796.html

Tested on DRA74 EVM and AM437x-SK.
Read performance increases from ~100kB/s to ~2.5MB/s.


Vignesh R (5):
  spi: introduce mmap read support for spi flash devices
  spi: spi-ti-qspi: add mmap mode read support
  mtd: devices: m25p80: add support for mmap read request
  ARM: dts: DRA7: add entry for qspi mmap region
  ARM: dts: AM4372: add entry for qspi mmap region

 Documentation/devicetree/bindings/spi/ti_qspi.txt |  18 +++-
 arch/arm/boot/dts/am4372.dtsi |   4 +-
 arch/arm/boot/dts/dra7.dtsi   |   6 +-
 drivers/mtd/devices/m25p80.c  |   8 ++
 drivers/spi/spi-ti-qspi.c | 106 +-
 include/linux/spi/spi.h   |  21 +
 6 files changed, 154 insertions(+), 9 deletions(-)

-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html