* [PATCH] ARM: sun8i: sina33: Enable USB gadget
From: Maxime Ripard @ 2016-11-04 14:44 UTC (permalink / raw)
To: linux-arm-kernel
The micro-USB on the SinA33 has a somewhat interesting design in the sense
that it has a micro USB connector, but the VBUS is (supposed to be)
controlled through an (unpopulated) jumper.
Obviously, that doesn't work really well, and only the peripheral mode
really works. Still enable it.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index fa8024072025..1c0d98cbd334 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -247,6 +247,11 @@
status = "okay";
};
+&usb_otg {
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
&usbphy {
status = "okay";
usb1_vbus-supply = <®_vcc5v0>; /* USB1 VBUS is always on */
--
2.10.1
^ permalink raw reply related
* [PATCH] simplefb: Separate clk / regulator get and enable steps
From: Hans de Goede @ 2016-11-04 14:45 UTC (permalink / raw)
To: linux-arm-kernel
Currently when a simplefb needs both clocks and regulators and one
of the regulators returns -EPROBE_DEFER when we try to get it, we end
up disabling the clocks. This causes the screen to go blank; and in some
cases my cause hardware state to be lost resulting in the framebuffer not
working at all.
This commit splits the get and enable steps and only enables
clocks and regulators after successfully getting all of them,
fixing the disabling of the clocks which were left enabled by
the firmware setting up the simplefb.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/video/fbdev/simplefb.c | 56 ++++++++++++++++++++++++++++++------------
1 file changed, 40 insertions(+), 16 deletions(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 61f799a..a3c44ec 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -180,10 +180,12 @@ static int simplefb_parse_pd(struct platform_device *pdev,
struct simplefb_par {
u32 palette[PSEUDO_PALETTE_SIZE];
#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
+ bool clks_enabled;
unsigned int clk_count;
struct clk **clks;
#endif
#if defined CONFIG_OF && defined CONFIG_REGULATOR
+ bool regulators_enabled;
u32 regulator_count;
struct regulator **regulators;
#endif
@@ -208,12 +210,12 @@ struct simplefb_par {
* the fb probe will not help us much either. So just complain and carry on,
* and hope that the user actually gets a working fb at the end of things.
*/
-static int simplefb_clocks_init(struct simplefb_par *par,
- struct platform_device *pdev)
+static int simplefb_clocks_get(struct simplefb_par *par,
+ struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct clk *clock;
- int i, ret;
+ int i;
if (dev_get_platdata(&pdev->dev) || !np)
return 0;
@@ -244,6 +246,14 @@ static int simplefb_clocks_init(struct simplefb_par *par,
par->clks[i] = clock;
}
+ return 0;
+}
+
+static void simplefb_clocks_enable(struct simplefb_par *par,
+ struct platform_device *pdev)
+{
+ int i, ret;
+
for (i = 0; i < par->clk_count; i++) {
if (par->clks[i]) {
ret = clk_prepare_enable(par->clks[i]);
@@ -256,8 +266,7 @@ static int simplefb_clocks_init(struct simplefb_par *par,
}
}
}
-
- return 0;
+ par->clks_enabled = true;
}
static void simplefb_clocks_destroy(struct simplefb_par *par)
@@ -269,7 +278,8 @@ static void simplefb_clocks_destroy(struct simplefb_par *par)
for (i = 0; i < par->clk_count; i++) {
if (par->clks[i]) {
- clk_disable_unprepare(par->clks[i]);
+ if (par->clks_enabled)
+ clk_disable_unprepare(par->clks[i]);
clk_put(par->clks[i]);
}
}
@@ -277,8 +287,10 @@ static void simplefb_clocks_destroy(struct simplefb_par *par)
kfree(par->clks);
}
#else
-static int simplefb_clocks_init(struct simplefb_par *par,
+static int simplefb_clocks_get(struct simplefb_par *par,
struct platform_device *pdev) { return 0; }
+static void simplefb_clocks_enable(struct simplefb_par *par,
+ struct platform_device *pdev) { }
static void simplefb_clocks_destroy(struct simplefb_par *par) { }
#endif
@@ -305,14 +317,14 @@ static void simplefb_clocks_destroy(struct simplefb_par *par) { }
* the fb probe will not help us much either. So just complain and carry on,
* and hope that the user actually gets a working fb at the end of things.
*/
-static int simplefb_regulators_init(struct simplefb_par *par,
- struct platform_device *pdev)
+static int simplefb_regulators_get(struct simplefb_par *par,
+ struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct property *prop;
struct regulator *regulator;
const char *p;
- int count = 0, i = 0, ret;
+ int count = 0, i = 0;
if (dev_get_platdata(&pdev->dev) || !np)
return 0;
@@ -354,6 +366,14 @@ static int simplefb_regulators_init(struct simplefb_par *par,
}
par->regulator_count = i;
+ return 0;
+}
+
+static void simplefb_regulators_enable(struct simplefb_par *par,
+ struct platform_device *pdev)
+{
+ int i, ret;
+
/* Enable all the regulators */
for (i = 0; i < par->regulator_count; i++) {
ret = regulator_enable(par->regulators[i]);
@@ -365,15 +385,14 @@ static int simplefb_regulators_init(struct simplefb_par *par,
par->regulators[i] = NULL;
}
}
-
- return 0;
+ par->regulators_enabled = true;
}
static void simplefb_regulators_destroy(struct simplefb_par *par)
{
int i;
- if (!par->regulators)
+ if (!par->regulators || !par->regulators_enabled)
return;
for (i = 0; i < par->regulator_count; i++)
@@ -381,8 +400,10 @@ static void simplefb_regulators_destroy(struct simplefb_par *par)
regulator_disable(par->regulators[i]);
}
#else
-static int simplefb_regulators_init(struct simplefb_par *par,
+static int simplefb_regulators_get(struct simplefb_par *par,
struct platform_device *pdev) { return 0; }
+static void simplefb_regulators_enable(struct simplefb_par *par,
+ struct platform_device *pdev) { }
static void simplefb_regulators_destroy(struct simplefb_par *par) { }
#endif
@@ -453,14 +474,17 @@ static int simplefb_probe(struct platform_device *pdev)
}
info->pseudo_palette = par->palette;
- ret = simplefb_clocks_init(par, pdev);
+ ret = simplefb_clocks_get(par, pdev);
if (ret < 0)
goto error_unmap;
- ret = simplefb_regulators_init(par, pdev);
+ ret = simplefb_regulators_get(par, pdev);
if (ret < 0)
goto error_clocks;
+ simplefb_clocks_enable(par, pdev);
+ simplefb_regulators_enable(par, pdev);
+
dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to 0x%p\n",
info->fix.smem_start, info->fix.smem_len,
info->screen_base);
--
2.9.3
^ permalink raw reply related
* [PATCHv6] support for AD5820 camera auto-focus coil
From: Tony Lindgren @ 2016-11-04 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104074533.GB3679@amd>
* Pavel Machek <pavel@ucw.cz> [161104 00:45]:
> Hi!
>
> > > > I have to admit I mostly use an N9.
> > >
> > > Well, if you compare that to development on PC, I prefer PC.
> > >
> > > Even arm development boards are usually easier, as they don't need too
> > > complex userspace, and do have working serial ports.
> > >
> > > But I do have a serial adapter for N900 now (thanks, sre), so my main
> > > problem now is that N900 takes a lot of time to boot into usable
> > > state.
> >
> > Yeah... I just upgraded my Debian installation (armel over NFS) a few major
> > numbers and I find it a lot slower than it used to do. I presume that's
> > mostly because of systemd...
>
> I'm not sure if systemd is to blame. (I'm booting into full GUI...)
>
> And yes, I noticed the slowdown in Debian 7 -> 8 transition, so I'm
> basically staying at Debian 7 as far as I can.
Maybe it's the armel vs armhf causing the slowdown?
Regards,
Tony
^ permalink raw reply
* [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
From: Tony Lindgren @ 2016-11-04 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104070955.GA3679@amd>
* Pavel Machek <pavel@ucw.cz> [161104 00:10]:
> On Thu 2016-11-03 22:00:56, Matt Ranostay wrote:
> Do you actually have hardware with more than one bq27xxx?
I can at least see the twl4030 battery/charger features
being used together with some bq device to monitor the
battery state. Not sure if that counts as multiple
instances here though :)
Regards,
Tony
^ permalink raw reply
* [PATCH 4/9] pinctrl: meson: allow gpio to request irq
From: Linus Walleij @ 2016-11-04 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477564941.2482.240.camel@baylibre.com>
On Thu, Oct 27, 2016 at 12:42 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> Ressource issue : When you create an irq mapping, in case of hierarchic
> domain, it calls the "alloc" function of the domain, which will
> eventually call the "alloc" function of the parent domain ... until you
> reach the "root" domain (here the gic).
(...)
> We are looking to create mapping "on-demand" to make the best use of
> the little number of interrupts we have. To catch request of drivers,
> like gpio-keys, which use gpio_to_irq, it looks the only viable place
> is the to_irq callback (at the moment).
>
> Drivers using gpio_to_irq in their probe function expect that this will
> give them the corresponding virq, so create the mapping if need be.
OK what I need to know is the following:
If this was not a gpio chip, just some random hierarchical irqchip
or mux from drivers/irqchip, where would you make the translation?
The answer to that question applies equally to any GPIO controller
that also provides an irqchip. .to_irq() is not the place to do the
translation.
I looked around and for example irq-s3c24xx.c seems to do this
in the irqdomain xlate() callback, which should only be called
when the interrupt is resolved for a consumer.
If that is the code that you partitioned over to drivers/irqchip,
then maybe this is a sign that this code should not be there
at all, but instead inside this gpiochip driver, or atleast accessible
by it so that your gpiochip driver has direct access to the
irqdomain it is using.
> However, I now get why you don't want that, it seems we have 2 types of
> platforms in the kernel right now:
>
> 1. The one creating the mapping in the to_irq callback. It might be
> because they just copy/paste from another driver doing it, or they may
> have a good reason for it (like I think we do)
>
> 2. the one which call gpio_to_irq in interrupt handlers. Honestly I did
> not know that one could that, but they are in the mainline too, and
> probably have a good reason for doing it.
They are probably all bad or legacy. None of this works with a
irqchip from DT like this:
foo: gpio at 0 {
#gpio-cells = <2>;
gpio-controller;
interrupt-cells = <2>;
interrupt-controller;
}
bar: bar at 1 {
interrupt-parent = <&foo>;
interrupt = <4>;
};
Here notice that bar is NOT doing gpios = <&foo 4>;
which is what you would do to get a GPIO and then call
.to_irq() on it. It just uses it as an interrupt controller.
This MUST work, or you cannot put interrupt-controller;
as a keyword on the gpiochip.
> irq_find_mapping looks safe in interrupt handler, I does not seem to
> sleep (please correct me if I'm wrong).
> irq_create_mapping definitely isn't, because of the irq_domain mutex.
Yep.
> We probably got into this situation because it wasn't clear enough
> whether to_irq was fast or slow (at least it took me a few mails to
> understand this ...)
I don't know either. It's just supposed to be a quick helper
to find the corresponding interrupt for a GPIO, it is not supposed
to have semantic side-effects.
> The two platform groups are most likely exclusive so nobody is sleeping
> in irq, everybody is happy. As a maintainer, I understand that you
> can't allow a dangerous situation like this to continue.
It's a mess allright. I need everyone's help to fix the mess.
> To fix the situation we could add a few things in the gpio subsys:
> - Make it clear that to_irq is fast (like you just did)
Sure patches accepted.
> - add a new callback (to_irq_slow ? provide_irq ? something else) which
> would be allowed to sleep and create mappings.
> - in gpio_to_irq function keeps calling to_irq like it does but also
> call to_irq_slow only if we are not in an interrupt context and a
> mapping could not be found. We could maybe use "in_interrupt()" for
> this ?
None of them should be allowed to create mappings because of the
explanation above: gpiochips and irqchips need to be
orthogonal.
> This way, we could keep the existing drivers working as they are (even
> if they are wrong) and slowly fix things up.
It doesn't seem to help with anything.
Instead go back to what I described above: if it was just
two irqchips: forget the fact that one of them is a GPIO chip
for a while, just two irqchips.
How does one irqchip map to another one?
That is what needs to happen, solely using the irqchip
infrastructure, NOT using .to_irq().
> Sorry, it was kind of long explanation but I hope things are more clear
> now.
I think I understand... famous last words.
>> I just misunderstand it as the global GPIO number, that is
>> not OK.
>
> Ok. Just to be clear, you are ok with the function
> "meson_gpio_to_hwirq" which just does this translation, right ?
That seems all right, the problem is relying on gpio_to_irq()
being called for the interrupts to work.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 10/13] ARM: dts: exynos: replace to "max-frequecy" instead of "clock-freq-min-max"
From: Krzysztof Kozlowski @ 2016-11-04 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4066252.a1W9ejEKHX@phil>
On Fri, Nov 04, 2016 at 12:19:49PM +0100, Heiko Stuebner wrote:
> Hi Jaehoon,
>
> Am Freitag, 4. November 2016, 19:21:30 CET schrieb Jaehoon Chung:
> > On 11/04/2016 03:41 AM, Krzysztof Kozlowski wrote:
> > > On Thu, Nov 03, 2016 at 03:21:32PM +0900, Jaehoon Chung wrote:
> > >> In drivers/mmc/core/host.c, there is "max-frequency" property.
> > >> It should be same behavior. So Use the "max-frequency" instead of
> > >> "clock-freq-min-max".
> > >>
> > >> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> > >> ---
> > >>
> > >> arch/arm/boot/dts/exynos3250-artik5-eval.dts | 2 +-
> > >> arch/arm/boot/dts/exynos3250-artik5.dtsi | 2 +-
> > >> arch/arm/boot/dts/exynos3250-monk.dts | 2 +-
> > >> arch/arm/boot/dts/exynos3250-rinato.dts | 2 +-
> > >> 4 files changed, 4 insertions(+), 4 deletions(-)
> > >
> > > This looks totally independent to rest of patches so it can be applied
> > > separately without any functional impact (except lack of minimum
> > > frequency). Is that correct?
> >
> > You're right. I will split the patches. And will resend.
> > Thanks!
>
> I think what Krzysztof was asking was just if he can simply pick up this patch
> alone, as it does not require any of the previous changes.
>
> Same is true for the Rockchip patches I guess, so we could just take them
> individually into samsung/rockchip dts branches.
Yes, I wanted to get exactly this information. I couldn't find it in
cover letter.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH V3 0/8] IOMMU probe deferral support
From: Sricharan @ 2016-11-04 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <421e2b14-0231-d376-02a0-097423120b3d@arm.com>
Hi Robin,
>>>Yikes, on second look, that definitely shouldn't be happening.
>>>Everything below is probably the resulting fallout.
>>
>>[ 40.206703] vfio-pci 0000:08:00.0: Failed to setup iommu ops
>>
>>I think the above print which says "failed to setup iommu_ops"
>>because the call ops->add_device failed in of_pci_iommu_configure
>>is the reason for the failure, in my case i simply do not get this even with
>>your scripts. ops->add_device succeeds in the rebind as well. So still
>>checking what could be happening in your case.
>
>I was looking at your code base from [1].The ops->add_device
>callback from of_pci_iommu_configure on the rebind is the
>one which is causing the failure. But not able to spot out
>from code which point is causing the failure. It would be very helpful
>if i can know which is the return value from the add_device callback
>or point inside add_device callback which fails in your setup.
>
>
>[1] git://linux-arm.org/linux-rm iommu/misc
With little more try, i saw an issue where i had an failure
similar to what you reported. The issue happens when multiple
devices fall in to same group due to matching sids. I ended up
doing a fix like below and it would be nice to verify if it is the same
that we are seeing in your setup and if the fix makes a difference ?
From: Sricharan R <sricharan@codeaurora.org>
Date: Fri, 4 Nov 2016 20:28:49 +0530
Subject: [PATCH] iommu/arm-smmu: Fix group's reference counting
iommu_group_get_for_dev which gets called in the add_device
callback, increases the reference count of the iommu_group,
so we do an iommu_group_put after that. iommu_group_get_for_dev
inturn calls device_group callback and in the case of arm-smmu
we call generic_device_group/pci_device_group which takes
care of increasing the group's reference. But when we return
an already existing group(when multiple devices have same group)
the reference is not incremented, resulting in issues when the
remove_device callback for the devices is invoked.
Fixing the same here.
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
---
drivers/iommu/arm-smmu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 71ce4b6..a1d0b3c 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1516,8 +1516,10 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
group = smmu->s2crs[idx].group;
}
- if (group)
+ if (group) {
+ iommu_group_get_by_id(iommu_group_id(group));
return group;
+ }
if (dev_is_pci(dev))
group = pci_device_group(dev);
--
1.8.2.1
^ permalink raw reply related
* [PATCH 1/2] arm64: hugetlb: remove the wrong pmd check in find_num_contig()
From: Catalin Marinas @ 2016-11-04 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104025216.GA19810@sha-win-210.asiapac.arm.com>
On Fri, Nov 04, 2016 at 10:52:17AM +0800, Huang Shijie wrote:
> On Thu, Nov 03, 2016 at 06:16:16PM -0600, Catalin Marinas wrote:
> > On Thu, Nov 03, 2016 at 10:27:38AM +0800, Huang Shijie wrote:
> > > diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> > > index 2e49bd2..4811ef1 100644
> > > --- a/arch/arm64/mm/hugetlbpage.c
> > > +++ b/arch/arm64/mm/hugetlbpage.c
> > > @@ -61,10 +61,6 @@ static int find_num_contig(struct mm_struct *mm, unsigned long addr,
> > > return 1;
> > > }
> > > pmd = pmd_offset(pud, addr);
> > > - if (!pmd_present(*pmd)) {
> > > - VM_BUG_ON(!pmd_present(*pmd));
> > > - return 1;
> > > - }
> > > if ((pte_t *)pmd == ptep) {
> > > *pgsize = PMD_SIZE;
> > > return CONT_PMDS;
> >
> > BTW, for the !pud_present() and !pgd_present() cases, shouldn't
> > find_num_contig() actually return 0? These are more likely real bugs, so
> > no point in setting the huge pte.
>
> The kernel will not call the find_num_contig() if the PGD/PUD are empty.
> Please see the code in the hugetlb_fault().
>
> ------------------------------------------------------
> ptep = huge_pte_offset(mm, address);
> if (ptep) {
> ...............................
> } else {
> ptep = huge_pte_alloc(mm, address, huge_page_size(h));
> if (!ptep)
> return VM_FAULT_OOM;
> }
> ------------------------------------------------------
Exactly. So what is the reason for returning 1 if !pgd_present()? Would
removing the checks entirely or adding BUG() be a better option?
--
Catalin
^ permalink raw reply
* [RFC PATCH v2 8/8] arm64: Wire up and expose the new compat vDSO
From: Catalin Marinas @ 2016-11-04 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027163058.12156-9-kevin.brodsky@arm.com>
On Thu, Oct 27, 2016 at 05:30:58PM +0100, Kevin Brodsky wrote:
> * The vDSO page replaces the vector page. The vDSO provides its own
> sigreturn trampolines, replacing those in the vector page, but the
> kuser helpers are gone. As a result enabling the compat vDSO will
> break userspace programs relying on the kuser helpers.
I think vDSO and vectors page should not exclude each other. If you want
to disable the vectors page, let's make it an independent config option
like the KUSER_HELPERS in arch/arm64/mm/Kconfig. But I would very much
like to be able to have both the vDSO and the vectors page at the same
time.
--
Catalin
^ permalink raw reply
* [PATCH net-next 0/2] ARM64: Add Internal PHY support for Meson GXL
From: Neil Armstrong @ 2016-11-04 15:51 UTC (permalink / raw)
To: linux-arm-kernel
The Amlogic Meson GXL SoCs have an internal RMII PHY that is muxed with the
external RGMII pins.
In order to support switching between the two PHYs links, extended registers
size for mdio-mux-mmioreg must be added.
The DT related patches submitted as RFC in [3] will be sent in a separate
patchset due to multiple patchsets and DTSI migrations.
Changes since v2 RFC patchset at : [3]
- Change phy Kconfig/Makefile alphabetic order
- GXL dtsi cleanup
Changes since original RFC patchset at : [2]
- Remove meson8b experimental phy switching
- Switch to mdio-mux-mmioreg with extennded size support
- Add internal phy support for S905x and p231
- Add external PHY support for p230
[1] http://lkml.kernel.org/r/1477932286-27482-1-git-send-email-narmstrong at baylibre.com
[2] http://lkml.kernel.org/r/1477060838-14164-1-git-send-email-narmstrong at baylibre.com
[3] http://lkml.kernel.org/r/1477932987-27871-1-git-send-email-narmstrong at baylibre.com
Neil Armstrong (2):
net: mdio-mux-mmioreg: Add support for 16bit and 32bit register sizes
net: phy: Add Meson GXL Internal PHY driver
.../devicetree/bindings/net/mdio-mux-mmioreg.txt | 4 +-
drivers/net/phy/Kconfig | 5 ++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/mdio-mux-mmioreg.c | 60 ++++++++++++----
drivers/net/phy/meson-gxl.c | 81 ++++++++++++++++++++++
5 files changed, 136 insertions(+), 15 deletions(-)
create mode 100644 drivers/net/phy/meson-gxl.c
--
1.9.1
^ permalink raw reply
* [PATCH net-next 1/2] net: mdio-mux-mmioreg: Add support for 16bit and 32bit register sizes
From: Neil Armstrong @ 2016-11-04 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478274683-1503-1-git-send-email-narmstrong@baylibre.com>
In order to support PHY switching on Amlogic GXL SoCs, add support for
16bit and 32bit registers sizes.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../devicetree/bindings/net/mdio-mux-mmioreg.txt | 4 +-
drivers/net/phy/mdio-mux-mmioreg.c | 60 +++++++++++++++++-----
2 files changed, 49 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
index 8516929..065e8bd 100644
--- a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
+++ b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
@@ -3,7 +3,7 @@ Properties for an MDIO bus multiplexer controlled by a memory-mapped device
This is a special case of a MDIO bus multiplexer. A memory-mapped device,
like an FPGA, is used to control which child bus is connected. The mdio-mux
node must be a child of the memory-mapped device. The driver currently only
-supports devices with eight-bit registers.
+supports devices with 8, 16 or 32-bit registers.
Required properties in addition to the generic multiplexer properties:
@@ -11,7 +11,7 @@ Required properties in addition to the generic multiplexer properties:
- reg : integer, contains the offset of the register that controls the bus
multiplexer. The size field in the 'reg' property is the size of
- register, and must therefore be 1.
+ register, and must therefore be 1, 2, or 4.
- mux-mask : integer, contains an eight-bit mask that specifies which
bits in the register control the actual bus multiplexer. The
diff --git a/drivers/net/phy/mdio-mux-mmioreg.c b/drivers/net/phy/mdio-mux-mmioreg.c
index d0bed52..6a33646 100644
--- a/drivers/net/phy/mdio-mux-mmioreg.c
+++ b/drivers/net/phy/mdio-mux-mmioreg.c
@@ -21,7 +21,8 @@
struct mdio_mux_mmioreg_state {
void *mux_handle;
phys_addr_t phys;
- uint8_t mask;
+ unsigned int iosize;
+ unsigned int mask;
};
/*
@@ -47,17 +48,47 @@ static int mdio_mux_mmioreg_switch_fn(int current_child, int desired_child,
struct mdio_mux_mmioreg_state *s = data;
if (current_child ^ desired_child) {
- void __iomem *p = ioremap(s->phys, 1);
- uint8_t x, y;
-
+ void __iomem *p = ioremap(s->phys, s->iosize);
if (!p)
return -ENOMEM;
- x = ioread8(p);
- y = (x & ~s->mask) | desired_child;
- if (x != y) {
- iowrite8((x & ~s->mask) | desired_child, p);
- pr_debug("%s: %02x -> %02x\n", __func__, x, y);
+ switch (s->iosize) {
+ case sizeof(uint8_t): {
+ uint8_t x, y;
+
+ x = ioread8(p);
+ y = (x & ~s->mask) | desired_child;
+ if (x != y) {
+ iowrite8((x & ~s->mask) | desired_child, p);
+ pr_debug("%s: %02x -> %02x\n", __func__, x, y);
+ }
+
+ break;
+ }
+ case sizeof(uint16_t): {
+ uint16_t x, y;
+
+ x = ioread16(p);
+ y = (x & ~s->mask) | desired_child;
+ if (x != y) {
+ iowrite16((x & ~s->mask) | desired_child, p);
+ pr_debug("%s: %04x -> %04x\n", __func__, x, y);
+ }
+
+ break;
+ }
+ case sizeof(uint32_t): {
+ uint32_t x, y;
+
+ x = ioread32(p);
+ y = (x & ~s->mask) | desired_child;
+ if (x != y) {
+ iowrite32((x & ~s->mask) | desired_child, p);
+ pr_debug("%s: %08x -> %08x\n", __func__, x, y);
+ }
+
+ break;
+ }
}
iounmap(p);
@@ -88,8 +119,11 @@ static int mdio_mux_mmioreg_probe(struct platform_device *pdev)
}
s->phys = res.start;
- if (resource_size(&res) != sizeof(uint8_t)) {
- dev_err(&pdev->dev, "only 8-bit registers are supported\n");
+ s->iosize = resource_size(&res);
+ if (s->iosize != sizeof(uint8_t) &&
+ s->iosize != sizeof(uint16_t) &&
+ s->iosize != sizeof(uint32_t)) {
+ dev_err(&pdev->dev, "only 8/16/32-bit registers are supported\n");
return -EINVAL;
}
@@ -98,8 +132,8 @@ static int mdio_mux_mmioreg_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "missing or invalid mux-mask property\n");
return -ENODEV;
}
- if (be32_to_cpup(iprop) > 255) {
- dev_err(&pdev->dev, "only 8-bit registers are supported\n");
+ if (be32_to_cpup(iprop) >= BIT(s->iosize * 8)) {
+ dev_err(&pdev->dev, "only 8/16/32-bit registers are supported\n");
return -EINVAL;
}
s->mask = be32_to_cpup(iprop);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 2/2] net: phy: Add Meson GXL Internal PHY driver
From: Neil Armstrong @ 2016-11-04 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478274683-1503-1-git-send-email-narmstrong@baylibre.com>
Add driver for the Internal RMII PHY found in the Amlogic Meson GXL SoCs.
This PHY seems to only implement some standard registers and need some
workarounds to provide autoneg values from vendor registers.
Some magic values are currently used to configure the PHY, and this a
temporary setup until clarification about these registers names and
registers fields are provided by Amlogic.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/net/phy/Kconfig | 5 +++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/meson-gxl.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 87 insertions(+)
create mode 100644 drivers/net/phy/meson-gxl.c
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 2651c8d..b48943a 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -264,6 +264,11 @@ config MARVELL_PHY
---help---
Currently has a driver for the 88E1011S
+config MESON_GXL_PHY
+ tristate "Amlogic Meson GXL Internal PHY"
+ ---help---
+ Currently has a driver for the Amlogic Meson GXL Internal PHY
+
config MICREL_PHY
tristate "Micrel PHYs"
---help---
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index e58667d..3cd5af7 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_INTEL_XWAY_PHY) += intel-xway.o
obj-$(CONFIG_LSI_ET1011C_PHY) += et1011c.o
obj-$(CONFIG_LXT_PHY) += lxt.o
obj-$(CONFIG_MARVELL_PHY) += marvell.o
+obj-$(CONFIG_MESON_GXL_PHY) += meson-gxl.o
obj-$(CONFIG_MICREL_KS8995MA) += spi_ks8995.o
obj-$(CONFIG_MICREL_PHY) += micrel.o
obj-$(CONFIG_MICROCHIP_PHY) += microchip.o
diff --git a/drivers/net/phy/meson-gxl.c b/drivers/net/phy/meson-gxl.c
new file mode 100644
index 0000000..1ea69b7
--- /dev/null
+++ b/drivers/net/phy/meson-gxl.c
@@ -0,0 +1,81 @@
+/*
+ * Amlogic Meson GXL Internal PHY Driver
+ *
+ * Copyright (C) 2015 Amlogic, Inc. All rights reserved.
+ * Copyright (C) 2016 BayLibre, SAS. All rights reserved.
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mii.h>
+#include <linux/ethtool.h>
+#include <linux/phy.h>
+#include <linux/netdevice.h>
+
+static int meson_gxl_config_init(struct phy_device *phydev)
+{
+ /* Enable Analog and DSP register Bank access by */
+ phy_write(phydev, 0x14, 0x0000);
+ phy_write(phydev, 0x14, 0x0400);
+ phy_write(phydev, 0x14, 0x0000);
+ phy_write(phydev, 0x14, 0x0400);
+
+ /* Write Analog register 23 */
+ phy_write(phydev, 0x17, 0x8E0D);
+ phy_write(phydev, 0x14, 0x4417);
+
+ /* Enable fractional PLL */
+ phy_write(phydev, 0x17, 0x0005);
+ phy_write(phydev, 0x14, 0x5C1B);
+
+ /* Program fraction FR_PLL_DIV1 */
+ phy_write(phydev, 0x17, 0x029A);
+ phy_write(phydev, 0x14, 0x5C1D);
+
+ /* Program fraction FR_PLL_DIV1 */
+ phy_write(phydev, 0x17, 0xAAAA);
+ phy_write(phydev, 0x14, 0x5C1C);
+
+ return 0;
+}
+
+static struct phy_driver meson_gxl_phy[] = {
+ {
+ .phy_id = 0x01814400,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Meson GXL Internal PHY",
+ .features = PHY_BASIC_FEATURES,
+ .flags = PHY_IS_INTERNAL,
+ .config_init = meson_gxl_config_init,
+ .config_aneg = genphy_config_aneg,
+ .aneg_done = genphy_aneg_done,
+ .read_status = genphy_read_status,
+ .suspend = genphy_suspend,
+ .resume = genphy_resume,
+ },
+};
+
+static struct mdio_device_id __maybe_unused meson_gxl_tbl[] = {
+ { 0x01814400, 0xfffffff0 },
+ { }
+};
+
+module_phy_driver(meson_gxl_phy);
+
+MODULE_DEVICE_TABLE(mdio, meson_gxl_tbl);
+
+MODULE_DESCRIPTION("Amlogic Meson GXL Internal PHY driver");
+MODULE_AUTHOR("Baoqi wang");
+MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
+MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
* [PATCH RFC 0/7] DMA: S3C64XX: Conversion to the new channel request API
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
This patch series aims to convert the s3c64xx platform to use
the new universal DMA channel request API, i.e. this is only
meaningful for non-dt systems using s3c64xx SoCs.
I'm sending the whole series as RFC since I didn't test it
yet, I'm going to prepare smdk6410 for testing this series.
It would be great if someone else could also test it,
either SPI or sound functionality verification would be
useful.
Then we could queue the first two patches in this series
for v4.10-rc1 and the remaining patches for subsequent
release.
The whole series can be pulled from git repository:
git://linuxtv.org/snawrocki/samsung.git
branch: for-v4.10/dma/pl080-s3c64xx
Thanks.
Sylwester Nawrocki (7):
dma: pl08x: Add support for the DMA slave map
ARM: S3C64XX: Add DMA slave maps for PL080 devices
spi: s3c64xx: Do not use platform_data for DMA parameters
ASoC: samsung: i2s: Do not use platform_data for DMA parameters
ASoC: samsung: pcm: Do not use platform_data for DMA parameters
ARM: S3C64XX: Drop unused DMA fields from struct s3c64xx_spi_csinfo
ARM: S3C64XX: Drop initialization of unused struct s3c_audio_pdata
fields
arch/arm/mach-s3c64xx/dev-audio.c | 19 ------------------
arch/arm/mach-s3c64xx/pl080.c | 32 +++++++++++++++++++++++++++++++
arch/arm/plat-samsung/devs.c | 9 ---------
drivers/dma/amba-pl08x.c | 3 +++
drivers/spi/spi-s3c64xx.c | 21 ++++----------------
include/linux/amba/pl08x.h | 4 ++++
include/linux/platform_data/asoc-s3c.h | 5 -----
include/linux/platform_data/spi-s3c64xx.h | 3 ---
sound/soc/samsung/i2s.c | 14 ++------------
sound/soc/samsung/pcm.c | 14 +++++---------
10 files changed, 50 insertions(+), 74 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH RFC 0/7] DMA: S3C64XX: Conversion to the new channel request API
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-1-git-send-email-s.nawrocki@samsung.com>
This patch series aims to convert the s3c64xx platform to use
the new universal DMA channel request API, i.e. this is only
meaningful for non-dt systems using s3c64xx SoCs.
I'm sending the whole series as RFC since I didn't test it
yet, I'm going to prepare smd6410 for testing this series.
It would be great if someone else could also test it,
either SPI or sound functionality verification would be
useful.
Then we could queue the first two patches in this series
for v4.10-rc1 and the remaining patches for subsequent
release.
The whole series can be pulled from git repository:
git://linuxtv.org/snawrocki/samsung.git
branch: for-v4.10/dma/pl080-s3c64xx
Thanks.
Sylwester Nawrocki (7):
dma: pl08x: Add support for the DMA slave map
ARM: S3C64XX: Add DMA slave maps for PL080 devices
spi: s3c64xx: Do not use platform_data for DMA parameters
ASoC: samsung: i2s: Do not use platform_data for DMA parameters
ASoC: samsung: pcm: Do not use platform_data for DMA parameters
ARM: S3C64XX: Drop unused DMA fields from struct s3c64xx_spi_csinfo
ARM: S3C64XX: Drop initialization of unused struct s3c_audio_pdata
fields
arch/arm/mach-s3c64xx/dev-audio.c | 19 ------------------
arch/arm/mach-s3c64xx/pl080.c | 32 +++++++++++++++++++++++++++++++
arch/arm/plat-samsung/devs.c | 9 ---------
drivers/dma/amba-pl08x.c | 3 +++
drivers/spi/spi-s3c64xx.c | 21 ++++----------------
include/linux/amba/pl08x.h | 4 ++++
include/linux/platform_data/asoc-s3c.h | 5 -----
include/linux/platform_data/spi-s3c64xx.h | 3 ---
sound/soc/samsung/i2s.c | 14 ++------------
sound/soc/samsung/pcm.c | 14 +++++---------
10 files changed, 50 insertions(+), 74 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH RFC 1/7] dma: pl08x: Add support for the DMA slave map
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-1-git-send-email-s.nawrocki@samsung.com>
This patch add support for the new channel request API
introduced in commit a8135d0d79e9d0ad3a4ff494fceeaae83
"dmaengine: core: Introduce new, universal API to request a channel"
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
drivers/dma/amba-pl08x.c | 3 +++
include/linux/amba/pl08x.h | 4 ++++
2 files changed, 7 insertions(+)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 939a7c3..d5c75c8 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -2307,6 +2307,9 @@ static int pl08x_probe(struct amba_device *adev, const struct amba_id *id)
ret = -EINVAL;
goto out_no_platdata;
}
+ } else {
+ pl08x->slave.filter.map = pl08x->pd->slave_map;
+ pl08x->slave.filter.mapcnt = pl08x->pd->slave_map_len;
}
/* By default, AHB1 only. If dualmaster, from platform */
diff --git a/include/linux/amba/pl08x.h b/include/linux/amba/pl08x.h
index 27e9ec8..5308eae 100644
--- a/include/linux/amba/pl08x.h
+++ b/include/linux/amba/pl08x.h
@@ -84,6 +84,8 @@ struct pl08x_channel_data {
* running any DMA transfer and multiplexing can be recycled
* @lli_buses: buses which LLIs can be fetched from: PL08X_AHB1 | PL08X_AHB2
* @mem_buses: buses which memory can be accessed from: PL08X_AHB1 | PL08X_AHB2
+ * @slave_map: DMA slave matching table
+ * @slave_map_len: number of elements in @slave_map
*/
struct pl08x_platform_data {
struct pl08x_channel_data *slave_channels;
@@ -93,6 +95,8 @@ struct pl08x_platform_data {
void (*put_xfer_signal)(const struct pl08x_channel_data *, int);
u8 lli_buses;
u8 mem_buses;
+ const struct dma_slave_map *slave_map;
+ int slave_map_len;
};
#ifdef CONFIG_AMBA_PL08X
--
1.9.1
^ permalink raw reply related
* [PATCH RFC 2/7] ARM: S3C64XX: Add DMA slave maps for PL080 devices
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-1-git-send-email-s.nawrocki@samsung.com>
This patch adds DMA slave map tables to the pl080 devices's
platform_data in order to support the new channel request API.
A few devices for which there was no DMA support with current
code are omitted from the tables.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
arch/arm/mach-s3c64xx/pl080.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm/mach-s3c64xx/pl080.c b/arch/arm/mach-s3c64xx/pl080.c
index 89c5a62..8c88680 100644
--- a/arch/arm/mach-s3c64xx/pl080.c
+++ b/arch/arm/mach-s3c64xx/pl080.c
@@ -117,6 +117,25 @@ static void pl08x_put_xfer_signal(const struct pl08x_channel_data *cd, int ch)
}
};
+static const struct dma_slave_map s3c64xx_dma0_slave_map[] = {
+ { "s3c6400-uart.0", "tx", (void *)"uart0_tx" },
+ { "s3c6400-uart.0", "rx", (void *)"uart0_rx" },
+ { "s3c6400-uart.1", "tx", (void *)"uart1_tx" },
+ { "s3c6400-uart.1", "rx", (void *)"uart1_rx" },
+ { "s3c6400-uart.2", "tx", (void *)"uart2_tx" },
+ { "s3c6400-uart.2", "rx", (void *)"uart2_rx" },
+ { "s3c6400-uart.3", "tx", (void *)"uart3_tx" },
+ { "s3c6400-uart.3", "rx", (void *)"uart3_rx" },
+ { "samsung-pcm.0", "tx", (void *)"pcm0_tx" },
+ { "samsung-pcm.0", "rx", (void *)"pcm0_rx" },
+ { "samsung-i2s.0", "tx", (void *)"i2s0_tx" },
+ { "samsung-i2s.0", "rx", (void *)"i2s0_rx" },
+ { "s3c6410-spi.0", "tx", (void *)"spi0_tx" },
+ { "s3c6410-spi.0", "rx", (void *)"spi0_rx" },
+ { "samsung-i2s.2", "tx", (void *)"i2s2_tx" },
+ { "samsung-i2s.2", "rx", (void *)"i2s2_rx" },
+};
+
struct pl08x_platform_data s3c64xx_dma0_plat_data = {
.memcpy_channel = {
.bus_id = "memcpy",
@@ -134,6 +153,8 @@ struct pl08x_platform_data s3c64xx_dma0_plat_data = {
.put_xfer_signal = pl08x_put_xfer_signal,
.slave_channels = s3c64xx_dma0_info,
.num_slave_channels = ARRAY_SIZE(s3c64xx_dma0_info),
+ .slave_map = s3c64xx_dma0_slave_map,
+ .slavecnt = ARRAY_SIZE(s3c64xx_dma0_slave_map),
};
static AMBA_AHB_DEVICE(s3c64xx_dma0, "dma-pl080s.0", 0,
@@ -207,6 +228,15 @@ static AMBA_AHB_DEVICE(s3c64xx_dma0, "dma-pl080s.0", 0,
},
};
+static const struct dma_slave_map s3c64xx_dma1_slave_map[] = {
+ { "samsung-pcm.1", "tx", (void *)"pcm1_tx" },
+ { "samsung-pcm.1", "rx", (void *)"pcm1_rx" },
+ { "samsung-i2s.1", "tx", (void *)"i2s1_tx" },
+ { "samsung-i2s.1", "rx", (void *)"i2s1_rx" },
+ { "s3c6410-spi.1", "tx", (void *)"spi1_tx" },
+ { "s3c6410-spi.1", "rx", (void *)"spi1_rx" },
+};
+
struct pl08x_platform_data s3c64xx_dma1_plat_data = {
.memcpy_channel = {
.bus_id = "memcpy",
@@ -224,6 +254,8 @@ struct pl08x_platform_data s3c64xx_dma1_plat_data = {
.put_xfer_signal = pl08x_put_xfer_signal,
.slave_channels = s3c64xx_dma1_info,
.num_slave_channels = ARRAY_SIZE(s3c64xx_dma1_info),
+ .slave_map = s3c64xx_dma1_slave_map,
+ .slavecnt = ARRAY_SIZE(s3c64xx_dma1_slave_map),
};
static AMBA_AHB_DEVICE(s3c64xx_dma1, "dma-pl080s.1", 0,
--
1.9.1
^ permalink raw reply related
* [PATCH RFC 3/7] spi: s3c64xx: Do not use platform_data for DMA parameters
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-1-git-send-email-s.nawrocki@samsung.com>
All related platforms use either devicetree or the DMA slave
map API for mapping DMA channels to DMA slaves so we can now
stop using platform_data for passing DMA details.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
drivers/spi/spi-s3c64xx.c | 21 ++++-----------------
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 3c09e94..28dfdce 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -341,27 +341,20 @@ static void s3c64xx_spi_set_cs(struct spi_device *spi, bool enable)
static int s3c64xx_spi_prepare_transfer(struct spi_master *spi)
{
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
- dma_filter_fn filter = sdd->cntrlr_info->filter;
struct device *dev = &sdd->pdev->dev;
- dma_cap_mask_t mask;
if (is_polling(sdd))
return 0;
- dma_cap_zero(mask);
- dma_cap_set(DMA_SLAVE, mask);
-
/* Acquire DMA channels */
- sdd->rx_dma.ch = dma_request_slave_channel_compat(mask, filter,
- sdd->cntrlr_info->dma_rx, dev, "rx");
+ sdd->rx_dma.ch = dma_request_slave_channel(dev, "rx");
if (!sdd->rx_dma.ch) {
dev_err(dev, "Failed to get RX DMA channel\n");
return -EBUSY;
}
spi->dma_rx = sdd->rx_dma.ch;
- sdd->tx_dma.ch = dma_request_slave_channel_compat(mask, filter,
- sdd->cntrlr_info->dma_tx, dev, "tx");
+ sdd->tx_dma.ch = dma_request_slave_channel(dev, "tx");
if (!sdd->tx_dma.ch) {
dev_err(dev, "Failed to get TX DMA channel\n");
dma_release_channel(sdd->rx_dma.ch);
@@ -1091,11 +1084,6 @@ static int s3c64xx_spi_probe(struct platform_device *pdev)
sdd->cur_bpw = 8;
- if (!sdd->pdev->dev.of_node && (!sci->dma_tx || !sci->dma_rx)) {
- dev_warn(&pdev->dev, "Unable to get SPI tx/rx DMA data. Switching to poll mode\n");
- sdd->port_conf->quirks = S3C64XX_SPI_QUIRK_POLL;
- }
-
sdd->tx_dma.direction = DMA_MEM_TO_DEV;
sdd->rx_dma.direction = DMA_DEV_TO_MEM;
@@ -1205,9 +1193,8 @@ static int s3c64xx_spi_probe(struct platform_device *pdev)
dev_dbg(&pdev->dev, "Samsung SoC SPI Driver loaded for Bus SPI-%d with %d Slaves attached\n",
sdd->port_id, master->num_chipselect);
- dev_dbg(&pdev->dev, "\tIOmem=[%pR]\tFIFO %dbytes\tDMA=[Rx-%p, Tx-%p]\n",
- mem_res, (FIFO_LVL_MASK(sdd) >> 1) + 1,
- sci->dma_rx, sci->dma_tx);
+ dev_dbg(&pdev->dev, "\tIOmem=[%pR]\tFIFO %dbytes\n",
+ mem_res, (FIFO_LVL_MASK(sdd) >> 1) + 1);
pm_runtime_mark_last_busy(&pdev->dev);
pm_runtime_put_autosuspend(&pdev->dev);
--
1.9.1
^ permalink raw reply related
* [PATCH RFC 4/7] ASoC: samsung: i2s: Do not use platform_data for DMA parameters
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-1-git-send-email-s.nawrocki@samsung.com>
All related platforms use either devicetree or the DMA slave
map API for mapping DMA channels to slave devices so we can now
stop using platform_data for passing DMA details.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
sound/soc/samsung/i2s.c | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 7e32cf4..95a9a3f 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -90,7 +90,6 @@ struct i2s_dai {
struct snd_dmaengine_dai_dma_data dma_playback;
struct snd_dmaengine_dai_dma_data dma_capture;
struct snd_dmaengine_dai_dma_data idma_playback;
- dma_filter_fn filter;
u32 quirks;
u32 suspend_i2smod;
u32 suspend_i2scon;
@@ -1244,7 +1243,7 @@ static int samsung_i2s_probe(struct platform_device *pdev)
return ret;
return samsung_asoc_dma_platform_register(&pdev->dev,
- sec_dai->filter, "tx-sec", NULL);
+ NULL, "tx-sec", NULL);
}
pri_dai = i2s_alloc_dai(pdev, false);
@@ -1262,10 +1261,6 @@ static int samsung_i2s_probe(struct platform_device *pdev)
return -EINVAL;
}
- pri_dai->dma_playback.filter_data = i2s_pdata->dma_playback;
- pri_dai->dma_capture.filter_data = i2s_pdata->dma_capture;
- pri_dai->filter = i2s_pdata->dma_filter;
-
if (&i2s_pdata->type)
i2s_cfg = &i2s_pdata->type.i2s;
@@ -1327,11 +1322,6 @@ static int samsung_i2s_probe(struct platform_device *pdev)
sec_dai->dma_playback.addr = regs_base + I2STXDS;
sec_dai->dma_playback.chan_name = "tx-sec";
- if (!np) {
- sec_dai->dma_playback.filter_data = i2s_pdata->dma_play_sec;
- sec_dai->filter = i2s_pdata->dma_filter;
- }
-
sec_dai->dma_playback.addr_width = 4;
sec_dai->addr = pri_dai->addr;
sec_dai->clk = pri_dai->clk;
@@ -1353,7 +1343,7 @@ static int samsung_i2s_probe(struct platform_device *pdev)
if (ret < 0)
goto err_free_dai;
- ret = samsung_asoc_dma_platform_register(&pdev->dev, pri_dai->filter,
+ ret = samsung_asoc_dma_platform_register(&pdev->dev, NULL,
NULL, NULL);
if (ret < 0)
goto err_free_dai;
--
1.9.1
^ permalink raw reply related
* [PATCH RFC 5/7] ASoC: samsung: pcm: Do not use platform_data for DMA parameters
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-1-git-send-email-s.nawrocki@samsung.com>
All related platforms use either devicetree or the DMA slave
map API for mapping DMA channels to slave devices so we can now
stop using platform_data for passing DMA details.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
sound/soc/samsung/pcm.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/sound/soc/samsung/pcm.c b/sound/soc/samsung/pcm.c
index 43e367a..ccedab2 100644
--- a/sound/soc/samsung/pcm.c
+++ b/sound/soc/samsung/pcm.c
@@ -134,18 +134,22 @@ struct s3c_pcm_info {
static struct snd_dmaengine_dai_dma_data s3c_pcm_stereo_out[] = {
[0] = {
.addr_width = 4,
+ .chan_name = "tx",
},
[1] = {
.addr_width = 4,
+ .chan_name = "tx",
},
};
static struct snd_dmaengine_dai_dma_data s3c_pcm_stereo_in[] = {
[0] = {
.addr_width = 4,
+ .chan_name = "rx",
},
[1] = {
.addr_width = 4,
+ .chan_name = "rx",
},
};
@@ -488,7 +492,6 @@ static int s3c_pcm_dev_probe(struct platform_device *pdev)
struct s3c_pcm_info *pcm;
struct resource *mem_res;
struct s3c_audio_pdata *pcm_pdata;
- dma_filter_fn filter;
int ret;
/* Check for valid device index */
@@ -555,13 +558,6 @@ static int s3c_pcm_dev_probe(struct platform_device *pdev)
s3c_pcm_stereo_in[pdev->id].addr = mem_res->start + S3C_PCM_RXFIFO;
s3c_pcm_stereo_out[pdev->id].addr = mem_res->start + S3C_PCM_TXFIFO;
- filter = NULL;
- if (pcm_pdata) {
- s3c_pcm_stereo_in[pdev->id].filter_data = pcm_pdata->dma_capture;
- s3c_pcm_stereo_out[pdev->id].filter_data = pcm_pdata->dma_playback;
- filter = pcm_pdata->dma_filter;
- }
-
pcm->dma_capture = &s3c_pcm_stereo_in[pdev->id];
pcm->dma_playback = &s3c_pcm_stereo_out[pdev->id];
@@ -574,7 +570,7 @@ static int s3c_pcm_dev_probe(struct platform_device *pdev)
goto err5;
}
- ret = samsung_asoc_dma_platform_register(&pdev->dev, filter,
+ ret = samsung_asoc_dma_platform_register(&pdev->dev, NULL,
NULL, NULL);
if (ret) {
dev_err(&pdev->dev, "failed to get register DMA: %d\n", ret);
--
1.9.1
^ permalink raw reply related
* [PATCH RFC 6/7] ARM: S3C64XX: Drop unused DMA fields from struct s3c64xx_spi_csinfo
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-1-git-send-email-s.nawrocki@samsung.com>
There is no drivers using those fields so remove them and
remaining initializations.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
arch/arm/plat-samsung/devs.c | 9 ---------
include/linux/platform_data/spi-s3c64xx.h | 3 ---
2 files changed, 12 deletions(-)
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index e93aa67..4e14bf6 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -1124,15 +1124,6 @@ void __init s3c64xx_spi0_set_platdata(int (*cfg_gpio)(void), int src_clk_nr,
pd.num_cs = num_cs;
pd.src_clk_nr = src_clk_nr;
pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi0_cfg_gpio;
- pd.dma_tx = (void *)DMACH_SPI0_TX;
- pd.dma_rx = (void *)DMACH_SPI0_RX;
-#if defined(CONFIG_PL330_DMA)
- pd.filter = pl330_filter;
-#elif defined(CONFIG_S3C64XX_PL080)
- pd.filter = pl08x_filter_id;
-#elif defined(CONFIG_S3C24XX_DMAC)
- pd.filter = s3c24xx_dma_filter;
-#endif
s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi0);
}
diff --git a/include/linux/platform_data/spi-s3c64xx.h b/include/linux/platform_data/spi-s3c64xx.h
index 5c1e21c..da79774 100644
--- a/include/linux/platform_data/spi-s3c64xx.h
+++ b/include/linux/platform_data/spi-s3c64xx.h
@@ -40,9 +40,6 @@ struct s3c64xx_spi_info {
int num_cs;
bool no_cs;
int (*cfg_gpio)(void);
- dma_filter_fn filter;
- void *dma_tx;
- void *dma_rx;
};
/**
--
1.9.1
^ permalink raw reply related
* [PATCH RFC 7/7] ARM: S3C64XX: Drop initialization of unused struct s3c_audio_pdata fields
From: Sylwester Nawrocki @ 2016-11-04 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-1-git-send-email-s.nawrocki@samsung.com>
There is no drivers using these fields so remove them and remaining
initializations.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
arch/arm/mach-s3c64xx/dev-audio.c | 19 -------------------
include/linux/platform_data/asoc-s3c.h | 5 -----
2 files changed, 24 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/dev-audio.c b/arch/arm/mach-s3c64xx/dev-audio.c
index b577833..a3f39dd 100644
--- a/arch/arm/mach-s3c64xx/dev-audio.c
+++ b/arch/arm/mach-s3c64xx/dev-audio.c
@@ -58,9 +58,6 @@ static int s3c64xx_i2s_cfg_gpio(struct platform_device *pdev)
static struct s3c_audio_pdata i2s0_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_playback = DMACH_I2S0_OUT,
- .dma_capture = DMACH_I2S0_IN,
};
struct platform_device s3c64xx_device_iis0 = {
@@ -80,9 +77,6 @@ struct platform_device s3c64xx_device_iis0 = {
static struct s3c_audio_pdata i2s1_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_playback = DMACH_I2S1_OUT,
- .dma_capture = DMACH_I2S1_IN,
};
struct platform_device s3c64xx_device_iis1 = {
@@ -102,9 +96,6 @@ struct platform_device s3c64xx_device_iis1 = {
static struct s3c_audio_pdata i2sv4_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_playback = DMACH_HSI_I2SV40_TX,
- .dma_capture = DMACH_HSI_I2SV40_RX,
.type = {
.i2s = {
.quirks = QUIRK_PRI_6CHAN,
@@ -153,9 +144,6 @@ static int s3c64xx_pcm_cfg_gpio(struct platform_device *pdev)
static struct s3c_audio_pdata s3c_pcm0_pdata = {
.cfg_gpio = s3c64xx_pcm_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_capture = DMACH_PCM0_RX,
- .dma_playback = DMACH_PCM0_TX,
};
struct platform_device s3c64xx_device_pcm0 = {
@@ -175,9 +163,6 @@ struct platform_device s3c64xx_device_pcm0 = {
static struct s3c_audio_pdata s3c_pcm1_pdata = {
.cfg_gpio = s3c64xx_pcm_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_playback = DMACH_PCM1_TX,
- .dma_capture = DMACH_PCM1_RX,
};
struct platform_device s3c64xx_device_pcm1 = {
@@ -209,10 +194,6 @@ static int s3c64xx_ac97_cfg_gpe(struct platform_device *pdev)
};
static struct s3c_audio_pdata s3c_ac97_pdata = {
- .dma_playback = DMACH_AC97_PCMOUT,
- .dma_filter = pl08x_filter_id,
- .dma_capture = DMACH_AC97_PCMIN,
- .dma_capture_mic = DMACH_AC97_MICIN,
};
static u64 s3c64xx_ac97_dmamask = DMA_BIT_MASK(32);
diff --git a/include/linux/platform_data/asoc-s3c.h b/include/linux/platform_data/asoc-s3c.h
index 15bf56e..2d415f6 100644
--- a/include/linux/platform_data/asoc-s3c.h
+++ b/include/linux/platform_data/asoc-s3c.h
@@ -42,11 +42,6 @@ struct samsung_i2s {
*/
struct s3c_audio_pdata {
int (*cfg_gpio)(struct platform_device *);
- dma_filter_fn dma_filter;
- void *dma_playback;
- void *dma_capture;
- void *dma_play_sec;
- void *dma_capture_mic;
union {
struct samsung_i2s i2s;
} type;
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 2/2] net: phy: Add Meson GXL Internal PHY driver
From: Florian Fainelli @ 2016-11-04 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478274683-1503-3-git-send-email-narmstrong@baylibre.com>
On 11/04/2016 08:51 AM, Neil Armstrong wrote:
> Add driver for the Internal RMII PHY found in the Amlogic Meson GXL SoCs.
>
> This PHY seems to only implement some standard registers and need some
> workarounds to provide autoneg values from vendor registers.
>
> Some magic values are currently used to configure the PHY, and this a
> temporary setup until clarification about these registers names and
> registers fields are provided by Amlogic.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [PATCH net-next 1/2] net: mdio-mux-mmioreg: Add support for 16bit and 32bit register sizes
From: Florian Fainelli @ 2016-11-04 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478274683-1503-2-git-send-email-narmstrong@baylibre.com>
On 11/04/2016 08:51 AM, Neil Armstrong wrote:
> In order to support PHY switching on Amlogic GXL SoCs, add support for
> 16bit and 32bit registers sizes.
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [RFC PATCH v2 8/8] arm64: Wire up and expose the new compat vDSO
From: Kevin Brodsky @ 2016-11-04 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104155039.5lxubpyt2dsuqxef@localhost>
On 04/11/2016 09:50, Catalin Marinas wrote:
> On Thu, Oct 27, 2016 at 05:30:58PM +0100, Kevin Brodsky wrote:
>> * The vDSO page replaces the vector page. The vDSO provides its own
>> sigreturn trampolines, replacing those in the vector page, but the
>> kuser helpers are gone. As a result enabling the compat vDSO will
>> break userspace programs relying on the kuser helpers.
> I think vDSO and vectors page should not exclude each other. If you want
> to disable the vectors page, let's make it an independent config option
> like the KUSER_HELPERS in arch/arm64/mm/Kconfig. But I would very much
> like to be able to have both the vDSO and the vectors page at the same
> time.
Indeed, I've had exactly the same feedback from Google yesterday (apparently many
Android apps with native libs still target ARMv6....). I'll add the option to keep
the kuser helpers.
There's a small problem though: how to ensure that the kuser helpers + sigreturn
trampolines are always included if the compat vDSO is not built? I can enforce
CONFIG_KUSER_HELPERS if !CONFIG_VDSO32 (directly in the code/Makefiles), but the
dependency cannot be expressed in Kconfig.
Thanks,
Kevin
^ permalink raw reply
* [PATCH v6 7/7] arm64: dts: NS2: add AMAC ethernet support
From: Jon Mason @ 2016-11-04 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <69ecd9b9-d495-9dfa-ad26-4fa622d951a0@cogentembedded.com>
On Fri, Nov 04, 2016 at 04:31:40PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 11/4/2016 8:11 AM, Jon Mason wrote:
>
> >Add support for the AMAC ethernet to the Broadcom Northstar2 SoC device
> >tree
> >
> >Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> >---
> > arch/arm64/boot/dts/broadcom/ns2-svk.dts | 5 +++++
> > arch/arm64/boot/dts/broadcom/ns2.dtsi | 12 ++++++++++++
> > 2 files changed, 17 insertions(+)
> >
> >diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
> >index b09f3bc..c4d5442 100644
> >--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
> >+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
> >@@ -56,6 +56,10 @@
> > };
> > };
> >
> >+&enet {
> >+ status = "ok";
>
> The spec dictates it should be "okay" (although "ok" is also recognized).
The rest of the file uses "ok". So, the addition above is consistent
with the other entries.
Perhaps a patch outside this series to convert the entire file from
"ok" to "okay" would be acceptable to you.
Thanks,
Jon
>
> >+};
> >+
> > &pci_phy0 {
> > status = "ok";
> > };
> >@@ -174,6 +178,7 @@
> > &mdio_mux_iproc {
> > mdio at 10 {
> > gphy0: eth-phy at 10 {
> >+ enet-phy-lane-swap;
> > reg = <0x10>;
> > };
> > };
> [...]
>
> MBR, Sergei
>
^ 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