* [PATCH 2/2] ARM: dts: bcm283x: fix typo in mailbox address
From: Eric Anholt @ 2016-10-27 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477505640-26658-2-git-send-email-stefan.wahren@i2se.com>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> The address of the mailbox node in the bcm283x.dts has also a typo.
> So fix it accordingly.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> Fixes: 05b682b7a3b2 ("ARM: bcm2835: dt: Add the mailbox to the device tree")
I've marked these to be applied once Rob acks the docs change.
^ permalink raw reply
* [PATCH 01/14] dma: sun6i-dma: Add burst case of 4
From: Maxime Ripard @ 2016-10-27 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161023183107.5b75b6aad62853378713299f@free.fr>
On Sun, Oct 23, 2016 at 06:31:07PM +0200, Jean-Francois Moine wrote:
> On Tue, 4 Oct 2016 18:55:54 +0200
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > On Tue, Oct 04, 2016 at 12:40:11PM +0200, Jean-Francois Moine wrote:
> > > On Tue, 4 Oct 2016 11:46:14 +0200
> > > Myl?ne Josserand <mylene.josserand@free-electrons.com> wrote:
> > >
> > > > Add the case of a burst of 4 which is handled by the SoC.
> > > >
> > > > Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>
> > > > ---
> > > > drivers/dma/sun6i-dma.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> > > > index 8346199..0485204 100644
> > > > --- a/drivers/dma/sun6i-dma.c
> > > > +++ b/drivers/dma/sun6i-dma.c
> > > > @@ -240,6 +240,8 @@ static inline s8 convert_burst(u32 maxburst)
> > > > switch (maxburst) {
> > > > case 1:
> > > > return 0;
> > > > + case 4:
> > > > + return 1;
> > > > case 8:
> > > > return 2;
> > > > default:
> > > > --
> > > > 2.9.3
> > >
> > > This patch has already been rejected by Maxime in the threads
> > > http://www.spinics.net/lists/dmaengine/msg08610.html
> > > and
> > > http://www.spinics.net/lists/dmaengine/msg08719.html
> > >
> > > I hope you will find the way he wants for this maxburst to be added.
> >
> > I was talking about something along these lines (not tested):
>
> I wonder why you don't submit this yourself.
I thought you were the one who cared. You asked for what I had in
mind, here it is.
> > -------8<---------
> > diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> > index 83461994e418..573ac4608293 100644
> > --- a/drivers/dma/sun6i-dma.c
> > +++ b/drivers/dma/sun6i-dma.c
> > @@ -240,6 +240,8 @@ static inline s8 convert_burst(u32 maxburst)
> > switch (maxburst) {
> > case 1:
> > return 0;
> > + case 4:
> > + return 1;
> > case 8:
> > return 2;
> > default:
> > @@ -1110,11 +1112,19 @@ static int sun6i_dma_probe(struct platform_device *pdev)
> > sdc->slave.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> > BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> > BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
> > + sdc->slave.dst_bursts = BIT(1) | BIT(8);
> > + sdc->slave.src_bursts = BIT(1) | BIT(8);
> > sdc->slave.directions = BIT(DMA_DEV_TO_MEM) |
> > BIT(DMA_MEM_TO_DEV);
> > sdc->slave.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
> > sdc->slave.dev = &pdev->dev;
> >
> > + if (of_device_is_compatible(pdev->dev.of_node,
> > + "allwinner,sun8i-h3-dma")) {
> > + sdc->slave.dst_bursts |= BIT(4);
> > + sdc->slave.src_bursts |= BIT(4);
> > + }
> > +
> > sdc->pchans = devm_kcalloc(&pdev->dev, sdc->cfg->nr_max_channels,
> > sizeof(struct sun6i_pchan), GFP_KERNEL);
> > if (!sdc->pchans)
> > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > index cc535a478bae..f7bbec24bb58 100644
> > --- a/include/linux/dmaengine.h
> > +++ b/include/linux/dmaengine.h
> > @@ -673,6 +673,8 @@ struct dma_filter {
> > * each type of direction, the dma controller should fill (1 <<
> > * <TYPE>) and same should be checked by controller as well
> > * @max_burst: max burst capability per-transfer
> > + * @dst_bursts: bitfield of the available burst sizes for the destination
> > + * @src_bursts: bitfield of the available burst sizes for the source
>
> You did not define dst_bursts nor src_bursts.
>
> > * @residue_granularity: granularity of the transfer residue reported
> > * by tx_status
> > * @device_alloc_chan_resources: allocate resources and return the
> > @@ -800,6 +802,14 @@ struct dma_device {
> > static inline int dmaengine_slave_config(struct dma_chan *chan,
> > struct dma_slave_config *config)
> > {
> > + if (config->src_maxburst && config->device->src_bursts &&
> > + !(BIT(config->src_maxburst) & config->device->src_bursts))
>
> The maxburst may be as big as 4Kibytes, then, I am not sure that this
> code will work!
>
> > + return -EINVAL;
> > +
> > + if (config->dst_maxburst && config->device->dst_bursts &&
> > + !(BIT(config->dst_maxburst) & config->device->dst_bursts))
> > + return -EINVAL;
> > +
> > if (chan->device->device_config)
> > return chan->device->device_config(chan, config);
> > -------8<------------
>
> Yes, I know that the burst size is always a power of 2.
> The best way to check it would be to change the {src,dts}_maxburst to a
> bitmap of the possible bursts as 0x0d for 1,4 and 8 bytes. But this
> asks for a lot of changes...
To be honest, I'm not really a big fan of those tree wide changes
without any way to maintain compatibility. It ends up in a single,
huge patch if we want to maintain bisectability that just isn't
reviewable.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161027/aaa8cf73/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] ARM: dts: exynos: Use macro for PWM signal polarity in Exynos5 boards
From: Javier Martinez Canillas @ 2016-10-27 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477590438-18095-1-git-send-email-javier@osg.samsung.com>
Using the PWM_POLARITY_INVERTED macro instead of the hardcoded number
0 makes the DTS easier to read.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 3 ++-
arch/arm/boot/dts/exynos5410-odroidxu.dts | 2 +-
arch/arm/boot/dts/exynos5420-peach-pit.dts | 3 ++-
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 3 ++-
arch/arm/boot/dts/exynos5422-odroidxu4.dts | 2 +-
arch/arm/boot/dts/exynos54xx-odroidxu-leds.dtsi | 5 +++--
arch/arm/boot/dts/exynos5800-peach-pi.dts | 3 ++-
7 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 8f3a80430748..4df36f7263fd 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -12,6 +12,7 @@
#include <dt-bindings/clock/maxim,max77686.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/input/input.h>
+#include <dt-bindings/pwm/pwm.h>
#include "exynos5250.dtsi"
/ {
@@ -198,7 +199,7 @@
backlight: backlight {
compatible = "pwm-backlight";
- pwms = <&pwm 0 1000000 0>;
+ pwms = <&pwm 0 1000000 PWM_POLARITY_INVERTED>;
brightness-levels = <0 100 500 1000 1500 2000 2500 2800>;
default-brightness-level = <7>;
enable-gpios = <&gpx3 0 GPIO_ACTIVE_HIGH>;
diff --git a/arch/arm/boot/dts/exynos5410-odroidxu.dts b/arch/arm/boot/dts/exynos5410-odroidxu.dts
index c4de1353e5df..56adaac1f4ec 100644
--- a/arch/arm/boot/dts/exynos5410-odroidxu.dts
+++ b/arch/arm/boot/dts/exynos5410-odroidxu.dts
@@ -40,7 +40,7 @@
fan0: pwm-fan {
compatible = "pwm-fan";
- pwms = <&pwm 0 20972 0>;
+ pwms = <&pwm 0 20972 PWM_POLARITY_INVERTED>;
cooling-min-state = <0>;
cooling-max-state = <3>;
#cooling-cells = <2>;
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 1f964ec35c5e..d83a12bb7112 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -13,6 +13,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/clock/maxim,max77802.h>
+#include <dt-bindings/pwm/pwm.h>
#include <dt-bindings/regulator/maxim,max77802.h>
#include "exynos5420.dtsi"
#include "exynos5420-cpus.dtsi"
@@ -37,7 +38,7 @@
backlight: backlight {
compatible = "pwm-backlight";
- pwms = <&pwm 0 1000000 0>;
+ pwms = <&pwm 0 1000000 PWM_POLARITY_INVERTED>;
brightness-levels = <0 100 500 1000 1500 2000 2500 2800>;
default-brightness-level = <7>;
power-supply = <&tps65090_fet1>;
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 246d298557f5..791af504a79f 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -15,6 +15,7 @@
#include <dt-bindings/clock/samsung,s2mps11.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pwm/pwm.h>
#include <dt-bindings/sound/samsung-i2s.h>
#include "exynos5800.dtsi"
#include "exynos5422-cpus.dtsi"
@@ -51,7 +52,7 @@
fan0: pwm-fan {
compatible = "pwm-fan";
- pwms = <&pwm 0 20972 0>;
+ pwms = <&pwm 0 20972 PWM_POLARITY_INVERTED>;
cooling-min-state = <0>;
cooling-max-state = <3>;
#cooling-cells = <2>;
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
index 2faf88627a48..93ac1d201f16 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
@@ -24,7 +24,7 @@
blueled {
label = "blue:heartbeat";
- pwms = <&pwm 2 2000000 0>;
+ pwms = <&pwm 2 2000000 PWM_POLARITY_INVERTED>;
pwm-names = "pwm2";
max_brightness = <255>;
linux,default-trigger = "heartbeat";
diff --git a/arch/arm/boot/dts/exynos54xx-odroidxu-leds.dtsi b/arch/arm/boot/dts/exynos54xx-odroidxu-leds.dtsi
index 0ed30206625c..1e3d65d34167 100644
--- a/arch/arm/boot/dts/exynos54xx-odroidxu-leds.dtsi
+++ b/arch/arm/boot/dts/exynos54xx-odroidxu-leds.dtsi
@@ -12,6 +12,7 @@
*/
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pwm/pwm.h>
/ {
pwmleds {
@@ -19,7 +20,7 @@
greenled {
label = "green:mmc0";
- pwms = <&pwm 1 2000000 0>;
+ pwms = <&pwm 1 2000000 PWM_POLARITY_INVERTED>;
pwm-names = "pwm1";
/*
* Green LED is much brighter than the others
@@ -31,7 +32,7 @@
blueled {
label = "blue:heartbeat";
- pwms = <&pwm 2 2000000 0>;
+ pwms = <&pwm 2 2000000 PWM_POLARITY_INVERTED>;
pwm-names = "pwm2";
max_brightness = <255>;
linux,default-trigger = "heartbeat";
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index f9ff7f07ae0c..b1bf73f51e9c 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -13,6 +13,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/clock/maxim,max77802.h>
+#include <dt-bindings/pwm/pwm.h>
#include <dt-bindings/regulator/maxim,max77802.h>
#include "exynos5800.dtsi"
#include "exynos5420-cpus.dtsi"
@@ -35,7 +36,7 @@
backlight: backlight {
compatible = "pwm-backlight";
- pwms = <&pwm 0 1000000 0>;
+ pwms = <&pwm 0 1000000 PWM_POLARITY_INVERTED>;
brightness-levels = <0 100 500 1000 1500 2000 2500 2800>;
default-brightness-level = <7>;
enable-gpios = <&gpx2 2 GPIO_ACTIVE_HIGH>;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: exynos: Use macro for PWM signal polarity in Exynos4 boards
From: Javier Martinez Canillas @ 2016-10-27 17:47 UTC (permalink / raw)
To: linux-arm-kernel
Using the PWM_POLARITY_INVERTED macro instead of the hardcoded number
0 makes the DTS easier to read.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 3 ++-
arch/arm/boot/dts/exynos4412-trats2.dts | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 99634c54dca9..480a80624b77 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -12,6 +12,7 @@
*/
/dts-v1/;
+#include <dt-bindings/pwm/pwm.h>
#include "exynos4412-odroid-common.dtsi"
/ {
@@ -35,7 +36,7 @@
fan0: pwm-fan {
compatible = "pwm-fan";
- pwms = <&pwm 0 10000 0>;
+ pwms = <&pwm 0 10000 PWM_POLARITY_INVERTED>;
cooling-min-state = <0>;
cooling-max-state = <3>;
#cooling-cells = <2>;
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts
index 41ecd6d465a7..63ad30507d4f 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -18,6 +18,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/clock/maxim,max77686.h>
+#include <dt-bindings/pwm/pwm.h>
/ {
model = "Samsung Trats 2 based on Exynos4412";
@@ -164,7 +165,7 @@
max77693_haptic {
compatible = "maxim,max77693-haptic";
haptic-supply = <&ldo26_reg>;
- pwms = <&pwm 0 38022 0>;
+ pwms = <&pwm 0 38022 PWM_POLARITY_INVERTED>;
};
charger {
--
2.7.4
^ permalink raw reply related
* [PATCH V4 0/5] firmware: Add support for TI System Control Interface (TI-SCI) protocol driver
From: Tero Kristo @ 2016-10-27 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <45f55012-f027-51d1-bdf1-6fa1950f59ed@oracle.com>
On 26/10/16 22:56, Santosh Shilimkar wrote:
> On 10/25/2016 10:34 AM, Tero Kristo wrote:
>> On 19/10/16 02:08, Nishanth Menon wrote:
>>> Version 4 of the series is basically a rebase to v4.9-rc1, no functional
>>> changes.
>>
>> Hi,
>>
>> Any final comments on this series, or shall I send a pull-req forward?
>> Very minimal changes compared to v3 so should be good to go imo.
>>
> The patchset looks fine to me from brief scan so please Go from
> my side at least for the pull request.
Queued for 4.10, pull request sent also. Thanks.
-Tero
^ permalink raw reply
* [PATCH V4 0/5] firmware: Add support for TI System Control Interface (TI-SCI) protocol driver
From: Tero Kristo @ 2016-10-27 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m260odhjcb.fsf@baylibre.com>
On 27/10/16 19:01, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
>
>> On 19/10/16 02:08, Nishanth Menon wrote:
>>> Version 4 of the series is basically a rebase to v4.9-rc1, no functional
>>> changes.
>>
>> Any final comments on this series, or shall I send a pull-req forward?
>> Very minimal changes compared to v3 so should be good to go imo.
>
> Not a comment on the series, but a question on TI-SCI.
>
> Will the uC firmware be open like it was on AM335x?
Currently it seems like it will be closed. :(
-Tero
^ permalink raw reply
* Add Allwinner Q8 tablets hardware manager
From: Pierre-Hugues Husson @ 2016-10-27 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4cfdd415-1965-7be9-b204-86a9931683a6@redhat.com>
2016-10-27 16:53 GMT+02:00 Hans de Goede <hdegoede@redhat.com>:
> Hi,
>
> No, the firmware-name (and matching resolution as different firmwares
> report different axis-ranges for the same digitizer) is selected
> primarily by the touchscreen_variant which sets: touchscreen_fw_name,
> touchscreen_width and touchscreen_height.
>
> The touchscreen_variant module option defaults to -1 which means "auto",
> when it is auto it gets set based on the touchscreen / accelerometer
> combination (which more or less uniquely identifies boards sofar),
> likewise all the other touchscreen module options default to -1,
> but can be overridden from the commandline.
>
> The intention is for things to just work, the commandline options are
> there as a fallback.
Ok, so I was really off. Sorry.
Now I think I understand the full complexity of the problem.
> We could just have:
>
> i2c-probe-stop-at-first-match-0 = <&touchscreen1>, <&touchscreen2>,
> <&touchscreen3>;
> i2c-probe-stop-at-first-match-1 = <&accelerometer1>,
> <&accelerometer2>;
>
> And have the i2c bus code look for an i2c-probe-stop-at-first-match-[i++]
> property
> until it is not found. Having a child-node with its own compatible for this
> feels wrong, as it uses a hierarchy where there really is none.
Ok, looks much better indeed.
I had one case where accelerometers could be on either i2c1 or i2c5.
Do you think this could be handled as well, or this makes things much
more complicated to fit in the i2c driver?
> So this would require us to be able to filter (to use your example)
> on if another i2c device is found and on which address it is found,
> that does not even take the rda559x check into account and is
> going to cause interesting ordering issues, how do we know when
> we can actually do the filtering if some of the variables we are
> filtering on are set by other auto-detected paths. Which auto-detect /
> i2c-probe-stop-at-first-match list do we execute first ? Worse
> actually for accelerometer orientation I will likely need to
> set the mount-matrix based on the detected touchscreen ...
>
> The rda559x here is a sdio wifi chip, which is also connected to the
> i2c, and currently is detected through i2c to be able to separately
> identify 2 q8 boards which share the same touchscreen + accelerometer
> combination and who knows what other checks I or other people can
> come up with to differentiate board variants which do not have
> a simple eeprom to uniquely id them.
>
> So as said before, no this cannot be all done in dt without
> adding a turing complete language to dt, and that is just to
> select which touchscreen_variant to use.
Ok, now that I understand the scope of your needs.
I agree with you, this needs a (close to) turing complete language.
I'm still not really happy about doing it in a driver, but I agree the
full scope you need is scarce enough.
Assuming this is done in a driver, there would need to be some
plumbing between i2c-probe-stop-at-first-match, device's probe
function and your driver, so that your driver only does the various
if/cases and DT changes, but there is no actual device communication
done in that driver.
> Then there also the probem of the combinatorial explosion having
> not only 2 firmware files but also invert-x and invert-y flags causes:
> We have 2 revisions with each 2 different firmware-files (more actually
> but I've reduced the set since some firmwares are compatible) with each
> both the x- and / or y axis as normal or inverted, for a total of:
> 2 (revision) * 2 (firmware-files) * 2 (x-inverted or not) * 2 (y...) = 16
> touchscreen variants, which means dt nodes for touchscreen1 to touchscreen16
> and that is just the silead gsl1680, some of these tablets also have
> elan or zeitec touchscreen controllers.
>
> Now imagine what happens if a new board comes out which needs a 3th firmware
> file... I hope you can understand this is not a route I want to go.
Right, I agree with you.
> Another problem is that if a user encounters the need for a new firmware
> variant he can now not easily try this (where as before we had
> module options to separately override firmware-name, the size, etc.
>
> As written in my previous mail, this is all rather gsl1680 specific,
> and esp. being able to override the firmware-name, the size, etc.
> through module options is going to be useful (to ask endusers to test
> stuff without recompiling) on x86 too. So we will likely want to add
> most of the necessary stuff to the silead driver anyways.
That's not currently the case, but can't we assume it will become easy
for users to install a DT overlay?
This would drop all your needs of module parameters, and would
actually be more modulable than your current scheme.
It is a more longer term thought, and could instead apply to further
boards having the same sort of troubles as you, rather than for this
first driver.
^ permalink raw reply
* [RFC PATCH 0/5] Add an overlay manager to handle board capes
From: Rob Herring @ 2016-10-27 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4ca9db09-e52c-11ec-133b-8f193b9b7174@redhat.com>
On Thu, Oct 27, 2016 at 10:13 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 27-10-16 15:41, Rob Herring wrote:
>>
>> Please Cc the maintainers of drivers/of/.
>>
>> + Frank R, Hans, Dmitry S
>>
>> On Wed, Oct 26, 2016 at 9:57 AM, Antoine Tenart
>> <antoine.tenart@free-electrons.com> wrote:
>>>
>>> Hi all,
>>>
>>> Many boards now come with dips and compatible capes; among others the
>>> C.H.I.P, or Beaglebones. All these boards have a kernel implementing an
>>> out-of-tree "cape manager" which is used to detected capes, retrieve
>>> their description and apply a corresponding overlay. This series is an
>>> attempt to start a discussion, with an implementation of such a manager
>>> which is somehow generic (i.e. formats or cape detectors can be added).
>>> Other use cases could make use of this manager to dynamically load dt
>>> overlays based on some input / hw presence.
>>
>>
>> I'd like to see an input source be the kernel command line and/or a DT
>> chosen property. Another overlay manager was proposed not to long
>> ago[1] as well. There's also the Allwinner tablet use case from Hans
>> where i2c devices are probed and detected. That's not using overlays
>> currently, but maybe could.
>
>
> Actually I'm currently thinking in a different direction, which I
> think will be good for the boards where some ICs are frequently
> replaced by 2nd (and 3th and 4th) sources, rather then that we're
> dealing with an extension connector with capes / daughter boards.
>
> Although there is some overlap I'm starting to think that we need to
> treat these 2 cases differently. Let me quickly copy and paste
> the basic idea I've for the 2nd source touchscreen / accelerometer
> chip case:
>
> """
> The kernel actually already has a detect() method in struct i2c_driver,
> we could use that (we would need to implement it in drivers which do not
> have it yet). Note on second thought it seems it may be better to use
> probe() for this, see below.
>
> Then we could have something like this in dt:
>
> &i2c0 {
> touchscreen1: gsl1680 at 40 {
> reg = <0x40>;
> compatible = "silead,gsl1680";
> enable-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> status = "disabled";
> };
>
> touchscreen2: ektf2127 at 15 {
> reg = <0x15>;
Do you ever have different devices with the same address? That would
be somewhat problematic as really these should be
"touchscreen@<addr>".
> compatible = "elan,ektf2127";
> enable-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> status = "disabled";
> };
>
> i2c-probe-stop-at-first-match-0 = <&touchscreen1>, <&touchscreen2>;
> i2c-probe-stop-at-first-match-1 = <&accelerometer1>, <&accelerometer2>;
> }
>
> Which would make the i2c subsys call detect (*) on each device, until
> a device is found. Likewise we could have a "i2c-probe-all" property
> which also walks a list of phandles but does not stop on the first
> match.
>
> ...
>
> *) Yes this sounds Linux specific, but it really is just "execute
> to-be-probed
> device compatible specific detection method"
> """
Yeah, not a fan of these properties at first glance. Why can't you
just fail probe on the non-existent devices?
> This does not 100% solve all q8 issues (see the "Add Allwinner Q8 tablets
> hardware manager" thread), but does solve quite a bit of the use-case
> and this matches what many vendor os-images (typically android) are
> actually doing for these kind of boards.
BTW, I've been meaning to ask you if you are looking at the Android
side of things as well?
> As for the bits this does not solve, those are mostly board specific details
> which cannot be probed at all, and on x86 are typically solved in the device
> driver by doing a dmi check to identify the board and then apply a board
> specific workaround in the driver.
>
> I've come to believe that we should similarly delegate dealing this to
> device
> drivers in the devicetree case. Note that dt should still of course fully
> describe the hardware for normal hardware, the driver would just need to
> care
> about weird board quirks in certain exceptions.
Which is fine IMO, though I do think we should look at those cases
carefully to ensure they stay the exception.
> A more interesting problem here is that dt does not have something like
> DMI, there is the machine compatible, but that typically does not contain
> board revision info (where as DMI often does). I believe that this is
> actually something which should be fixed at the bootloader level
> have it prepend a new machine compatible which contains revision info.
>
> Hmm, if we make the bootloader prepend a new machine compatible which
> contains
> revision info, we could then trigger quirks on this and in some cases avoid
> the need for dealing with board quirks in the driver ...
That would work. Board and chip versions both need better handling in
kernel IMO.
QCom has a whole scheme around version numbering in compatible
strings. (Unfortunately, bootloaders only support their previous way
of doing things.)
> Note this is all very specific to dealing with board (revision) variants,
> for add-ons having the bootloader add info to the machine compatible does
> not seem the right solution.
Agreed.
Rob
^ permalink raw reply
* [linux-sunxi] [PATCH v5 2/7] ASoC: sunxi: Add a simple HDMI CODEC
From: Jean-Francois Moine @ 2016-10-27 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67cE8v3=XtTzDBst2D2U6wM8pffQYK9nEok+j4xnPT39A@mail.gmail.com>
On Fri, 28 Oct 2016 00:54:34 +0800
Chen-Yu Tsai <wens@csie.org> wrote:
> There's already a driver for basically the same thing:
>
> sound/soc/codec/hdmi-codec.c
>
> You use it by registering a sub-device from your hdmi driver, with the
> proper platform_data and callbacks. Grep for HDMI_CODEC_DRV_NAME for
> platforms already using it.
I know that for a long time, and I will not use it on any account: it is
a gasworks!
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH 3/3] ARM: dts: exynos: Document eMMC/SD/SDIO devices in Exynos5800 Peach Pi board
From: Javier Martinez Canillas @ 2016-10-27 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477588303-13681-1-git-send-email-javier@osg.samsung.com>
There's a cognitive load to figure out which mmc device nodes corresponds
to the eMMC flash, uSD card and WiFI SDIO module on the Peach Pi board.
So it's better to have comments in the DTS to make this more clear.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm/boot/dts/exynos5800-peach-pi.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 01f466816fea..f9ff7f07ae0c 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -665,6 +665,7 @@
status = "okay";
};
+/* eMMC flash */
&mmc_0 {
status = "okay";
num-slots = <1>;
@@ -683,6 +684,7 @@
bus-width = <8>;
};
+/* WiFi SDIO module */
&mmc_1 {
status = "okay";
num-slots = <1>;
@@ -702,6 +704,7 @@
vqmmc-supply = <&buck10_reg>;
};
+/* uSD card */
&mmc_2 {
status = "okay";
num-slots = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: exynos: Document eMMC/SD/SDIO devices in Exynos5420 Pit board
From: Javier Martinez Canillas @ 2016-10-27 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477588303-13681-1-git-send-email-javier@osg.samsung.com>
There's a cognitive load to figure out which mmc device nodes corresponds
to the eMMC flash, uSD card and WiFI SDIO module on the Peach Pit board.
So it's better to have comments in the DTS to make this more clear.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index ec4a00f1ce01..1f964ec35c5e 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -697,6 +697,7 @@
status = "okay";
};
+/* eMMC flash */
&mmc_0 {
status = "okay";
num-slots = <1>;
@@ -714,6 +715,7 @@
bus-width = <8>;
};
+/* WiFi SDIO module */
&mmc_1 {
status = "okay";
num-slots = <1>;
@@ -733,6 +735,7 @@
vqmmc-supply = <&buck10_reg>;
};
+/* uSD card */
&mmc_2 {
status = "okay";
num-slots = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: exynos: Document eMMC/SD/SDIO devices in Exynos5250 Snow board
From: Javier Martinez Canillas @ 2016-10-27 17:11 UTC (permalink / raw)
To: linux-arm-kernel
There's a cognitive load to figure out which mmc device node corresponds
to the eMMC flash, uSD card and WiFI SDIO module on the Snow boards.
So it's better to have comments in the DTS to make this more clear.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index d5d51916bb74..8f3a80430748 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -523,6 +523,7 @@
status = "okay";
};
+/* eMMC flash */
&mmc_0 {
status = "okay";
num-slots = <1>;
@@ -536,6 +537,7 @@
cap-mmc-highspeed;
};
+/* uSD card */
&mmc_2 {
status = "okay";
num-slots = <1>;
@@ -553,6 +555,8 @@
/*
* On Snow we've got SIP WiFi and so can keep drive strengths low to
* reduce EMI.
+ *
+ * WiFi SDIO module
*/
&mmc_3 {
status = "okay";
--
2.7.4
^ permalink raw reply related
* Add Allwinner Q8 tablets hardware manager
From: Pantelis Antoniou @ 2016-10-27 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ-oXjT=eVwEk7t5WoZAhjMhiZZkq0NN5tFLidSnUNO97D62zQ@mail.gmail.com>
Hi Pierre,
> On Oct 27, 2016, at 19:59 , Pierre-Hugues Husson <phh@phh.me> wrote:
>
> 2016-10-27 17:52 GMT+02:00 Pantelis Antoniou <pantelis.antoniou@konsulko.com>:
>> Yes there is no EEPROM but you might be able to map probing results to
>> a fake ?model? number.
>>
>> Let me expand a bit:
>>
>> Assume that you have a number of probing steps, for example A, B, C each
>> returning true or false, and C being executed only when B is ?true? you
>> could do this to generate a bit field that identifies it.
>>
>> For example let?s assume that model FOO?s probing steps are
>>
>> A false, B true, C false -> 010
>>
>> Model?s BAR
>>
>> A true, B false, C don?t care -> 10x
>>
>> Mapping these to models could be
>>
>> Model FOO, (010 & 111) == 010 (all three probing steps must match)
>>
>> Model BAR, (10x & 110) = 100 (the first two probing steps must match)
>
> This method looks too complex on multiple grounds.
> Assuming your method, I'm not too sure how this would actually be
> described in a DTS.
> Such probing steps should include reading/matching IDs in an EEPROM/on
> an ADC, but it should also include the result of a driver's probe.
> Also, drivers should have a way to report an ID/OTP instead of just a
> boolean.
>
Err, I don?t think you got the point.
The probing steps are done by a board specific probe driver.
This driver performs the probing steps (which is exactly what Hans?s
method now does) but instead of applying changes to the device tree
programmatically generates a model string.
This model string can be used by a general purpose overlay manager to apply
the overlay(s) for the specific board. The plural part is important - read
below.
> As you mentioned, it is a way to distinguish models, not just a set of
> parameters.
> Does this mean that this DT would lead to loading various DT based on
> the matching model, which would look like a FIT?
> Also there is a modularity problem there. If I have phones with either
> screen A or screen B, and with either accelerometer A or accelerometer
> B, I would have to implement all four combinations.
>
The model lookup need not result in a simple overlay to apply.
So for your case it would be:
model corp,0 -> overlay screen A + overlay accel A
model corp,1 -> overlay screen A + overlay accel B
model corp,2 -> overlay screen B + overlay accel A
model corp,3 -> overlay screen B + overlay accel B
You don?t need the combinatorial number of overlays.
> I'm starting to agree with Hans, and to be able to implement
> everything he needs, would require a turing complete device-tree,
> which can include and apply device-tree overlays.
> This doesn't mean it can't be done, nor that it shouldn't be done, but
> that's a lot of work.
>
> Hans' i2c-probe-stop-at-first-match does make sense for most usecases,
> but I have two problems with it:
> 1. It is I2C specific (as I've mentioned earlier, I have the same
> needs with DSI panels)
> 2. This looks like a temporary solution if a turing-complete solution
> is to be implemented.
A custom I2C method would not be optimal IMO.
Regards
? Pantelis
^ permalink raw reply
* SMR masking and PCI
From: Stuart Yoder @ 2016-10-27 17:10 UTC (permalink / raw)
To: linux-arm-kernel
Hi Robin,
A question about how the SMR masking defined in the arm,smmu binding
relates to the PCI iommu-map.
The #iommu-cells property defines the number of cells an "IOMMU specifier"
takes and 2 is specified to be:
SMMUs with stream matching support and complex masters
may use a value of 2, where the second cell represents
an SMR mask to combine with the ID in the first cell.
An iommu-map entry is defined as:
(rid-base,iommu,iommu-base,length)
What seems to be currently missing in the iommu-map support is
the possibility the case where #iommu-cells=<2>.
In this case iommu-base which is an IOMMU specifier should
occupy 2 cells. For example on an ls2085a we would want:
iommu-map = <0x0 0x6 0x7 0x3ff 0x1
0x100 0x6 0x8 0x3ff 0x1>;
...to mask our stream IDs to 10 bits.
This should work in theory and comply with the bindings, no?
of_pci_map_rid() seems to have a hardcoded assumption that
each field in the map is 4 bytes.
(Also, I guess that msi-map is not affected by this since it
is not related to the IOMMU...but we do have common code
handling both maps.)
Thanks,
Stuart
^ permalink raw reply
* [PATCH V3 5/6] ARM: tegra: Add Tegra20 GMI support
From: kbuild test robot @ 2016-10-27 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477576872-2665-6-git-send-email-mirza.krak@gmail.com>
Hi Mirza,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.9-rc2 next-20161027]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/Mirza-Krak/clk-tegra-add-TEGRA20_CLK_NOR-to-init-table/20161027-225528
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-davinci_all_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> Error: arch/arm/boot/dts/tegra20.dtsi:1.1-8 syntax error
FATAL ERROR: Unable to parse input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 20355 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161028/4237b36b/attachment-0001.gz>
^ permalink raw reply
* Add Allwinner Q8 tablets hardware manager
From: Pierre-Hugues Husson @ 2016-10-27 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9B288597-7812-459D-A5C7-B61107751DA6@konsulko.com>
2016-10-27 17:52 GMT+02:00 Pantelis Antoniou <pantelis.antoniou@konsulko.com>:
> Yes there is no EEPROM but you might be able to map probing results to
> a fake ?model? number.
>
> Let me expand a bit:
>
> Assume that you have a number of probing steps, for example A, B, C each
> returning true or false, and C being executed only when B is ?true? you
> could do this to generate a bit field that identifies it.
>
> For example let?s assume that model FOO?s probing steps are
>
> A false, B true, C false -> 010
>
> Model?s BAR
>
> A true, B false, C don?t care -> 10x
>
> Mapping these to models could be
>
> Model FOO, (010 & 111) == 010 (all three probing steps must match)
>
> Model BAR, (10x & 110) = 100 (the first two probing steps must match)
This method looks too complex on multiple grounds.
Assuming your method, I'm not too sure how this would actually be
described in a DTS.
Such probing steps should include reading/matching IDs in an EEPROM/on
an ADC, but it should also include the result of a driver's probe.
Also, drivers should have a way to report an ID/OTP instead of just a
boolean.
As you mentioned, it is a way to distinguish models, not just a set of
parameters.
Does this mean that this DT would lead to loading various DT based on
the matching model, which would look like a FIT?
Also there is a modularity problem there. If I have phones with either
screen A or screen B, and with either accelerometer A or accelerometer
B, I would have to implement all four combinations.
I'm starting to agree with Hans, and to be able to implement
everything he needs, would require a turing complete device-tree,
which can include and apply device-tree overlays.
This doesn't mean it can't be done, nor that it shouldn't be done, but
that's a lot of work.
Hans' i2c-probe-stop-at-first-match does make sense for most usecases,
but I have two problems with it:
1. It is I2C specific (as I've mentioned earlier, I have the same
needs with DSI panels)
2. This looks like a temporary solution if a turing-complete solution
is to be implemented.
^ permalink raw reply
* [PATCH 1/2] ARM: memory: da8xx-ddrctl: new driver
From: Kevin Hilman @ 2016-10-27 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477503355-2600-2-git-send-email-bgolaszewski@baylibre.com>
Bartosz Golaszewski <bgolaszewski@baylibre.com> writes:
> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
[...]
> + for (; setting->name; setting++) {
> + knob = da8xx_ddrctl_match_knob(setting);
> + if (!knob) {
> + dev_warn(dev,
> + "no such config option: %s\n", setting->name);
> + continue;
> + }
> +
> + if (knob->reg > (res->end - res->start - sizeof(u32))) {
Why the "- sizeof(u32)"? Shouldn't this just be resource_size(res)?
(c.f. linux/ioport.h)
> + dev_warn(dev,
> + "register offset of '%s' exceeds mapped memory size\n",
> + knob->name);
> + continue;
> + }
> +
> + reg = __raw_readl(ddrctl + knob->reg);
> + reg &= knob->mask;
> + reg |= setting->val << knob->shift;
> +
> + dev_dbg(dev, "writing 0x%08x to %s\n", reg, setting->name);
> +
> + __raw_writel(reg, ddrctl + knob->reg);
Can you use the normal readl/writel here? Or explain why the raw ones
are needed?
> + }
> +
> + return 0;
> +}
> +
Otherwise, looks good to me. With the changes above, feel free to add
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Kevin
^ permalink raw reply
* [linux-sunxi] [PATCH v5 2/7] ASoC: sunxi: Add a simple HDMI CODEC
From: Chen-Yu Tsai @ 2016-10-27 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5cb540f20f64d28bd7dee82a0e14ee5209631979.1477142934.git.moinejf@free.fr>
On Fri, Oct 21, 2016 at 3:44 PM, Jean-Francois Moine <moinejf@free.fr> wrote:
> Allwinner's SoCs include support for both audio and video on HDMI.
> This patch defines a simple audio CODEC which may be used in sunxi
> HDMI video drivers.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
There's already a driver for basically the same thing:
sound/soc/codec/hdmi-codec.c
You use it by registering a sub-device from your hdmi driver, with the
proper platform_data and callbacks. Grep for HDMI_CODEC_DRV_NAME for
platforms already using it.
ChenYu
> ---
> include/sound/sunxi_hdmi.h | 23 +++++++++
> sound/soc/codecs/Kconfig | 9 ++++
> sound/soc/codecs/Makefile | 2 +
> sound/soc/codecs/sunxi-hdmi.c | 106 ++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 140 insertions(+)
> create mode 100644 include/sound/sunxi_hdmi.h
> create mode 100644 sound/soc/codecs/sunxi-hdmi.c
>
> diff --git a/include/sound/sunxi_hdmi.h b/include/sound/sunxi_hdmi.h
> new file mode 100644
> index 0000000..0986bb9
> --- /dev/null
> +++ b/include/sound/sunxi_hdmi.h
> @@ -0,0 +1,23 @@
> +#ifndef __SUNXI_HDMI_H__
> +#define __SUNXI_HDMI_H__
> +/*
> + * Copyright (C) 2016 Jean-Fran?ois Moine
> + *
> + * 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.
> + */
> +
> +struct sunxi_hdmi_codec {
> + u8 *eld;
> + int (*set_audio_input)(struct device *dev,
> + int enable,
> + unsigned sample_rate,
> + unsigned sample_bit);
> +};
> +
> +int sunxi_hdmi_codec_register(struct device *dev);
> +void sunxi_hdmi_codec_unregister(struct device *dev);
> +
> +#endif /* __SUNXI_HDMI_H__ */
> diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> index c67667b..53385b1 100644
> --- a/sound/soc/codecs/Kconfig
> +++ b/sound/soc/codecs/Kconfig
> @@ -131,6 +131,7 @@ config SND_SOC_ALL_CODECS
> select SND_SOC_STA529 if I2C
> select SND_SOC_STAC9766 if SND_SOC_AC97_BUS
> select SND_SOC_STI_SAS
> + select SND_SOC_SUNXI_HDMI
> select SND_SOC_TAS2552 if I2C
> select SND_SOC_TAS5086 if I2C
> select SND_SOC_TAS571X if I2C
> @@ -793,6 +794,14 @@ config SND_SOC_STAC9766
> config SND_SOC_STI_SAS
> tristate "codec Audio support for STI SAS codec"
>
> +config SND_SOC_SUNXI_HDMI
> + tristate "Allwinner sunxi HDMI Support"
> + default m if DRM_SUNXI_DE2_HDMI=m
> + default y if DRM_SUNXI_DE2_HDMI=y
> + select SND_PCM_ELD
> + help
> + Enable HDMI audio output
> +
> config SND_SOC_TAS2552
> tristate "Texas Instruments TAS2552 Mono Audio amplifier"
> depends on I2C
> diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
> index 958cd49..35804eb 100644
> --- a/sound/soc/codecs/Makefile
> +++ b/sound/soc/codecs/Makefile
> @@ -139,6 +139,7 @@ snd-soc-sta350-objs := sta350.o
> snd-soc-sta529-objs := sta529.o
> snd-soc-stac9766-objs := stac9766.o
> snd-soc-sti-sas-objs := sti-sas.o
> +snd-soc-sunxi-hdmi-objs := sunxi-hdmi.o
> snd-soc-tas5086-objs := tas5086.o
> snd-soc-tas571x-objs := tas571x.o
> snd-soc-tas5720-objs := tas5720.o
> @@ -359,6 +360,7 @@ obj-$(CONFIG_SND_SOC_STA350) += snd-soc-sta350.o
> obj-$(CONFIG_SND_SOC_STA529) += snd-soc-sta529.o
> obj-$(CONFIG_SND_SOC_STAC9766) += snd-soc-stac9766.o
> obj-$(CONFIG_SND_SOC_STI_SAS) += snd-soc-sti-sas.o
> +obj-$(CONFIG_SND_SOC_SUNXI_HDMI) += snd-soc-sunxi-hdmi.o
> obj-$(CONFIG_SND_SOC_TAS2552) += snd-soc-tas2552.o
> obj-$(CONFIG_SND_SOC_TAS5086) += snd-soc-tas5086.o
> obj-$(CONFIG_SND_SOC_TAS571X) += snd-soc-tas571x.o
> diff --git a/sound/soc/codecs/sunxi-hdmi.c b/sound/soc/codecs/sunxi-hdmi.c
> new file mode 100644
> index 0000000..0d08676
> --- /dev/null
> +++ b/sound/soc/codecs/sunxi-hdmi.c
> @@ -0,0 +1,106 @@
> +/*
> + * Allwinner HDMI codec
> + *
> + * Copyright (C) 2016 Jean-Francois Moine <moinejf@free.fr>
> + *
> + * 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.
> + */
> +
> +#include <linux/module.h>
> +#include <sound/soc.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <sound/pcm_drm_eld.h>
> +#include <sound/pcm_params.h>
> +
> +#include "sound/sunxi_hdmi.h"
> +
> +#define SUNXI_HDMI_FORMATS (SNDRV_PCM_FMTBIT_S8 | \
> + SNDRV_PCM_FMTBIT_S16_LE | \
> + SNDRV_PCM_FMTBIT_S20_3LE | \
> + SNDRV_PCM_FMTBIT_S24_LE | \
> + SNDRV_PCM_FMTBIT_S32_LE)
> +
> +static int sunxi_hdmi_codec_startup(struct snd_pcm_substream *substream,
> + struct snd_soc_dai *dai)
> +{
> + struct snd_pcm_runtime *runtime = substream->runtime;
> + struct sunxi_hdmi_codec *priv = dev_get_drvdata(dai->dev);
> + u8 *eld;
> +
> + eld = priv->eld;
> + if (!eld)
> + return -ENODEV;
> +
> + return snd_pcm_hw_constraint_eld(runtime, eld);
> +}
> +
> +static int sunxi_hdmi_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params,
> + struct snd_soc_dai *dai)
> +{
> + struct sunxi_hdmi_codec *priv = dev_get_drvdata(dai->dev);
> + unsigned sample_bit;
> +
> + if (params_format(params) == SNDRV_PCM_FORMAT_S16_LE)
> + sample_bit = 16;
> + else
> + sample_bit = 24;
> +
> + return priv->set_audio_input(dai->dev, true,
> + params_rate(params),
> + sample_bit);
> +}
> +
> +static void sunxi_hdmi_codec_shutdown(struct snd_pcm_substream *substream,
> + struct snd_soc_dai *dai)
> +{
> + struct sunxi_hdmi_codec *priv = dev_get_drvdata(dai->dev);
> +
> + priv->set_audio_input(dai->dev, false, 0, 0);
> +}
> +
> +static const struct snd_soc_dai_ops sunxi_hdmi_codec_ops = {
> + .startup = sunxi_hdmi_codec_startup,
> + .hw_params = sunxi_hdmi_hw_params,
> + .shutdown = sunxi_hdmi_codec_shutdown,
> +};
> +
> +static struct snd_soc_dai_driver sunxi_hdmi_codec = {
> + .name = "hdmi", /* must be the name of the node in the DT */
> + .playback = {
> + .stream_name = "HDMI Playback",
> + .channels_min = 1,
> + .channels_max = 8,
> + .rates = SNDRV_PCM_RATE_CONTINUOUS,
> + .rate_min = 8000,
> + .rate_max = 192000,
> + .formats = SUNXI_HDMI_FORMATS,
> + },
> + .ops = &sunxi_hdmi_codec_ops,
> +};
> +
> +static const struct snd_soc_codec_driver sunxi_hdmi_codec_drv = {
> + .ignore_pmdown_time = true,
> +};
> +
> +/* functions called from the HDMI video driver */
> +int sunxi_hdmi_codec_register(struct device *dev)
> +{
> + return snd_soc_register_codec(dev, &sunxi_hdmi_codec_drv,
> + &sunxi_hdmi_codec, 1);
> +}
> +EXPORT_SYMBOL_GPL(sunxi_hdmi_codec_register);
> +
> +void sunxi_hdmi_codec_unregister(struct device *dev)
> +{
> + snd_soc_unregister_codec(dev);
> +}
> +EXPORT_SYMBOL_GPL(sunxi_hdmi_codec_unregister);
> +
> +MODULE_AUTHOR("Jean-Francois Moine <moinejf@free.fr>");
> +MODULE_DESCRIPTION("Allwinner HDMI CODEC");
> +MODULE_LICENSE("GPL");
> --
> 2.10.1
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH v3] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Eric Anholt @ 2016-10-27 16:52 UTC (permalink / raw)
To: linux-arm-kernel
From: Linus Walleij <linus.walleij@linaro.org>
The idea is to give useful names to GPIO lines that an implementer
will be using from userspace, e.g. for maker type projects. These are
user-visible using tools/gpio/lsgpio.c
v2: Major rewrite by anholt: Flatten each GPIO line to a line in the
file for better diffing, prefix all expansion header pins with
"P<number>" or "P5HEADER_P<number>" and drop the mostly-unused
GPIO_GEN<smallnumber> names in favor of GPIO<socgpionumber>, fix
extra '[]' on a couple of lines, fix locations of SD_CARD_DETECT,
CAM_GPIO and STATUS_LED, fix HDMI_HPD polarities, rewrite A+ using
unreleased schematics.
v3: More changes by anholt: Drop P<number> / P5HEADER<number>
prefixes. I had been skeptical about adding them, and was
convinced to drop them by Gottfried (who probably has more
experience with GPIOs in educational contexts than the rest of
us). Also drop [] brackets for "is pinmuxed", which didn't seem
to clarify, and were ambiguous for things like the SPI_*-labeled
pins which may or may not actually be pinmuxed to SPI.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
---
arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 65 +++++++++++++++++++++++++++++++
arch/arm/boot/dts/bcm2835-rpi-a.dts | 67 ++++++++++++++++++++++++++++++++
arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 66 +++++++++++++++++++++++++++++++
arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 66 +++++++++++++++++++++++++++++++
arch/arm/boot/dts/bcm2835-rpi-b.dts | 67 ++++++++++++++++++++++++++++++++
5 files changed, 331 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
index 21507c922783..5a22c7965f34 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
@@ -22,6 +22,71 @@
};
&gpio {
+ /*
+ * This is based on the unreleased schematic for the Model A+.
+ *
+ * Legend:
+ * "NC" = not connected (no rail from the SoC)
+ * "FOO" = GPIO line named "FOO" on the schematic
+ * "FOO_N" = GPIO line named "FOO" on schematic, active low
+ */
+ gpio-line-names = "SDA0",
+ "SCL0",
+ "SDA1",
+ "SCL1",
+ "GPIO_GCLK",
+ "GPIO5",
+ "GPIO6",
+ "SPI_CE1_N",
+ "SPI_CE0_N",
+ "SPI_MISO",
+ "SPI_MOSI",
+ "SPI_SCLK",
+ "GPIO12",
+ "GPIO13",
+ /* Serial port */
+ "TXD0",
+ "RXD0",
+ "GPIO16",
+ "GPIO17",
+ "GPIO18",
+ "GPIO19",
+ "GPIO20",
+ "GPIO21",
+ "GPIO22",
+ "GPIO23",
+ "GPIO24",
+ "GPIO25",
+ "GPIO26",
+ "GPIO27",
+ "SDA0",
+ "SCL0",
+ "NC", /* GPIO30 */
+ "NC", /* GPIO31 */
+ "NC", /* GPIO32 */
+ "NC", /* GPIO33 */
+ "NC", /* GPIO34 */
+ "PWR_LOW_N", /* GPIO35 */
+ "NC", /* GPIO36 */
+ "NC", /* GPIO37 */
+ "NC", /* GPIO38 */
+ "NC", /* GPIO39 */
+ "PWM0_OUT", /* GPIO40 */
+ "CAM_GPIO0", /* GPIO41 */
+ "NC", /* GPIO42 */
+ "NC", /* GPIO43 */
+ "NC", /* GPIO44 */
+ "PWM1_OUT", /* GPIO45 */
+ "HDMI_HPD_N",
+ "STATUS_LED",
+ /* Used by SD Card */
+ "SD_CLK_R",
+ "SD_CMD_R",
+ "SD_DATA0_R",
+ "SD_DATA1_R",
+ "SD_DATA2_R",
+ "SD_DATA3_R";
+
pinctrl-0 = <&gpioout &alt0 &i2s_alt0>;
/* I2S interface */
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a.dts b/arch/arm/boot/dts/bcm2835-rpi-a.dts
index 5afba0900449..54f98c59a75d 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a.dts
@@ -15,6 +15,73 @@
};
&gpio {
+ /*
+ * Taken from Raspberry-Pi-Rev-1.0-Model-AB-Schematics.pdf
+ * RPI00021 sheet 02
+ *
+ * Legend:
+ * "NC" = not connected (no rail from the SoC)
+ * "FOO" = GPIO line named "FOO" on the schematic
+ * "FOO_N" = GPIO line named "FOO" on schematic, active low
+ */
+ gpio-line-names = "SDA0",
+ "SCL0",
+ "SDA1",
+ "SCL1",
+ "GPIO_GCLK",
+ "CAM_CLK",
+ "LAN_RUN",
+ "SPI_CE1_N",
+ "SPI_CE0_N",
+ "SPI_MISO",
+ "SPI_MOSI",
+ "SPI_SCLK",
+ "NC", /* GPIO12 */
+ "NC", /* GPIO13 */
+ /* Serial port */
+ "TXD0",
+ "RXD0",
+ "STATUS_LED_N",
+ "GPIO17",
+ "GPIO18",
+ "NC", /* GPIO19 */
+ "NC", /* GPIO20 */
+ "GPIO21",
+ "GPIO22",
+ "GPIO23",
+ "GPIO24",
+ "GPIO25",
+ "NC", /* GPIO26 */
+ "CAM_GPIO",
+ /* Binary number representing build/revision */
+ "CONFIG0",
+ "CONFIG1",
+ "CONFIG2",
+ "CONFIG3",
+ "NC", /* GPIO32 */
+ "NC", /* GPIO33 */
+ "NC", /* GPIO34 */
+ "NC", /* GPIO35 */
+ "NC", /* GPIO36 */
+ "NC", /* GPIO37 */
+ "NC", /* GPIO38 */
+ "NC", /* GPIO39 */
+ "PWM0_OUT",
+ "NC", /* GPIO41 */
+ "NC", /* GPIO42 */
+ "NC", /* GPIO43 */
+ "NC", /* GPIO44 */
+ "PWM1_OUT",
+ "HDMI_HPD_P",
+ "SD_CARD_DET",
+ /* Used by SD Card */
+ "SD_CLK_R",
+ "SD_CMD_R",
+ "SD_DATA0_R",
+ "SD_DATA1_R",
+ "SD_DATA2_R",
+ "SD_DATA3_R";
+
pinctrl-0 = <&gpioout &alt0 &i2s_alt2>;
/* I2S interface */
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
index 38f66aa244fe..f4bd78352a28 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
@@ -23,6 +23,72 @@
};
&gpio {
+ /*
+ * Taken from Raspberry-Pi-B-Plus-V1.2-Schematics.pdf
+ * RPI-BPLUS sheet 1
+ *
+ * Legend:
+ * "NC" = not connected (no rail from the SoC)
+ * "FOO" = GPIO line named "FOO" on the schematic
+ * "FOO_N" = GPIO line named "FOO" on schematic, active low
+ */
+ gpio-line-names = "ID_SD",
+ "ID_SC",
+ "SDA1",
+ "SCL1",
+ "GPIO_GCLK",
+ "GPIO5",
+ "GPIO6",
+ "SPI_CE1_N",
+ "SPI_CE0_N",
+ "SPI_MISO",
+ "SPI_MOSI",
+ "SPI_SCLK",
+ "GPIO12",
+ "GPIO13",
+ /* Serial port */
+ "TXD0",
+ "RXD0",
+ "GPIO16",
+ "GPIO17",
+ "GPIO18",
+ "GPIO19",
+ "GPIO20",
+ "GPIO21",
+ "GPIO22",
+ "GPIO23",
+ "GPIO24",
+ "GPIO25",
+ "GPIO26",
+ "GPIO27",
+ "SDA0",
+ "SCL0",
+ "NC", /* GPIO30 */
+ "LAN_RUN", /* GPIO31 */
+ "CAM_GPIO1", /* GPIO32 */
+ "NC", /* GPIO33 */
+ "NC", /* GPIO34 */
+ "PWR_LOW_N", /* GPIO35 */
+ "NC", /* GPIO36 */
+ "NC", /* GPIO37 */
+ "NC", /* GPIO38 */
+ "NC", /* GPIO39 */
+ "PWM0_OUT", /* GPIO40 */
+ "CAM_GPIO0", /* GPIO41 */
+ "NC", /* GPIO42 */
+ "NC", /* GPIO43 */
+ "ETHCLK", /* GPIO44 */
+ "PWM1_OUT", /* GPIO45 */
+ "HDMI_HPD_N",
+ "STATUS_LED",
+ /* Used by SD Card */
+ "SD_CLK_R",
+ "SD_CMD_R",
+ "SD_DATA0_R",
+ "SD_DATA1_R",
+ "SD_DATA2_R",
+ "SD_DATA3_R";
+
pinctrl-0 = <&gpioout &alt0 &i2s_alt0>;
/* I2S interface */
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
index 75e045aba7ce..9d1d4c6ce1f0 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
@@ -16,6 +16,72 @@
};
&gpio {
+ /*
+ * Taken from Raspberry-Pi-Rev-2.0-Model-AB-Schematics.pdf
+ * RPI00022 sheet 02
+ *
+ * Legend:
+ * "NC" = not connected (no rail from the SoC)
+ * "FOO" = GPIO line named "FOO" on the schematic
+ * "FOO_N" = GPIO line named "FOO" on schematic, active low
+ */
+ gpio-line-names = "SDA0",
+ "SCL0",
+ "SDA1",
+ "SCL1",
+ "GPIO_GCLK",
+ "CAM_CLK",
+ "LAN_RUN",
+ "SPI_CE1_N",
+ "SPI_CE0_N",
+ "SPI_MISO",
+ "SPI_MOSI",
+ "SPI_SCLK",
+ "NC", /* GPIO12 */
+ "NC", /* GPIO13 */
+ /* Serial port */
+ "TXD0",
+ "RXD0",
+ "STATUS_LED_N",
+ "GPIO17",
+ "GPIO18",
+ "NC", /* GPIO19 */
+ "NC", /* GPIO20 */
+ "CAM_GPIO",
+ "GPIO22",
+ "GPIO23",
+ "GPIO24",
+ "GPIO25",
+ "NC", /* GPIO 26 */
+ "GPIO27",
+ "GPIO28",
+ "GPIO29",
+ "GPIO30",
+ "GPIO31",
+ "NC", /* GPIO32 */
+ "NC", /* GPIO33 */
+ "NC", /* GPIO34 */
+ "NC", /* GPIO35 */
+ "NC", /* GPIO36 */
+ "NC", /* GPIO37 */
+ "NC", /* GPIO38 */
+ "NC", /* GPIO39 */
+ "PWM0_OUT",
+ "NC", /* GPIO41 */
+ "NC", /* GPIO42 */
+ "NC", /* GPIO43 */
+ "NC", /* GPIO44 */
+ "PWM1_OUT",
+ "HDMI_HPD_P",
+ "SD_CARD_DET",
+ /* Used by SD Card */
+ "SD_CLK_R",
+ "SD_CMD_R",
+ "SD_DATA0_R",
+ "SD_DATA1_R",
+ "SD_DATA2_R",
+ "SD_DATA3_R";
+
pinctrl-0 = <&gpioout &alt0 &i2s_alt2>;
/* I2S interface */
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index 76a254b3219a..71f50e16c646 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -16,6 +16,73 @@
};
&gpio {
+ /*
+ * Taken from Raspberry-Pi-Rev-1.0-Model-AB-Schematics.pdf
+ * RPI00021 sheet 02
+ *
+ * Legend:
+ * "NC" = not connected (no rail from the SoC)
+ * "FOO" = GPIO line named "FOO" on the schematic
+ * "FOO_N" = GPIO line named "FOO" on schematic, active low
+ */
+ gpio-line-names = "SDA0",
+ "SCL0",
+ "SDA1",
+ "SCL1",
+ "GPIO_GCLK",
+ "CAM_CLK",
+ "LAN_RUN",
+ "SPI_CE1_N",
+ "SPI_CE0_N",
+ "SPI_MISO",
+ "SPI_MOSI",
+ "SPI_SCLK",
+ "NC", /* GPIO12 */
+ "NC", /* GPIO13 */
+ /* Serial port */
+ "TXD0",
+ "RXD0",
+ "STATUS_LED_N",
+ "GPIO17",
+ "GPIO18",
+ "NC", /* GPIO19 */
+ "NC", /* GPIO20 */
+ "GPIO21",
+ "GPIO22",
+ "GPIO23",
+ "GPIO24",
+ "GPIO25",
+ "NC", /* GPIO26 */
+ "CAM_GPIO",
+ /* Binary number representing build/revision */
+ "CONFIG0",
+ "CONFIG1",
+ "CONFIG2",
+ "CONFIG3",
+ "NC", /* GPIO32 */
+ "NC", /* GPIO33 */
+ "NC", /* GPIO34 */
+ "NC", /* GPIO35 */
+ "NC", /* GPIO36 */
+ "NC", /* GPIO37 */
+ "NC", /* GPIO38 */
+ "NC", /* GPIO39 */
+ "PWM0_OUT",
+ "NC", /* GPIO41 */
+ "NC", /* GPIO42 */
+ "NC", /* GPIO43 */
+ "NC", /* GPIO44 */
+ "PWM1_OUT",
+ "HDMI_HPD_P",
+ "SD_CARD_DET",
+ /* Used by SD Card */
+ "SD_CLK_R",
+ "SD_CMD_R",
+ "SD_DATA0_R",
+ "SD_DATA1_R",
+ "SD_DATA2_R",
+ "SD_DATA3_R";
+
pinctrl-0 = <&gpioout &alt0>;
};
--
2.9.3
^ permalink raw reply related
* [PATCH v6 00/16] ACPI IORT ARM SMMU support
From: Lorenzo Pieralisi @ 2016-10-27 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0i=ZZDwnAU_=cAW5NR5M7EAOVPmpdqfMhf_jGmeZoHLVQ@mail.gmail.com>
On Thu, Oct 27, 2016 at 12:24:48PM +0200, Rafael J. Wysocki wrote:
> On Wed, Oct 26, 2016 at 1:04 PM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> > Rafael, Joerg (and anyone else CC'ed),
> >
> > On Tue, Oct 18, 2016 at 05:03:58PM +0100, Lorenzo Pieralisi wrote:
> >> This patch series is v6 of a previous posting:
> >>
> >> https://lkml.org/lkml/2016/9/9/418
> >>
> >> v5 -> v6
> >> - Rebased against v4.9-rc1
> >> - Changed FWNODE_IOMMU to FWNODE_ACPI_STATIC
> >> - Moved platform devices creation into IORT code
> >> - Updated fwnode handling
> >> - Added default dma masks initialization
> >
> > Any comments on v6 ? Patches touching generic ACPI code
> > are {1, 2, 7}, patch 4 updates the IOMMU of_iommu_{set/get}_ops()
> > API to make it work on ACPI systems too, by replacing the
> > device_node with a fwnode_handle pointer as look-up token;
> > the remainder of patches are ARM specific and creates the
> > infrastructure to probe ARM SMMU devices through ACPI,
> > ARM IORT table in particular. Given the generic bits changes
> > above I would not leave it to late -rc to reach an agreement
> > please, thank you.
>
> I'll do my best to look at these in the next few days, but please also
> note what I wrote before:
>
> http://marc.info/?l=linux-acpi&m=147744344531599&w=2
Thanks, understood, I asked because if I have to respin it I'd like
to do it asap and the generic ACPI patches are simple but fundamental
to the series, anyway I think it is something we can manage next week
at LPC.
Thanks !
Lorenzo
^ permalink raw reply
* [PATCH] irq-bcm2836: Prevent spurious interrupts, and trap them early
From: Eric Anholt @ 2016-10-27 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027164051.22493-1-eric@anholt.net>
From: Phil Elwell <phil@raspberrypi.org>
The old arch-specific IRQ macros included a dsb to ensure the
write to clear the mailbox interrupt completed before returning
from the interrupt. The BCM2836 irqchip driver needs the same
precaution to avoid spurious interrupts.
Spurious interrupts are still possible for other reasons,
though, so trap them early.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
---
Phil, your patch didn't apply because it looks like you pasted into
gmail (tabs got converted to spaces). git-send-email can avoid that.
I've pulled it out of the rpi tree and applied the s-o-b from your
email.
Also, patches to lkml need to be sent to the relevant maintainers or
they won't get picked up. ./scripts/get_maintainer.pl <patch> can
give you the list of who to send to/cc.
drivers/irqchip/irq-bcm2836.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index d96b2c947e74..93e3f7660c42 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -175,6 +175,7 @@ __exception_irq_entry bcm2836_arm_irqchip_handle_irq(struct pt_regs *regs)
u32 ipi = ffs(mbox_val) - 1;
writel(1 << ipi, mailbox0);
+ dsb(sy);
handle_IPI(ipi, regs);
#endif
} else if (stat) {
--
2.9.3
^ permalink raw reply related
* [PATCH] irq-bcm2836: Prevent spurious interrupts, and trap them early
From: Eric Anholt @ 2016-10-27 16:40 UTC (permalink / raw)
To: linux-arm-kernel
From: Phil Elwell <phil@raspberrypi.org>
The old arch-specific IRQ macros included a dsb to ensure the
write to clear the mailbox interrupt completed before returning
from the interrupt. The BCM2836 irqchip driver needs the same
precaution to avoid spurious interrupts.
Spurious interrupts are still possible for other reasons,
though, so trap them early.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
---
Phil, your patch didn't apply because it looks like you pasted into
gmail (tabs got converted to spaces). git-send-email can avoid that.
I've pulled it out of the rpi tree and applied the s-o-b from your
email.
Also, patches to lkml need to be sent to the relevant maintainers or
they won't get picked up. ./scripts/get_maintainer.pl <patch> can
give you the list of who to send to/cc.
drivers/irqchip/irq-bcm2836.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index d96b2c947e74..93e3f7660c42 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -175,6 +175,7 @@ __exception_irq_entry bcm2836_arm_irqchip_handle_irq(struct pt_regs *regs)
u32 ipi = ffs(mbox_val) - 1;
writel(1 << ipi, mailbox0);
+ dsb(sy);
handle_IPI(ipi, regs);
#endif
} else if (stat) {
--
2.9.3
^ permalink raw reply related
* [PATCH v3] drivers: psci: PSCI checker module
From: Lorenzo Pieralisi @ 2016-10-27 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9cf15020-5116-5082-d3d3-fba80fe2de70@arm.com>
On Thu, Oct 27, 2016 at 05:06:00PM +0100, Kevin Brodsky wrote:
> On 27/10/16 15:54, Paul E. McKenney wrote:
> >On Thu, Oct 27, 2016 at 01:51:57PM +0100, Kevin Brodsky wrote:
> >> On 27/10/16 10:13, Lorenzo Pieralisi wrote:
> >>> On Wed, Oct 26, 2016 at 11:11:48AM -0700, Paul E. McKenney wrote:
> >>>> On Wed, Oct 26, 2016 at 06:35:34PM +0100, Lorenzo Pieralisi wrote:
> >>>>> On Wed, Oct 26, 2016 at 10:22:52AM -0700, Paul E. McKenney wrote:
> >>>>>> On Wed, Oct 26, 2016 at 06:10:06PM +0100, Lorenzo Pieralisi wrote:
> >>>> [ . . . ]
> >>>>
> >>>>>>> Thanks a lot for your feedback, thoughts appreciated.
> >>>>>> Let me ask the question more directly.
> >>>>>>
> >>>>>> Why on earth are we trying to run these tests concurrently?
> >>>>> We must prevent that, no question about that, that's why I started
> >>>>> this discussion. It is not fine to enable this checker and the
> >>>>> RCU/LOCK torture hotplug tests at the same time.
> >>>>>
> >>>>>> After all, if we just run one at a time in isolation, there is no
> >>>>>> problem.
> >>>>> Fine by me, it was to understand if the current assumptions we made
> >>>>> are correct and they are definitely not. If we enable the PSCI checker
> >>>>> we must disable the torture rcu/lock hotplug tests either statically or
> >>>>> dynamically.
> >>>> What rcutorture, locktorture, and rcuperf do is to invoke
> >>>> torture_init_begin(), which returns false if one of these tests
> >>>> is already running.
> >>>>
> >>>> Perhaps we should extract this torture-test-exclusion and require
> >>>> than conflicting torture tests invoke it?
> >>> Yes if it can be extracted as a check (but it should also prevent the
> >>> torture tests from running and vice versa), either that or Kconfig
> >>> dependency (which we could do as a first step, waiting to add the
> >>> required interface to the torture test code ?).
> >>>
> >>> Thanks !
> >>> Lorenzo
> >>
> >> That sounds like a reasonable idea, but then that would mean that the PSCI checker
> >> would have to wait until the torture test is finished if it is already running (and
> >> the other way around).
> >>
> >> I wasn't aware that torture tests were hotplugging CPUs. I think that the most
> >> sensible thing to do right now is to make CONFIG_PSCI_CHECKER depend on
> >> !CONFIG_TORTURE_TEST (or maybe specifically !CONFIG_RCU_TORTURE_TEST &&
> >> !CONFIG_LOCK_TORTURE_TEST). We can try to make them work together afterwards, but for
> >> the sake of getting this patch merged in a reasonable amount of time, I think we
> >> should just exclude the conflicting tests at the build level in this patch. I'll also
> >> update the comment accordingly.
> >
> >I suggest !CONFIG_TORTURE_TEST, given that there are a couple of other
> >tests in the offing.
> >
> > Thanx, Paul
>
> Fair enough. If that's fine with Lorenzo, I'll add the dependency and post v4.
Yes, that's fine by me, thanks a lot !
Lorenzo
^ permalink raw reply
* [RFC PATCH v2 8/8] arm64: Wire up and expose the new compat vDSO
From: Kevin Brodsky @ 2016-10-27 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027163058.12156-1-kevin.brodsky@arm.com>
Expose the new compat vDSO via the COMPAT_VDSO config option.
The option is not enabled in defconfig for two reasons:
* 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.
* We really need a 32-bit compiler this time, and we rely on the user
to provide it themselves by setting CROSS_COMPILE_ARM32. Therefore
enabling the option by default would make little sense, since the
user must explicitly set an environment variable anyway.
CONFIG_COMPAT_VDSO is not directly used in the code, because we want
to ignore it (build as if it were not set) if the user didn't set
CROSS_COMPILE_ARM32 properly. If the variable has been set to a valid
prefix, CONFIG_VDSO32 will be set; this is the option that the code
and Makefiles test.
For more flexibility, like CROSS_COMPILE, CROSS_COMPILE_ARM32 can also
be set via CONFIG_CROSS_COMPILE_ARM32 (the environment variable
overrides the config option).
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
---
arch/arm64/Kconfig | 26 ++++++++++++++++++++++++++
arch/arm64/Makefile | 28 ++++++++++++++++++++++++++--
arch/arm64/kernel/Makefile | 8 ++++++--
3 files changed, 58 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 969ef880d234..883e50def0eb 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1017,6 +1017,32 @@ config SYSVIPC_COMPAT
def_bool y
depends on COMPAT && SYSVIPC
+config COMPAT_VDSO
+ bool "32-bit vDSO"
+ depends on COMPAT
+ default n
+ help
+ Warning: this completely removes the compat vector page, including
+ kuser helpers, which may break 32-bit processes.
+
+ Warning: a 32-bit toolchain is necessary to build the vDSO. You
+ must explicitly define which toolchain should be used by setting
+ CROSS_COMPILE_ARM32 to the prefix of the 32-bit toolchain (same format
+ as CROSS_COMPILE). If a 32-bit compiler cannot be found, a warning
+ will be printed and the kernel will be built as if COMPAT_VDSO had not
+ been set.
+
+ Provide a vDSO to 32-bit processes. It includes the symbols provided
+ by the vDSO from the 32-bit kernel, so that a 32-bit libc can use
+ the compat vDSO without modification. It also provides sigreturn
+ trampolines, and replaces the vector page.
+
+config CROSS_COMPILE_ARM32
+ string "32-bit toolchain prefix"
+ help
+ Same as setting CROSS_COMPILE_ARM32 in the environment, but saved for
+ future builds. The environment variable overrides this config option.
+
endmenu
menu "Power management options"
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 3635b8662724..370d8de0c100 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -37,10 +37,32 @@ $(warning LSE atomics not supported by binutils)
endif
endif
-KBUILD_CFLAGS += -mgeneral-regs-only $(lseinstr)
+ifeq ($(CONFIG_COMPAT_VDSO), y)
+ CROSS_COMPILE_ARM32 ?= $(CONFIG_CROSS_COMPILE_ARM32:"%"=%)
+
+ # Check that the user has provided a valid prefix for the 32-bit toolchain.
+ # To prevent selecting the system gcc by default, the prefix is not allowed to
+ # be empty, unlike CROSS_COMPILE. In the unlikely event that the system gcc
+ # is actually the 32-bit ARM compiler to be used, the variable can be set to
+ # the dirname (e.g. CROSS_COMPILE_ARM32=/usr/bin/).
+ # Note: this Makefile is read both before and after regenerating the
+ # config (if needed). Any warning appearing before the config has been
+ # regenerated should be ignored.
+ ifeq ($(CROSS_COMPILE_ARM32),)
+ $(warning CROSS_COMPILE_ARM32 not defined or empty, the compat vDSO will not be built)
+ else ifeq ($(shell which $(CROSS_COMPILE_ARM32)gcc 2> /dev/null),)
+ $(warning $(CROSS_COMPILE_ARM32)gcc not found, the compat vDSO will not be built)
+ else
+ export CROSS_COMPILE_ARM32
+ export CONFIG_VDSO32 := y
+ vdso32 := -DCONFIG_VDSO32=1
+ endif
+endif
+
+KBUILD_CFLAGS += -mgeneral-regs-only $(lseinstr) $(vdso32)
KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
KBUILD_CFLAGS += $(call cc-option, -mpc-relative-literal-loads)
-KBUILD_AFLAGS += $(lseinstr)
+KBUILD_AFLAGS += $(lseinstr) $(vdso32)
ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
KBUILD_CPPFLAGS += -mbig-endian
@@ -139,6 +161,8 @@ archclean:
prepare: vdso_prepare
vdso_prepare: prepare0
$(Q)$(MAKE) $(build)=arch/arm64/kernel/vdso include/generated/vdso-offsets.h
+ $(if $(CONFIG_VDSO32),$(Q)$(MAKE) $(build)=arch/arm64/kernel/vdso32 \
+ include/generated/vdso32-offsets.h)
define archhelp
echo '* Image.gz - Compressed kernel image (arch/$(ARCH)/boot/Image.gz)'
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 7d66bbaafc0c..1487f8cd06dd 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -27,8 +27,11 @@ OBJCOPYFLAGS := --prefix-symbols=__efistub_
$(obj)/%.stub.o: $(obj)/%.o FORCE
$(call if_changed,objcopy)
-arm64-obj-$(CONFIG_COMPAT) += sys32.o kuser32.o signal32.o \
- sys_compat.o entry32.o
+arm64-obj-$(CONFIG_COMPAT) += sys32.o signal32.o sys_compat.o \
+ entry32.o
+ifneq ($(CONFIG_VDSO32),y)
+arm64-obj-y += kuser32.o
+endif
arm64-obj-$(CONFIG_FUNCTION_TRACER) += ftrace.o entry-ftrace.o
arm64-obj-$(CONFIG_MODULES) += arm64ksyms.o module.o
arm64-obj-$(CONFIG_ARM64_MODULE_PLTS) += module-plts.o
@@ -52,6 +55,7 @@ arm64-obj-$(CONFIG_KEXEC) += machine_kexec.o relocate_kernel.o \
cpu-reset.o
obj-y += $(arm64-obj-y) vdso/ probes/
+obj-$(CONFIG_VDSO32) += vdso32/
obj-m += $(arm64-obj-m)
head-y := head.o
extra-y += $(head-y) vmlinux.lds
--
2.10.0
^ permalink raw reply related
* [RFC PATCH v2 7/8] arm64: compat: Use vDSO sigreturn trampolines if available
From: Kevin Brodsky @ 2016-10-27 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027163058.12156-1-kevin.brodsky@arm.com>
If the compat vDSO is enabled, it replaces the vector page. Therefore,
we use the sigreturn trampolines it provides instead of those in the
vector page.
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
---
arch/arm64/include/asm/vdso.h | 3 +++
arch/arm64/kernel/signal32.c | 15 +++++++++++++++
2 files changed, 18 insertions(+)
diff --git a/arch/arm64/include/asm/vdso.h b/arch/arm64/include/asm/vdso.h
index 839ce0031bd5..f2a952338f1e 100644
--- a/arch/arm64/include/asm/vdso.h
+++ b/arch/arm64/include/asm/vdso.h
@@ -28,6 +28,9 @@
#ifndef __ASSEMBLY__
#include <generated/vdso-offsets.h>
+#ifdef CONFIG_VDSO32
+#include <generated/vdso32-offsets.h>
+#endif
#define VDSO_SYMBOL(base, name) \
({ \
diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
index 9de7d128e0e0..b72a4180a531 100644
--- a/arch/arm64/kernel/signal32.c
+++ b/arch/arm64/kernel/signal32.c
@@ -28,6 +28,7 @@
#include <asm/signal32.h>
#include <asm/uaccess.h>
#include <asm/unistd.h>
+#include <asm/vdso.h>
struct compat_vfp_sigframe {
compat_ulong_t magic;
@@ -438,6 +439,19 @@ static void compat_setup_return(struct pt_regs *regs, struct k_sigaction *ka,
retcode = ptr_to_compat(ka->sa.sa_restorer);
} else {
/* Set up sigreturn pointer */
+#ifdef CONFIG_VDSO32
+ void *vdso_page = current->mm->context.vdso;
+ void *trampoline =
+ (ka->sa.sa_flags & SA_SIGINFO
+ ? (thumb
+ ? VDSO_SYMBOL(vdso_page, compat_rt_sigreturn_thumb)
+ : VDSO_SYMBOL(vdso_page, compat_rt_sigreturn_arm))
+ : (thumb
+ ? VDSO_SYMBOL(vdso_page, compat_sigreturn_thumb)
+ : VDSO_SYMBOL(vdso_page, compat_sigreturn_arm)));
+
+ retcode = ptr_to_compat(trampoline) + thumb;
+#else
unsigned int idx = thumb << 1;
if (ka->sa.sa_flags & SA_SIGINFO)
@@ -446,6 +460,7 @@ static void compat_setup_return(struct pt_regs *regs, struct k_sigaction *ka,
retcode = AARCH32_VECTORS_BASE +
AARCH32_KERN_SIGRET_CODE_OFFSET +
(idx << 2) + thumb;
+#endif
}
regs->regs[0] = usig;
--
2.10.0
^ permalink raw reply related
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