* [PATCH] ARM: i.MX6: add more chip revision support
From: Shawn Guo @ 2014-07-21 5:38 UTC (permalink / raw)
To: linux-arm-kernel
From: Jason Liu <r64343@freescale.com>
Add more revision support for the new i.MX6DQ tap-out (TO1.5). This
TO1.5 is the Rev 1.3 as documented in i.MX6DQ data sheet, because TO1.3
and TO1.4 are never revealed.
Signed-off-by: Jason Liu <r64343@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
---
arch/arm/mach-imx/anatop.c | 9 +++++++++
arch/arm/mach-imx/mxc.h | 2 ++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/mach-imx/anatop.c b/arch/arm/mach-imx/anatop.c
index 4a40bbb46183..459ba290744b 100644
--- a/arch/arm/mach-imx/anatop.c
+++ b/arch/arm/mach-imx/anatop.c
@@ -104,6 +104,15 @@ void __init imx_init_revision_from_anatop(void)
case 2:
revision = IMX_CHIP_REVISION_1_2;
break;
+ case 3:
+ revision = IMX_CHIP_REVISION_1_3;
+ break;
+ case 4:
+ revision = IMX_CHIP_REVISION_1_4;
+ break;
+ case 5:
+ revision = IMX_CHIP_REVISION_1_5;
+ break;
default:
revision = IMX_CHIP_REVISION_UNKNOWN;
}
diff --git a/arch/arm/mach-imx/mxc.h b/arch/arm/mach-imx/mxc.h
index a39b69ef4301..17a41ca65acf 100644
--- a/arch/arm/mach-imx/mxc.h
+++ b/arch/arm/mach-imx/mxc.h
@@ -43,6 +43,8 @@
#define IMX_CHIP_REVISION_1_1 0x11
#define IMX_CHIP_REVISION_1_2 0x12
#define IMX_CHIP_REVISION_1_3 0x13
+#define IMX_CHIP_REVISION_1_4 0x14
+#define IMX_CHIP_REVISION_1_5 0x15
#define IMX_CHIP_REVISION_2_0 0x20
#define IMX_CHIP_REVISION_2_1 0x21
#define IMX_CHIP_REVISION_2_2 0x22
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] PCI: spear: Fix Section mismatch compilation warning for probe()
From: Viresh Kumar @ 2014-07-21 4:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+dSoYp83wnXXHnfQ__GkQvoNcijmktvwqvcpazsQGioQ@mail.gmail.com>
On 21 July 2014 07:45, Rob Herring <robherring2@gmail.com> wrote:
> The Fixes tag is new and the format is documented in SubmittingPatches
Yeah, just saw that for the first time :)
> IIRC. I believe it is also supposed to be quotes rather than
> parentheses around the commit message if we want to be really picky.
Actually both: ("$subject")
I never saw the doc and picked how it was done by Rafael for cpufreq stuff.
Though he was correctly adding 12 digits of the sha key, but the quotes
were missing :)
I will take care of this now.
--
viresh
^ permalink raw reply
* [PATCH 2/6] net/macb: add scatter-gather hw feature
From: David Miller @ 2014-07-21 4:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fda3a504240e1f6863107ef6bf1e78586671a030.1405689937.git.cyrille.pitchen@atmel.com>
From: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Date: Fri, 18 Jul 2014 16:21:14 +0200
> + if (tx_skb->mapped_as_page) {
> + dma_unmap_page(&bp->pdev->dev, tx_skb->mapping,
> + tx_skb->size, DMA_TO_DEVICE);
> + } else {
> + dma_unmap_single(&bp->pdev->dev, tx_skb->mapping,
> + tx_skb->size, DMA_TO_DEVICE);
> + }
Please do not use curly braces for basic block composed of a single statement.
^ permalink raw reply
* [PATCH 1/6] net/macb: configure for FIFO mode and non-gigabit
From: David Miller @ 2014-07-21 4:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <34adf38d52eb31e3ffd36149d320eb0872452bb1.1405689937.git.cyrille.pitchen@atmel.com>
From: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Date: Fri, 18 Jul 2014 16:21:13 +0200
> From: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> This addition will also allow to configure DMA burst length.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> Acked-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
> ---
> drivers/net/ethernet/cadence/macb.c | 72 +++++++++++++++++++++++++++----------
> drivers/net/ethernet/cadence/macb.h | 19 ++++++++--
> 2 files changed, 71 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> index e9daa07..0896d88 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -264,7 +264,8 @@ static void macb_handle_link_change(struct net_device *dev)
> reg |= MACB_BIT(FD);
> if (phydev->speed == SPEED_100)
> reg |= MACB_BIT(SPD);
> - if (phydev->speed == SPEED_1000)
> + if (phydev->speed == SPEED_1000
> + && bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE)
Conditional operators end lines, they do not begin lines.
Also you must start the second and subsequent lines at the very
first column after the openning parenthesis of the first line.
^ permalink raw reply
* [alsa-devel] [PATCH 2/4] ASoC: s3c64xx/smartq: use dynamic registration
From: Alexandre Courbot @ 2014-07-21 3:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717110540.GS17528@sirena.org.uk>
On Thu, Jul 17, 2014 at 8:05 PM, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Jul 17, 2014 at 12:41:23PM +0200, Thierry Reding wrote:
>> On Thu, Jul 17, 2014 at 11:17:23AM +0100, Mark Brown wrote:
>
>> > Not so sure about that - what about requesting GPIOs for a bidirectional
>> > bus? Thinking about SPI bitbanging here.
>
>> Wouldn't you want to use a different means that the gpiod_array_*() API
>> to handle those cases? gpiod_array_*() is probably most useful to handle
>> bulk operations on a set of GPIOs that do essentially the same thing. If
>> you get and then need to index into that array to handle them all
>> differently then you don't gain very much.
>
> For set and get, sure - but it's still useful to be able to do bulk
> requests for GPIOs especially since that's the only bit of the interface
> that requires error handling.
I foresee many problems if people start using gpiod_array_get() as a
way to spare a few lines of error-checking code. First all the GPIOs
would end into an array instead of members with meaningful names -
unless they are moved later on, but doing so would add extra code and
somewhat kill the purpose. It also becomes more difficult to maintain
as you are dealing with array indexes to update all over the code.
Finally, it will make it more difficult to use gpiod_array_*() the way
it is intended to be used, as you would have to discriminate between
GPIOs of the same function and the rest by yourself.
Also, if such a convenience function is legitimate for GPIO, shouldn't
it also apply to other sub-systems? E.g. regulator_array_get()?
Maybe I am missing your point, but I still think some error-handling
code really doesn't hurt here, and the few drivers that would actually
benefit from a more automated GPIO request error handling can easily
implement it themselves. Let's keep gpiod_array_*() single-purposed
and to the point.
^ permalink raw reply
* The imx6q suspend/resume is broken on 3.16-rc due to PCIe
From: Shawn Guo @ 2014-07-21 3:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5DS2NR57kzrjzMBSh8urxSB84Y0TPSJCaGjf7q3cPZPmg@mail.gmail.com>
On Sun, Jul 20, 2014 at 11:55:42PM -0300, Fabio Estevam wrote:
> On Sun, Jul 20, 2014 at 11:50 PM, Shawn Guo <shawn.guo@freescale.com> wrote:
> > On Fri, Jul 18, 2014 at 11:21:48AM +0200, Lucas Stach wrote:
> >> However I seem to have a board with rev 1.1 silicon and although the pci
> >> driver starts up it never establishes a link. So my board may just work
> >> by chance as I don't really know the differences between rev 1.1 silicon
> >> and later revisions.
> >
> > Lucas, thanks for the info.
> >
> > I just checked my board on which the issue is seen, and found it has a
> > rev 1.3 silicon. I just tested on a board with rev 1.2 and did not even
> > see the issue.
> >
> > Richard,
> >
> > Is this an issue only with rev 1.3?
>
> I could see this issue on my board with rev 1.2.
Hmm, that's strange. I tested two imx6q-sabresd boards with rev 1.2
silicon, and did not see this issue. Hopefully, someone else can also
test.
Shawn
^ permalink raw reply
* The imx6q suspend/resume is broken on 3.16-rc due to PCIe
From: Fabio Estevam @ 2014-07-21 2:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721025034.GH8537@dragon>
On Sun, Jul 20, 2014 at 11:50 PM, Shawn Guo <shawn.guo@freescale.com> wrote:
> On Fri, Jul 18, 2014 at 11:21:48AM +0200, Lucas Stach wrote:
>> However I seem to have a board with rev 1.1 silicon and although the pci
>> driver starts up it never establishes a link. So my board may just work
>> by chance as I don't really know the differences between rev 1.1 silicon
>> and later revisions.
>
> Lucas, thanks for the info.
>
> I just checked my board on which the issue is seen, and found it has a
> rev 1.3 silicon. I just tested on a board with rev 1.2 and did not even
> see the issue.
>
> Richard,
>
> Is this an issue only with rev 1.3?
I could see this issue on my board with rev 1.2.
^ permalink raw reply
* The imx6q suspend/resume is broken on 3.16-rc due to PCIe
From: Shawn Guo @ 2014-07-21 2:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405675308.6072.6.camel@weser.hi.pengutronix.de>
On Fri, Jul 18, 2014 at 11:21:48AM +0200, Lucas Stach wrote:
> However I seem to have a board with rev 1.1 silicon and although the pci
> driver starts up it never establishes a link. So my board may just work
> by chance as I don't really know the differences between rev 1.1 silicon
> and later revisions.
Lucas, thanks for the info.
I just checked my board on which the issue is seen, and found it has a
rev 1.3 silicon. I just tested on a board with rev 1.2 and did not even
see the issue.
Richard,
Is this an issue only with rev 1.3?
Shawn
^ permalink raw reply
* Issue found in Armada 370: "No buffer space available" error during continuous ping
From: Maggie Mae Roxas @ 2014-07-21 2:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAB8gEUsLmuDkTzGsq8fVs9dZ90d82Brw2cAPBOnobUTcSgQabA@mail.gmail.com>
Hi Willy,
Good day.
BTW, here are some answers to your questions.
> In fact I don't know if you're running your own board or a "standard"
one (a mirabox or any NAS board).
We are using a "customized" one, not a "standard" one.
We based the design on Armada 370 RD Evaluation Board, but we used
Marvell 88E1512 as Ethernet PHY and Marvell 88F6707 as processor
instead of the ones in the Armada 370 RD (I think it uses Marvell
88E1310 as Ethernet PHY and Marvell 88F6W11 as processor).
> Because that could also be one of the
differences between what you observe on your side and our respective
experiences with our boards.
Acknowledged.
> Maggie, do you know if it is possible that for any reason your board
would not deliver an IRQ on Tx completion ? That could explain things.
> You can easily test reverting commit 4f3a4f701b just in case.
> If that's the case, then the next step will be to figure out how it is possible
that IRQs are disabled!
After reverting 4f3a4f701b, as I reported, issue does not happen anymore.
Please let me know how to "figure out how it is possible that IRQs are
disabled".
Also, what is the impact if I use this combination?
> - use 3.13.9 mvneta.c
> - apply cd71e246c16b30e3f396a85943d5f596202737ba
> - revert 4f3a4f701b59a3e4b5c8503ac3d905c0a326f922
Are there functionalities that won't work?
Thank you very much for your support.
Regards,
Maggie Roxas
On Sun, Jul 20, 2014 at 6:57 PM, Maggie Mae Roxas
<maggie.mae.roxas@gmail.com> wrote:
> Hi Willy, Thomas,
> Good day.
>
>> I'll try this one, specifcally this combination:
>> - use 3.13.9 mvneta.c
>> - apply cd71e246c16b30e3f396a85943d5f596202737ba
>> - revert 4f3a4f701b59a3e4b5c8503ac3d905c0a326f922
>
> This is to confirm that "No buffer space available" issue is resolved
> after I applied above combinations in in v3.13.9.
> Thanks a lot for the help!
>
> BTW, sorry for the late update - all our connections, electricity and
> stuff are unstable for the past week due to typhoon and we only got
> everything working just today.
>
> Thank you again for attending to our reports.
>
> Regards,
> Maggie Roxas
>
> On Thu, Jul 17, 2014 at 1:15 AM, Willy Tarreau <w@1wt.eu> wrote:
>> Hi Maggie,
>>
>> On Wed, Jul 16, 2014 at 10:37:47PM -0700, Maggie Mae Roxas wrote:
>>> Hi Thomas, Willy,
>>> Good day.
>>>
>>> First of all, thanks again for looking further into this.
>>>
>>> > Maggie, do you know if it is possible that for any reason your board
>>> > would not deliver an IRQ on Tx completion ? That could explain things.
>>>
>>> I'm sorrry but I'm not really sure how to check this - all I know is
>>> that the difference in the working and not-working setup (both
>>> software and hardware) is the mvneta.c.
>>
>> In fact I don't know if you're running your own board or a "standard"
>> one (a mirabox or any NAS board). Because that could also be one of the
>> differences between what you observe on your side and our respective
>> experiences with our boards.
>>
>>> > You can easily test reverting commit 4f3a4f701b just in case. If that's
>>> > the case, then the next step will be to figure out how it is possible
>>> > that IRQs are disabled!
>>> I'll try this one, specifcally this combination:
>>> - use 3.13.9 mvneta.c
>>> - apply cd71e246c16b30e3f396a85943d5f596202737ba
>>> - revert 4f3a4f701b59a3e4b5c8503ac3d905c0a326f922
>>>
>>> I will update you the results within today until latest tomorrow.
>>
>> OK fine, thank you!
>>
>> Willy
>>
^ permalink raw reply
* [PATCHv7 4/4] ARM: dts: Fix wrong compatible string for Exynos3250 ADC
From: Chanwoo Choi @ 2014-07-21 2:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405909068-22539-1-git-send-email-cw00.choi@samsung.com>
This patchset fix wrong compatible string for Exynos3250 ADC. Exynos3250 SoC
need to control only special clock for ADC. Exynos SoC except for Exynos3250
has not included special clock for ADC. The exynos ADC driver can control
special clock if compatible string is 'exynos3250-adc-v2'.
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
---
arch/arm/boot/dts/exynos3250.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index 15c9c87..8ab1289 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -407,10 +407,10 @@
};
adc: adc at 126C0000 {
- compatible = "samsung,exynos-adc-v3";
+ compatible = "samsung,exynos3250-adc";
reg = <0x126C0000 0x100>, <0x10020718 0x4>;
interrupts = <0 137 0>;
- clock-names = "adc", "sclk_tsadc";
+ clock-names = "adc", "sclk";
clocks = <&cmu CLK_TSADC>, <&cmu CLK_SCLK_TSADC>;
#io-channel-cells = <1>;
io-channel-ranges;
--
1.8.0
^ permalink raw reply related
* [PATCHv7 3/4] iio: devicetree: Add DT binding documentation for Exynos3250 ADC
From: Chanwoo Choi @ 2014-07-21 2:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405909068-22539-1-git-send-email-cw00.choi@samsung.com>
This patch add DT binding documentation for Exynos3250 ADC IP. Exynos3250 has
special clock ('sclk_adc') for ADC which provide clock to internal ADC.
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
---
.../devicetree/bindings/arm/samsung/exynos-adc.txt | 25 ++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 832fe8c..6d34891 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -14,14 +14,21 @@ Required properties:
for exynos4412/5250 controllers.
Must be "samsung,exynos-adc-v2" for
future controllers.
+ Must be "samsung,exynos3250-adc" for
+ controllers compatible with ADC of Exynos3250.
- reg: Contains ADC register address range (base address and
length) and the address of the phy enable register.
- interrupts: Contains the interrupt information for the timer. The
format is being dependent on which interrupt controller
the Samsung device uses.
- #io-channel-cells = <1>; As ADC has multiple outputs
-- clocks From common clock binding: handle to adc clock.
-- clock-names From common clock binding: Shall be "adc".
+- clocks From common clock bindings: handles to clocks specified
+ in "clock-names" property, in the same order.
+- clock-names From common clock bindings: list of clock input names
+ used by ADC block:
+ - "adc" : ADC bus clock
+ - "sclk" : ADC special clock (only for Exynos3250 and
+ compatible ADC block)
- vdd-supply VDD input supply.
Note: child nodes can be added for auto probing from device tree.
@@ -41,6 +48,20 @@ adc: adc at 12D10000 {
vdd-supply = <&buck5_reg>;
};
+Example: adding device info in dtsi file for Exynos3250 with additional sclk
+
+adc: adc at 126C0000 {
+ compatible = "samsung,exynos3250-adc";
+ reg = <0x126C0000 0x100>, <0x10020718 0x4>;
+ interrupts = <0 137 0>;
+ #io-channel-cells = <1>;
+ io-channel-ranges;
+
+ clocks = <&cmu CLK_TSADC>, <&cmu CLK_SCLK_TSADC>;
+ clock-names = "adc", "sclk";
+
+ vdd-supply = <&buck5_reg>;
+};
Example: Adding child nodes in dts file
--
1.8.0
^ permalink raw reply related
* [PATCHv7 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
From: Chanwoo Choi @ 2014-07-21 2:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405909068-22539-1-git-send-email-cw00.choi@samsung.com>
This patch control special clock for ADC in Exynos series's FSYS block.
If special clock of ADC is registerd on clock list of common clk framework,
Exynos ADC drvier have to control this clock.
Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
- 'adc' clock: bus clock for ADC
Exynos3250 has additional 'sclk_adc' clock as following:
- 'sclk_adc' clock: special clock for ADC which provide clock to internal ADC
Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc' clock
in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included 'sclk_adc'
clock in FSYS_BLK.
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
---
drivers/iio/adc/exynos_adc.c | 111 +++++++++++++++++++++++++++++++++++++++----
1 file changed, 103 insertions(+), 8 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index dde4ca8..87e0895 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -24,6 +24,7 @@
#include <linux/platform_device.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
+#include <linux/errno.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/io.h>
@@ -70,8 +71,9 @@
#define ADC_V2_CON2_ACH_SEL(x) (((x) & 0xF) << 0)
#define ADC_V2_CON2_ACH_MASK 0xF
-#define MAX_ADC_V2_CHANNELS 10
-#define MAX_ADC_V1_CHANNELS 8
+#define MAX_ADC_V2_CHANNELS 10
+#define MAX_ADC_V1_CHANNELS 8
+#define MAX_EXYNOS3250_ADC_CHANNELS 2
/* Bit definitions common for ADC_V1 and ADC_V2 */
#define ADC_CON_EN_START (1u << 0)
@@ -81,9 +83,11 @@
struct exynos_adc {
struct exynos_adc_data *data;
+ struct device *dev;
void __iomem *regs;
void __iomem *enable_reg;
struct clk *clk;
+ struct clk *sclk;
unsigned int irq;
struct regulator *vdd;
@@ -95,6 +99,7 @@ struct exynos_adc {
struct exynos_adc_data {
int num_channels;
+ bool needs_sclk;
void (*init_hw)(struct exynos_adc *info);
void (*exit_hw)(struct exynos_adc *info);
@@ -102,6 +107,66 @@ struct exynos_adc_data {
void (*start_conv)(struct exynos_adc *info, unsigned long addr);
};
+static void exynos_adc_unprepare_clk(struct exynos_adc *info)
+{
+ if (info->data->needs_sclk)
+ clk_unprepare(info->sclk);
+ clk_unprepare(info->clk);
+}
+
+static int exynos_adc_prepare_clk(struct exynos_adc *info)
+{
+ int ret;
+
+ ret = clk_prepare(info->clk);
+ if (ret) {
+ dev_err(info->dev, "failed preparing adc clock: %d\n", ret);
+ return ret;
+ }
+
+ if (info->data->needs_sclk) {
+ ret = clk_prepare(info->sclk);
+ if (ret) {
+ clk_unprepare(info->clk);
+ dev_err(info->dev,
+ "failed preparing sclk_adc clock: %d\n", ret);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static void exynos_adc_disable_clk(struct exynos_adc *info)
+{
+ if (info->data->needs_sclk)
+ clk_disable(info->sclk);
+ clk_disable(info->clk);
+}
+
+static int exynos_adc_enable_clk(struct exynos_adc *info)
+{
+ int ret;
+
+ ret = clk_enable(info->clk);
+ if (ret) {
+ dev_err(info->dev, "failed enabling adc clock: %d\n", ret);
+ return ret;
+ }
+
+ if (info->data->needs_sclk) {
+ ret = clk_enable(info->sclk);
+ if (ret) {
+ clk_disable(info->clk);
+ dev_err(info->dev,
+ "failed enabling sclk_adc clock: %d\n", ret);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
static void exynos_adc_v1_init_hw(struct exynos_adc *info)
{
u32 con1;
@@ -208,6 +273,16 @@ static const struct exynos_adc_data const exynos_adc_v2_data = {
.start_conv = exynos_adc_v2_start_conv,
};
+static const struct exynos_adc_data const exynos3250_adc_data = {
+ .num_channels = MAX_EXYNOS3250_ADC_CHANNELS,
+ .needs_sclk = true,
+
+ .init_hw = exynos_adc_v2_init_hw,
+ .exit_hw = exynos_adc_v2_exit_hw,
+ .clear_irq = exynos_adc_v2_clear_irq,
+ .start_conv = exynos_adc_v2_start_conv,
+};
+
static const struct of_device_id exynos_adc_match[] = {
{
.compatible = "samsung,exynos-adc-v1",
@@ -215,6 +290,9 @@ static const struct of_device_id exynos_adc_match[] = {
}, {
.compatible = "samsung,exynos-adc-v2",
.data = &exynos_adc_v2_data,
+ }, {
+ .compatible = "samsung,exynos3250-adc",
+ .data = &exynos3250_adc_data,
},
{},
};
@@ -376,6 +454,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
}
info->irq = irq;
+ info->dev = &pdev->dev;
init_completion(&info->completion);
@@ -386,6 +465,16 @@ static int exynos_adc_probe(struct platform_device *pdev)
return PTR_ERR(info->clk);
}
+ if (info->data->needs_sclk) {
+ info->sclk = devm_clk_get(&pdev->dev, "sclk");
+ if (IS_ERR(info->sclk)) {
+ dev_err(&pdev->dev,
+ "failed getting sclk clock, err = %ld\n",
+ PTR_ERR(info->sclk));
+ return PTR_ERR(info->sclk);
+ }
+ }
+
info->vdd = devm_regulator_get(&pdev->dev, "vdd");
if (IS_ERR(info->vdd)) {
dev_err(&pdev->dev, "failed getting regulator, err = %ld\n",
@@ -397,10 +486,14 @@ static int exynos_adc_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = clk_prepare_enable(info->clk);
+ ret = exynos_adc_prepare_clk(info);
if (ret)
goto err_disable_reg;
+ ret = exynos_adc_enable_clk(info);
+ if (ret)
+ goto err_unprepare_clk;
+
platform_set_drvdata(pdev, indio_dev);
indio_dev->name = dev_name(&pdev->dev);
@@ -443,7 +536,9 @@ err_irq:
err_disable_clk:
if (info->data->exit_hw)
info->data->exit_hw(info);
- clk_disable_unprepare(info->clk);
+ exynos_adc_disable_clk(info);
+err_unprepare_clk:
+ exynos_adc_unprepare_clk(info);
err_disable_reg:
regulator_disable(info->vdd);
return ret;
@@ -460,7 +555,8 @@ static int exynos_adc_remove(struct platform_device *pdev)
free_irq(info->irq, info);
if (info->data->exit_hw)
info->data->exit_hw(info);
- clk_disable_unprepare(info->clk);
+ exynos_adc_disable_clk(info);
+ exynos_adc_unprepare_clk(info);
regulator_disable(info->vdd);
return 0;
@@ -474,8 +570,7 @@ static int exynos_adc_suspend(struct device *dev)
if (info->data->exit_hw)
info->data->exit_hw(info);
-
- clk_disable_unprepare(info->clk);
+ exynos_adc_disable_clk(info);
regulator_disable(info->vdd);
return 0;
@@ -491,7 +586,7 @@ static int exynos_adc_resume(struct device *dev)
if (ret)
return ret;
- ret = clk_prepare_enable(info->clk);
+ ret = exynos_adc_enable_clk(info);
if (ret)
return ret;
--
1.8.0
^ permalink raw reply related
* [PATCHv7 1/4] iio: adc: exynos_adc: Add exynos_adc_data structure to improve readability
From: Chanwoo Choi @ 2014-07-21 2:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405909068-22539-1-git-send-email-cw00.choi@samsung.com>
This patchset add 'exynos_adc_data' structure which includes some functions
to control ADC operation and specific data according to ADC version (v1 or v2).
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
---
drivers/iio/adc/exynos_adc.c | 226 ++++++++++++++++++++++++++++---------------
1 file changed, 147 insertions(+), 79 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 010578f..dde4ca8 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -39,11 +39,6 @@
#include <linux/iio/machine.h>
#include <linux/iio/driver.h>
-enum adc_version {
- ADC_V1,
- ADC_V2
-};
-
/* EXYNOS4412/5250 ADC_V1 registers definitions */
#define ADC_V1_CON(x) ((x) + 0x00)
#define ADC_V1_DLY(x) ((x) + 0x08)
@@ -85,6 +80,7 @@ enum adc_version {
#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
struct exynos_adc {
+ struct exynos_adc_data *data;
void __iomem *regs;
void __iomem *enable_reg;
struct clk *clk;
@@ -97,43 +93,139 @@ struct exynos_adc {
unsigned int version;
};
-static const struct of_device_id exynos_adc_match[] = {
- { .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
- { .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
- {},
+struct exynos_adc_data {
+ int num_channels;
+
+ void (*init_hw)(struct exynos_adc *info);
+ void (*exit_hw)(struct exynos_adc *info);
+ void (*clear_irq)(struct exynos_adc *info);
+ void (*start_conv)(struct exynos_adc *info, unsigned long addr);
};
-MODULE_DEVICE_TABLE(of, exynos_adc_match);
-static inline unsigned int exynos_adc_get_version(struct platform_device *pdev)
+static void exynos_adc_v1_init_hw(struct exynos_adc *info)
{
- const struct of_device_id *match;
+ u32 con1;
- match = of_match_node(exynos_adc_match, pdev->dev.of_node);
- return (unsigned int)match->data;
+ writel(1, info->enable_reg);
+
+ /* set default prescaler values and Enable prescaler */
+ con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
+
+ /* Enable 12-bit ADC resolution */
+ con1 |= ADC_V1_CON_RES;
+ writel(con1, ADC_V1_CON(info->regs));
+}
+
+static void exynos_adc_v1_exit_hw(struct exynos_adc *info)
+{
+ u32 con;
+
+ writel(0, info->enable_reg);
+
+ con = readl(ADC_V1_CON(info->regs));
+ con |= ADC_V1_CON_STANDBY;
+ writel(con, ADC_V1_CON(info->regs));
+}
+
+static void exynos_adc_v1_clear_irq(struct exynos_adc *info)
+{
+ writel(1, ADC_V1_INTCLR(info->regs));
}
-static void exynos_adc_hw_init(struct exynos_adc *info)
+static void exynos_adc_v1_start_conv(struct exynos_adc *info,
+ unsigned long addr)
+{
+ u32 con1;
+
+ writel(addr, ADC_V1_MUX(info->regs));
+
+ con1 = readl(ADC_V1_CON(info->regs));
+ writel(con1 | ADC_CON_EN_START, ADC_V1_CON(info->regs));
+}
+
+static const struct exynos_adc_data const exynos_adc_v1_data = {
+ .num_channels = MAX_ADC_V1_CHANNELS,
+
+ .init_hw = exynos_adc_v1_init_hw,
+ .exit_hw = exynos_adc_v1_exit_hw,
+ .clear_irq = exynos_adc_v1_clear_irq,
+ .start_conv = exynos_adc_v1_start_conv,
+};
+
+static void exynos_adc_v2_init_hw(struct exynos_adc *info)
{
u32 con1, con2;
- if (info->version == ADC_V2) {
- con1 = ADC_V2_CON1_SOFT_RESET;
- writel(con1, ADC_V2_CON1(info->regs));
+ writel(1, info->enable_reg);
- con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
- ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
- writel(con2, ADC_V2_CON2(info->regs));
+ con1 = ADC_V2_CON1_SOFT_RESET;
+ writel(con1, ADC_V2_CON1(info->regs));
- /* Enable interrupts */
- writel(1, ADC_V2_INT_EN(info->regs));
- } else {
- /* set default prescaler values and Enable prescaler */
- con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
+ con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
+ ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
+ writel(con2, ADC_V2_CON2(info->regs));
- /* Enable 12-bit ADC resolution */
- con1 |= ADC_V1_CON_RES;
- writel(con1, ADC_V1_CON(info->regs));
- }
+ /* Enable interrupts */
+ writel(1, ADC_V2_INT_EN(info->regs));
+}
+
+static void exynos_adc_v2_exit_hw(struct exynos_adc *info)
+{
+ u32 con;
+
+ writel(0, info->enable_reg);
+
+ con = readl(ADC_V2_CON1(info->regs));
+ con &= ~ADC_CON_EN_START;
+ writel(con, ADC_V2_CON1(info->regs));
+}
+
+static void exynos_adc_v2_clear_irq(struct exynos_adc *info)
+{
+ writel(1, ADC_V2_INT_ST(info->regs));
+}
+
+static void exynos_adc_v2_start_conv(struct exynos_adc *info,
+ unsigned long addr)
+{
+ u32 con1, con2;
+
+ con2 = readl(ADC_V2_CON2(info->regs));
+ con2 &= ~ADC_V2_CON2_ACH_MASK;
+ con2 |= ADC_V2_CON2_ACH_SEL(addr);
+ writel(con2, ADC_V2_CON2(info->regs));
+
+ con1 = readl(ADC_V2_CON1(info->regs));
+ writel(con1 | ADC_CON_EN_START, ADC_V2_CON1(info->regs));
+}
+
+static const struct exynos_adc_data const exynos_adc_v2_data = {
+ .num_channels = MAX_ADC_V2_CHANNELS,
+
+ .init_hw = exynos_adc_v2_init_hw,
+ .exit_hw = exynos_adc_v2_exit_hw,
+ .clear_irq = exynos_adc_v2_clear_irq,
+ .start_conv = exynos_adc_v2_start_conv,
+};
+
+static const struct of_device_id exynos_adc_match[] = {
+ {
+ .compatible = "samsung,exynos-adc-v1",
+ .data = &exynos_adc_v1_data,
+ }, {
+ .compatible = "samsung,exynos-adc-v2",
+ .data = &exynos_adc_v2_data,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, exynos_adc_match);
+
+static struct exynos_adc_data *exynos_adc_get_data(struct platform_device *pdev)
+{
+ const struct of_device_id *match;
+
+ match = of_match_node(exynos_adc_match, pdev->dev.of_node);
+ return (struct exynos_adc_data *)match->data;
}
static int exynos_read_raw(struct iio_dev *indio_dev,
@@ -144,7 +236,6 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
{
struct exynos_adc *info = iio_priv(indio_dev);
unsigned long timeout;
- u32 con1, con2;
int ret;
if (mask != IIO_CHAN_INFO_RAW)
@@ -154,28 +245,15 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
reinit_completion(&info->completion);
/* Select the channel to be used and Trigger conversion */
- if (info->version == ADC_V2) {
- con2 = readl(ADC_V2_CON2(info->regs));
- con2 &= ~ADC_V2_CON2_ACH_MASK;
- con2 |= ADC_V2_CON2_ACH_SEL(chan->address);
- writel(con2, ADC_V2_CON2(info->regs));
-
- con1 = readl(ADC_V2_CON1(info->regs));
- writel(con1 | ADC_CON_EN_START,
- ADC_V2_CON1(info->regs));
- } else {
- writel(chan->address, ADC_V1_MUX(info->regs));
-
- con1 = readl(ADC_V1_CON(info->regs));
- writel(con1 | ADC_CON_EN_START,
- ADC_V1_CON(info->regs));
- }
+ if (info->data->start_conv)
+ info->data->start_conv(info, chan->address);
timeout = wait_for_completion_timeout
(&info->completion, EXYNOS_ADC_TIMEOUT);
if (timeout == 0) {
dev_warn(&indio_dev->dev, "Conversion timed out! Resetting\n");
- exynos_adc_hw_init(info);
+ if (info->data->init_hw)
+ info->data->init_hw(info);
ret = -ETIMEDOUT;
} else {
*val = info->value;
@@ -193,13 +271,11 @@ static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
struct exynos_adc *info = (struct exynos_adc *)dev_id;
/* Read value */
- info->value = readl(ADC_V1_DATX(info->regs)) &
- ADC_DATX_MASK;
+ info->value = readl(ADC_V1_DATX(info->regs)) & ADC_DATX_MASK;
+
/* clear irq */
- if (info->version == ADC_V2)
- writel(1, ADC_V2_INT_ST(info->regs));
- else
- writel(1, ADC_V1_INTCLR(info->regs));
+ if (info->data->clear_irq)
+ info->data->clear_irq(info);
complete(&info->completion);
@@ -277,6 +353,12 @@ static int exynos_adc_probe(struct platform_device *pdev)
info = iio_priv(indio_dev);
+ info->data = exynos_adc_get_data(pdev);
+ if (!info->data) {
+ dev_err(&pdev->dev, "failed getting exynos_adc_data\n");
+ return -EINVAL;
+ }
+
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
info->regs = devm_ioremap_resource(&pdev->dev, mem);
if (IS_ERR(info->regs))
@@ -319,10 +401,6 @@ static int exynos_adc_probe(struct platform_device *pdev)
if (ret)
goto err_disable_reg;
- writel(1, info->enable_reg);
-
- info->version = exynos_adc_get_version(pdev);
-
platform_set_drvdata(pdev, indio_dev);
indio_dev->name = dev_name(&pdev->dev);
@@ -331,11 +409,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
indio_dev->info = &exynos_adc_iio_info;
indio_dev->modes = INDIO_DIRECT_MODE;
indio_dev->channels = exynos_adc_iio_channels;
-
- if (info->version == ADC_V1)
- indio_dev->num_channels = MAX_ADC_V1_CHANNELS;
- else
- indio_dev->num_channels = MAX_ADC_V2_CHANNELS;
+ indio_dev->num_channels = info->data->num_channels;
ret = request_irq(info->irq, exynos_adc_isr,
0, dev_name(&pdev->dev), info);
@@ -349,7 +423,8 @@ static int exynos_adc_probe(struct platform_device *pdev)
if (ret)
goto err_irq;
- exynos_adc_hw_init(info);
+ if (info->data->init_hw)
+ info->data->init_hw(info);
ret = of_platform_populate(np, exynos_adc_match, NULL, &indio_dev->dev);
if (ret < 0) {
@@ -366,7 +441,8 @@ err_of_populate:
err_irq:
free_irq(info->irq, info);
err_disable_clk:
- writel(0, info->enable_reg);
+ if (info->data->exit_hw)
+ info->data->exit_hw(info);
clk_disable_unprepare(info->clk);
err_disable_reg:
regulator_disable(info->vdd);
@@ -382,7 +458,8 @@ static int exynos_adc_remove(struct platform_device *pdev)
exynos_adc_remove_devices);
iio_device_unregister(indio_dev);
free_irq(info->irq, info);
- writel(0, info->enable_reg);
+ if (info->data->exit_hw)
+ info->data->exit_hw(info);
clk_disable_unprepare(info->clk);
regulator_disable(info->vdd);
@@ -394,19 +471,10 @@ static int exynos_adc_suspend(struct device *dev)
{
struct iio_dev *indio_dev = dev_get_drvdata(dev);
struct exynos_adc *info = iio_priv(indio_dev);
- u32 con;
- if (info->version == ADC_V2) {
- con = readl(ADC_V2_CON1(info->regs));
- con &= ~ADC_CON_EN_START;
- writel(con, ADC_V2_CON1(info->regs));
- } else {
- con = readl(ADC_V1_CON(info->regs));
- con |= ADC_V1_CON_STANDBY;
- writel(con, ADC_V1_CON(info->regs));
- }
+ if (info->data->exit_hw)
+ info->data->exit_hw(info);
- writel(0, info->enable_reg);
clk_disable_unprepare(info->clk);
regulator_disable(info->vdd);
@@ -427,8 +495,8 @@ static int exynos_adc_resume(struct device *dev)
if (ret)
return ret;
- writel(1, info->enable_reg);
- exynos_adc_hw_init(info);
+ if (info->data->init_hw)
+ info->data->init_hw(info);
return 0;
}
--
1.8.0
^ permalink raw reply related
* [PATCHv7 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean
From: Chanwoo Choi @ 2014-07-21 2:17 UTC (permalink / raw)
To: linux-arm-kernel
This patchset support Exynos3250 ADC (Analog Digital Converter) because
Exynos3250 has additional special clock for ADC IP.
Changes from v6:
- Use "exynos3250-adc" compatible string instead of "exynos3250-adc-v2"
- Use "sclk" clock name instead of "sclk_adc"
- Remove un-necessary macro for exyno-adc-data-v2 structure.
- Remove '(void *)' cast and mark the exynos-adc-data structure as 'const'
- Change the number of ADC channels (Exynos3250 has only two channels for ADC)
Changes from v5:
- Add acked message by Kukjin Kim
- Add reviewed messgae by Tomasz Figa
- Fix typo (for for -> for)
Changes from v4:
- Use 'exynos_adc_data' structure instead of 'exynos_adc_ops' structure
and remove enum variable of ADC version
- Fix wrong name of special clock (sclk_tsadc -> sclk_adc)
- Add reviewed message by Naveen Krishna Chatradhi
- Add functions for ADC clock control
Changes from v3:
- Add new 'exynos_adc_ops' structure to improve readability according to
Tomasz Figa comment[1]
[1] https://lkml.org/lkml/2014/4/16/238
- Add new 'exynos3250-adc-v2' compatible string to support Exynos3250 ADC
- Fix wrong compaitlbe string of ADC in Exynos3250 dtsi file
Changes from v2:
- Check return value of clock function to deal with error exception
- Fix minor coding style to improve readability
Changes from v1:
- Add new "samsung,exynos-adc-v3" compatible to support Exynos3250 ADC
- Add a patch about DT binding documentation
Chanwoo Choi (4):
iio: adc: exynos_adc: Add exynos_adc_data structure to improve
readability
iio: adc: exynos_adc: Control special clock of ADC to support
Exynos3250 ADC
iio: devicetree: Add DT binding documentation for Exynos3250 ADC
ARM: dts: Fix wrong compatible string for Exynos3250 ADC
.../devicetree/bindings/arm/samsung/exynos-adc.txt | 25 +-
arch/arm/boot/dts/exynos3250.dtsi | 4 +-
drivers/iio/adc/exynos_adc.c | 335 +++++++++++++++------
3 files changed, 274 insertions(+), 90 deletions(-)
--
1.8.0
^ permalink raw reply
* [PATCH 1/2] PCI: spear: Fix Section mismatch compilation warning for probe()
From: Rob Herring @ 2014-07-21 2:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpokOJLKOwB_rKz0W-1T0nYX7-2_8nm3wQr6khR55x4gqrA@mail.gmail.com>
On Sun, Jul 20, 2014 at 7:12 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 21 July 2014 00:56, Olof Johansson <olof@lixom.net> wrote:
>> Please use 12 significant digits, since 7 might not be sufficient later
>> on in time. I've fixed it up here.
>
> I surely didn't knew this and haven't seen other maintainers do this
> as well.. And thought, whatever "git log --online" gives would be
> enough.
The Fixes tag is new and the format is documented in SubmittingPatches
IIRC. I believe it is also supposed to be quotes rather than
parentheses around the commit message if we want to be really picky.
Rob
^ permalink raw reply
* FEC driver hangs hardware on i.MX6SX
From: fugang.duan at freescale.com @ 2014-07-21 2:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721015915.GG8537@dragon>
From: Shawn Guo <shawn.guo@freescale.com> Data: Monday, July 21, 2014 9:59 AM
>To: Richard Cochran
>Cc: Duan Fugang-B38611; linux-arm-kernel at lists.infradead.org;
>netdev at vger.kernel.org; Li Frank-B20596; David S. Miller
>Subject: Re: FEC driver hangs hardware on i.MX6SX
>
>On Sun, Jul 20, 2014 at 08:20:49AM +0200, Richard Cochran wrote:
>> On Sun, Jul 20, 2014 at 10:57:33AM +0800, Shawn Guo wrote:
>> >
>> > I think the cause is that PTP is still accessing registers after FEC
>> > driver calls fec_enet_clk_enable(ndev, false) to disable FEC clocks.
>> > Can you please try to provide a fix for this regression soon?
>>
>> What do you mean by, "PTP is still accessing registers"?
>>
>> The only access to any register is through the driver, and the driver
>> can and should make sure all register accesses are safe.
>
>Sorry for being vague, Richard. I meant PTP driver is still accessing
>registers.
>
>With Fugang's clock management patch, FEC clocks will be disabled to save
>power after FEC gets probed. But at that point, fec_ptp driver already
>launches a timer, which will trigger the read on FEC ATIME register once
>per second.
>
>Shawn
Yes, why does it cause at imx6sx platform ?
Because imx5x, imx6q/dl/sl enet register access don't cause system hang when clock is disab led, just return one error value that is zero.
But for imx6sx, if there disable enet ipg clock, and access register, which cause system hang.
For clock management patch itself, there have no any problem.
Just ptp driver has one issue which think clock is always on.
I submit one patch to fix the ptp issue.
Thanks,
Andy
^ permalink raw reply
* FEC driver hangs hardware on i.MX6SX
From: Shawn Guo @ 2014-07-21 1:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140720062048.GB5686@netboy>
On Sun, Jul 20, 2014 at 08:20:49AM +0200, Richard Cochran wrote:
> On Sun, Jul 20, 2014 at 10:57:33AM +0800, Shawn Guo wrote:
> >
> > I think the cause is that PTP is still accessing registers after FEC
> > driver calls fec_enet_clk_enable(ndev, false) to disable FEC clocks.
> > Can you please try to provide a fix for this regression soon?
>
> What do you mean by, "PTP is still accessing registers"?
>
> The only access to any register is through the driver, and the driver
> can and should make sure all register accesses are safe.
Sorry for being vague, Richard. I meant PTP driver is still accessing
registers.
With Fugang's clock management patch, FEC clocks will be disabled to
save power after FEC gets probed. But at that point, fec_ptp driver
already launches a timer, which will trigger the read on FEC ATIME
register once per second.
Shawn
^ permalink raw reply
* Issue found in Armada 370: "No buffer space available" error during continuous ping
From: Maggie Mae Roxas @ 2014-07-21 1:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717081527.GJ14723@1wt.eu>
Hi Willy, Thomas,
Good day.
> I'll try this one, specifcally this combination:
> - use 3.13.9 mvneta.c
> - apply cd71e246c16b30e3f396a85943d5f596202737ba
> - revert 4f3a4f701b59a3e4b5c8503ac3d905c0a326f922
This is to confirm that "No buffer space available" issue is resolved
after I applied above combinations in in v3.13.9.
Thanks a lot for the help!
BTW, sorry for the late update - all our connections, electricity and
stuff are unstable for the past week due to typhoon and we only got
everything working just today.
Thank you again for attending to our reports.
Regards,
Maggie Roxas
On Thu, Jul 17, 2014 at 1:15 AM, Willy Tarreau <w@1wt.eu> wrote:
> Hi Maggie,
>
> On Wed, Jul 16, 2014 at 10:37:47PM -0700, Maggie Mae Roxas wrote:
>> Hi Thomas, Willy,
>> Good day.
>>
>> First of all, thanks again for looking further into this.
>>
>> > Maggie, do you know if it is possible that for any reason your board
>> > would not deliver an IRQ on Tx completion ? That could explain things.
>>
>> I'm sorrry but I'm not really sure how to check this - all I know is
>> that the difference in the working and not-working setup (both
>> software and hardware) is the mvneta.c.
>
> In fact I don't know if you're running your own board or a "standard"
> one (a mirabox or any NAS board). Because that could also be one of the
> differences between what you observe on your side and our respective
> experiences with our boards.
>
>> > You can easily test reverting commit 4f3a4f701b just in case. If that's
>> > the case, then the next step will be to figure out how it is possible
>> > that IRQs are disabled!
>> I'll try this one, specifcally this combination:
>> - use 3.13.9 mvneta.c
>> - apply cd71e246c16b30e3f396a85943d5f596202737ba
>> - revert 4f3a4f701b59a3e4b5c8503ac3d905c0a326f922
>>
>> I will update you the results within today until latest tomorrow.
>
> OK fine, thank you!
>
> Willy
>
^ permalink raw reply
* [PATCHv6 3/4] iio: devicetree: Add DT binding documentation for Exynos3250 ADC
From: Chanwoo Choi @ 2014-07-21 1:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5381273.c6GzlyQ7Ea@wuerfel>
On 07/19/2014 03:48 AM, Arnd Bergmann wrote:
> On Saturday 19 July 2014 02:02:09 Chanwoo Choi wrote:
>> On Sat, Jul 19, 2014 at 1:33 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Saturday 19 July 2014 01:23:15 Chanwoo Choi wrote:
>>>> If don't add new compatible including specific exynos version,
>>>> I would add new 'adc-needs-sclk' property with existing 'exynos-adc-v2'
>>>> compatible name.
>
> What I actually meant is using compatible="exynos-adc-v2.1" or similar
> rather than "exynos3250-adc". However, as you already explained, the
> version numbers are apparently just made up, so using "exynos3250-adc"
> is actually better here. If a future exynos7890 uses the same clocks
> as exynos3250, it can simply use the same "exynos3250-adc" string here.
OK, I'll use "exynos3250-adc" compatible string instead of "exynos3250-adc-v2".
>
>>>> Dear Naveen, Tomasz,
>>>>
>>>> If existing exynos-adc driver add just one property for 'sclk_adc'
>>>> as following, exynos-adc could not include the exynos version
>>>> in compatible name.
>>>>
>>>> I need your opinion about it.
>>>>
>>>> adc: adc at 126C0000 {
>>>> compatible = "samsung,exynos-adc-v2";
>>>> reg = <0x126C0000 0x100>, <0x10020718 0x4>;
>>>> interrupts = <0 137 0>;
>>>> clock-names = "adc", "sclk_adc";
>>>> clocks = <&cmu CLK_TSADC>, <&cmu CLK_SCLK_TSADC>;
>>>> + adc-needs-sclk;
>>>> #io-channel-cells = <1>;
>>>> io-channel-ranges;
>>>> }
>>>
>>> How about just making it an optional clock? That would be much
>>> easier because then you can simply see if the clock itself is
>>> there and use it, or otherwise ignore it.
>>
>> The v1 of this patchset[1] got the clock of 'sclk_adc' but if the dt node
>> of ADC in dtsi file didn't include 'sclk_adc', print just warning message
>> without stopping probe as following:
>>
>> [1] https://lkml.org/lkml/2014/4/10/710
>>
>> + info->sclk = devm_clk_get(&pdev->dev, "sclk_adc");
>> + if (IS_ERR(info->sclk)) {
>> + dev_warn(&pdev->dev, "failed getting sclk clock, err = %ld\n",
>> + PTR_ERR(info->sclk));
>> + info->sclk = NULL;
>> + }
>>
>> But, Tomasz Figa suggested the method[2] of this patchset(v6).
>> [2] https://lkml.org/lkml/2014/4/11/189
>
> Yes, your current version is certainly better than this, but another way
> to address Tomasz' comment would be to change the binding to list the "sclk"
> as optional for any device and make the code silently ignore missing sclk
> entries, like:
>
>
> info->sclk = devm_clk_get(&pdev->dev, "sclk");
> if (IS_ERR(info->sclk)) {
> switch (PTR_ERR(info->sclk)) {
> case -EPROBE_DEFER:
> /* silently return error so we can retry */
> return -EPROBE_DEFER:
> case -ENOENT:
> /* silently ignore missing optional clk */
> info->sclk = NULL;
> break;
> default:
> /* any other error: clk is defined by doesn't work */
> dev_err(&pdev->dev, "failed getting sclk clock, err = %ld\n",
> PTR_ERR(info->sclk));
> return PTR_ERR(info->sclk));
> }
> }
I tested this patch suggested by you.
But, devm_clk_get returns always '-ENOENT' on follwong two cases:
Case 1.
ADC dt node in exynos3250.dtsi don't include 'sclk' clock as following:
adc: adc at 126C0000 {
compatible = "samsung,exynos3250-adc";
reg = <0x126C0000 0x100>, <0x10020718 0x4>;
interrupts = <0 137 0>;
clock-names = "adc";
clocks = <&cmu CLK_TSADC>;
#io-channel-cells = <1>;
io-channel-ranges;
};
Case 2.
ADC dt node in exynos3250.dtsi don't include 'sclk' clock
but, exynos3250 clock controller don't support CLK_SCLK_TSADC clock as following:
adc: adc at 126C0000 {
compatible = "samsung,exynos3250-adc";
reg = <0x126C0000 0x100>, <0x10020718 0x4>;
interrupts = <0 137 0>;
clock-names = "adc", "sclk";
clocks = <&cmu CLK_TSADC>, <&cmu CLK_SCLK_TSADC>;
#io-channel-cells = <1>;
io-channel-ranges;
};
So, I think exynos-adc needs to use 'needs_sclk' field suggested by Tomasz Figa.
>
> One more comment about the name: Both in the code you use "sclk" as the
> name, so presumably that is the actual name of the clk as known to this
> driver, and it makes sense to use clock-names="sclk" as well, if you want
> to have any name.
OK, I'll use 'sclk' clock name for special clock of ADC.
Thanks,
Chanwoo Choi
^ permalink raw reply
* [PATCH v6 4/5] PCI: add PCI controller for keystone PCIe h/w
From: Jingoo Han @ 2014-07-21 1:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C9839C.5090604@ti.com>
On Saturday, July 19, 2014 5:29 AM, Murali Karicheri wrote:
> On 07/18/2014 03:31 PM, Rob Herring wrote:
> > On Fri, Jul 18, 2014 at 10:14 AM, Murali Karicheri<m-karicheri2@ti.com> wrote:
> --- Cut ---
> >> +
> >> +Optional properties:-
> >> + phys: phandle to Generic Keystone SerDes phy for PCI
> >> + phy-names: name of the Generic Keystine SerDes phy for PCI
> >> + - If boot loader already does PCI link establishment, then phys and
> >> + phy-names shouldn't be present.
> >> + ti,enable-linktrain - Enable Link training.
> >> + - If boot loader already does PCI link establishment, then this
> >> + shouldn't be present.
> >
> > Can't you read from the h/w if the link is trained?
I agree with Rob Herring's suggestion.
>
> Yes.
>
> There are customers who use this driver with PCI Link setup done in the
> boot loader. This property tells the driver to bypass Link setup
> procedure in that case. Is this undesirable and if so. how other
> platforms handle it? Check first if link is trained or start the link
> setup procedure? Let me know. If this is fine, please provide your Ack.
Please, check the following code of Exynos PCIe diver.
./drivers/pci/host/pci-exynos.c
static int exynos_pcie_establish_link(struct pcie_port *pp)
{
struct exynos_pcie *exynos_pcie = to_exynos_pcie(pp);
void __iomem *elbi_base = exynos_pcie->elbi_base;
void __iomem *pmu_base = exynos_pcie->pmu_base;
if (dw_pcie_link_up(pp)) {
dev_err(pp->dev, "Link already up\n");
return 0;
}
.....
In the case of Exynos PCIe, the Exynos PCIe driver checks the
h/w bit such as PCIE_ELBI_LTSSM_ENABLE bit of PCIE_ELBI_RDLH_LINKUP
offset register.
If the link is already set up by the boot loader or other reasons,
the driver will skip some initialization codes.
The first step is that you find such h/w bit for checking link up.
If so, please add the code for skipping, when the link is already
set up.
Best regards,
Jingoo Han
^ permalink raw reply
* linux-next: manual merge of the samsung tree with the arm-soc tree
From: Stephen Rothwell @ 2014-07-21 1:13 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kukjin,
Today's linux-next merge of the samsung tree got a conflict in
arch/arm/mach-exynos/pm.c between commit 7310d99ffcd1 ("ARM: EXYNOS:
Fix build breakge with PM_SLEEP=n") from the arm-soc tree and commit
66df3ce29804 ("ARM: EXYNOS: Refactored code for using PMU address via
DT") from the samsung tree.
I fixed it up (the code modified by the latter was moved by the former,
so I applied the following patch to the new file) and can carry the fix
as necessary (no action is required).
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 21 Jul 2014 11:11:17 +1000
Subject: [PATCH] ARM: EXYNOS: fixup for code movement
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/arm/mach-exynos/platsmp.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 8b66a9e02b87..1e43b53d23b7 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -43,7 +43,7 @@ extern void exynos4_secondary_startup(void);
*/
void exynos_cpu_power_down(int cpu)
{
- __raw_writel(0, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
+ pmu_raw_writel(0, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
}
/**
@@ -54,8 +54,8 @@ void exynos_cpu_power_down(int cpu)
*/
void exynos_cpu_power_up(int cpu)
{
- __raw_writel(S5P_CORE_LOCAL_PWR_EN,
- EXYNOS_ARM_CORE_CONFIGURATION(cpu));
+ pmu_raw_writel(S5P_CORE_LOCAL_PWR_EN,
+ EXYNOS_ARM_CORE_CONFIGURATION(cpu));
}
/**
@@ -65,7 +65,7 @@ void exynos_cpu_power_up(int cpu)
*/
int exynos_cpu_power_state(int cpu)
{
- return (__raw_readl(EXYNOS_ARM_CORE_STATUS(cpu)) &
+ return (pmu_raw_readl(EXYNOS_ARM_CORE_STATUS(cpu)) &
S5P_CORE_LOCAL_PWR_EN);
}
@@ -75,7 +75,7 @@ int exynos_cpu_power_state(int cpu)
*/
void exynos_cluster_power_down(int cluster)
{
- __raw_writel(0, EXYNOS_COMMON_CONFIGURATION(cluster));
+ pmu_raw_writel(0, EXYNOS_COMMON_CONFIGURATION(cluster));
}
/**
@@ -84,8 +84,8 @@ void exynos_cluster_power_down(int cluster)
*/
void exynos_cluster_power_up(int cluster)
{
- __raw_writel(S5P_CORE_LOCAL_PWR_EN,
- EXYNOS_COMMON_CONFIGURATION(cluster));
+ pmu_raw_writel(S5P_CORE_LOCAL_PWR_EN,
+ EXYNOS_COMMON_CONFIGURATION(cluster));
}
/**
@@ -95,7 +95,7 @@ void exynos_cluster_power_up(int cluster)
*/
int exynos_cluster_power_state(int cluster)
{
- return (__raw_readl(EXYNOS_COMMON_STATUS(cluster)) &
+ return (pmu_raw_readl(EXYNOS_COMMON_STATUS(cluster)) &
S5P_CORE_LOCAL_PWR_EN);
}
--
2.0.1
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140721/733fad21/attachment.sig>
^ permalink raw reply related
* [PATCH 1/2] PCI: spear: Fix Section mismatch compilation warning for probe()
From: Viresh Kumar @ 2014-07-21 0:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMi0HgL14zMqALvqT_cGMr13mGSN0O493eLmydt8Dscqug@mail.gmail.com>
On 21 July 2014 05:51, Olof Johansson <olof@lixom.net> wrote:
> Oh, sorry, I got distracted by my kid waking up so the email was a bit short. :)
I can understand, mine is 14 months :)
> The easiest way of doing it is to switch to 12 by default. In your .gitconfig:
>
> [core]
> abbrev = 12
Oh, that will be extremely useful. Thanks.
^ permalink raw reply
* [PATCH 1/2] PCI: spear: Fix Section mismatch compilation warning for probe()
From: Olof Johansson @ 2014-07-21 0:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpokOJLKOwB_rKz0W-1T0nYX7-2_8nm3wQr6khR55x4gqrA@mail.gmail.com>
On Sun, Jul 20, 2014 at 5:12 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 21 July 2014 00:56, Olof Johansson <olof@lixom.net> wrote:
>> Please use 12 significant digits, since 7 might not be sufficient later
>> on in time. I've fixed it up here.
>
> I surely didn't knew this and haven't seen other maintainers do this
> as well.. And thought, whatever "git log --online" gives would be
> enough.
>
> Will take care of this in future.
Oh, sorry, I got distracted by my kid waking up so the email was a bit short. :)
The easiest way of doing it is to switch to 12 by default. In your .gitconfig:
[core]
abbrev = 12
-Olof
^ permalink raw reply
* [PATCH 1/2] PCI: spear: Fix Section mismatch compilation warning for probe()
From: Viresh Kumar @ 2014-07-21 0:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140720192649.GA30124@quad.lixom.net>
On 21 July 2014 00:56, Olof Johansson <olof@lixom.net> wrote:
> Please use 12 significant digits, since 7 might not be sufficient later
> on in time. I've fixed it up here.
I surely didn't knew this and haven't seen other maintainers do this
as well.. And thought, whatever "git log --online" gives would be
enough.
Will take care of this in future.
^ permalink raw reply
* [PATCH 2/2] iio: exynos-adc: add experimental touchscreen support
From: Hartmut Knaack @ 2014-07-20 21:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CBC8D6.6020509@kernel.org>
Jonathan Cameron schrieb:
> On 18/07/14 20:29, Arnd Bergmann wrote:
>> This adds support for the touchscreen on Samsung s3c64xx.
>> The driver is completely untested but shows roughly how
>> it could be done, following the example of the at91 driver.
>>
> Hi Arnd,
>
>> Open questions include:
>>
>> - compared to the old plat-samsung/adc driver, there is
>> no support for prioritizing ts over other clients, nor
>> for oversampling. From my reading of the code, the
>> priorities didn't actually have any effect at all, but
>> the oversampling might be needed. Maybe the original
>> authors have some insight.
>>
>> - I simply register the input device from the adc driver
>> itself, as the at91 code does. The driver also supports
>> sub-nodes, but I don't understand how they are meant
>> to be used, so using those might be better.
> So, the alternative you are (I think) referring to is to use
> the buffered in kernel client interface. That way a separate
> touch screen driver can use the output channels provided by IIO
> in much the same way you might use a regulator or similar.
> Note that whilst this is similar to the simple polled interface
> used for things like the iio_hwmon driver, the data flow is
> quite different (clearly the polled interfce would be
> inappropriate here).
>
> Whilst we've discussed it in the past for touch screen drivers
> like this, usually the hardware isn't generic enough to be
> of any real use if not being used as a touch screen. As such
> it's often simpler to just have the support directly in the
> driver (as you've observed the at91 driver does this).
>
> Whilst the interface has been there a while, it's not really had
> all that much use. The original target was the simpler case
> of 3D accelerometer where we have a generic iio to input
> bridge driver. Time constraints meant that I haven't yet actually
> formally submitted the input side of this. Whilst there are lots
> of other things that can use this interface, right now nothing
> actually does so.
>
>> - The new exynos_read_s3c64xx_ts() function is intentionally
>> very similar to the existing exynos_read_raw() functions.
>> It should probably be changed, either by merging the two
>> into one, or by simplifying the exynos_read_s3c64xx_ts()
>> function. This depends a bit on the answers to the questions
>> above.
> I'd be tempted to not bother keeping them that similar. It's
> not a generic IIO channel so simplify it where possible.
>> - We probably need to add support for platform_data as well,
>> I've skipped this so far.
>>
>> - Is anybody able to debug this driver on real hardware?
>> While it's possible that it actually works, it's more
>> likely that I made a few subtle mistakes.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Looks pretty good to me. A few symantic bits and pieces and
> one bug spotted. Short and sweet.
>> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>> index e1b74828f413..4329bf3c3326 100644
>> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>> @@ -41,6 +41,10 @@ Required properties:
>> and compatible ADC block)
>> - vdd-supply VDD input supply.
>>
>> +Optional properties:
>> +- has-touchscreen: If present, indicates that a touchscreen is
>> + connected an usable.
>> +
>> Note: child nodes can be added for auto probing from device tree.
>>
>> Example: adding device info in dtsi file
>> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
>> index 5f95638513d2..cf1d9f3e2492 100644
>> --- a/drivers/iio/adc/exynos_adc.c
>> +++ b/drivers/iio/adc/exynos_adc.c
>> @@ -34,6 +34,7 @@
>> #include <linux/regulator/consumer.h>
>> #include <linux/of_platform.h>
>> #include <linux/err.h>
>> +#include <linux/input.h>
> Might want to make the input side optional at compile time...
> I supose the existing parts are unlikely to be used much in headless
> devices, but you never know. Maybe we just leave this until someone
> shouts they want to be able to avoid compiling it in.
>> #include <linux/iio/iio.h>
>> #include <linux/iio/machine.h>
>> @@ -103,6 +104,7 @@
>>
>> /* Bit definitions common for ADC_V1 and ADC_V2 */
>> #define ADC_CON_EN_START (1u << 0)
>> +#define ADC_DATX_PRESSED (1u << 15)
>> #define ADC_DATX_MASK 0xFFF
>>
>> #define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
>> @@ -110,16 +112,20 @@
>> struct exynos_adc {
>> struct exynos_adc_data *data;
>> struct device *dev;
>> + struct input_dev *input;
>> void __iomem *regs;
>> void __iomem *enable_reg;
>> struct clk *clk;
>> struct clk *sclk;
>> unsigned int irq;
>> + unsigned int tsirq;
>> struct regulator *vdd;
>>
>> struct completion completion;
>>
>> + bool read_ts;
>> u32 value;
>> + u32 value2;
> As I state further down, I'd rather keep a little
> clear of the naming used in IIO for bits that aren't
> going through IIO (less confusing!). Maybe just
> have
> u32 x, y;
>> unsigned int version;
>> };
>>
>> @@ -390,12 +396,61 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
>> return ret;
>> }
>>
>> +static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev,
>> + struct iio_chan_spec const *chan,
>> + int *val,
>> + int *val2,
>> + long mask)
>> +{
>> + struct exynos_adc *info = iio_priv(indio_dev);
>> + unsigned long timeout;
>> + int ret;
>> +
>> + if (mask != IIO_CHAN_INFO_RAW)
>> + return -EINVAL;
>> +
>> + mutex_lock(&indio_dev->mlock);
>> + info->read_ts = 1;
Since info->read_ts is of type bool, use true/false.
>> +
>> + reinit_completion(&info->completion);
>> +
>> + writel(ADC_S3C2410_TSC_PULL_UP_DISABLE | ADC_TSC_AUTOPST,
>> + ADC_V1_TSC(info->regs));
>> +
>> + /* Select the ts channel to be used and Trigger conversion */
>> + info->data->start_conv(info, 0);
> 0 is a rather magic value. A define perhaps?
>> +
>> + timeout = wait_for_completion_timeout
>> + (&info->completion, EXYNOS_ADC_TIMEOUT);
>> + if (timeout == 0) {
>> + dev_warn(&indio_dev->dev, "Conversion timed out! Resetting\n");
>> + if (info->data->init_hw)
>> + info->data->init_hw(info);
>> + ret = -ETIMEDOUT;
>> + } else {
>> + *val = info->value;
>> + *val2 = info->value2;
> This is definitely abuse as those two values are not intended for
> different values. If you want to do this please use different naming
> and don't try to fiddle it into the IIO read raw framework.
> As you've suggested above, better to simplify this code and drop the
> bits cloned from the other handler.
>> + ret = IIO_VAL_INT;
>> + }
>> +
>> + info->read_ts = 0;
>> + mutex_unlock(&indio_dev->mlock);
>> +
>> + return ret;
>> +}
>> +
>> static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
>> {
>> struct exynos_adc *info = (struct exynos_adc *)dev_id;
>>
>> /* Read value */
>> - info->value = readl(ADC_V1_DATX(info->regs)) & ADC_DATX_MASK;
>> + if (info->read_ts) {
>> + info->value = readl(ADC_V1_DATX(info->regs)) & ADC_DATX_MASK;
>> + info->value2 = readl(ADC_V1_DATY(info->regs)) & ADC_DATX_MASK;
> ADC_DATY_MASK would be more obviously correct.
>
>> + writel(ADC_TSC_WAIT4INT | ADC_S3C2443_TSC_UD_SEN, ADC_V1_TSC(info->regs));
> Perhaps the above is cryptic enough to warrant a comment?
>> + } else {
>> + info->value = readl(ADC_V1_DATX(info->regs)) & ADC_DATX_MASK;
>> + }
>>
>> /* clear irq */
>> if (info->data->clear_irq)
>> @@ -406,6 +461,46 @@ static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
>> return IRQ_HANDLED;
>> }
>>
>> +/*
>> + * Here we (ab)use a threaded interrupt handler to stay running
>> + * for as long as the touchscreen remains pressed, we report
>> + * a new event with the latest data and then sleep until the
>> + * next timer tick. This mirrors the behavior of the old
>> + * driver, with much less code.
>> + */
>> +static irqreturn_t exynos_ts_isr(int irq, void *dev_id)
>> +{
>> + struct exynos_adc *info = dev_id;
>> + struct iio_dev *dev = dev_get_drvdata(info->dev);
>> + u32 x, y;
>> + bool pressed;
>> + int ret;
>> +
>> + do {
>> + ret =exynos_read_s3c64xx_ts(dev, NULL, &x, &y, IIO_CHAN_INFO_RAW);
> = exynos
>> + if (ret == -ETIMEDOUT)
>> + break;
>> +
>> + pressed = x & y & ADC_DATX_PRESSED;
>> + if (!pressed)
>> + break;
>> +
>> + input_report_abs(info->input, ABS_X, x & ADC_DATX_MASK);
>> + input_report_abs(info->input, ABS_Y, y & ADC_DATX_MASK);
>> + input_report_key(info->input, BTN_TOUCH, 1);
>> + input_sync(info->input);
>> +
>> + msleep(1);
>> + } while (1);
>> +
>> + input_report_key(info->input, BTN_TOUCH, 0);
>> + input_sync(info->input);
>> +
>> + writel(0, ADC_V1_CLRINTPNDNUP(info->regs));
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> static int exynos_adc_reg_access(struct iio_dev *indio_dev,
>> unsigned reg, unsigned writeval,
>> unsigned *readval)
>> @@ -457,12 +552,57 @@ static int exynos_adc_remove_devices(struct device *dev, void *c)
>> return 0;
>> }
>>
>> +static int exynos_adc_ts_init(struct exynos_adc *info)
>> +{
>> + int ret;
>> +
>> + info->input = input_allocate_device();
>> + if (!info->input)
>> + return -ENOMEM;
>> +
>> + info->input->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
>> + info->input->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
>> +
>> + input_set_abs_params(info->input, ABS_X, 0, 0x3FF, 0, 0);
>> + input_set_abs_params(info->input, ABS_Y, 0, 0x3FF, 0, 0);
>> +
>> + /* data from s3c2410_ts driver */
>> + info->input->name = "S3C24xx TouchScreen";
>> + info->input->id.bustype = BUS_HOST;
>> + info->input->id.vendor = 0xDEAD;
>> + info->input->id.product = 0xBEEF;
>> + info->input->id.version = 0x0200;
>> +
>> + ret = input_register_device(info->input);
>> + if (ret) {
>> + input_free_device(info->input);
>> + goto err;
Just return ret, without goto (and get rid of label err).
>> + }
>> +
>> + if (info->tsirq > 0)
>> + ret = request_threaded_irq(info->irq, NULL, exynos_ts_isr,
>> + 0, "touchscreen", info);
> info->tsirq
> (that had me really confused for a moment ;)
> Also, perhaps a more specific name. touchscreen_updown or similar as the
> main interrupt is also used during touchscreen operation.
>> + if (ret < 0) {
>> + dev_err(info->dev, "failed requesting touchsccreen irq, irq = %d\n",
>> + info->irq);
>> + goto err_input;
>> + }
>> +
>> + return 0;
>> +
Probably better to get rid of the labels and move the code up, as it is only used once.
>> +err_input:
>> + input_unregister_device(info->input);
>> +err:
>> + return ret;
>> +}
>> +
>> static int exynos_adc_probe(struct platform_device *pdev)
>> {
>> struct exynos_adc *info = NULL;
>> struct device_node *np = pdev->dev.of_node;
>> struct iio_dev *indio_dev = NULL;
>> struct resource *mem;
>> + bool has_ts;
>> int ret = -ENODEV;
>> int irq;
>>
>> @@ -498,8 +638,14 @@ static int exynos_adc_probe(struct platform_device *pdev)
>> dev_err(&pdev->dev, "no irq resource?\n");
>> return irq;
>> }
>> -
>> info->irq = irq;
>> +
>> + irq = platform_get_irq(pdev, 1);
>> + if (irq == -EPROBE_DEFER)
>> + return irq;
What about other possible error codes?
>> +
>> + info->tsirq = irq;
>> +
>> info->dev = &pdev->dev;
>>
>> init_completion(&info->completion);
>> @@ -565,6 +711,12 @@ static int exynos_adc_probe(struct platform_device *pdev)
>> if (info->data->init_hw)
>> info->data->init_hw(info);
>>
>> + has_ts = of_property_read_bool(pdev->dev.of_node, "has-touchscreen");
>> + if (has_ts)
>> + ret = exynos_adc_ts_init(info);
>> + if (ret)
>> + goto err_iio;
>> +
>> ret = of_platform_populate(np, exynos_adc_match, NULL, &indio_dev->dev);
>> if (ret < 0) {
>> dev_err(&pdev->dev, "failed adding child nodes\n");
>> @@ -576,6 +728,11 @@ static int exynos_adc_probe(struct platform_device *pdev)
>> err_of_populate:
>> device_for_each_child(&indio_dev->dev, NULL,
>> exynos_adc_remove_devices);
>> + if (has_ts) {
>> + input_unregister_device(info->input);
>> + free_irq(info->tsirq, info);
>> + }
>> +err_iio:
>> iio_device_unregister(indio_dev);
>> err_irq:
>> free_irq(info->irq, info);
>> @@ -595,9 +752,12 @@ static int exynos_adc_remove(struct platform_device *pdev)
>> struct iio_dev *indio_dev = platform_get_drvdata(pdev);
>> struct exynos_adc *info = iio_priv(indio_dev);
>>
>> + input_free_device(info->input);
>> device_for_each_child(&indio_dev->dev, NULL,
>> exynos_adc_remove_devices);
>> iio_device_unregister(indio_dev);
>> + if (info->tsirq > 0)
>> + free_irq(info->tsirq, info);
>> free_irq(info->irq, info);
>> if (info->data->exit_hw)
>> info->data->exit_hw(info);
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox