* [PATCH 0/2] mmc: allow mmc_alloc_host() and tmio_mmc_host_alloc()
From: Greg Kroah-Hartman @ 2016-11-13 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNAThxsE3QW4EdPUyxmxbnt_PPjeogi8Fox5AHkddsuu-Sg@mail.gmail.com>
On Fri, Nov 11, 2016 at 12:19:05PM +0900, Masahiro Yamada wrote:
> 2016-11-10 22:35 GMT+09:00 Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> > On Thu, Nov 10, 2016 at 10:24:21PM +0900, Masahiro Yamada wrote:
> >>
> >> sdhci_alloc_host() returns an error pointer when it fails.
> >> but mmc_alloc_host() cannot.
> >>
> >> This series allow to propagate a proper error code
> >> when host-allocation fails.
> >
> > Why? What can we really do about the error except give up? Why does
> > having a explicit error value make any difference to the caller, they
> > can't do anything different, right?
>
>
> The error code is shown in the console, like
>
> probe of 5a000000.sdhc failed with error -12
>
>
> The proper error code will give a clue why the driver failed to probe.
Can't the mmc core show the reason once, and not require each and every
individual driver to show/say the same thing? All a driver needs to
know is if it worked or didn't work. Every time it didn't work, it
needs to unwind stuff and then recover properly.
The drivers do not do different things based on what type of error
happened, as they don't care at all.
So I strongly suggest leaving it simple, as it is today, as this makes
drivers simpler, they don't have to duplicate the same type of error
reporting all over the place, and it's easy to audit for.
It also makes it so that large patchsets that touch every driver like
this are not needed at all.
> > I suggest just leaving it as-is, it's simple, and you don't have to mess
> > with PTR_ERR() anywhere.
>
>
> Why?
>
> Most of driver just give up probing for any error,
> but we still do ERR_PTR()/PTR_ERR() here and there.
> I think this patch is the same pattern.
I think we need to get rid of more of the ERR_PTR() stuff, as again,
it's useless. All we need to know is an error happened, that's it.
> If a function returns NULL on failure, we need to think about
> "what is the most common failure case".
>
> Currently, MMC drivers assume -ENOMEM is the best
> fit for mmc_alloc_host(), but the assumption is fragile.
>
> Already, mmc_alloc_host() calls a function
> that returns not only -ENOMEM, but also -ENOSPC.
>
> In the future, some other failure cases might be
> added to mmc_alloc_host().
>
> Once we decide the API returns an error pointer,
> drivers just propagate the return value from the API.
> This is much more stable implementation.
Again, no, it makes more work for the different drivers, duplicates code
all over the place, and really doesn't help any user, or developer, out
at all.
Just have the mmc core properly log what went wrong, and all should be
fine.
Again, keep it simple, that's the best policy for the kernel, and
really, most software :)
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2 1/6] Documentation: dt-bindings: Document STM32 ADC DT bindings
From: Jonathan Cameron @ 2016-11-13 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478794738-28933-2-git-send-email-fabrice.gasnier@st.com>
On 10/11/16 16:18, Fabrice Gasnier wrote:
> This patch adds documentation of device tree bindings for the STM32 ADC.
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
> .../devicetree/bindings/iio/adc/st,stm32-adc.txt | 85 ++++++++++++++++++++++
> 1 file changed, 85 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
> new file mode 100644
> index 0000000..8b20c23
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
> @@ -0,0 +1,85 @@
> +STMicroelectronics STM32 ADC device driver
> +
> +STM32 ADC is a successive approximation analog-to-digital converter.
> +It has several multiplexed input channels. Conversions can be performed
> +in single, continuous, scan or discontinuous mode. Result of the ADC is
> +stored in a left-aligned or right-aligned 32-bit data register.
> +Conversions can be launched in software or using hardware triggers.
> +
> +The analog watchdog feature allows the application to detect if the input
> +voltage goes beyond the user-defined, higher or lower thresholds.
> +
> +Each STM32 ADC block can have up to 3 ADC instances.
> +
> +Each instance supports two contexts to manage conversions, each one has its
> +own configurable sequence and trigger:
> +- regular conversion can be done in sequence, running in background
> +- injected conversions have higher priority, and so have the ability to
> + interrupt regular conversion sequence (either triggered in SW or HW).
> + Regular sequence is resumed, in case it has been interrupted.
> +
> +Contents of a stm32 adc root node:
> +-----------------------------------
> +Required properties:
> +- compatible: Should be "st,stm32f4-adc-core".
> +- reg: Offset and length of the ADC block register set.
> +- interrupts: Must contain the interrupt for ADC block.
> +- clocks: Clock for the analog circuitry (common to all ADCs).
> +- clock-names: Must be "adc".
> +- interrupt-controller: Identifies the controller node as interrupt-parent
> +- vref-supply: Phandle to the vref input analog reference voltage.
> +- #interrupt-cells = <1>;
> +- #address-cells = <1>;
> +- #size-cells = <0>;
> +
> +Optional properties:
> +- A pinctrl state named "default" for each ADC channel may be defined to set
> + inX ADC pins in mode of operation for analog input on external pin.
> +
> +Contents of a stm32 adc child node:
> +-----------------------------------
> +An ADC block node should contain at least one subnode, representing an
> +ADC instance available on the machine.
> +
> +Required properties:
> +- compatible: Should be "st,stm32f4-adc".
> +- reg: Offset of ADC instance in ADC block (e.g. may be 0x0, 0x100, 0x200).
> +- st,adc-channels: List of single-ended channels muxed for this ADC.
> + It can have up to 16 channels, numbered from 0 to 15 (resp. for in0..in15).
> +- interrupt-parent: Phandle to the parent interrupt controller.
> +- interrupts: IRQ Line for the ADC (e.g. may be 0 for adc at 0, 1 for adc at 100 or
> + 2 for adc at 200).
> +- #io-channel-cells = <1>: See the IIO bindings section "IIO consumers" in
> + Documentation/devicetree/bindings/iio/iio-bindings.txt
> +
> +Optional properties:
> +- clocks: Input clock private to this ADC instance.
I'm a little surprised this is optional. Perhaps some text here explaining why?
> +
> +Example:
> + adc: adc at 40012000 {
> + compatible = "st,stm32f4-adc-core";
> + reg = <0x40012000 0x400>;
> + interrupts = <18>;
> + clocks = <&rcc 0 168>;
> + clock-names = "adc";
> + vref-supply = <®_vref>;
> + interrupt-controller;
> + pinctrl-names = "default";
> + pinctrl-0 = <&adc3_in8_pin>;
> +
> + #interrupt-cells = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + adc at 0 {
> + compatible = "st,stm32f4-adc";
> + #io-channel-cells = <1>;
> + reg = <0x0>;
> + clocks = <&rcc 0 168>;
> + interrupt-parent = <&adc>;
> + interrupts = <0>;
> + st,adc-channels = <8>;
> + };
> + ...
> + other adc child nodes follow...
> + };
>
^ permalink raw reply
* Applied "ASoC: mioa701_wm9713: add missing white space in dev_err message" to the asoc tree
From: Mark Brown @ 2016-11-13 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112163025.4801-1-colin.king@canonical.com>
The patch
ASoC: mioa701_wm9713: add missing white space in dev_err message
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 28ab49bf9bd9185d8221392a5195bb6c989ed7c7 Mon Sep 17 00:00:00 2001
From: Colin Ian King <colin.king@canonical.com>
Date: Sat, 12 Nov 2016 16:30:25 +0000
Subject: [PATCH] ASoC: mioa701_wm9713: add missing white space in dev_err
message
There is a missing whitespace in the dev_err message between
"will" and "lead". Add the whitespace.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/pxa/mioa701_wm9713.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/pxa/mioa701_wm9713.c b/sound/soc/pxa/mioa701_wm9713.c
index d1661fa6ee08..0fe0abec8fc4 100644
--- a/sound/soc/pxa/mioa701_wm9713.c
+++ b/sound/soc/pxa/mioa701_wm9713.c
@@ -187,7 +187,7 @@ static int mioa701_wm9713_probe(struct platform_device *pdev)
mioa701.dev = &pdev->dev;
rc = devm_snd_soc_register_card(&pdev->dev, &mioa701);
if (!rc)
- dev_warn(&pdev->dev, "Be warned that incorrect mixers/muxes setup will"
+ dev_warn(&pdev->dev, "Be warned that incorrect mixers/muxes setup will "
"lead to overheating and possible destruction of your device."
" Do not use without a good knowledge of mio's board design!\n");
return rc;
--
2.10.2
^ permalink raw reply related
* [PATCH v3 1/2] iommu/dma: Implement dma_{map,unmap}_resource()
From: Catalin Marinas @ 2016-11-13 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7d54803d32968be46a1a525d7160feb13af72f00.1478887214.git.robin.murphy@arm.com>
On Fri, Nov 11, 2016 at 06:27:34PM +0000, Robin Murphy wrote:
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index c5ab8667e6f2..8b745260b3bc 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -432,13 +432,12 @@ int iommu_dma_mmap(struct page **pages, size_t size, struct vm_area_struct *vma)
> return ret;
> }
>
> -dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page,
> - unsigned long offset, size_t size, int prot)
> +dma_addr_t __iommu_dma_map(struct device *dev, phys_addr_t phys,
> + size_t size, int prot)
This should be static.
--
Catalin
^ permalink raw reply
* [PATCH v3 2/2] arm64: Wire up iommu_dma_{map, unmap}_resource()
From: Catalin Marinas @ 2016-11-13 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <706f6bc883775206d661f38d9c1cbaa4cc4d04b7.1478887214.git.robin.murphy@arm.com>
On Fri, Nov 11, 2016 at 06:27:35PM +0000, Robin Murphy wrote:
> With no coherency to worry about, just plug'em straight in.
>
> CC: Catalin Marinas <catalin.marinas@arm.com>
> CC: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> arch/arm64/mm/dma-mapping.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 3f74d0d98de6..5cd0a383b14b 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -796,6 +796,8 @@ static struct dma_map_ops iommu_dma_ops = {
> .sync_single_for_device = __iommu_sync_single_for_device,
> .sync_sg_for_cpu = __iommu_sync_sg_for_cpu,
> .sync_sg_for_device = __iommu_sync_sg_for_device,
> + .map_resource = iommu_dma_map_resource,
> + .unmap_resource = iommu_dma_unmap_resource,
> .dma_supported = iommu_dma_supported,
> .mapping_error = iommu_dma_mapping_error,
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
I guess these two patches would go in via the iommu tree.
--
Catalin
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Jacek Anaszewski @ 2016-11-13 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cb0aa3ce-ee48-66b8-510c-bd70917afec9@redhat.com>
Hi,
On 11/12/2016 10:14 PM, Hans de Goede wrote:
> Hi,
>
> On 12-11-16 20:14, Jacek Anaszewski wrote:
>
> <snip>
>
>>>>> Why a dedicated file? Are we going to mirror brightness here
>>>>> wrt r/w (show/store) behavior ? If not userspace now needs
>>>>> 2 open fds which is not really nice. If we are and we are
>>>>> not going to use poll for something else on brightness itself
>>>>> then why not just poll directly on brightness ?
>>>>
>>>> My main concern is that reporting only hw brightness changes
>>>> wouldn't be consistent with general brightness file purpose.
>>>> One could expect that brightness changes made by triggers
>>>> should be also reported.
>>>
>>> Ok, I agree that not notifying poll() while an actual
>>> read() would result in a different value is not really good
>>> semantics.
>>>
>>> I don't like to call it hw_brightness_change though, as
>>> mentioned before I believe that if we were to start with
>>> a clean slate we would make the brightness file's read/write
>>> behavior more a mirror of itself.
>>>
>>> So I would like to propose creating a new read-write
>>> user_brightness file.
>>>
>>> The write behavior would be 100% identical to the brightness
>>> file (in code terms it will call the same store function).
>>>
>>> The the read behavior otoh will be different: it will shows
>>> the last brightness as set by the user, this would show the
>>> read behavior we really want of brightness: show the real
>>> brightness when not blinking / triggers are active and show
>>> the brightness used when on when blinking / triggers are active.
>>>
>>> We could then add poll support on this new user_brightness
>>> file, thus avoiding the problem with the extra cpu-load on
>>> notifications on blinking / triggers.
>>
>> I agree that user_brightness allows to solve the issues you raised
>> about inconsistent write and read brightness' semantics
>> (which is not that painful IMHO).
>>
>> Reporting non-user brightness changes on user_brightness file
>> doesn't sound reasonable though.
>
> The changes I'm interested in are user brightness changes they
> are just not done through sysfs, but through a hardwired hotkey,
> they are however very much done by the user.
Ah, so this file name would be misleading especially taking into account
the context in which "user" is used in kernel, which predominantly
means "userspace", e.g. copy_to_user(), copy_from_user().
>> Also, how would we read the
>> brightness set by the firmware? We'd have to read brightness
>> file, so still two files would have to be opened which is
>> a second drawback of this approach.
>
> No, look carefully at the definition of the read behavior
> I plan to put in the ABI doc:
OK, "user" was what confused me. So in this case changes made
by the firmware even if in a result of user activity
(pressing hardware key) obviously cannot be treated similarly
to the changes made from the userspace context.
Unless you're able to give references to the kernel code which
contradict my judgement.
>
> "Reading this file will return the actual led brightness
> when not blinking and no triggers are active; reading this
> file will return the brightness used when the led is on
> when blinking or triggers are active."
This is unnecessarily entangled. Blinking means timer trigger
is active.
> So for e.g. the backlit keyboard case reading this single
> file will return the actual brightness of the backlight,
> since this does not involve blinking or triggers.
>
> Basically the idea is that the user_brightness file
> will have the semantics which IMHO the brightness file
> itself should have had from the beginning, but which
> we can't change now due to ABI reasons.
And in fact introducing user_brightness file would indeed
fix that shortcoming. However without providing notifications
of hw brightness changes on it.
>> Having no difference in this area between the two approaches
>> I'm still in favour of the read-only file for notifying
>> brightness changes procured by hardware.
>
> That brings back the needing 2 fds problem; and does
> not solve userspace not being able to reliably read
> the led on brightness when blinking or using triggers.
>
> And this also has the issue that one is doing poll() on
> one fd to detect changes on another fd,
It is not necessarily true. We can treat the polling on
hw_brightness_change file as a means to detect brightness
changes procured by hardware and we can read that brightness
by executing read on this same fd. It could return -ENODATA
if no such an event has occurred so far.
> which is completely
> unheard of in any kernel API, so I still vote NACK for the
> entire idea of having a different file purely for notifying
> changes. The way unix defines poll to work means that the
> poll() and read() must be on the same fd, anything else
> does not make sense.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [PATCH] ARM: dts: imx6sx-udoo: Add board specific compatible strings
From: Fabio Estevam @ 2016-11-13 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478021892-18344-1-git-send-email-fabio.estevam@nxp.com>
Hi Shawn,
On Tue, Nov 1, 2016 at 3:38 PM, Fabio Estevam <fabio.estevam@nxp.com> wrote:
> Add a compatible entry for the specific board versions.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> arch/arm/boot/dts/imx6sx-udoo-neo-basic.dts | 2 +-
> arch/arm/boot/dts/imx6sx-udoo-neo-extended.dts | 2 +-
> arch/arm/boot/dts/imx6sx-udoo-neo-full.dts | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6sx-udoo-neo-basic.dts b/arch/arm/boot/dts/imx6sx-udoo-neo-basic.dts
> index 0b88878..0c1fc1a 100644
> --- a/arch/arm/boot/dts/imx6sx-udoo-neo-basic.dts
> +++ b/arch/arm/boot/dts/imx6sx-udoo-neo-basic.dts
> @@ -46,7 +46,7 @@
>
> / {
> model = "UDOO Neo Basic";
> - compatible = "fsl,imx6sx";
> + compatible = "udoo,neobasic", "fsl,imx6sx";
Just to let you know that Rob has alreasy applied the patch that add
udoo in vendor-prefixes.txt:
https://git.kernel.org/cgit/linux/kernel/git/robh/linux.git/commit/?h=for-next&id=61bdc6a118e402543a724808c651bb7ca2751bd9
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Hans de Goede @ 2016-11-13 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b5ae20d7-8394-7ad5-1830-13173e9105c4@gmail.com>
Hi,
On 13-11-16 12:44, Jacek Anaszewski wrote:
> Hi,
>
> On 11/12/2016 10:14 PM, Hans de Goede wrote:
<snip>
>>>> So I would like to propose creating a new read-write
>>>> user_brightness file.
>>>>
>>>> The write behavior would be 100% identical to the brightness
>>>> file (in code terms it will call the same store function).
>>>>
>>>> The the read behavior otoh will be different: it will shows
>>>> the last brightness as set by the user, this would show the
>>>> read behavior we really want of brightness: show the real
>>>> brightness when not blinking / triggers are active and show
>>>> the brightness used when on when blinking / triggers are active.
>>>>
>>>> We could then add poll support on this new user_brightness
>>>> file, thus avoiding the problem with the extra cpu-load on
>>>> notifications on blinking / triggers.
>>>
>>> I agree that user_brightness allows to solve the issues you raised
>>> about inconsistent write and read brightness' semantics
>>> (which is not that painful IMHO).
>>>
>>> Reporting non-user brightness changes on user_brightness file
>>> doesn't sound reasonable though.
>>
>> The changes I'm interested in are user brightness changes they
>> are just not done through sysfs, but through a hardwired hotkey,
>> they are however very much done by the user.
>
> Ah, so this file name would be misleading especially taking into account
> the context in which "user" is used in kernel, which predominantly
> means "userspace", e.g. copy_to_user(), copy_from_user().
>
>>> Also, how would we read the
>>> brightness set by the firmware? We'd have to read brightness
>>> file, so still two files would have to be opened which is
>>> a second drawback of this approach.
>>
>> No, look carefully at the definition of the read behavior
>> I plan to put in the ABI doc:
>
> OK, "user" was what confused me. So in this case changes made
> by the firmware even if in a result of user activity
> (pressing hardware key) obviously cannot be treated similarly
> to the changes made from the userspace context.
In the end both result on the brightness of the device
changing, so any userspace process interested in monitoring
the brightness will want to know about both type of changes.
> Unless you're able to give references to the kernel code which
> contradict my judgement.
AFAIK the audio code will signal volume changes done by
hardwired buttons the same way as audio changes done
by userspace calling into the kernel. This also makes
sense because in the end, what is interesting for a
mixer app, is that the volume changed, and what the
new volume is.
>> "Reading this file will return the actual led brightness
>> when not blinking and no triggers are active; reading this
>> file will return the brightness used when the led is on
>> when blinking or triggers are active."
>
> This is unnecessarily entangled. Blinking means timer trigger
> is active.
Ok.
>> So for e.g. the backlit keyboard case reading this single
>> file will return the actual brightness of the backlight,
>> since this does not involve blinking or triggers.
>>
>> Basically the idea is that the user_brightness file
>> will have the semantics which IMHO the brightness file
>> itself should have had from the beginning, but which
>> we can't change now due to ABI reasons.
>
> And in fact introducing user_brightness file would indeed
> fix that shortcoming. However without providing notifications
> of hw brightness changes on it.
See above, I believe such a file should report any
changes in brightness, except those caused by triggers,
so it would report hw brightness changes.
Anyways if you're not interested in fixing the
shortcomings of the current read behavior on the
brightness file (I'm fine with that, I can live
with the shortcomings) I suggest that we simply go
with v2 of my poll() patch.
>>> Having no difference in this area between the two approaches
>>> I'm still in favour of the read-only file for notifying
>>> brightness changes procured by hardware.
>>
>> That brings back the needing 2 fds problem; and does
>> not solve userspace not being able to reliably read
>> the led on brightness when blinking or using triggers.
>>
>> And this also has the issue that one is doing poll() on
>> one fd to detect changes on another fd,
>
> It is not necessarily true. We can treat the polling on
> hw_brightness_change file as a means to detect brightness
> changes procured by hardware and we can read that brightness
> by executing read on this same fd. It could return -ENODATA
> if no such an event has occurred so far.
That would still require 2 fds as userspace also wants to
be able to set the keyboard backlight, but allowing read()
on the hw_brightness_change file at least fixes the weirdness
where userspace gets woken from poll() without being able to
read. So if you insist on going the hw_brightness_change file
route, then I can live with that (and upower will simply
need to open 2 fds, that is doable).
But, BUT, I would greatly prefer to just go for v4 of my
patch, which fixes the only real problem we've seen with
my patch as original merged without adding a new, somewhat
convoluted sysfs attribute.
Regards,
Hans
^ permalink raw reply
* [PATCH 9/10] ARM: sun5i: Convert to CCU
From: Chen-Yu Tsai @ 2016-11-13 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4046893c1810045bac3eeb1ea3a35c5771d250e0.1478625788.git-series.maxime.ripard@free-electrons.com>
On Wed, Nov 9, 2016 at 1:23 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Now that we have drivers for all of them, convert all the SoCs that share
> the sun5i DTSI to the new CCU driver.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> arch/arm/boot/dts/sun5i-a10s.dtsi | 94 +-------
> arch/arm/boot/dts/sun5i-a13.dtsi | 140 +-----------
> arch/arm/boot/dts/sun5i-r8.dtsi | 10 +-
> arch/arm/boot/dts/sun5i.dtsi | 368 ++++---------------------------
> 4 files changed, 90 insertions(+), 522 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi b/arch/arm/boot/dts/sun5i-a10s.dtsi
> index 7aa8c7aa0153..1d26ae7267dc 100644
> --- a/arch/arm/boot/dts/sun5i-a10s.dtsi
> +++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
> @@ -61,99 +61,33 @@
> #size-cells = <1>;
> ranges;
>
> - framebuffer at 0 {
> - compatible = "allwinner,simple-framebuffer",
> - "simple-framebuffer";
> - allwinner,pipeline = "de_be0-lcd0-hdmi";
> - clocks = <&pll3>, <&pll5 1>, <&ahb_gates 36>,
> - <&ahb_gates 43>, <&ahb_gates 44>;
> - status = "disabled";
> - };
> -
> framebuffer at 1 {
> compatible = "allwinner,simple-framebuffer",
> "simple-framebuffer";
> - allwinner,pipeline = "de_be0-lcd0";
> - clocks = <&pll3>, <&pll5 1>, <&ahb_gates 36>,
> - <&ahb_gates 44>;
> + allwinner,pipeline = "de_be0-lcd0-tve0";
> + clocks = <&ccu CLK_AHB_TVE>, <&ccu CLK_AHB_LCD>,
> + <&ccu CLK_AHB_DE_BE>, <&ccu CLK_DE_BE>,
> + <&ccu CLK_TCON_CH1>, <&ccu CLK_DRAM_DE_BE>;
> status = "disabled";
> };
>
> framebuffer at 2 {
> compatible = "allwinner,simple-framebuffer",
> "simple-framebuffer";
> - allwinner,pipeline = "de_be0-lcd0-tve0";
> - clocks = <&pll3>, <&pll5 1>, <&ahb_gates 34>,
> - <&ahb_gates 36>, <&ahb_gates 44>;
> + allwinner,pipeline = "de_be0-lcd0-hdmi";
> + clocks = <&ccu CLK_AHB_LCD>, <&ccu CLK_AHB_HDMI>,
> + <&ccu CLK_AHB_DE_BE>, <&ccu CLK_DRAM_DE_BE>,
> + <&ccu CLK_DE_BE>, <&ccu CLK_HDMI>;
You might want to mention you moved the framebuffer nodes around.
Or maybe do it in a separate patch.
> status = "disabled";
> };
> };
>
> - clocks {
> - ahb_gates: clk at 01c20060 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun5i-a10s-ahb-gates-clk";
> - reg = <0x01c20060 0x8>;
> - clocks = <&ahb>;
> - clock-indices = <0>, <1>,
> - <2>, <5>, <6>,
> - <7>, <8>, <9>,
> - <10>, <13>,
> - <14>, <17>, <18>,
> - <20>, <21>, <22>,
> - <26>, <28>, <32>,
> - <34>, <36>, <40>,
> - <43>, <44>,
> - <46>, <51>,
> - <52>;
> - clock-output-names = "ahb_usbotg", "ahb_ehci",
> - "ahb_ohci", "ahb_ss", "ahb_dma",
> - "ahb_bist", "ahb_mmc0", "ahb_mmc1",
> - "ahb_mmc2", "ahb_nand",
> - "ahb_sdram", "ahb_emac", "ahb_ts",
> - "ahb_spi0", "ahb_spi1", "ahb_spi2",
> - "ahb_gps", "ahb_stimer", "ahb_ve",
> - "ahb_tve", "ahb_lcd", "ahb_csi",
> - "ahb_hdmi", "ahb_de_be",
> - "ahb_de_fe", "ahb_iep",
> - "ahb_mali400";
> - };
> -
> - apb0_gates: clk at 01c20068 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun5i-a10s-apb0-gates-clk";
> - reg = <0x01c20068 0x4>;
> - clocks = <&apb0>;
> - clock-indices = <0>, <3>,
> - <5>, <6>,
> - <10>;
> - clock-output-names = "apb0_codec", "apb0_iis",
> - "apb0_pio", "apb0_ir",
> - "apb0_keypad";
> - };
> -
> - apb1_gates: clk at 01c2006c {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun5i-a10s-apb1-gates-clk";
> - reg = <0x01c2006c 0x4>;
> - clocks = <&apb1>;
> - clock-indices = <0>, <1>,
> - <2>, <16>,
> - <17>, <18>,
> - <19>;
> - clock-output-names = "apb1_i2c0", "apb1_i2c1",
> - "apb1_i2c2", "apb1_uart0",
> - "apb1_uart1", "apb1_uart2",
> - "apb1_uart3";
> - };
> - };
> -
> soc at 01c00000 {
> emac: ethernet at 01c0b000 {
> compatible = "allwinner,sun4i-a10-emac";
> reg = <0x01c0b000 0x1000>;
> interrupts = <55>;
> - clocks = <&ahb_gates 17>;
> + clocks = <&ccu CLK_AHB_EMAC>;
> allwinner,sram = <&emac_sram 1>;
> status = "disabled";
> };
> @@ -169,7 +103,7 @@
> pwm: pwm at 01c20e00 {
> compatible = "allwinner,sun5i-a10s-pwm";
> reg = <0x01c20e00 0xc>;
> - clocks = <&osc24M>;
> + clocks = <&ccu CLK_HOSC>;
> #pwm-cells = <3>;
> status = "disabled";
> };
> @@ -180,7 +114,7 @@
> interrupts = <1>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 16>;
> + clocks = <&ccu CLK_APB1_UART0>;
> status = "disabled";
> };
>
> @@ -190,12 +124,16 @@
> interrupts = <3>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 18>;
> + clocks = <&ccu CLK_APB1_UART2>;
> status = "disabled";
> };
> };
> };
>
> +&ccu {
> + compatible = "allwinner,sun5i-a10s-ccu";
> +};
> +
> &pio {
> compatible = "allwinner,sun5i-a10s-pinctrl";
>
> diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
> index a17ba0243db3..0330304f1d42 100644
> --- a/arch/arm/boot/dts/sun5i-a13.dtsi
> +++ b/arch/arm/boot/dts/sun5i-a13.dtsi
> @@ -61,8 +61,8 @@
> compatible = "allwinner,simple-framebuffer",
> "simple-framebuffer";
> allwinner,pipeline = "de_be0-lcd0";
> - clocks = <&ahb_gates 36>, <&ahb_gates 44>, <&de_be_clk>,
> - <&tcon_ch0_clk>, <&dram_gates 26>;
> + clocks = <&ccu CLK_AHB_LCD>, <&ccu CLK_AHB_DE_BE>, <&ccu CLK_DE_BE>,
> + <&ccu CLK_TCON_CH0>, <&ccu CLK_DRAM_DE_BE>;
> status = "disabled";
> };
> };
> @@ -99,114 +99,6 @@
> };
> };
>
> - clocks {
> - ahb_gates: clk at 01c20060 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun5i-a13-ahb-gates-clk";
> - reg = <0x01c20060 0x8>;
> - clocks = <&ahb>;
> - clock-indices = <0>, <1>,
> - <2>, <5>, <6>,
> - <7>, <8>, <9>,
> - <10>, <13>,
> - <14>, <20>,
> - <21>, <22>,
> - <28>, <32>, <34>,
> - <36>, <40>, <44>,
> - <46>, <51>,
> - <52>;
> - clock-output-names = "ahb_usbotg", "ahb_ehci",
> - "ahb_ohci", "ahb_ss", "ahb_dma",
> - "ahb_bist", "ahb_mmc0", "ahb_mmc1",
> - "ahb_mmc2", "ahb_nand",
> - "ahb_sdram", "ahb_spi0",
> - "ahb_spi1", "ahb_spi2",
> - "ahb_stimer", "ahb_ve", "ahb_tve",
> - "ahb_lcd", "ahb_csi", "ahb_de_be",
> - "ahb_de_fe", "ahb_iep",
> - "ahb_mali400";
> - };
> -
> - apb0_gates: clk at 01c20068 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun5i-a13-apb0-gates-clk";
> - reg = <0x01c20068 0x4>;
> - clocks = <&apb0>;
> - clock-indices = <0>, <5>,
> - <6>;
> - clock-output-names = "apb0_codec", "apb0_pio",
> - "apb0_ir";
> - };
> -
> - apb1_gates: clk at 01c2006c {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun5i-a13-apb1-gates-clk";
> - reg = <0x01c2006c 0x4>;
> - clocks = <&apb1>;
> - clock-indices = <0>, <1>,
> - <2>, <17>,
> - <19>;
> - clock-output-names = "apb1_i2c0", "apb1_i2c1",
> - "apb1_i2c2", "apb1_uart1",
> - "apb1_uart3";
> - };
> -
> - dram_gates: clk at 01c20100 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun5i-a13-dram-gates-clk",
> - "allwinner,sun4i-a10-gates-clk";
> - reg = <0x01c20100 0x4>;
> - clocks = <&pll5 0>;
> - clock-indices = <0>,
> - <1>,
> - <25>,
> - <26>,
> - <29>,
> - <31>;
> - clock-output-names = "dram_ve",
> - "dram_csi",
> - "dram_de_fe",
> - "dram_de_be",
> - "dram_ace",
> - "dram_iep";
> - };
> -
> - de_be_clk: clk at 01c20104 {
> - #clock-cells = <0>;
> - #reset-cells = <0>;
> - compatible = "allwinner,sun4i-a10-display-clk";
> - reg = <0x01c20104 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll5 1>;
> - clock-output-names = "de-be";
> - };
> -
> - de_fe_clk: clk at 01c2010c {
> - #clock-cells = <0>;
> - #reset-cells = <0>;
> - compatible = "allwinner,sun4i-a10-display-clk";
> - reg = <0x01c2010c 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll5 1>;
> - clock-output-names = "de-fe";
> - };
> -
> - tcon_ch0_clk: clk at 01c20118 {
> - #clock-cells = <0>;
> - #reset-cells = <1>;
> - compatible = "allwinner,sun4i-a10-tcon-ch0-clk";
> - reg = <0x01c20118 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> - clock-output-names = "tcon-ch0-sclk";
> - };
> -
> - tcon_ch1_clk: clk at 01c2012c {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-tcon-ch1-clk";
> - reg = <0x01c2012c 0x4>;
> - clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> - clock-output-names = "tcon-ch1-sclk";
> - };
> - };
> -
> display-engine {
> compatible = "allwinner,sun5i-a13-display-engine";
> allwinner,pipelines = <&fe0>;
> @@ -217,11 +109,11 @@
> compatible = "allwinner,sun5i-a13-tcon";
> reg = <0x01c0c000 0x1000>;
> interrupts = <44>;
> - resets = <&tcon_ch0_clk 1>;
> + resets = <&ccu RST_LCD>;
> reset-names = "lcd";
> - clocks = <&ahb_gates 36>,
> - <&tcon_ch0_clk>,
> - <&tcon_ch1_clk>;
> + clocks = <&ccu CLK_AHB_LCD>,
> + <&ccu CLK_TCON_CH0>,
> + <&ccu CLK_TCON_CH1>;
Just curious, is CLK_TCON_CH1_SCLK ever used?
> clock-names = "ahb",
> "tcon-ch0",
> "tcon-ch1";
> @@ -254,7 +146,7 @@
> pwm: pwm at 01c20e00 {
> compatible = "allwinner,sun5i-a13-pwm";
> reg = <0x01c20e00 0xc>;
> - clocks = <&osc24M>;
> + clocks = <&ccu CLK_HOSC>;
> #pwm-cells = <3>;
> status = "disabled";
> };
> @@ -263,11 +155,11 @@
> compatible = "allwinner,sun5i-a13-display-frontend";
> reg = <0x01e00000 0x20000>;
> interrupts = <47>;
> - clocks = <&ahb_gates 46>, <&de_fe_clk>,
> - <&dram_gates 25>;
> + clocks = <&ccu CLK_DE_FE>, <&ccu CLK_DE_FE>,
> + <&ccu CLK_DRAM_DE_FE>;
> clock-names = "ahb", "mod",
> "ram";
> - resets = <&de_fe_clk>;
> + resets = <&ccu RST_DE_FE>;
> status = "disabled";
>
> ports {
> @@ -290,14 +182,14 @@
> be0: display-backend at 01e60000 {
> compatible = "allwinner,sun5i-a13-display-backend";
> reg = <0x01e60000 0x10000>;
> - clocks = <&ahb_gates 44>, <&de_be_clk>,
> - <&dram_gates 26>;
> + clocks = <&ccu CLK_AHB_DE_BE>, <&ccu CLK_DE_BE>,
> + <&ccu CLK_DRAM_DE_BE>;
> clock-names = "ahb", "mod",
> "ram";
> - resets = <&de_be_clk>;
> + resets = <&ccu RST_DE_BE>;
> status = "disabled";
>
> - assigned-clocks = <&de_be_clk>;
> + assigned-clocks = <&ccu CLK_DE_BE>;
> assigned-clock-rates = <300000000>;
>
> ports {
> @@ -330,6 +222,10 @@
> };
> };
>
> +&ccu {
> + compatible = "allwinner,sun5i-a13-ccu";
> +};
> +
> &cpu0 {
> clock-latency = <244144>; /* 8 32k periods */
> operating-points = <
> diff --git a/arch/arm/boot/dts/sun5i-r8.dtsi b/arch/arm/boot/dts/sun5i-r8.dtsi
> index 8b058f53b7dc..4c1141396c99 100644
> --- a/arch/arm/boot/dts/sun5i-r8.dtsi
> +++ b/arch/arm/boot/dts/sun5i-r8.dtsi
> @@ -51,9 +51,9 @@
> compatible = "allwinner,simple-framebuffer",
> "simple-framebuffer";
> allwinner,pipeline = "de_be0-lcd0-tve0";
> - clocks = <&ahb_gates 34>, <&ahb_gates 36>,
> - <&ahb_gates 44>, <&de_be_clk>,
> - <&tcon_ch1_clk>, <&dram_gates 26>;
> + clocks = <&ccu CLK_AHB_TVE>, <&ccu CLK_AHB_LCD>,
> + <&ccu CLK_AHB_DE_BE>, <&ccu CLK_DE_BE>,
> + <&ccu CLK_TCON_CH1>, <&ccu CLK_DRAM_DE_BE>;
> status = "disabled";
> };
> };
> @@ -62,8 +62,8 @@
> tve0: tv-encoder at 01c0a000 {
> compatible = "allwinner,sun4i-a10-tv-encoder";
> reg = <0x01c0a000 0x1000>;
> - clocks = <&ahb_gates 34>;
> - resets = <&tcon_ch0_clk 0>;
> + clocks = <&ccu CLK_AHB_TVE>;
> + resets = <&ccu RST_TVE>;
> status = "disabled";
>
> port {
> diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
> index b4ccee8cfb02..2dbc7623ec04 100644
> --- a/arch/arm/boot/dts/sun5i.dtsi
> +++ b/arch/arm/boot/dts/sun5i.dtsi
> @@ -44,13 +44,29 @@
>
> #include "skeleton.dtsi"
>
> -#include <dt-bindings/clock/sun4i-a10-pll2.h>
> +#include <dt-bindings/clock/sun5i-ccu.h>
> #include <dt-bindings/dma/sun4i-a10.h>
> #include <dt-bindings/pinctrl/sun4i-a10.h>
> +#include <dt-bindings/reset/sun5i-ccu.h>
>
> / {
> interrupt-parent = <&intc>;
>
> + chosen {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + framebuffer at 0 {
> + compatible = "allwinner,simple-framebuffer",
> + "simple-framebuffer";
> + allwinner,pipeline = "de_be0-lcd0";
> + clocks = <&ccu CLK_AHB_LCD>, <&ccu CLK_AHB_DE_BE>, <&ccu CLK_DE_BE>,
> + <&ccu CLK_TCON_CH0>, <&ccu CLK_DRAM_DE_BE>;
> + status = "disabled";
> + };
> + };
> +
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -59,7 +75,7 @@
> device_type = "cpu";
> compatible = "arm,cortex-a8";
> reg = <0x0>;
> - clocks = <&cpu>;
> + clocks = <&ccu CLK_CPU>;
> };
> };
>
> @@ -68,291 +84,19 @@
> #size-cells = <1>;
> ranges;
>
> - /*
> - * This is a dummy clock, to be used as placeholder on
> - * other mux clocks when a specific parent clock is not
> - * yet implemented. It should be dropped when the driver
> - * is complete.
> - */
> - dummy: dummy {
> - #clock-cells = <0>;
> - compatible = "fixed-clock";
> - clock-frequency = <0>;
> - };
> -
> osc24M: clk at 01c20050 {
> #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-osc-clk";
> - reg = <0x01c20050 0x4>;
> + compatible = "fixed-clock";
> clock-frequency = <24000000>;
> clock-output-names = "osc24M";
> };
>
> - osc3M: osc3M_clk {
> - compatible = "fixed-factor-clock";
> - #clock-cells = <0>;
> - clock-div = <8>;
> - clock-mult = <1>;
> - clocks = <&osc24M>;
> - clock-output-names = "osc3M";
> - };
> -
> osc32k: clk at 0 {
> #clock-cells = <0>;
> compatible = "fixed-clock";
> clock-frequency = <32768>;
> clock-output-names = "osc32k";
> };
> -
> - pll1: clk at 01c20000 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-pll1-clk";
> - reg = <0x01c20000 0x4>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll1";
> - };
> -
> - pll2: clk at 01c20008 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun5i-a13-pll2-clk";
> - reg = <0x01c20008 0x8>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll2-1x", "pll2-2x",
> - "pll2-4x", "pll2-8x";
> - };
> -
> - pll3: clk at 01c20010 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-pll3-clk";
> - reg = <0x01c20010 0x4>;
> - clocks = <&osc3M>;
> - clock-output-names = "pll3";
> - };
> -
> - pll3x2: pll3x2_clk {
> - compatible = "allwinner,sun4i-a10-pll3-2x-clk", "fixed-factor-clock";
> - #clock-cells = <0>;
> - clock-div = <1>;
> - clock-mult = <2>;
> - clocks = <&pll3>;
> - clock-output-names = "pll3-2x";
> - };
> -
> - pll4: clk at 01c20018 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-pll1-clk";
> - reg = <0x01c20018 0x4>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll4";
> - };
> -
> - pll5: clk at 01c20020 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-pll5-clk";
> - reg = <0x01c20020 0x4>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll5_ddr", "pll5_other";
> - };
> -
> - pll6: clk at 01c20028 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-pll6-clk";
> - reg = <0x01c20028 0x4>;
> - clocks = <&osc24M>;
> - clock-output-names = "pll6_sata", "pll6_other", "pll6";
> - };
> -
> - pll7: clk at 01c20030 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-pll3-clk";
> - reg = <0x01c20030 0x4>;
> - clocks = <&osc3M>;
> - clock-output-names = "pll7";
> - };
> -
> - pll7x2: pll7x2_clk {
> - compatible = "fixed-factor-clock";
> - #clock-cells = <0>;
> - clock-div = <1>;
> - clock-mult = <2>;
> - clocks = <&pll7>;
> - clock-output-names = "pll7-2x";
> - };
> -
> - /* dummy is 200M */
> - cpu: cpu at 01c20054 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-cpu-clk";
> - reg = <0x01c20054 0x4>;
> - clocks = <&osc32k>, <&osc24M>, <&pll1>, <&dummy>;
> - clock-output-names = "cpu";
> - };
> -
> - axi: axi at 01c20054 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-axi-clk";
> - reg = <0x01c20054 0x4>;
> - clocks = <&cpu>;
> - clock-output-names = "axi";
> - };
> -
> - ahb: ahb at 01c20054 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun5i-a13-ahb-clk";
> - reg = <0x01c20054 0x4>;
> - clocks = <&axi>, <&cpu>, <&pll6 1>;
> - clock-output-names = "ahb";
> - /*
> - * Use PLL6 as parent, instead of CPU/AXI
> - * which has rate changes due to cpufreq
> - */
> - assigned-clocks = <&ahb>;
> - assigned-clock-parents = <&pll6 1>;
> - };
> -
> - apb0: apb0 at 01c20054 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-apb0-clk";
> - reg = <0x01c20054 0x4>;
> - clocks = <&ahb>;
> - clock-output-names = "apb0";
> - };
> -
> - apb1: clk at 01c20058 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-apb1-clk";
> - reg = <0x01c20058 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&osc32k>;
> - clock-output-names = "apb1";
> - };
> -
> - axi_gates: clk at 01c2005c {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-axi-gates-clk";
> - reg = <0x01c2005c 0x4>;
> - clocks = <&axi>;
> - clock-indices = <0>;
> - clock-output-names = "axi_dram";
> - };
> -
> - nand_clk: clk at 01c20080 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c20080 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "nand";
> - };
> -
> - ms_clk: clk at 01c20084 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c20084 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "ms";
> - };
> -
> - mmc0_clk: clk at 01c20088 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-mmc-clk";
> - reg = <0x01c20088 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "mmc0",
> - "mmc0_output",
> - "mmc0_sample";
> - };
> -
> - mmc1_clk: clk at 01c2008c {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-mmc-clk";
> - reg = <0x01c2008c 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "mmc1",
> - "mmc1_output",
> - "mmc1_sample";
> - };
> -
> - mmc2_clk: clk at 01c20090 {
> - #clock-cells = <1>;
> - compatible = "allwinner,sun4i-a10-mmc-clk";
> - reg = <0x01c20090 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "mmc2",
> - "mmc2_output",
> - "mmc2_sample";
> - };
> -
> - ts_clk: clk at 01c20098 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c20098 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "ts";
> - };
> -
> - ss_clk: clk at 01c2009c {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c2009c 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "ss";
> - };
> -
> - spi0_clk: clk at 01c200a0 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200a0 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "spi0";
> - };
> -
> - spi1_clk: clk at 01c200a4 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200a4 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "spi1";
> - };
> -
> - spi2_clk: clk at 01c200a8 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200a8 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "spi2";
> - };
> -
> - ir0_clk: clk at 01c200b0 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-mod0-clk";
> - reg = <0x01c200b0 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "ir0";
> - };
> -
> - usb_clk: clk at 01c200cc {
> - #clock-cells = <1>;
> - #reset-cells = <1>;
> - compatible = "allwinner,sun5i-a13-usb-clk";
> - reg = <0x01c200cc 0x4>;
> - clocks = <&pll6 1>;
> - clock-output-names = "usb_ohci0", "usb_phy";
> - };
> -
> - codec_clk: clk at 01c20140 {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-codec-clk";
> - reg = <0x01c20140 0x4>;
> - clocks = <&pll2 SUN4I_A10_PLL2_1X>;
> - clock-output-names = "codec";
> - };
> -
> - mbus_clk: clk at 01c2015c {
> - #clock-cells = <0>;
> - compatible = "allwinner,sun5i-a13-mbus-clk";
> - reg = <0x01c2015c 0x4>;
> - clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> - clock-output-names = "mbus";
> - };
> };
>
> soc at 01c00000 {
> @@ -395,7 +139,7 @@
> compatible = "allwinner,sun4i-a10-dma";
> reg = <0x01c02000 0x1000>;
> interrupts = <27>;
> - clocks = <&ahb_gates 6>;
> + clocks = <&ccu CLK_AHB_DMA>;
> #dma-cells = <2>;
> };
>
> @@ -403,7 +147,7 @@
> compatible = "allwinner,sun4i-a10-spi";
> reg = <0x01c05000 0x1000>;
> interrupts = <10>;
> - clocks = <&ahb_gates 20>, <&spi0_clk>;
> + clocks = <&ccu CLK_AHB_SPI0>, <&ccu CLK_SPI0>;
> clock-names = "ahb", "mod";
> dmas = <&dma SUN4I_DMA_DEDICATED 27>,
> <&dma SUN4I_DMA_DEDICATED 26>;
> @@ -417,7 +161,7 @@
> compatible = "allwinner,sun4i-a10-spi";
> reg = <0x01c06000 0x1000>;
> interrupts = <11>;
> - clocks = <&ahb_gates 21>, <&spi1_clk>;
> + clocks = <&ccu CLK_AHB_SPI1>, <&ccu CLK_SPI1>;
> clock-names = "ahb", "mod";
> dmas = <&dma SUN4I_DMA_DEDICATED 9>,
> <&dma SUN4I_DMA_DEDICATED 8>;
> @@ -430,14 +174,8 @@
> mmc0: mmc at 01c0f000 {
> compatible = "allwinner,sun5i-a13-mmc";
> reg = <0x01c0f000 0x1000>;
> - clocks = <&ahb_gates 8>,
> - <&mmc0_clk 0>,
> - <&mmc0_clk 1>,
> - <&mmc0_clk 2>;
> - clock-names = "ahb",
> - "mmc",
> - "output",
> - "sample";
> + clocks = <&ccu CLK_AHB_MMC0>, <&ccu CLK_MMC0>;
> + clock-names = "ahb", "mmc";
> interrupts = <32>;
> status = "disabled";
> #address-cells = <1>;
> @@ -447,14 +185,8 @@
> mmc1: mmc at 01c10000 {
> compatible = "allwinner,sun5i-a13-mmc";
> reg = <0x01c10000 0x1000>;
> - clocks = <&ahb_gates 9>,
> - <&mmc1_clk 0>,
> - <&mmc1_clk 1>,
> - <&mmc1_clk 2>;
> - clock-names = "ahb",
> - "mmc",
> - "output",
> - "sample";
> + clocks = <&ccu CLK_AHB_MMC1>, <&ccu CLK_MMC1>;
> + clock-names = "ahb", "mmc";
> interrupts = <33>;
> status = "disabled";
> #address-cells = <1>;
> @@ -464,14 +196,8 @@
> mmc2: mmc at 01c11000 {
> compatible = "allwinner,sun5i-a13-mmc";
> reg = <0x01c11000 0x1000>;
> - clocks = <&ahb_gates 10>,
> - <&mmc2_clk 0>,
> - <&mmc2_clk 1>,
> - <&mmc2_clk 2>;
> - clock-names = "ahb",
> - "mmc",
> - "output",
> - "sample";
> + clocks = <&ccu CLK_AHB_MMC2>, <&ccu CLK_MMC2>;
> + clock-names = "ahb", "mmc";
> interrupts = <34>;
> status = "disabled";
> #address-cells = <1>;
> @@ -481,7 +207,7 @@
> usb_otg: usb at 01c13000 {
> compatible = "allwinner,sun4i-a10-musb";
> reg = <0x01c13000 0x0400>;
> - clocks = <&ahb_gates 0>;
> + clocks = <&ccu CLK_AHB_OTG>;
> interrupts = <38>;
> interrupt-names = "mc";
> phys = <&usbphy 0>;
> @@ -496,9 +222,9 @@
> compatible = "allwinner,sun5i-a13-usb-phy";
> reg = <0x01c13400 0x10 0x01c14800 0x4>;
> reg-names = "phy_ctrl", "pmu1";
> - clocks = <&usb_clk 8>;
> + clocks = <&ccu CLK_USB_PHY0>;
> clock-names = "usb_phy";
> - resets = <&usb_clk 0>, <&usb_clk 1>;
> + resets = <&ccu RST_USB_PHY0>, <&ccu RST_USB_PHY1>;
> reset-names = "usb0_reset", "usb1_reset";
> status = "disabled";
> };
> @@ -507,7 +233,7 @@
> compatible = "allwinner,sun5i-a13-ehci", "generic-ehci";
> reg = <0x01c14000 0x100>;
> interrupts = <39>;
> - clocks = <&ahb_gates 1>;
> + clocks = <&ccu CLK_AHB_EHCI>;
> phys = <&usbphy 1>;
> phy-names = "usb";
> status = "disabled";
> @@ -517,7 +243,7 @@
> compatible = "allwinner,sun5i-a13-ohci", "generic-ohci";
> reg = <0x01c14400 0x100>;
> interrupts = <40>;
> - clocks = <&usb_clk 6>, <&ahb_gates 2>;
> + clocks = <&ccu CLK_USB_OHCI>, <&ccu CLK_AHB_OHCI>;
> phys = <&usbphy 1>;
> phy-names = "usb";
> status = "disabled";
> @@ -527,7 +253,7 @@
> compatible = "allwinner,sun4i-a10-spi";
> reg = <0x01c17000 0x1000>;
> interrupts = <12>;
> - clocks = <&ahb_gates 22>, <&spi2_clk>;
> + clocks = <&ccu CLK_AHB_SPI2>, <&ccu CLK_SPI2>;
> clock-names = "ahb", "mod";
> dmas = <&dma SUN4I_DMA_DEDICATED 29>,
> <&dma SUN4I_DMA_DEDICATED 28>;
> @@ -537,6 +263,14 @@
> #size-cells = <0>;
> };
>
> + ccu: clock at 01c20000 {
> + reg = <0x01c20000 0x400>;
> + clocks = <&osc24M>, <&osc32k>;
> + clock-names = "hosc", "losc";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> intc: interrupt-controller at 01c20400 {
> compatible = "allwinner,sun4i-a10-ic";
> reg = <0x01c20400 0x400>;
> @@ -547,7 +281,7 @@
> pio: pinctrl at 01c20800 {
> reg = <0x01c20800 0x400>;
> interrupts = <28>;
> - clocks = <&apb0_gates 5>;
> + clocks = <&ccu CLK_APB0_PIO>;
> gpio-controller;
> interrupt-controller;
> #interrupt-cells = <3>;
> @@ -641,7 +375,7 @@
> compatible = "allwinner,sun4i-a10-timer";
> reg = <0x01c20c00 0x90>;
> interrupts = <22>;
> - clocks = <&osc24M>;
> + clocks = <&ccu CLK_HOSC>;
> };
>
> wdt: watchdog at 01c20c90 {
> @@ -661,7 +395,7 @@
> compatible = "allwinner,sun4i-a10-codec";
> reg = <0x01c22c00 0x40>;
> interrupts = <30>;
> - clocks = <&apb0_gates 0>, <&codec_clk>;
> + clocks = <&ccu CLK_APB0_CODEC>, <&ccu CLK_CODEC>;
> clock-names = "apb", "codec";
> dmas = <&dma SUN4I_DMA_NORMAL 19>,
> <&dma SUN4I_DMA_NORMAL 19>;
> @@ -687,7 +421,7 @@
> interrupts = <2>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 17>;
> + clocks = <&ccu CLK_APB1_UART1>;
> status = "disabled";
> };
>
> @@ -697,7 +431,7 @@
> interrupts = <4>;
> reg-shift = <2>;
> reg-io-width = <4>;
> - clocks = <&apb1_gates 19>;
> + clocks = <&ccu CLK_APB1_UART3>;
> status = "disabled";
> };
>
> @@ -705,7 +439,7 @@
> compatible = "allwinner,sun4i-a10-i2c";
> reg = <0x01c2ac00 0x400>;
> interrupts = <7>;
> - clocks = <&apb1_gates 0>;
> + clocks = <&ccu CLK_APB1_I2C0>;
> status = "disabled";
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -715,7 +449,7 @@
> compatible = "allwinner,sun4i-a10-i2c";
> reg = <0x01c2b000 0x400>;
> interrupts = <8>;
> - clocks = <&apb1_gates 1>;
> + clocks = <&ccu CLK_APB1_I2C1>;
> status = "disabled";
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -725,7 +459,7 @@
> compatible = "allwinner,sun4i-a10-i2c";
> reg = <0x01c2b400 0x400>;
> interrupts = <9>;
> - clocks = <&apb1_gates 2>;
> + clocks = <&ccu CLK_APB1_I2C2>;
> status = "disabled";
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -735,7 +469,7 @@
> compatible = "allwinner,sun5i-a13-hstimer";
> reg = <0x01c60000 0x1000>;
> interrupts = <82>, <83>;
> - clocks = <&ahb_gates 28>;
> + clocks = <&ccu CLK_AHB_HSTIMER>;
> };
> };
> };
The rest looks good.
ChenYu
^ permalink raw reply
* [PATCH] drm/sun4i: constify component_ops structures
From: Daniel Vetter @ 2016-11-13 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478971198-3659-1-git-send-email-Julia.Lawall@lip6.fr>
On Sat, Nov 12, 2016 at 6:19 PM, Julia Lawall <Julia.Lawall@lip6.fr> wrote:
> These component_ops structures are only used as the second argument to
> component_add and component_del, which are declared as const, so the
> structures can be declared as const as well.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
>
> static struct component_ops i at p = { ... };
>
> @ok1@
> identifier r.i;
> expression e1;
> position p;
> @@
>
> component_add(e1,&i at p)
>
> @ok2@
> identifier r.i;
> expression e1;
> position p;
> @@
>
> component_del(e1, &i at p)
>
> @bad@
> position p != {r.p,ok1.p,ok2.p};
> identifier r.i;
> struct component_ops e;
> @@
>
> e at i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
>
> static
> +const
> struct component_ops i = { ... };
> // </smpl>
>
> The result of the size command before the change is (arm):
>
> text data bss dec hex filename
> 5266 236 8 5510 1586 sun4i_backend.o
> 6393 236 8 6637 19ed sun4i_tcon.o
> 3700 368 8 4076 fec sun4i_tv.o
> 1668 108 0 1776 6f0 sun6i_drc.o
>
> and after the change:
>
> text data bss dec hex filename
> 5274 228 8 5510 1586 sun4i_backend.o
> 6401 228 8 6637 19ed sun4i_tcon.o
> 3708 360 8 4076 fec sun4i_tv.o
> 1676 100 0 1776 6f0 sun6i_drc.o
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied to drm-misc, thanks.
-Daniel
>
> ---
> drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_tv.c | 2 +-
> drivers/gpu/drm/sun4i/sun6i_drc.c | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index 7eb2a96..2e08f96 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -409,7 +409,7 @@ static void sun4i_backend_unbind(struct device *dev, struct device *master,
> reset_control_assert(backend->reset);
> }
>
> -static struct component_ops sun4i_backend_ops = {
> +static const struct component_ops sun4i_backend_ops = {
> .bind = sun4i_backend_bind,
> .unbind = sun4i_backend_unbind,
> };
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index c6afb24..ea2906f 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -545,7 +545,7 @@ static void sun4i_tcon_unbind(struct device *dev, struct device *master,
> sun4i_tcon_free_clocks(tcon);
> }
>
> -static struct component_ops sun4i_tcon_ops = {
> +static const struct component_ops sun4i_tcon_ops = {
> .bind = sun4i_tcon_bind,
> .unbind = sun4i_tcon_unbind,
> };
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
> index 1dd3d9e..d430b331 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
> @@ -667,7 +667,7 @@ static void sun4i_tv_unbind(struct device *dev, struct device *master,
> clk_disable_unprepare(tv->clk);
> }
>
> -static struct component_ops sun4i_tv_ops = {
> +static const struct component_ops sun4i_tv_ops = {
> .bind = sun4i_tv_bind,
> .unbind = sun4i_tv_unbind,
> };
> diff --git a/drivers/gpu/drm/sun4i/sun6i_drc.c b/drivers/gpu/drm/sun4i/sun6i_drc.c
> index 6ef707c..09bba85 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_drc.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_drc.c
> @@ -80,7 +80,7 @@ static void sun6i_drc_unbind(struct device *dev, struct device *master,
> reset_control_assert(drc->reset);
> }
>
> -static struct component_ops sun6i_drc_ops = {
> +static const struct component_ops sun6i_drc_ops = {
> .bind = sun6i_drc_bind,
> .unbind = sun6i_drc_unbind,
> };
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v3] crypto: arm64/sha2: integrate OpenSSL implementations of SHA256/SHA512
From: Andy Polyakov @ 2016-11-13 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_Y-ik0L9mh4z-g3fHKjPt780_znCQNU-jAwXifLgAo4A@mail.gmail.com>
> (+ Andy)
>
> ...
>>
>> Looking at the generated code, I see references to __ARMEB__ and
> __ILP32__.
>> The former is probably a bug,
Oh! You mean that it should be __AARCH64EB__/__AARCH64EL__! Apparently I
simply went on assuming that it would be __ARMEB__/__ARMEL__ even in
64-bit case. As Ard mentioned, there is a number of modules that can be
compiled for either 32- or 64-bit case, and supposedly that's where this
blunder stems from. Will fix... As for it being actually tested. No, I
don't have big-endian AArch64 setup, and big-endian segments in AArch64
are based on experience with endian neutrality elsewhere. I.e. it's
based on observations what it takes to achieve the neutrality elsewhere,
e.g. ARM, MIPS, PPC, and then exercising equivalent approach even here.
Modulo fact that I apparently got macros wrong :-(
>> whilst the second is not required.
Note that references to __ILP32__ are also inside #ifndef
__KERNEL__/#endif, i.e. they won't be even evaluated when compiled for
kernel. Or in other words it's shared code artefact just like #if[n]def
__KERNEL__ itself. You either disregard it or remove altogether, but
then code becomes specific and not shared :-)
>> There are
>> also some commented out instructions, which is weird.
Commented instructions denote those that are moved into next round in
order to improve instruction scheduling on either of processors. In
other words it means that you should spot it further below [in generated
code]. Yes, it's weird, but it helps me to remember which instructions
are moved. On side note it's not uncommon that instruction scheduling is
result of compromise. In general I attempt to schedule instruction for
near-optimal performance on *multiple* processors, but sometimes you
have to make compromises. One is mentioned in commentary section for
this very module, the Apple A7 vs. Cortex-A53 thing. Well, it's not like
the commented instruction you're observing is the only result of the
compromise, it's merely an example of how said compromises can manifest
themselves, as somewhat weird irregularities in the code, possibly with
commented instructions.
^ permalink raw reply
* [PATCH 0/2] ARM: bcm2835: Fix names for the Raspberry Pi GPIO lines
From: Stefan Wahren @ 2016-11-13 18:12 UTC (permalink / raw)
To: linux-arm-kernel
This patch series should fix and extend the patch V4 "ARM: bcm2835: Add names
for the Raspberry Pi GPIO lines" from Linus Walleij and Eric Anholt.
Stefan Wahren (2):
ARM: bcm2835: Fix names for the Raspberry Pi GPIO lines
ARM: bcm2835: Add names for the Raspberry Pi Zero GPIO lines
arch/arm/boot/dts/bcm2835-rpi-a-plus-gpio.dtsi | 75 +++++++++++++++++++++++
arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 76 +-----------------------
arch/arm/boot/dts/bcm2835-rpi-a.dts | 4 +-
arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 2 +-
arch/arm/boot/dts/bcm2835-rpi-b.dts | 4 +-
arch/arm/boot/dts/bcm2835-rpi-zero.dts | 11 +---
6 files changed, 82 insertions(+), 90 deletions(-)
create mode 100644 arch/arm/boot/dts/bcm2835-rpi-a-plus-gpio.dtsi
--
1.7.9.5
^ permalink raw reply
* [PATCH 1/2] ARM: bcm2835: Fix names for the Raspberry Pi GPIO lines
From: Stefan Wahren @ 2016-11-13 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479060729-25769-1-git-send-email-stefan.wahren@i2se.com>
There are some differences between the schematics and the official firmware
DTS [1]. So based on these additional information the following has been
changed:
* use consistent "CAM_GPIO1" for camera LED
* use consistent "CAM_GPIO0" for camera shutdown
* add "USB_LIMIT" for USB current limit (0=600mA, 1=1200mA)
[1] - https://github.com/raspberrypi/documentation/blob/master/configuration/images/dt-blob.dts
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 4 ++--
arch/arm/boot/dts/bcm2835-rpi-a.dts | 4 ++--
arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 2 +-
arch/arm/boot/dts/bcm2835-rpi-b.dts | 4 ++--
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
index 5a22c79..d070454 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
@@ -63,13 +63,13 @@
"SCL0",
"NC", /* GPIO30 */
"NC", /* GPIO31 */
- "NC", /* GPIO32 */
+ "CAM_GPIO1", /* GPIO32 */
"NC", /* GPIO33 */
"NC", /* GPIO34 */
"PWR_LOW_N", /* GPIO35 */
"NC", /* GPIO36 */
"NC", /* GPIO37 */
- "NC", /* GPIO38 */
+ "USB_LIMIT", /* GPIO38 */
"NC", /* GPIO39 */
"PWM0_OUT", /* GPIO40 */
"CAM_GPIO0", /* GPIO41 */
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a.dts b/arch/arm/boot/dts/bcm2835-rpi-a.dts
index 54f98c5..46d078e 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a.dts
@@ -29,7 +29,7 @@
"SDA1",
"SCL1",
"GPIO_GCLK",
- "CAM_CLK",
+ "CAM_GPIO1",
"LAN_RUN",
"SPI_CE1_N",
"SPI_CE0_N",
@@ -52,7 +52,7 @@
"GPIO24",
"GPIO25",
"NC", /* GPIO26 */
- "CAM_GPIO",
+ "CAM_GPIO0",
/* Binary number representing build/revision */
"CONFIG0",
"CONFIG1",
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
index b67587e..432088e 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
@@ -71,7 +71,7 @@
"PWR_LOW_N", /* GPIO35 */
"NC", /* GPIO36 */
"NC", /* GPIO37 */
- "NC", /* GPIO38 */
+ "USB_LIMIT", /* GPIO38 */
"NC", /* GPIO39 */
"PWM0_OUT", /* GPIO40 */
"CAM_GPIO0", /* GPIO41 */
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index 71f50e1..4d56fe3 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -30,7 +30,7 @@
"SDA1",
"SCL1",
"GPIO_GCLK",
- "CAM_CLK",
+ "CAM_GPIO1",
"LAN_RUN",
"SPI_CE1_N",
"SPI_CE0_N",
@@ -53,7 +53,7 @@
"GPIO24",
"GPIO25",
"NC", /* GPIO26 */
- "CAM_GPIO",
+ "CAM_GPIO0",
/* Binary number representing build/revision */
"CONFIG0",
"CONFIG1",
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] ARM: bcm2835: Add names for the Raspberry Pi Zero GPIO lines
From: Stefan Wahren @ 2016-11-13 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479060729-25769-1-git-send-email-stefan.wahren@i2se.com>
This adds the GPIO names for the Raspberry Pi Zero. Since there are no
schematics for the RPi Zero use the same as the Model A+.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
arch/arm/boot/dts/bcm2835-rpi-a-plus-gpio.dtsi | 75 +++++++++++++++++++++++
arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 76 +-----------------------
arch/arm/boot/dts/bcm2835-rpi-zero.dts | 11 +---
3 files changed, 77 insertions(+), 85 deletions(-)
create mode 100644 arch/arm/boot/dts/bcm2835-rpi-a-plus-gpio.dtsi
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus-gpio.dtsi b/arch/arm/boot/dts/bcm2835-rpi-a-plus-gpio.dtsi
new file mode 100644
index 0000000..741d64d
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2835-rpi-a-plus-gpio.dtsi
@@ -0,0 +1,75 @@
+&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 */
+ "CAM_GPIO1", /* GPIO32 */
+ "NC", /* GPIO33 */
+ "NC", /* GPIO34 */
+ "PWR_LOW_N", /* GPIO35 */
+ "NC", /* GPIO36 */
+ "NC", /* GPIO37 */
+ "USB_LIMIT", /* 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 */
+ i2s_alt0: i2s_alt0 {
+ brcm,pins = <18 19 20 21>;
+ brcm,function = <BCM2835_FSEL_ALT0>;
+ };
+};
+
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
index d070454..9b665da 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
@@ -2,6 +2,7 @@
#include "bcm2835.dtsi"
#include "bcm2835-rpi.dtsi"
#include "bcm283x-rpi-usb-host.dtsi"
+#include "bcm2835-rpi-a-plus-gpio.dtsi"
/ {
compatible = "raspberrypi,model-a-plus", "brcm,bcm2835";
@@ -21,81 +22,6 @@
};
};
-&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 */
- "CAM_GPIO1", /* GPIO32 */
- "NC", /* GPIO33 */
- "NC", /* GPIO34 */
- "PWR_LOW_N", /* GPIO35 */
- "NC", /* GPIO36 */
- "NC", /* GPIO37 */
- "USB_LIMIT", /* 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 */
- i2s_alt0: i2s_alt0 {
- brcm,pins = <18 19 20 21>;
- brcm,function = <BCM2835_FSEL_ALT0>;
- };
-};
-
&hdmi {
hpd-gpios = <&gpio 46 GPIO_ACTIVE_LOW>;
};
diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero.dts b/arch/arm/boot/dts/bcm2835-rpi-zero.dts
index 7c1c180..0154ae0 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-zero.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-zero.dts
@@ -13,6 +13,7 @@
#include "bcm2835.dtsi"
#include "bcm2835-rpi.dtsi"
#include "bcm283x-rpi-usb-host.dtsi"
+#include "bcm2835-rpi-a-plus-gpio.dtsi"
/ {
compatible = "raspberrypi,model-zero", "brcm,bcm2835";
@@ -25,16 +26,6 @@
};
};
-&gpio {
- pinctrl-0 = <&gpioout &alt0 &i2s_alt0>;
-
- /* I2S interface */
- i2s_alt0: i2s_alt0 {
- brcm,pins = <18 19 20 21>;
- brcm,function = <BCM2835_FSEL_ALT0>;
- };
-};
-
&hdmi {
hpd-gpios = <&gpio 46 GPIO_ACTIVE_LOW>;
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH] input: bma150: Only claim to support the bma180 if the separate iio bma180 driver is not build
From: Hans de Goede @ 2016-11-13 18:34 UTC (permalink / raw)
To: linux-arm-kernel
commit ef3714fdbc8d ("Input: bma150 - extend chip detection for bma180"),
adds bma180 chip-ids to the input bma150 driver, assuming that they are
100% compatible, but the bma180 is not compatible with the bma150 at all,
it has 14 bits resolution instead of 10, and it has quite different
control registers too.
Treating the bma180 as a bma150 wrt its data registers will just result
in throwing away the lowest 4 bits, which is not too bad. But the ctrl
registers are a different story. Things happen to just work but supporting
that certainly does not make treating the bma180 the same as the bma150
right.
Since some setups depend on the evdev interface the bma150 driver offers
on top of the bma180, we cannot simply remove the bma180 ids.
So this commit only removes the bma180 id when the bma180 iio driver,
which does treat the bma180 properly, is enabled.
Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/input/misc/bma150.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/input/misc/bma150.c b/drivers/input/misc/bma150.c
index b0d4453..9fa1c9a 100644
--- a/drivers/input/misc/bma150.c
+++ b/drivers/input/misc/bma150.c
@@ -539,7 +539,11 @@ static int bma150_probe(struct i2c_client *client,
}
chip_id = i2c_smbus_read_byte_data(client, BMA150_CHIP_ID_REG);
- if (chip_id != BMA150_CHIP_ID && chip_id != BMA180_CHIP_ID) {
+ if (chip_id != BMA150_CHIP_ID
+#ifndef CONFIG_BMA180
+ && chip_id != BMA180_CHIP_ID
+#endif
+ ) {
dev_err(&client->dev, "BMA150 chip id error: %d\n", chip_id);
return -EINVAL;
}
@@ -643,7 +647,9 @@ static UNIVERSAL_DEV_PM_OPS(bma150_pm, bma150_suspend, bma150_resume, NULL);
static const struct i2c_device_id bma150_id[] = {
{ "bma150", 0 },
+#ifndef CONFIG_BMA180
{ "bma180", 0 },
+#endif
{ "smb380", 0 },
{ "bma023", 0 },
{ }
--
2.9.3
^ permalink raw reply related
* [linux-sunxi] [PATCH 1/3] ARM: sunxi: add support for H2+ SoC
From: Hans de Goede @ 2016-11-13 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111164654.15273-1-icenowy@aosc.xyz>
Hi,
On 11-11-16 17:46, Icenowy Zheng wrote:
> Allwinner H2+ is a quad-core Cortex-A7 SoC.
>
> It is very like H3, that they share the same SoC ID (0x1680), and H3
> memory maps as well as drivers works well on the SoC.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
I agree that given that the chip-id is 1680 for both
this does seem to be the same die as the H3, and given
that we do not have any datasheets, I agree that just
treating the H2+ as a H3 is best for now, we can always
change h2.dtsi to actually differentiate things later.
This entire series LGTM and is:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
> ---
> Documentation/arm/sunxi/README | 4 ++++
> Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
> arch/arm/mach-sunxi/sunxi.c | 1 +
> 3 files changed, 6 insertions(+)
>
> diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
> index cd02433..1fe4d99c 100644
> --- a/Documentation/arm/sunxi/README
> +++ b/Documentation/arm/sunxi/README
> @@ -63,6 +63,10 @@ SunXi family
> + User Manual
> http://dl.linux-sunxi.org/A33/A33%20user%20manual%20release%201.1.pdf
>
> + - Allwinner H2+ (sun8i)
> + + No document available now, but is known to be working properly with
> + H3 drivers and memory map.
> +
> - Allwinner H3 (sun8i)
> + Datasheet
> http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
> index 3975d0a..0c0f277 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> @@ -13,5 +13,6 @@ using one of the following compatible strings:
> allwinner,sun8i-a33
> allwinner,sun8i-a83t
> allwinner,sun8i-h3
> + allwinner,sun8i-h2plus
> allwinner,sun9i-a80
> nextthing,gr8
> diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
> index 2e2bde2..3647ad7 100644
> --- a/arch/arm/mach-sunxi/sunxi.c
> +++ b/arch/arm/mach-sunxi/sunxi.c
> @@ -63,6 +63,7 @@ static const char * const sun8i_board_dt_compat[] = {
> "allwinner,sun8i-a23",
> "allwinner,sun8i-a33",
> "allwinner,sun8i-a83t",
> + "allwinner,sun8i-h2plus",
> "allwinner,sun8i-h3",
> NULL,
> };
>
^ permalink raw reply
* [PATCH 0/3] soc: avoid module usage in non-modular code
From: Paul Gortmaker @ 2016-11-13 19:02 UTC (permalink / raw)
To: linux-arm-kernel
This series of commits is a part of a larger project to ensure
people don't reference modular support functions in non-modular
code. Overall there was roughly 5k lines of dead code in the
kernel due to this. So far we've fixed several areas, like tty,
x86, net, gpio ... and we continue to work on other areas.
There are several reasons to not use module support for code that
can never be built as a module, but the big ones are:
(1) it is easy to accidentally code up unused module_exit and remove code
(2) it can be misleading when reading the source, thinking it can be
modular when the Makefile and/or Kconfig prohibit it
(3) it requires the include of the module.h header file which in turn
includes nearly everything else.
Two of the changes are essentially source only -- the resuting module
will be binary equivalent. Only the FSL driver has unused code in
addition to the use of modular macros that get converted.
Note the FSL SOC driver just appeared in linux-next and so this series
won't apply on Linus' master branch. These commits were applied to
linux-next and build tested there.
Paul.
---
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Scott Wood <oss@buserror.net>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Yangbo Lu <yangbo.lu@nxp.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-tegra at vger.kernel.org
Paul Gortmaker (3):
soc: sunxi: make sunxi_sram explicitly non-modular
soc: tegra: make fuse-tegra explicitly non-modular
soc: fsl: make guts driver explicitly non-modular
drivers/soc/fsl/guts.c | 17 ++---------------
drivers/soc/sunxi/sunxi_sram.c | 9 ++-------
drivers/soc/tegra/fuse/fuse-tegra.c | 4 ++--
3 files changed, 6 insertions(+), 24 deletions(-)
--
2.10.1
^ permalink raw reply
* [PATCH 1/3] soc: sunxi: make sunxi_sram explicitly non-modular
From: Paul Gortmaker @ 2016-11-13 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113190302.18099-1-paul.gortmaker@windriver.com>
The Kconfig currently controlling compilation of this code is:
drivers/soc/sunxi/Kconfig:config SUNXI_SRAM
drivers/soc/sunxi/Kconfig: bool
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.
Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/soc/sunxi/sunxi_sram.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/soc/sunxi/sunxi_sram.c b/drivers/soc/sunxi/sunxi_sram.c
index 99e354c8f53f..5e10408a2aef 100644
--- a/drivers/soc/sunxi/sunxi_sram.c
+++ b/drivers/soc/sunxi/sunxi_sram.c
@@ -12,7 +12,7 @@
#include <linux/debugfs.h>
#include <linux/io.h>
-#include <linux/module.h>
+#include <linux/init.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_device.h>
@@ -269,7 +269,6 @@ static const struct of_device_id sunxi_sram_dt_match[] = {
{ .compatible = "allwinner,sun4i-a10-sram-controller" },
{ },
};
-MODULE_DEVICE_TABLE(of, sunxi_sram_dt_match);
static struct platform_driver sunxi_sram_driver = {
.driver = {
@@ -278,8 +277,4 @@ static struct platform_driver sunxi_sram_driver = {
},
.probe = sunxi_sram_probe,
};
-module_platform_driver(sunxi_sram_driver);
-
-MODULE_AUTHOR("Maxime Ripard <maxime.ripard@free-electrons.com>");
-MODULE_DESCRIPTION("Allwinner sunXi SRAM Controller Driver");
-MODULE_LICENSE("GPL");
+builtin_platform_driver(sunxi_sram_driver);
--
2.10.1
^ permalink raw reply related
* [PATCH 3/3] soc: fsl: make guts driver explicitly non-modular
From: Paul Gortmaker @ 2016-11-13 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113190302.18099-1-paul.gortmaker@windriver.com>
The Kconfig currently controlling compilation of this code is:
drivers/soc/fsl/Kconfig:config FSL_GUTS
drivers/soc/fsl/Kconfig: bool
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and it allows us to drop the ".remove"
code for non-modular drivers.
Since the code was already not using module_init, the init ordering
remains unchanged with this commit.
Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
Cc: Scott Wood <oss@buserror.net>
Cc: Yangbo Lu <yangbo.lu@nxp.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/soc/fsl/guts.c | 17 ++---------------
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index 0ac88263c2d7..b4d2fd9263b2 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -11,7 +11,7 @@
#include <linux/io.h>
#include <linux/slab.h>
-#include <linux/module.h>
+#include <linux/init.h>
#include <linux/of_fdt.h>
#include <linux/sys_soc.h>
#include <linux/of_address.h>
@@ -180,12 +180,6 @@ static int fsl_guts_probe(struct platform_device *pdev)
return 0;
}
-static int fsl_guts_remove(struct platform_device *dev)
-{
- soc_device_unregister(soc_dev);
- return 0;
-}
-
/*
* Table for matching compatible strings, for device tree
* guts node, for Freescale QorIQ SOCs.
@@ -212,15 +206,14 @@ static const struct of_device_id fsl_guts_of_match[] = {
{ .compatible = "fsl,ls2080a-dcfg", },
{}
};
-MODULE_DEVICE_TABLE(of, fsl_guts_of_match);
static struct platform_driver fsl_guts_driver = {
.driver = {
.name = "fsl-guts",
+ .suppress_bind_attrs = true,
.of_match_table = fsl_guts_of_match,
},
.probe = fsl_guts_probe,
- .remove = fsl_guts_remove,
};
static int __init fsl_guts_init(void)
@@ -228,9 +221,3 @@ static int __init fsl_guts_init(void)
return platform_driver_register(&fsl_guts_driver);
}
core_initcall(fsl_guts_init);
-
-static void __exit fsl_guts_exit(void)
-{
- platform_driver_unregister(&fsl_guts_driver);
-}
-module_exit(fsl_guts_exit);
--
2.10.1
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: sun5i: Add touchscreen node to reference-design-tablet.dtsi
From: Hans de Goede @ 2016-11-13 19:22 UTC (permalink / raw)
To: linux-arm-kernel
Just like on sun8i all sun5i tablets use the same interrupt and power
gpios for their touchscreens. I've checked all known a13 fex files and
only the UTOO P66 uses a different gpio for the interrupt.
Add a touchscreen node to sun5i-reference-design-tablet.dtsi, which
fills in the necessary gpios to avoid duplication in the tablet dts files,
just like we do in sun8i-reference-design-tablet.dtsi.
This will make future patches adding touchscreen nodes to a13 tablets
simpler.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 38 ++++++++--------------
.../boot/dts/sun5i-reference-design-tablet.dtsi | 25 ++++++++++++++
2 files changed, 39 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
index a8b0bcc..3d7ff10 100644
--- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
+++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
@@ -83,22 +83,6 @@
allwinner,pins = "PG3";
};
-&i2c1 {
- icn8318: touchscreen at 40 {
- compatible = "chipone,icn8318";
- reg = <0x40>;
- interrupt-parent = <&pio>;
- interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
- pinctrl-names = "default";
- pinctrl-0 = <&ts_wake_pin_p66>;
- wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
- touchscreen-size-x = <800>;
- touchscreen-size-y = <480>;
- touchscreen-inverted-x;
- touchscreen-swapped-x-y;
- };
-};
-
&mmc2 {
pinctrl-names = "default";
pinctrl-0 = <&mmc2_pins_a>;
@@ -121,20 +105,26 @@
allwinner,drive = <SUN4I_PINCTRL_10_MA>;
allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
};
-
- ts_wake_pin_p66: ts_wake_pin at 0 {
- allwinner,pins = "PB3";
- allwinner,function = "gpio_out";
- allwinner,drive = <SUN4I_PINCTRL_10_MA>;
- allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
- };
-
};
®_usb0_vbus {
gpio = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
};
+&touchscreen {
+ compatible = "chipone,icn8318";
+ reg = <0x40>;
+ /* The P66 uses a different EINT then the reference design */
+ interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
+ /* The icn8318 binding expects wake-gpios instead of power-gpios */
+ wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ touchscreen-inverted-x;
+ touchscreen-swapped-x-y;
+ status = "okay";
+};
+
&uart1 {
/* The P66 uses the uart pins as gpios */
status = "disabled";
diff --git a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
index 20cc940..7af488a 100644
--- a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
+++ b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
@@ -41,6 +41,7 @@
*/
#include "sunxi-reference-design-tablet.dtsi"
+#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/pwm/pwm.h>
/ {
@@ -84,6 +85,23 @@
};
&i2c1 {
+ /*
+ * The gsl1680 is rated at 400KHz and it will not work reliable at
+ * 100KHz, this has been confirmed on multiple different q8 tablets.
+ * All other devices on this bus are also rated for 400KHz.
+ */
+ clock-frequency = <400000>;
+
+ touchscreen: touchscreen {
+ interrupt-parent = <&pio>;
+ interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; /* EINT11 (PG11) */
+ pinctrl-names = "default";
+ pinctrl-0 = <&ts_power_pin>;
+ power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
+ /* Tablet dts must provide reg and compatible */
+ status = "disabled";
+ };
+
pcf8563: rtc at 51 {
compatible = "nxp,pcf8563";
reg = <0x51>;
@@ -125,6 +143,13 @@
allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
};
+ ts_power_pin: ts_power_pin {
+ allwinner,pins = "PB3";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
usb0_vbus_detect_pin: usb0_vbus_detect_pin at 0 {
allwinner,pins = "PG1";
allwinner,function = "gpio_in";
--
2.9.3
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: sun8i: reference-design-tablet: ldo_io1 is vcc-touchscreen
From: Hans de Goede @ 2016-11-13 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113192203.7101-1-hdegoede@redhat.com>
On some Q8 and other tablets ldo_io1 is used as vcc-touchscreen,
config at as such in sun8i-reference-design-tablet.dtsi.
Note that it will only be enabled when it us actually referenced by
a foo-supply property in the touchscreen node, so for tablets which
do not use ldo_io1 as vcc-touchscreen, it will be disabled.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
arch/arm/boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts | 7 -------
arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi | 7 +++++++
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts b/arch/arm/boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts
index a86cbed..21bb291 100644
--- a/arch/arm/boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts
+++ b/arch/arm/boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts
@@ -98,13 +98,6 @@
};
};
-®_ldo_io1 {
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-name = "vcc-touchscreen";
- status = "okay";
-};
-
&touchscreen {
reg = <0x40>;
compatible = "silead,gsl1680";
diff --git a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
index 08cd001..69bc0cd 100644
--- a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
+++ b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
@@ -209,6 +209,13 @@
status = "okay";
};
+®_ldo_io1 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-touchscreen";
+ status = "okay";
+};
+
®_rtc_ldo {
regulator-name = "vcc-rtc";
};
--
2.9.3
^ permalink raw reply related
* [PATCH fpga 9/9] fpga: Remove support for non-sg drivers
From: atull @ 2016-11-13 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8078ce27-5df0-c882-ffa3-d0c9316b7c54@gmail.com>
On Thu, 10 Nov 2016, Joshua Clayton wrote:
>
>
> On 11/10/2016 08:33 AM, Jason Gunthorpe wrote:
> >>> struct fpga_manager_ops {
> >>> enum fpga_mgr_states (*state)(struct fpga_manager *mgr);
> >>> - int (*write_init)(struct fpga_manager *mgr, u32 flags,
> >>> - const char *buf, size_t count);
> >>> - int (*write)(struct fpga_manager *mgr, const char *buf, size_t count);
> >>> int (*write_init_sg)(struct fpga_manager *mgr, u32 flags,
> >>> struct sg_table *sgt);
> >>> int (*write_sg)(struct fpga_manager *mgr, struct sg_table *sgt);
> >>> @@ -118,6 +113,8 @@ struct fpga_manager {
> >>>
> >>> int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags,
> >>> const char *buf, size_t count);
> >>> +int fpga_mgr_buf_load_sg(struct fpga_manager *mgr, u32 flags,
> >>> + struct sg_table *sgt);
> >>>
> >>> int fpga_mgr_firmware_load(struct fpga_manager *mgr, u32 flags,
> >>> const char *image_name);
> >> I don't have any feeling either way about switching to scatter-gather.
> >> (Not zynq or socfpga user)
> >> But I do object to renaming the API.
> >> write_init() and write() do not imply a particular implementation, nor even that
> >> the buffer is coherent.
> > Neither the sg or old linear interface imply any particular
> > underlying driver implementation.
> >
> > All that is being changed is how the list of physical pages gets
> > passed to the driver. The linear interface requires them to be
> > contiguously mapped (eg in a vmap) while the SG interface
> > directly passes a list of physical page addresses.
> >
> > Any alogrithm that works with the old interface can run on the new
> > interface, and the new interface can support much better options for
> > DMA drivers, while not requiring the higher layers to perform a high
> > order allocation (vmap or otherwise) to create the contiguous memory.
> >
> > The reason the old interface is being deleted here is so the fpga mgr
> > API can be expanded to accept a sg list directly. Since we cannot
> > convert a general sg list to linear memory the liner option must be
> > totally removed.
> OK. That sounds reasonable.
> >> I am working to merge an fpga manager which uses SPI to load the bitstream
> >> (see https://www.spinics.net/lists/arm-kernel/msg539328.html)
> >> Any dma in use there would come from the spi driver. write_init_sg, and write_sg
> >> don't make any sense in my case.
> > No, it still make lots of sense.
> >
> > SPI has been slowly transforming to use the same sort of SG scheme
> > universally, including facing the client. (see
> > 6ad45a27cbe343ec8d7888e5edf6335499a4b555)
> Thanks for sharing that link.
> >
> > Some day your driver can just pass the SGs directly to spi and
> > everything will be great.
> >
> > In the mean time it can do sg_miter_next to get mapped buffers.
> ..so I have a way forward if this series gets merged.
> That was my main concern.
> And as a dma n00b, learning to use dma engine structures to do
> non-dma xfer was not very high on my list.
> >> Would it not make sense to keep the top level API the same?
> > Fundamentally no.
NACK for now. Let's slow down here a bit.
I don't see any rush in getting rid of the contiguous
buffer interface.
At the very least, my socfpga-a10 driver is using the old
interface and has been just applied. And currently your
socfpga changes are untested whereas my original driver
has been in use and is known to work.
Let's wait on that patch until we have quite a few FPGA's
supported and can be sure that we won't miss the old
interface.
Alan
> >
> > Jason
> Joshua
>
^ permalink raw reply
* Three different LED brightnesses (was Re: PM regression with LED changes in next-20161109)
From: Pavel Machek @ 2016-11-13 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3a3bb3f8-e54a-e7d0-da30-7f90b00c29b3@redhat.com>
Hi!
> >No, that's just adding more mess on the system.
> >
> >Here's better proposal:
> >
> >brightness (write): what we do today. (Mess, but too late to change it)
> > (read): -Esomething or what we do today (if someone
> > acutally uses it)
>
> As said Jacek has already nacked any changes to read behavior.
>
> > (poll): -Esomething
>
> Making poll() on sysfs attributes return -Esomething is not possible,
> the internal sysfs API does not allow this.
>
> >current_brightness (write): -Esomething, or maybe change brightness
> > for triggers that can work with that
> > (read, poll): if the current trigger can get current
> > state of led, do it, otherwise -Esomething...
> > or maybe file should be simply hidden from sysfs.
>
> So write is -EINVAL and read is the same as what brightness currently does,
> so I see no use in introducing this new file.
No, read is not same as current brightness file. Currently, reading
brightness file returns either current brightness or maximum
brightness, and userspace can't tell which is which.
> >trigger_max_brightness (read,write): change the maximum brightness for
> > a trigger.
> > (poll): -Esomething
>
> The write behavior here is the same as what brightness currently does
> and the read behavior is that of what I suggested for
No, it is not. "brightness" behaviour is currently broken, as it sets
either current brightness or maximum trigger brightness.
> We've 2 sorts of brightness really:
>
> 1) transient brightness, aka current brightness, when blinking or
> triggers are used this will switch many times a second
> between off and some on level.
>
> 2) non-transient brightness, for non blinking leds this is the
> actual brightness, for blinking leds this is the brightness
> level used when the led is on.
Yes, and we want reasonable interface where userspace sees those two
brightnesses.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161113/f90abee5/attachment.sig>
^ permalink raw reply
* [PATCH v3] crypto: arm64/sha2: integrate OpenSSL implementations of SHA256/SHA512
From: Ard Biesheuvel @ 2016-11-13 21:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c8306030-d4eb-fea7-441a-3476cd308496@openssl.org>
On 13 November 2016 at 15:12, Andy Polyakov <appro@openssl.org> wrote:
>> (+ Andy)
>>
>> ...
>>>
>>> Looking at the generated code, I see references to __ARMEB__ and
>> __ILP32__.
>>> The former is probably a bug,
>
> Oh! You mean that it should be __AARCH64EB__/__AARCH64EL__!
Indeed:
$ aarch64-linux-gnu-gcc -dM -E - <<<"" |grep AARCH
#define __AARCH64_CMODEL_SMALL__ 1
#define __AARCH64EL__ 1
$ aarch64-linux-gnu-gcc -dM -E -mbig-endian - <<<"" |grep AARCH
#define __AARCH64_CMODEL_SMALL__ 1
#define __AARCH64EB__ 1
--
Ard.
^ permalink raw reply
* [PATCH v2 00/19] Various Armada 370/XP DT warning fixup
From: Gregory CLEMENT @ 2016-11-13 21:23 UTC (permalink / raw)
To: linux-arm-kernel
As it was done a few months ago for kirkwood, this patchset fixes up
various warning from the DT compiler when using the flag W=1 with
make.
In this second version I used the target and attributes property of
the memory windows when MBUS_ID. Indeed by adding this information to
the unit-address is really uniq as required bu the epar as explained
in this email:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/466941.html.
As for the first version, the only remaining warnings are the following:
DTC arch/arm/boot/dts/armada-370-db.dtb
Warning (unit_address_vs_reg): Node /sound/simple-audio-card,dai-link at 0 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound/simple-audio-card,dai-link at 1 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound/simple-audio-card,dai-link at 2 has a unit name, but no reg property
However it seems a false positive as here the '@' is part of the name
of the node and is not a reference of an address. Moreover the node
name is directly used by the driver so it must not be modified.
Gregory
Gregory CLEMENT (19):
ARM: dts: armada-xp-matrix: Fix the location of the pcie-controller
node
ARM: dts: armada-370-xp: move the cpurst node in the common file
ARM: dts: armada-370-xp: add node labels
ARM: dts: armada-370-xp: Use the node labels
ARM: dts: armada-370-xp: Fixup mdio DT warning
ARM: dts: armada-370-xp: Fixup bootrom DT warning
ARM: dts: armada-370-xp: Fixup devbus DT warning
ARM: dts: armada-370-xp: Fixup bm-bppi DT warning
ARM: dts: armada-370-xp: Fixup sa-ram DT warning
ARM: dts: armada-xp: Fixup pcie DT warnings
ARM: dts: armada-370: Fixup pcie DT warnings
ARM: dts: armada-370-xp: Remove skeleton.dtsi
ARM: dts: armada-370-xp: Fixup l2-cache DT warning
ARM: dts: armada-370-xp: Fixup internal-regs DT warning
ARM: dts: armada-370-xp: Fixup soc DT warning
ARM: dts: armada-370-xp: Fixup memory DT warning
ARM: dts: armada-370-xp: Remove address from dsa unit name
ARM: dts: armada-370-xp: Remove button address and fixup names
ARM: dts: armada-370-xp: Fixup regulator DT warning
arch/arm/boot/dts/armada-370-db.dts | 67 ++++----
arch/arm/boot/dts/armada-370-dlink-dns327l.dts | 34 ++---
arch/arm/boot/dts/armada-370-mirabox.dts | 61 ++++----
arch/arm/boot/dts/armada-370-netgear-rn102.dts | 54 +++----
arch/arm/boot/dts/armada-370-netgear-rn104.dts | 62 ++++----
arch/arm/boot/dts/armada-370-rd.dts | 61 ++++----
arch/arm/boot/dts/armada-370-seagate-nas-4bay.dts | 31 ++--
arch/arm/boot/dts/armada-370-seagate-nas-xbay.dtsi | 49 +++---
.../dts/armada-370-seagate-personal-cloud-2bay.dts | 4 +-
.../boot/dts/armada-370-seagate-personal-cloud.dts | 4 +-
.../dts/armada-370-seagate-personal-cloud.dtsi | 48 +++---
arch/arm/boot/dts/armada-370-synology-ds213j.dts | 22 +--
arch/arm/boot/dts/armada-370-xp.dtsi | 43 +++---
arch/arm/boot/dts/armada-370.dtsi | 144 +++++++++--------
arch/arm/boot/dts/armada-xp-axpwifiap.dts | 72 ++++-----
arch/arm/boot/dts/armada-xp-db.dts | 170 ++++++++++-----------
arch/arm/boot/dts/armada-xp-gp.dts | 146 +++++++++---------
arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 57 ++++---
arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 56 +++----
arch/arm/boot/dts/armada-xp-matrix.dts | 24 +--
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 16 +-
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 24 +--
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 26 ++--
arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 71 ++++-----
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 124 +++++++--------
arch/arm/boot/dts/armada-xp-synology-ds414.dts | 79 +++++-----
arch/arm/boot/dts/armada-xp.dtsi | 106 ++++++-------
27 files changed, 832 insertions(+), 823 deletions(-)
--
2.10.2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox