* [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
* 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 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
* 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
* 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
* [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
* [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 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
* [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
* [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
* 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
* [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
* [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 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 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 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: 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 v6] tty/serial: at91: fix hardware handshake on Atmel platforms
From: Uwe Kleine-König @ 2016-10-27 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027160406.25738-1-richard.genoud@gmail.com>
Hello Richard,
On Thu, Oct 27, 2016 at 06:04:06PM +0200, Richard Genoud wrote:
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index fd8aa1f4ba78..168b10cad47b 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -2132,11 +2132,29 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
> mode |= ATMEL_US_USMODE_RS485;
> } else if (termios->c_cflag & CRTSCTS) {
> /* RS232 with hardware handshake (RTS/CTS) */
> - if (atmel_use_dma_rx(port) && !atmel_use_fifo(port)) {
> - dev_info(port->dev, "not enabling hardware flow control because DMA is used");
> - termios->c_cflag &= ~CRTSCTS;
> - } else {
> + if (atmel_use_fifo(port) &&
> + !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
> + /*
> + * with ATMEL_US_USMODE_HWHS set, the controller will
> + * be able to drive the RTS pin high/low when the RX
> + * FIFO is above RXFTHRES/below RXFTHRES2.
> + * It will also disable the transmitter when the CTS
> + * pin is high.
> + * This mode is not activated if CTS pin is a GPIO
> + * because in this case, the transmitter is always
> + * disabled (there must be an internal pull-up
> + * responsible for this behaviour).
> + * If the RTS pin is a GPIO, the controller won't be
> + * able to drive it according to the FIFO thresholds,
> + * but it will be handled by the driver.
> + */
> mode |= ATMEL_US_USMODE_HWHS;
You use
!mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)
as indicator that the cts mode of the respective pin is used. Is this
reliable? (It's not if there are machines that don't use CTS, neither as
gpio nor using the hardware function.) Maybe this needs a dt property to
indicate that there is no (hw)handshaking available?
> + } else {
> + ...
> }
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2] irqchip/bcm2836: Prevent spurious interrupts
From: Eric Anholt @ 2016-10-27 18:20 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.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
---
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 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027164051.22493-1-eric@anholt.net>
Eric Anholt <eric@anholt.net> writes:
> 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.
And then it was my turn to fumble a patch email. Autocompleted the
wrong version(s). Resending :(
^ permalink raw reply
* [linux-sunxi] [PATCH v5 2/7] ASoC: sunxi: Add a simple HDMI CODEC
From: Mark Brown @ 2016-10-27 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027191634.f2fa6478cd07d84a60274339@free.fr>
On Thu, Oct 27, 2016 at 07:16:34PM +0200, Jean-Francois Moine wrote:
> 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!
If there are problems with what's there then articulate them and fix
them, don't just open code something separate. Just open coding
something else without any articulated reasoning is not helping things.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161027/1b274085/attachment-0001.sig>
^ permalink raw reply
* [PATCH V3 5/6] ARM: tegra: Add Tegra20 GMI support
From: Mirza Krak @ 2016-10-27 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201610280016.MiLeMJw9%fengguang.wu@intel.com>
2016-10-27 19:09 GMT+02:00 kbuild test robot <lkp@intel.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
That one was embarrassing. Sorry...
Best Regards
Mirza
^ permalink raw reply
* [PATCH 0/3] Add memremap executable mapping and extend drivers/misc/sram.c
From: Dave Gerlach @ 2016-10-27 18:56 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
There are several instances when one would want to execute out of on-chip
SRAM, such as PM code on ARM platforms, so once again revisiting this
series to allow that in a generic manner. Seems that having a solution for
allowing SRAM to be mapped as executable will help clean up PM code on several
ARM platforms that are using ARM internal __arm_ioremap_exec API
and also open the door for PM support on new platforms like TI AM335x and
AM437x. This was last sent as RFC here [1] and based on comments from Russell
King and Arnd Bergmann has been rewritten to use memremap API rather than
ioremap API, as executable iomem does not really make sense.
I still see several platforms (at-91, imx6, socfpga) that could make use
of this and use the generic sram driver to allocate the SRAM needed for PM.
This series allows direct allocation of SRAM using the generic SRAM driver
that will be already mapped as executable. Otherwise platform SRAM allocation
code must be used or if the generic sram driver is used as-is the memory
must be remapped as executable after it has been mapped normally by the
SRAM driver.
I had sent omap3 series to convert from using old omap sram platform
mapping code to using the generic sram driver instead here [2] which was
based on previous RFC but can easily be rebased on this updated series.
Finally, forthcoming TI am335x and am437x PM code must make use of
it as well, as portions of PM code are moving in to drivers.
Changes from the RFC include:
- Rather than introduce ioremap_exec API, use memremap API, as the concept
of executable iomem does not make sense; any memory that can used to
run code should not have io side effects like iomem.
- Rather than having a fallback mapping if a platform does not support
exec mappings under the memremap API, have the mapping fail, as if you
are mapping memory as exec, presumably you will then try to run code
from it which will fail anyway, so it makes more sense to prevent the
mapping in the first place.
- Update sram driver to use memremap rather than ioremap for exec flags.
Regards,
Dave
[1] http://www.spinics.net/lists/arm-kernel/msg503071.html
[2] http://www.spinics.net/lists/linux-omap/msg128753.html
Dave Gerlach (3):
ARM: memremap: implement arch_memremap_exec/exec_nocache
memremap: add MEMREMAP_EXEC and MEMREMAP_EXEC_NOCACHE flags
misc: SRAM: Add option to map SRAM to allow code execution
Documentation/devicetree/bindings/sram/sram.txt | 2 ++
arch/arm/include/asm/io.h | 5 ++++
arch/arm/mm/ioremap.c | 16 ++++++++++++
arch/arm/mm/nommu.c | 12 +++++++++
drivers/misc/sram.c | 7 +++++
include/linux/io.h | 2 ++
kernel/memremap.c | 34 ++++++++++++++++++++++++-
7 files changed, 77 insertions(+), 1 deletion(-)
--
2.9.3
^ permalink raw reply
* [PATCH 1/3] ARM: memremap: implement arch_memremap_exec/exec_nocache
From: Dave Gerlach @ 2016-10-27 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027185612.22362-1-d-gerlach@ti.com>
Introduce arch_memremap_exec and arch_memremap_exec_nocache for ARM to
allow mapping of memory as executable. Some platforms have a requirement
to map on-chip memory, such as SRAM, to hold and run code that cannot be
executed in DRAM, such as low-level PM code or code to reconfigure the
DRAM controller itself.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
arch/arm/include/asm/io.h | 5 +++++
arch/arm/mm/ioremap.c | 16 ++++++++++++++++
arch/arm/mm/nommu.c | 12 ++++++++++++
3 files changed, 33 insertions(+)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 021692c64de3..67476a5add20 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -411,6 +411,11 @@ void __iomem *ioremap_wc(resource_size_t res_cookie, size_t size);
void iounmap(volatile void __iomem *iomem_cookie);
#define iounmap iounmap
+void *arch_memremap_exec(phys_addr_t phys_addr, size_t size);
+void *arch_memremap_exec_nocache(phys_addr_t phys_addr, size_t size);
+#define arch_memremap_exec arch_memremap_exec
+#define arch_memremap_exec_nocache arch_memremap_exec_nocache
+
void *arch_memremap_wb(phys_addr_t phys_addr, size_t size);
#define arch_memremap_wb arch_memremap_wb
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index ff0eed23ddf1..5c22a7a0b349 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -419,6 +419,22 @@ __arm_ioremap_exec(phys_addr_t phys_addr, size_t size, bool cached)
__builtin_return_address(0));
}
+void *arch_memremap_exec(phys_addr_t phys_addr, size_t size)
+{
+ return (__force void *)arch_ioremap_caller(phys_addr, size,
+ MT_MEMORY_RWX,
+ __builtin_return_address(0));
+}
+EXPORT_SYMBOL(arch_memremap_exec);
+
+void *arch_memremap_exec_nocache(phys_addr_t phys_addr, size_t size)
+{
+ return (__force void *)arch_ioremap_caller(phys_addr, size,
+ MT_MEMORY_RWX_NONCACHED,
+ __builtin_return_address(0));
+}
+EXPORT_SYMBOL(arch_memremap_exec_nocache);
+
void *arch_memremap_wb(phys_addr_t phys_addr, size_t size)
{
return (__force void *)arch_ioremap_caller(phys_addr, size,
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 2740967727e2..038922133ec4 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -390,6 +390,18 @@ void *arch_memremap_wb(phys_addr_t phys_addr, size_t size)
return (void *)phys_addr;
}
+void *arch_memremap_exec(phys_addr_t phys_addr, size_t size)
+{
+ return (void *)phys_addr;
+}
+EXPORT_SYMBOL(arch_memremap_exec);
+
+void *arch_memremap_exec_nocache(phys_addr_t phys_addr, size_t size)
+{
+ return (void *)phys_addr;
+}
+EXPORT_SYMBOL(arch_memremap_exec_nocache);
+
void __iounmap(volatile void __iomem *addr)
{
}
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] memremap: add MEMREMAP_EXEC and MEMREMAP_EXEC_NOCACHE flags
From: Dave Gerlach @ 2016-10-27 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027185612.22362-1-d-gerlach@ti.com>
Add flags to memremap() for MEMREMAP_EXEC and MEMREMAP_EXEC_NOCACHE
mappings. Mappings provided by these flags will both allow execution,
with MEMREMAP_EXEC_NOCACHE also requiring the memory to be mapped
non-cached. These mappings are useful for architectures that must map
on-chip memory such as SRAM and then copy and execute code from it, such
as code used to reconfigure system memory controllers or the low-level PM
code on ARM platforms.
Also add stubs for both underlying arch_memremap_exec/nocache calls that
return NULL so that if either is attempted from a platform cannot map
memory in such a way will fail.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
include/linux/io.h | 2 ++
kernel/memremap.c | 34 +++++++++++++++++++++++++++++++++-
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/include/linux/io.h b/include/linux/io.h
index e2c8419278c1..6668b6b9123b 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -136,6 +136,8 @@ enum {
MEMREMAP_WB = 1 << 0,
MEMREMAP_WT = 1 << 1,
MEMREMAP_WC = 1 << 2,
+ MEMREMAP_EXEC = 1 << 3,
+ MEMREMAP_EXEC_NOCACHE = 1 << 4,
};
void *memremap(resource_size_t offset, size_t size, unsigned long flags);
diff --git a/kernel/memremap.c b/kernel/memremap.c
index b501e390bb34..47cefc64057d 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -34,6 +34,21 @@ static void *arch_memremap_wb(resource_size_t offset, unsigned long size)
}
#endif
+#ifndef arch_memremap_exec
+static void *arch_memremap_exec(resource_size_t offset, unsigned long size)
+{
+ return NULL;
+}
+#endif
+
+#ifndef arch_memremap_exec_nocache
+static void *arch_memremap_exec_nocache(resource_size_t offset,
+ unsigned long size)
+{
+ return NULL;
+}
+#endif
+
static void *try_ram_remap(resource_size_t offset, size_t size)
{
unsigned long pfn = PHYS_PFN(offset);
@@ -48,7 +63,8 @@ static void *try_ram_remap(resource_size_t offset, size_t size)
* memremap() - remap an iomem_resource as cacheable memory
* @offset: iomem resource start address
* @size: size of remap
- * @flags: any of MEMREMAP_WB, MEMREMAP_WT and MEMREMAP_WC
+ * @flags: any of MEMREMAP_WB, MEMREMAP_WT, MEMREMAP_WC, MEMREMAP_EXEC,
+ * and MEMREMAP_EXEC_NOCACHE
*
* memremap() is "ioremap" for cases where it is known that the resource
* being mapped does not have i/o side effects and the __iomem
@@ -70,6 +86,16 @@ static void *try_ram_remap(resource_size_t offset, size_t size)
* MEMREMAP_WC - establish a writecombine mapping, whereby writes may
* be coalesced together (e.g. in the CPU's write buffers), but is otherwise
* uncached. Attempts to map System RAM with this mapping type will fail.
+ *
+ * MEMREMAP_EXEC - map memory as cached, as MEMREMAP_WB does, but also
+ * executable to allow for executing code from something like an on-chip
+ * memory. If support for executable mapping is not present on platform
+ * then the mapping will fail.
+ *
+ * MEMREMAP_EXEC_NOCACHE - map memory as non-cached and executable to allow
+ * for executing code from something like an on-chip memory. If support for
+ * executable, non-cached mapping is not present on platform then the
+ * mapping will fail.
*/
void *memremap(resource_size_t offset, size_t size, unsigned long flags)
{
@@ -118,6 +144,12 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
if (!addr && (flags & MEMREMAP_WC))
addr = ioremap_wc(offset, size);
+ if (!addr && (flags & MEMREMAP_EXEC))
+ addr = arch_memremap_exec(offset, size);
+
+ if (!addr && (flags & MEMREMAP_EXEC_NOCACHE))
+ addr = arch_memremap_exec_nocache(offset, size);
+
return addr;
}
EXPORT_SYMBOL(memremap);
--
2.9.3
^ 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