* [PATCH v2 2/3] spi: pxa2xx: Prepare for edge-triggered interrupts
From: Jan Kiszka @ 2017-01-17 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7fd7a8eb-4302-523b-08dd-f2a28b845a5e@siemens.com>
On 2017-01-16 20:46, Jan Kiszka wrote:
> On 2017-01-16 20:07, Andy Shevchenko wrote:
>> On Mon, 2017-01-16 at 19:44 +0100, Jan Kiszka wrote:
>>> When using the a device with edge-triggered interrupts, such as MSIs,
>>> the interrupt handler has to ensure that there is a point in time
>>> during
>>> its execution where all interrupts sources are silent so that a new
>>> event can trigger a new interrupt again.
>>>
>>> This is achieved here by looping over SSSR evaluation. We need to take
>>> into account that SSCR1 may be changed by the transfer handler, thus
>>> we
>>> need to redo the mask calculation, at least regarding the volatile
>>> interrupt enable bit (TIE).
>>>
>>
>> So, more comments/questions below.
>>
>>>
>>> sccr1_reg = pxa2xx_spi_read(drv_data, SSCR1);
>>>
>>> - /* Ignore possible writes if we don't need to write */
>>> - if (!(sccr1_reg & SSCR1_TIE))
>>> - mask &= ~SSSR_TFS;
>>> -
>>> /* Ignore RX timeout interrupt if it is disabled */
>>> if (!(sccr1_reg & SSCR1_TINTE))
>>> mask &= ~SSSR_TINT;
>>>
>>> - if (!(status & mask))
>>> - return IRQ_NONE;
>>> + while (1) {
>>
>> Can we switch to do-while and move previous block here?
>
> Don't see how this would help (without duplicating more code).
>
>> Btw, can TINTE
>> bit be set again during a loop?
>
> Nope, it's statically set, at least so far.
>
> What we could do is simply restarting ssp_int
>
>>
>>> + /* Ignore possible writes if we don't need to write
>>> */
>>> + if (!(sccr1_reg & SSCR1_TIE))
>>> + mask &= ~SSSR_TFS;
>>>
>>> - if (!drv_data->master->cur_msg) {
>>> - handle_bad_msg(drv_data);
>>> - /* Never fail */
>>> - return IRQ_HANDLED;
>>> - }
>>> + if (!(status & mask))
>>> + return ret;
>>> +
>>> + if (!drv_data->master->cur_msg) {
>>> + handle_bad_msg(drv_data);
>>> + /* Never fail */
>>> + return IRQ_HANDLED;
>>> + }
>>> +
>>
>>> + ret |= drv_data->transfer_handler(drv_data);
>>
>> So, we might call handler several times. This needs to be commented in
>> the code why you do so.
>
> I can move the commit log into the code.
>
>>
>>>
>>> - return drv_data->transfer_handler(drv_data);
>>> + status = pxa2xx_spi_read(drv_data, SSSR);
>>
>> Would it be possible to get all 1:s from the register
>> (something/autosuspend just powered off it by timeout?) ?
>>
>
> Not sure if that can happen, but I guess it would be simpler and more
> readable to simply do this instead:
>
> while (1) {
> /*
> * If the device is not yet in RPM suspended state and we get an
> * interrupt that is meant for another device, check if status
> * bits are all set to one. That means that the device is
> * already powered off.
> */
> status = pxa2xx_spi_read(drv_data, SSSR);
> if (status == ~0)
> return ret;
>
> sccr1_reg = pxa2xx_spi_read(drv_data, SSCR1);
>
> /* Ignore RX timeout interrupt if it is disabled */
> if (!(sccr1_reg & SSCR1_TINTE))
> mask &= ~SSSR_TINT;
>
> /* Ignore possible writes if we don't need to write */
> if (!(sccr1_reg & SSCR1_TIE))
> mask &= ~SSSR_TFS;
>
> if (!(status & mask))
> return ret;
>
> if (!drv_data->master->cur_msg) {
> handle_bad_msg(drv_data);
> /* Never fail */
> return IRQ_HANDLED;
> }
>
> ret |= drv_data->transfer_handler(drv_data);
> }
>
>
> i.e. preserve the current structure, just add the loop.
>
OK, please let me know if you want a v3 of this patch with the structure
above. If there are further concerns/questions, just let me know as
well, but I'd like to close this topic if possible.
Thanks,
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply
* [PATCH v2 14/14] ARM: dts: da850-lcdk: enable the SATA node
From: David Lechner @ 2017-01-17 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484655976-25382-15-git-send-email-bgolaszewski@baylibre.com>
On 01/17/2017 06:26 AM, Bartosz Golaszewski wrote:
> Enable the SATA node for da850-lcdk. We omit the pinctrl property on
> purpose - the muxed SATA pins are not hooked up to anything
> SATA-related on the lcdk.
>
> The REFCLKN/P rate on the board is 100MHz, so we need a multiplier of
> 15 for 1.5GHz PLL rate.
The multiplier is no longer in device tree, so this comment is not
necessary.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/boot/dts/da850-lcdk.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
> index afcb482..fbeee3c 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -105,6 +105,10 @@
> status = "okay";
> };
>
> +&sata {
> + status = "okay";
> +};
> +
> &mdio {
> pinctrl-names = "default";
> pinctrl-0 = <&mdio_pins>;
>
^ permalink raw reply
* [PATCH] Fix coding style errors "open brace go on the same line"
From: Adrien Descamps @ 2017-01-17 18:57 UTC (permalink / raw)
To: linux-arm-kernel
Open braces for enum, union and struct go on the same line.
Signed-off-by: Adrien Descamps <adrien.descamps@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
---
.../interface/vchi/connections/connection.h | 3 +--
.../interface/vchi/message_drivers/message.h | 9 +++------
drivers/staging/vc04_services/interface/vchi/vchi.h | 18 ++++++------------
.../staging/vc04_services/interface/vchi/vchi_common.h | 9 +++------
.../vc04_services/interface/vchiq_arm/vchiq_debugfs.h | 3 +--
5 files changed, 14 insertions(+), 28 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchi/connections/connection.h b/drivers/staging/vc04_services/interface/vchi/connections/connection.h
index fef6ac3..e793cdf 100644
--- a/drivers/staging/vc04_services/interface/vchi/connections/connection.h
+++ b/drivers/staging/vc04_services/interface/vchi/connections/connection.h
@@ -217,8 +217,7 @@ typedef void (*VCHI_BUFFER_FREE)(VCHI_CONNECTION_SERVICE_HANDLE_T service_hand
System driver struct
*****************************************************************************/
-struct opaque_vchi_connection_api_t
-{
+struct opaque_vchi_connection_api_t {
// Routine to init the connection
VCHI_CONNECTION_INIT_T init;
diff --git a/drivers/staging/vc04_services/interface/vchi/message_drivers/message.h b/drivers/staging/vc04_services/interface/vchi/message_drivers/message.h
index 8b3f767..a7740a4 100644
--- a/drivers/staging/vc04_services/interface/vchi/message_drivers/message.h
+++ b/drivers/staging/vc04_services/interface/vchi/message_drivers/message.h
@@ -53,14 +53,12 @@ typedef enum message_event_type {
MESSAGE_EVENT_MSG_DISCARDED
} MESSAGE_EVENT_TYPE_T;
-typedef enum vchi_msg_flags
-{
+typedef enum vchi_msg_flags {
VCHI_MSG_FLAGS_NONE = 0x0,
VCHI_MSG_FLAGS_TERMINATE_DMA = 0x1
} VCHI_MSG_FLAGS_T;
-typedef enum message_tx_channel
-{
+typedef enum message_tx_channel {
MESSAGE_TX_CHANNEL_MESSAGE = 0,
MESSAGE_TX_CHANNEL_BULK = 1 // drivers may provide multiple bulk channels, from 1 upwards
} MESSAGE_TX_CHANNEL_T;
@@ -69,8 +67,7 @@ typedef enum message_tx_channel
#define MESSAGE_TX_CHANNEL_BULK_PREV(c) (MESSAGE_TX_CHANNEL_BULK+((c)-MESSAGE_TX_CHANNEL_BULK+VCHI_MAX_BULK_TX_CHANNELS_PER_CONNECTION-1)%VCHI_MAX_BULK_TX_CHANNELS_PER_CONNECTION)
#define MESSAGE_TX_CHANNEL_BULK_NEXT(c) (MESSAGE_TX_CHANNEL_BULK+((c)-MESSAGE_TX_CHANNEL_BULK+1)%VCHI_MAX_BULK_TX_CHANNELS_PER_CONNECTION)
-typedef enum message_rx_channel
-{
+typedef enum message_rx_channel {
MESSAGE_RX_CHANNEL_MESSAGE = 0,
MESSAGE_RX_CHANNEL_BULK = 1 // drivers may provide multiple bulk channels, from 1 upwards
} MESSAGE_RX_CHANNEL_T;
diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h b/drivers/staging/vc04_services/interface/vchi/vchi.h
index d693728..44169d6 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -61,8 +61,7 @@ struct vchi_version {
#define VCHI_VERSION(v_) { v_, v_ }
#define VCHI_VERSION_EX(v_, m_) { v_, m_ }
-typedef enum
-{
+typedef enum {
VCHI_VEC_POINTER,
VCHI_VEC_HANDLE,
VCHI_VEC_LIST
@@ -71,26 +70,22 @@ typedef enum
typedef struct vchi_msg_vector_ex {
VCHI_MSG_VECTOR_TYPE_T type;
- union
- {
+ union {
// a memory handle
- struct
- {
+ struct {
VCHI_MEM_HANDLE_T handle;
uint32_t offset;
int32_t vec_len;
} handle;
// an ordinary data pointer
- struct
- {
+ struct {
const void *vec_base;
int32_t vec_len;
} ptr;
// a nested vector list
- struct
- {
+ struct {
struct vchi_msg_vector_ex *vec;
uint32_t vec_len;
} list;
@@ -114,8 +109,7 @@ struct opaque_vchi_service_t;
// Descriptor for a held message. Allocated by client, initialised by vchi_msg_hold,
// vchi_msg_iter_hold or vchi_msg_iter_hold_next. Fields are for internal VCHI use only.
-typedef struct
-{
+typedef struct {
struct opaque_vchi_service_t *service;
void *message;
} VCHI_HELD_MSG_T;
diff --git a/drivers/staging/vc04_services/interface/vchi/vchi_common.h b/drivers/staging/vc04_services/interface/vchi/vchi_common.h
index d535a72..3f7d843 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi_common.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi_common.h
@@ -36,8 +36,7 @@
//flags used when sending messages (must be bitmapped)
-typedef enum
-{
+typedef enum {
VCHI_FLAGS_NONE = 0x0,
VCHI_FLAGS_BLOCK_UNTIL_OP_COMPLETE = 0x1, // waits for message to be received, or sent (NB. not the same as being seen on other side)
VCHI_FLAGS_CALLBACK_WHEN_OP_COMPLETE = 0x2, // run a callback when message sent
@@ -62,8 +61,7 @@ typedef enum {
} VCHI_CRC_CONTROL_T;
//callback reasons when an event occurs on a service
-typedef enum
-{
+typedef enum {
VCHI_CALLBACK_REASON_MIN,
//This indicates that there is data available
@@ -111,8 +109,7 @@ typedef enum
} VCHI_CALLBACK_REASON_T;
// service control options
-typedef enum
-{
+typedef enum {
VCHI_SERVICE_OPTION_MIN,
VCHI_SERVICE_OPTION_TRACE,
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.h b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.h
index 4d6a378..1d95e3d 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.h
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.h
@@ -36,8 +36,7 @@
#include "vchiq_core.h"
-typedef struct vchiq_debugfs_node_struct
-{
+typedef struct vchiq_debugfs_node_struct {
struct dentry *dentry;
} VCHIQ_DEBUGFS_NODE_T;
--
2.1.4
^ permalink raw reply related
* [GIT PULL 2/2] Broadcom defconfig fixes for 4.10
From: Florian Fainelli @ 2017-01-17 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117060849.GE16607@localhost>
On 01/16/2017 10:08 PM, Olof Johansson wrote:
> On Sat, Jan 14, 2017 at 06:36:36PM -0800, Florian Fainelli wrote:
>> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
>>
>> Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
>>
>> are available in the git repository at:
>>
>> http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.10/defconfig-fixes
>>
>> for you to fetch changes up to 91546c56624a79f4a8fd80bede6b5a38c0f0ad78:
>>
>> ARM: multi_v7_defconfig: set bcm47xx watchdog (2017-01-12 16:03:12 -0800)
>>
>> ----------------------------------------------------------------
>> This pull request contains fixes to multi_v7_defconfig for Broadcom ARM-based
>> SoCs, please pull the following changes:
>>
>> - Valenting fixes two incorrect Kconfig symbols for BCM47xx: NVRAM and watchdog drivers
>>
>> ----------------------------------------------------------------
>> Valentin Rothberg (2):
>> ARM: multi_v7_defconfig: fix config typo
>> ARM: multi_v7_defconfig: set bcm47xx watchdog
>
> Merged. How did we even get here? Did the options rename or did someone
> edit config files by hand?
It's not me, it's the cat! I hand edited the file and goofed up
stupidly, twice!
Thanks!
--
Florian
^ permalink raw reply
* [PATCH v3] arm64: mm: Fix NOMAP page initialization
From: Will Deacon @ 2017-01-17 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117100015.GG5020@rric.localdomain>
On Tue, Jan 17, 2017 at 11:00:15AM +0100, Robert Richter wrote:
> On 13.01.17 14:15:00, Robert Richter wrote:
> > On 13.01.17 09:19:04, Will Deacon wrote:
> > > On Thu, Jan 12, 2017 at 07:58:25PM +0100, Robert Richter wrote:
> > > > On 12.01.17 16:05:36, Will Deacon wrote:
> > > > > On Mon, Jan 09, 2017 at 12:53:20PM +0100, Robert Richter wrote:
> > > >
> > > > > > Kernel compile times (3 runs each):
> > > > > >
> > > > > > pfn_valid_within():
> > > > > >
> > > > > > real 6m4.088s
> > > > > > user 372m57.607s
> > > > > > sys 16m55.158s
> > > > > >
> > > > > > real 6m1.532s
> > > > > > user 372m48.453s
> > > > > > sys 16m50.370s
> > > > > >
> > > > > > real 6m4.061s
> > > > > > user 373m18.753s
> > > > > > sys 16m57.027s
> > > > >
> > > > > Did you reboot the machine between each build here, or only when changing
> > > > > kernel? If the latter, do you see variations in kernel build time by simply
> > > > > rebooting the same Image?
> > > >
> > > > I built it in a loop on the shell, so no reboots between builds. Note
> > > > that I was building the kernel in /dev/shm to not access harddisks. I
> > > > think build times should be comparable then since there is no fs
> > > > caching.
> > >
> > > I guess I'm really asking what the standard deviation is if you *do* reboot
> > > between builds, using the same kernel. It's hard to tell whether the numbers
> > > are due to the patches, or just because of noise incurred by the way things
> > > happen to initialise.
> >
> > Ok, I am going to test this.
>
> See below the data for a test with reboots between every 3 builds (9
> builds per kernel). Though some deviation can be seen between reboots
> there is a trend.
I can't really see the trend given that, for system time, your
pfn_valid_within results have a variance of ~9 and the early_pfn_valid
results have a variance of ~92. Given that the variance seems to come
about due to the reboots, I think we need more numbers to establish whether
the data sets end up largely overlapping or if they really are disjoint.
Will
^ permalink raw reply
* [PATCH 3/5] ARM64: dts: meson-gxbb-p20x: add reset for the ethernet PHY
From: Jerome Brunet @ 2017-01-17 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202234739.22929-4-martin.blumenstingl@googlemail.com>
On Sat, 2016-12-03 at 00:47 +0100, Martin Blumenstingl wrote:
> This resets the ethernet PHY during boot to get the PHY into a
> "clean"
> state. While here also specify the phy-handle of the ethmac node to
> make the PHY configuration similar to the one we have on GXL devices.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.co
> m>
> Tested-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> ?arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15
> +++++++++++++++
> ?1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> index 203be28..2abc553 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> @@ -134,10 +134,25 @@
> ? pinctrl-names = "default";
> ?};
> ?
> +&mdio0 {
> + ethernet_phy0: ethernet-phy at 0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
Sorry for the late reply.
I just tried on the p200 and this patch (serie) breaks the network on
it. The PHY is not detected anymore.
>From the KSZ9031 Datasheet : "PHY Address 0h is supported as the unique
PHY address only; it is not supported as the broadcast PHY address
[...]"
So we can't just use the broadcast address here:
reg should be <3>.
> + };
> +};
> +
> ?ðmac {
> ? status = "okay";
> ? pinctrl-0 = <ð_rgmii_pins>;
> ? pinctrl-names = "default";
> +
> + phy-handle = <ðernet_phy0>;
> +
> + snps,reset-gpio = <&gpio GPIOZ_14 0>;
> + snps,reset-delays-us = <0 10000 1000000>;
> + snps,reset-active-low;
> +
> + phy-mode = "rgmii";
We can't define this in p20x. actually the p201 uses an rmii.
I have not idea about gpio reset, or the phy address for the p201.
I suppose it would be better to move this to meson-gxbb_p200.dts
I don't know if anybody has a p201, but until we can confirm a working
Ethernet configuration, we should probably drop it for the p201
Of course the problem was already there before this patch ...
> ?};
> ?
> ?&ir {
^ permalink raw reply
* [PATCH 0/5] meson-gx: reset RGMII PHYs and configure TX delay
From: Jerome Brunet @ 2017-01-17 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202234739.22929-1-martin.blumenstingl@googlemail.com>
On Sat, 2016-12-03 at 00:47 +0100, Martin Blumenstingl wrote:
> This partially fixes the 1000Mbit/s ethernet TX throughput issues (on
> networks which are not affected by the EEE problem, as reported here:
> [1]).
> The actual problem for the TX throughput issues was that the TX delay
> was applied twice:
> - once "accidentally" by the PHY (this was fixed with [2])
> - once by the MAC because there was a hardcoded TX delay (of 2ns),
> ? this will be configurable with the changes from [0]
>
> These are the dts changes which belong to my other series (in v2
> these patches were part of the other series, upon request of the
> net maintainers I have split the .dts changes into their own series
> so
> we are able to take both through different trees):
> "[PATCH net-next v3 0/2] stmmac: dwmac-meson8b: configurable
> RGMII TX delay": [0].
> Thus this series depends on the ACK for the binding changes in the
> other series!
>
> I based these changes on my other series "[PATCH v2 0/2] GXL and GXM
> SCPI improvements": [3]
>
>
> [0] http://lists.infradead.org/pipermail/linux-amlogic/2016-December/
> 001834.html
> [1] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/
> 001607.html
> [2] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/
> 001707.html
> [3] http://lists.infradead.org/pipermail/linux-amlogic/2016-December/
> 001831.html
>
> Martin Blumenstingl (5):
> ? ARM64: dts: meson-gx: move the MDIO node to meson-gx
Sorry for the late reply, I've only been able to test this yesterday.
With "snps,dwmac-mdio" provided in meson-gx.dtsi, the mdio_node is
defined in?stmmac_mdio_register and auto-detection of the PHY is
disabled for all meson-gx boards.
I wonder if this is desirable ? or maybe this something we could fix in
stmmac ? (perform auto-detect the mdio bus is provided without a PHY)
Also, I think bisect is broken between patch 1 and patch 4: The PHY of
some boards won't be detected between these patches. Should we squash
them ??
> ? ARM64: dts: meson-gxbb-odroidc2: add reset for the ethernet PHY
> ? ARM64: dts: meson-gxbb-p20x: add reset for the ethernet PHY
> ? ARM64: dts: meson-gxbb-vega-s95: add reset for the ethernet PHY
> ? ARM64: dts: amlogic: add the ethernet TX delay configuration
>
Last remark, about the use of?ethernet-phy-idXXXX.XXXX in the odroid
and the vega: Isn't it better to let phylib do the autodetection of the
phy id ?
If we want to specify the id in DT, we should probably add it for the
Micrel PHY of the p200 as well, for consistency.
> ?arch/arm64/boot/dts/amlogic/meson-gx.dtsi????????????|??6 ++++++
> ?arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts??| 17
> +++++++++++++++++
> ?arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi?????| 17
> +++++++++++++++++
> ?arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 17
> +++++++++++++++++
> ?arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts |??2 ++
> ?arch/arm64/boot/dts/amlogic/meson-gxl.dtsi???????????|??6 ------
> ?arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts??|??2 ++
> ?arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts??|??2 ++
> ?8 files changed, 63 insertions(+), 6 deletions(-)
>
^ permalink raw reply
* CONFIG_PCIEASPM breaks PCIe on Marvell Armada 385 machine
From: Russell King - ARM Linux @ 2017-01-17 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117181458.GB11063@bhelgaas-glaptop.roam.corp.google.com>
On Tue, Jan 17, 2017 at 12:14:58PM -0600, Bjorn Helgaas wrote:
> The instrumentation has evolved a bit since then. Latest is below (could
> still use improvement, but it does address your suggestions above):
>
> https://bugzilla.kernel.org/attachment.cgi?id=251691 (CONFIG_PCIEASPM=y)
> https://bugzilla.kernel.org/attachment.cgi?id=251701 (CONFIG_PCIEASPM not set)
Thanks.
The point at which things die is when we request a link retrain - I've
augmented the trace with the register names:
pci 0000:02:00.0: rd where=0x074 size=4 val=0x8dc1 (hw) EXP_DEVCAP
pcie_aspm_configure_common_clock():
pci 0000:02:00.0: rd where=0x082 size=2 val=0x1011 (hw) EXP_LNKSTA
pci 0000:??:??.?: rd where=0x052 size=2 val=0x1011 (sw) EXP_LNKSTA
pci 0000:02:00.0: rd where=0x080 size=2 val=0x0 (hw) EXP_LNKCTL
pci 0000:02:00.0: wr where=0x080 size=2 val=0x40 (hw) EXP_LNKCTL
Enables common clock configuration on the device.
pci 0000:??:??.?: rd where=0x050 size=2 val=0x40 (sw) EXP_LNKCTL
pci 0000:??:??.?: wr where=0x050 size=2 val=0x40 (sw) EXP_LNKCTL
Common clock configuration is already enabled on the root.
pci 0000:??:??.?: rd where=0x050 size=4 val=0x10110040 (sw) EXP_LNKCTL
pci 0000:??:??.?: wr where=0x050 size=2 val=0x60 (sw) EXP_LNKCTL
Here we request the train, setting bit 5 in the link control
register.
pci 0000:??:??.?: rd where=0x050 size=4 val=0x110040 (sw) EXP_LNKCTL
pci 0000:??:??.?: rd where=0x052 size=2 val=0x811 (sw) EXP_LNKSTA
pci 0000:??:??.?: rd where=0x052 size=2 val=0x811 (sw) EXP_LNKSTA
Waiting for the link training bit to clear...
pci 0000:??:??.?: rd where=0x052 size=2 val=0x11 (sw) EXP_LNKSTA
and it's cleared here - but note that the link is still down.
pci 0000:??:??.?: rd where=0x04c size=4 val=0x3ac12 (sw) EXP_LNKCAP
pci 0000:??:??.?: rd where=0x050 size=2 val=0x40 (sw) EXP_LNKCTL
pcie_get_aspm_reg() for the root.
pci 0000:02:00.0: rd where=0x07c size=4 val=0xffffffff (no link)
pcie_get_aspm_reg() for the device (fails).
So, I think the question is... why does asking for a retrain cause
the link to fail and never recover?
Uwe, can you try:
setpci -s <whatever-the-id-of-the-root-is-it's-blanked-out-in-the-above> \
0x50.w=0x60
and see whether it remains alive (you can check by reading the root
register 0x52.w - bit 12 should be set once bit 11 clears again.
If that's successful, maybe setting the common clock bit on the PCIe
device is what's causing the problem, in which case:
setpci -s 02:00.0 0x80.w=0x40
setpci -s <whatever-the-id-of-the-root-is-it's-blanked-out-in-the-above> \
0x50.w=0x60
I would imagine would cause the link to go down. So, the question
this gives us is why the common clock setup is not working on your
platform. Maybe we need to source the SLC bit in the link status
from DT, though I'd like to understand what's going on here more
first.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v9 2/5] i2c: Add STM32F4 I2C driver
From: Uwe Kleine-König @ 2017-01-17 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484666821-20551-3-git-send-email-cedric.madianga@gmail.com>
Hello,
On Tue, Jan 17, 2017 at 04:26:58PM +0100, M'boumba Cedric Madianga wrote:
> +static void stm32f4_i2c_set_rise_time(struct stm32f4_i2c_dev *i2c_dev)
> +{
> + u32 freq = DIV_ROUND_UP(i2c_dev->parent_rate, HZ_TO_MHZ);
> + u32 trise;
> +
> + /*
> + * These bits must be programmed with the maximum SCL rise time given in
> + * the I2C bus specification, incremented by 1.
> + *
> + * In standard mode, the maximum allowed SCL rise time is 1000 ns.
> + * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is equal to
> + * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
> + * programmed with 09h.(1000 ns / 125 ns = 8 + 1)
* programmed with 0x9. (1000 ns / 125 ns = 8)
> + * So, for I2C standard mode TRISE = FREQ[5:0] + 1
> + *
> + * In fast mode, the maximum allowed SCL rise time is 300 ns.
> + * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is equal to
> + * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
> + * programmed with 03h.(300 ns / 125 ns = 2 + 1)
as above s/03h/0x3/; s/.(/. (/; s/+ 1//;
> + * So, for I2C fast mode TRISE = FREQ[5:0] * 300 / 1000 + 1
> + */
> + if (i2c_dev->speed == STM32F4_I2C_SPEED_STANDARD)
> + trise = freq + 1;
> + else
> + trise = freq * 300 / 1000 + 1;
I'd use
* 3 / 10
without downside and lesser chance to overflow.
> +
> + writel_relaxed(STM32F4_I2C_TRISE_VALUE(trise),
> + i2c_dev->base + STM32F4_I2C_TRISE);
> +}
> +
> +static void stm32f4_i2c_set_speed_mode(struct stm32f4_i2c_dev *i2c_dev)
> +{
> + u32 val;
> + u32 ccr = 0;
> +
> + if (i2c_dev->speed == STM32F4_I2C_SPEED_STANDARD) {
> + /*
> + * In standard mode:
> + * t_scl_high = t_scl_low = CCR * I2C parent clk period
> + * So to reach 100 kHz, we have:
> + * CCR = I2C parent rate / 100 kHz >> 1
> + *
> + * For example with parent rate = 2 MHz:
> + * CCR = 2000000 / (100000 << 1) = 10
> + * t_scl_high = t_scl_low = 10 * (1 / 2000000) = 5000 ns
> + * t_scl_high + t_scl_low = 10000 ns so 100 kHz is reached
> + */
> + val = i2c_dev->parent_rate / (100000 << 1);
> + } else {
> + /*
> + * In fast mode, we compute CCR with duty = 0 as with low
> + * frequencies we are not able to reach 400 kHz.
> + * In that case:
> + * t_scl_high = CCR * I2C parent clk period
> + * t_scl_low = 2 * CCR * I2C parent clk period
> + * So, CCR = I2C parent rate / (400 kHz * 3)
> + *
> + * For example with parent rate = 6 MHz:
> + * CCR = 6000000 / (400000 * 3) = 5
> + * t_scl_high = 5 * (1 / 6000000) = 833 ns > 600 ns
> + * t_scl_low = 2 * 5 * (1 / 6000000) = 1667 ns > 1300 ns
> + * t_scl_high + t_scl_low = 2500 ns so 400 kHz is reached
> + */
Huh, that's surprising. So you don't use DUTY any more. I found two
hints in the manual that contradict here:
f_{PCLK1} must be at least 2 MHz to achieve Sm mode I2C
frequencies. It must be at least 4 MHz to achieve Fm mode I2C
frequencies. It must be a multiple of 10MHz to reach the
400 kHz maximum I2C Fm mode clock.
and
[...]
If DUTY = 1: (to reach 400 kHz)
Strange.
> + val = DIV_ROUND_UP(i2c_dev->parent_rate, 400000 * 3);
the manual reads:
The minimum allowed value is 0x04, except in FAST DUTY mode
where the minimum allowed value is 0x01
You don't check for that, right?
CCR is 11 bits wide. A comment confirming that this cannot overflow
would be nice.
+ /* select Fast Mode */
> + ccr |= STM32F4_I2C_CCR_FS;
I didn't check the rest of the code, so let's assume it's good :-)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] arm64: dts: qcom: Replace PMU compatible with a53 specific one
From: Stephen Boyd @ 2017-01-17 19:47 UTC (permalink / raw)
To: linux-arm-kernel
The PMU on msm8916 is for the cortex-a53 type CPU. Update the
compatible to the more specific one so we can get the a53
specific events out of the PMU.
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 466ca5705c99..572d1a58844f 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -156,7 +156,7 @@
};
pmu {
- compatible = "arm,armv8-pmuv3";
+ compatible = "arm,cortex-a53-pmu";
interrupts = <GIC_PPI 7 GIC_CPU_MASK_SIMPLE(4)>;
};
--
2.10.0.297.gf6727b0
^ permalink raw reply related
* [PATCH v12 6/7] arm64: pmu: Detect and enable multiple PMUs in an ACPI system
From: Jeremy Linton @ 2017-01-17 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116182838.GA1843@red-moon>
On 01/16/2017 12:28 PM, Lorenzo Pieralisi wrote:
> On Tue, Jan 10, 2017 at 11:17:51AM -0600, Jeremy Linton wrote:
>
> [...]
>
>> +static int __init pmu_acpi_init(void)
>> +{
>> + struct pmu_types *pmu, *safe_temp;
>> + bool unused_madt_entries;
>> + LIST_HEAD(pmus);
>> +
>> + if (acpi_disabled)
>> + return 0;
>> +
>> + unused_madt_entries = arm_pmu_acpi_determine_cpu_types(&pmus);
>
> IIUC (and that's an if) unused_madt_entries is a "buffer" that you add
> to all platform devices you manage to create through midr matching to
> make sure there are enough resource entries when/if a cpu of the
> respective type is onlined.
>
> If that's the case unused_madt_entries can't be a bool.
Some where along in the patch churn, it transformed from a bool
indicating there were extras to the count which triggered allocation at
max cpu counts to just adding in the difference. So yes, its a bug if
there is more than 1 offline CPU. I will resubmit it.
>
> Second question I have is what happens if cpus that aren't online
> have an midr that differs from all the entries parsed at init time
> (ie those you created a platform device for), that's certainly
> a pesky corner case though.
Yes, right now if you have an entire class of cores offline at boot and
they are later brought online, they won't get PMU entries because that
requires creating another platform device, and the posted code can't
handle that. I was ignoring it for this patch set because it fails
gracefully and I didn't want to add even more churn.
^ permalink raw reply
* [GIT PULL] ARM: at91: soc for 4.11
From: Alexandre Belloni @ 2017-01-17 20:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof
A single cleanup for mach-at91. Maybe I'll send another pull request
later with further PM cleanup. Else, that will probably be all for 4.11
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.11-soc
for you to fetch changes up to 6cc7fbdf8d931eefa2d0aabf0d2840e94ba09ae5:
ARM: at91: pm: remove useless extern definition (2017-01-11 13:21:24 +0100)
----------------------------------------------------------------
SoC for 4.11:
- small cleanup
----------------------------------------------------------------
Alexandre Belloni (1):
ARM: at91: pm: remove useless extern definition
arch/arm/mach-at91/pm.c | 2 +-
arch/arm/mach-at91/pm.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [GIT PULL] ARM: at91: drivers for 4.11
From: Alexandre Belloni @ 2017-01-17 20:03 UTC (permalink / raw)
To: linux-arm-kernel
Arnd, Olof,
This is a single fix for the atmel-ebi.
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.11-drivers
for you to fetch changes up to ee194289502a6901cc77dc9a893bf2afd351ac5e:
memory/atmel-ebi: Fix ns <-> cycles conversions (2017-01-10 16:01:34 +0100)
----------------------------------------------------------------
Drivers for 4.11:
- atmel-ebi: Fix ns <-> cycles conversions
----------------------------------------------------------------
Boris Brezillon (1):
memory/atmel-ebi: Fix ns <-> cycles conversions
drivers/memory/atmel-ebi.c | 27 ++++++++++++++-------------
1 file changed, 14 insertions(+), 13 deletions(-)
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/4] phy: sun4i-usb: support PHY0 on H3 in MUSB mode
From: Maxime Ripard @ 2017-01-17 20:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3866431484672228@web20j.yandex.ru>
On Wed, Jan 18, 2017 at 12:57:08AM +0800, Icenowy Zheng wrote:
>
>
> 17.01.2017, 16:06, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> > On Tue, Jan 17, 2017 at 03:14:46AM +0800, Icenowy Zheng wrote:
> >> ?The PHY0 on H3 can be wired either to MUSB controller or OHCI/EHCI
> >> ?controller.
> >>
> >> ?The original driver wired it to OHCI/EHCI controller; however, as the
> >> ?code to use PHY0 as OHCI/EHCI is missing, it makes the PHY fully
> >> ?unusable.
> >>
> >> ?Rename the register (according to its function and the name in BSP
> >> ?driver), and remove the code which wires the PHY0 to OHCI/EHCI, as MUSB
> >> ?can support both peripheral and host mode (although the host mode of
> >> ?MUSB is buggy).
> >
> > Can you elaborate on that? What's wrong with it?
>
> The configuration is at bit 0 of register 0x20 in PHY.
>
> When the PHY is reseted, it defaults as MUSB mode.
>
> However, the original author of the H3 PHY code seems to be lack of
> this knowledge (He named it PHY_UNK_H3), and changed the PHY to HCI
> mode.
>
> I just removed the code that wires it to HCI mode, thus it will work
> in MUSB mode, with my sun8i-h3-musb patch.
I have no idea what you mean by MUSB mode.
Do you mean that the previous code was only working in host mode, and
now it only works in peripheral?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170117/69bbe9da/attachment.sig>
^ permalink raw reply
* [PATCH 1/4] phy: sun4i-usb: support PHY0 on H3 in MUSB mode
From: Chen-Yu Tsai @ 2017-01-17 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117200658.gcrcxeanthdtwg26@lukather>
Hi,
On Wed, Jan 18, 2017 at 4:06 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Wed, Jan 18, 2017 at 12:57:08AM +0800, Icenowy Zheng wrote:
>>
>>
>> 17.01.2017, 16:06, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>> > On Tue, Jan 17, 2017 at 03:14:46AM +0800, Icenowy Zheng wrote:
>> >> The PHY0 on H3 can be wired either to MUSB controller or OHCI/EHCI
>> >> controller.
>> >>
>> >> The original driver wired it to OHCI/EHCI controller; however, as the
>> >> code to use PHY0 as OHCI/EHCI is missing, it makes the PHY fully
>> >> unusable.
>> >>
>> >> Rename the register (according to its function and the name in BSP
>> >> driver), and remove the code which wires the PHY0 to OHCI/EHCI, as MUSB
>> >> can support both peripheral and host mode (although the host mode of
>> >> MUSB is buggy).
>> >
>> > Can you elaborate on that? What's wrong with it?
>>
>> The configuration is at bit 0 of register 0x20 in PHY.
>>
>> When the PHY is reseted, it defaults as MUSB mode.
>>
>> However, the original author of the H3 PHY code seems to be lack of
>> this knowledge (He named it PHY_UNK_H3), and changed the PHY to HCI
>> mode.
>>
>> I just removed the code that wires it to HCI mode, thus it will work
>> in MUSB mode, with my sun8i-h3-musb patch.
>
> I have no idea what you mean by MUSB mode.
>
> Do you mean that the previous code was only working in host mode, and
> now it only works in peripheral?
>From what I understand, with the H3, Allwinner has put a mux
in front of the MUSB controller. The mux can send the USB data
to/from the MUSB controller, or a standard EHCI/OHCI pair.
This register controls said mux.
This means we can use a proper USB host for host mode,
instead of the limited support in MUSB.
ChenYu
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [GIT PULL] ARM: at91: DT for 4.11
From: Alexandre Belloni @ 2017-01-17 20:09 UTC (permalink / raw)
To: linux-arm-kernel
Arnd, Olof,
Here is the DT pull request, adding a few boards and improving
sama5d2 and sama5d4 support.
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.11-dt
for you to fetch changes up to 21dd0ece34c2a07432a1cd0bbcb4815ce2b49173:
ARM: dts: at91: add devicetree for the Axentia TSE-850 (2017-01-10 16:16:33 +0100)
----------------------------------------------------------------
DT for 4.11:
- New boards: Axentia TSE-850, sama5d36ek CMP
- new device definitions for sama5d2
- Fix DMA allocation on sama5d4 for secure peripherals
----------------------------------------------------------------
Alex (1):
ARM: dts: at91: sama5d2: add ssc0 definition
Nicolas Ferre (5):
ARM: dts: at91: sama5d4: change DMA allocation for secure peripherals
ARM: dts: at91: sama5d4 Xplained: enable UART1 node with DMA
ARM: dts: at91: add dma1 definition to sama5d2
ARM: dts: at91: sama5d2: move UART3 to DMA1
ARM: dts: at91: sama5d2 Xplained: use DMA for UART3
Peter Rosin (2):
ARM: dts: at91: sama5d3_uart: fix reg sizes to match documentation
ARM: dts: at91: add devicetree for the Axentia TSE-850
Wenyou Yang (1):
ARM: dts: at91: add dts file for sama5d36ek CMP board
Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
MAINTAINERS | 8 +
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/at91-linea.dtsi | 49 ++++
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 2 +
arch/arm/boot/dts/at91-sama5d4_xplained.dts | 6 +
arch/arm/boot/dts/at91-tse850-3.dts | 274 ++++++++++++++++++++
arch/arm/boot/dts/sama5d2.dtsi | 30 ++-
arch/arm/boot/dts/sama5d36ek_cmp.dts | 87 +++++++
arch/arm/boot/dts/sama5d3_uart.dtsi | 4 +-
arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 201 +++++++++++++++
arch/arm/boot/dts/sama5d3xmb_cmp.dtsi | 301 ++++++++++++++++++++++
arch/arm/boot/dts/sama5d4.dtsi | 16 +-
13 files changed, 987 insertions(+), 12 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
create mode 100644 arch/arm/boot/dts/at91-linea.dtsi
create mode 100644 arch/arm/boot/dts/at91-tse850-3.dts
create mode 100644 arch/arm/boot/dts/sama5d36ek_cmp.dts
create mode 100644 arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
create mode 100644 arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [GIT PULL] ARM: at91: defconfig for 4.11
From: Alexandre Belloni @ 2017-01-17 20:10 UTC (permalink / raw)
To: linux-arm-kernel
Arnd, Olof,
A single patch, adding the drivers needed by the newly added Axentia
TSE-850
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.11-defconfig
for you to fetch changes up to f46b1d47d4a14ddf0f935283c7c0bd0d446c54b0:
ARM: sama5_defconfig: add support for the Axentia TSE-850 board (2017-01-10 16:13:48 +0100)
----------------------------------------------------------------
defconfig for 4.11:
- Add driver support for the Axentia TSE-850
----------------------------------------------------------------
Peter Rosin (1):
ARM: sama5_defconfig: add support for the Axentia TSE-850 board
arch/arm/configs/sama5_defconfig | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [GIT PULL] Amlogic fixes for v4.10-rc4
From: Olof Johansson @ 2017-01-17 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m2wpdt4qll.fsf@baylibre.com>
On Tue, Jan 17, 2017 at 08:07:50AM -0800, Kevin Hilman wrote:
> Hi Olof,
>
> Olof Johansson <olof@lixom.net> writes:
>
> > On Mon, Jan 16, 2017 at 03:24:59PM +0100, Andreas F??rber wrote:
> >> Am 13.01.2017 um 19:17 schrieb Kevin Hilman:
> >> > ----------------------------------------------------------------
> >> > Amlogic fixes for v4.10-rc4
> >> > - odroid-c2: disable DVFS to avoid crashes due to broken SCPI
> >> > - fix misc. crashes by adding known reserved memory regions
> >> >
> >> > ----------------------------------------------------------------
> >> > Neil Armstrong (2):
> >> > ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS
> >>
> >> > ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
> >>
> >> Objection against the latter patch introducing widespread usage of
> >> hardcoded linux,usable-memory properties - please review closely before
> >> considering to merge.
> >
> > Holding off until that discussion has concluded. Following up on that thread as
> > well.
>
> While we rework the reserved memory fix, could you cherry-pick the SCPI
> fix from this branch into fixes? That one is independent from this, and
> is also a nasty crash.
Sure! Applied to fixes.
Thanks,
-Olof
^ permalink raw reply
* [PATCH v2 1/3] clk: bcm2835: Don't rate change PLLs on behalf of DSI PLL dividers.
From: Eric Anholt @ 2017-01-17 20:31 UTC (permalink / raw)
To: linux-arm-kernel
Our core PLLs are intended to be configured once and left alone. With
the SET_RATE_PARENT, asking to set the PLLD_DSI1 clock rate would
change PLLD just to get closer to the requested DSI clock, thus
changing PLLD_PER, the UART and ethernet PHY clock rates downstream of
it, and breaking ethernet.
We *do* want PLLH to change so that PLLH_AUX can be exactly the value
we want, though. Thus, we need to have a per-divider policy of
whether to pass rate changes up.
Signed-off-by: Eric Anholt <eric@anholt.net>
---
drivers/clk/bcm/clk-bcm2835.c | 42 ++++++++++++++++++++++++++++--------------
1 file changed, 28 insertions(+), 14 deletions(-)
diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 0d14409097e7..3d0848d535d7 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -428,6 +428,7 @@ struct bcm2835_pll_divider_data {
u32 load_mask;
u32 hold_mask;
u32 fixed_divider;
+ u32 flags;
};
struct bcm2835_clock_data {
@@ -1252,7 +1253,7 @@ bcm2835_register_pll_divider(struct bcm2835_cprman *cprman,
init.num_parents = 1;
init.name = divider_name;
init.ops = &bcm2835_pll_divider_clk_ops;
- init.flags = CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED;
+ init.flags = data->flags | CLK_IGNORE_UNUSED;
divider = devm_kzalloc(cprman->dev, sizeof(*divider), GFP_KERNEL);
if (!divider)
@@ -1466,7 +1467,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.a2w_reg = A2W_PLLA_CORE,
.load_mask = CM_PLLA_LOADCORE,
.hold_mask = CM_PLLA_HOLDCORE,
- .fixed_divider = 1),
+ .fixed_divider = 1,
+ .flags = CLK_SET_RATE_PARENT),
[BCM2835_PLLA_PER] = REGISTER_PLL_DIV(
.name = "plla_per",
.source_pll = "plla",
@@ -1474,7 +1476,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.a2w_reg = A2W_PLLA_PER,
.load_mask = CM_PLLA_LOADPER,
.hold_mask = CM_PLLA_HOLDPER,
- .fixed_divider = 1),
+ .fixed_divider = 1,
+ .flags = CLK_SET_RATE_PARENT),
[BCM2835_PLLA_DSI0] = REGISTER_PLL_DIV(
.name = "plla_dsi0",
.source_pll = "plla",
@@ -1490,7 +1493,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.a2w_reg = A2W_PLLA_CCP2,
.load_mask = CM_PLLA_LOADCCP2,
.hold_mask = CM_PLLA_HOLDCCP2,
- .fixed_divider = 1),
+ .fixed_divider = 1,
+ .flags = CLK_SET_RATE_PARENT),
/* PLLB is used for the ARM's clock. */
[BCM2835_PLLB] = REGISTER_PLL(
@@ -1514,7 +1518,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.a2w_reg = A2W_PLLB_ARM,
.load_mask = CM_PLLB_LOADARM,
.hold_mask = CM_PLLB_HOLDARM,
- .fixed_divider = 1),
+ .fixed_divider = 1,
+ .flags = CLK_SET_RATE_PARENT),
/*
* PLLC is the core PLL, used to drive the core VPU clock.
@@ -1543,7 +1548,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.a2w_reg = A2W_PLLC_CORE0,
.load_mask = CM_PLLC_LOADCORE0,
.hold_mask = CM_PLLC_HOLDCORE0,
- .fixed_divider = 1),
+ .fixed_divider = 1,
+ .flags = CLK_SET_RATE_PARENT),
[BCM2835_PLLC_CORE1] = REGISTER_PLL_DIV(
.name = "pllc_core1",
.source_pll = "pllc",
@@ -1551,7 +1557,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.a2w_reg = A2W_PLLC_CORE1,
.load_mask = CM_PLLC_LOADCORE1,
.hold_mask = CM_PLLC_HOLDCORE1,
- .fixed_divider = 1),
+ .fixed_divider = 1,
+ .flags = CLK_SET_RATE_PARENT),
[BCM2835_PLLC_CORE2] = REGISTER_PLL_DIV(
.name = "pllc_core2",
.source_pll = "pllc",
@@ -1559,7 +1566,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.a2w_reg = A2W_PLLC_CORE2,
.load_mask = CM_PLLC_LOADCORE2,
.hold_mask = CM_PLLC_HOLDCORE2,
- .fixed_divider = 1),
+ .fixed_divider = 1,
+ .flags = CLK_SET_RATE_PARENT),
[BCM2835_PLLC_PER] = REGISTER_PLL_DIV(
.name = "pllc_per",
.source_pll = "pllc",
@@ -1567,7 +1575,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.a2w_reg = A2W_PLLC_PER,
.load_mask = CM_PLLC_LOADPER,
.hold_mask = CM_PLLC_HOLDPER,
- .fixed_divider = 1),
+ .fixed_divider = 1,
+ .flags = CLK_SET_RATE_PARENT),
/*
* PLLD is the display PLL, used to drive DSI display panels.
@@ -1596,7 +1605,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.a2w_reg = A2W_PLLD_CORE,
.load_mask = CM_PLLD_LOADCORE,
.hold_mask = CM_PLLD_HOLDCORE,
- .fixed_divider = 1),
+ .fixed_divider = 1,
+ .flags = CLK_SET_RATE_PARENT),
[BCM2835_PLLD_PER] = REGISTER_PLL_DIV(
.name = "plld_per",
.source_pll = "plld",
@@ -1604,7 +1614,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.a2w_reg = A2W_PLLD_PER,
.load_mask = CM_PLLD_LOADPER,
.hold_mask = CM_PLLD_HOLDPER,
- .fixed_divider = 1),
+ .fixed_divider = 1,
+ .flags = CLK_SET_RATE_PARENT),
[BCM2835_PLLD_DSI0] = REGISTER_PLL_DIV(
.name = "plld_dsi0",
.source_pll = "plld",
@@ -1649,7 +1660,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.a2w_reg = A2W_PLLH_RCAL,
.load_mask = CM_PLLH_LOADRCAL,
.hold_mask = 0,
- .fixed_divider = 10),
+ .fixed_divider = 10,
+ .flags = CLK_SET_RATE_PARENT),
[BCM2835_PLLH_AUX] = REGISTER_PLL_DIV(
.name = "pllh_aux",
.source_pll = "pllh",
@@ -1657,7 +1669,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.a2w_reg = A2W_PLLH_AUX,
.load_mask = CM_PLLH_LOADAUX,
.hold_mask = 0,
- .fixed_divider = 1),
+ .fixed_divider = 1,
+ .flags = CLK_SET_RATE_PARENT),
[BCM2835_PLLH_PIX] = REGISTER_PLL_DIV(
.name = "pllh_pix",
.source_pll = "pllh",
@@ -1665,7 +1678,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.a2w_reg = A2W_PLLH_PIX,
.load_mask = CM_PLLH_LOADPIX,
.hold_mask = 0,
- .fixed_divider = 10),
+ .fixed_divider = 10,
+ .flags = CLK_SET_RATE_PARENT),
/* the clocks */
--
2.11.0
^ permalink raw reply related
* [PATCH v2 2/3] clk: bcm2835: Register the DSI0/DSI1 pixel clocks.
From: Eric Anholt @ 2017-01-17 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117203157.23822-1-eric@anholt.net>
The DSI pixel clocks are muxed from clocks generated in the analog phy
by the DSI driver. In order to set them as parents, we need to do the
same name lookup dance on them as we do for our root oscillator.
Signed-off-by: Eric Anholt <eric@anholt.net>
---
v2: now with of_clk_parent_fill().
.../bindings/clock/brcm,bcm2835-cprman.txt | 15 ++-
drivers/clk/bcm/clk-bcm2835.c | 121 +++++++++++++++++++--
include/dt-bindings/clock/bcm2835.h | 2 +
3 files changed, 125 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt b/Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt
index e56a1df3a9d3..dd906db34b32 100644
--- a/Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt
+++ b/Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt
@@ -16,7 +16,20 @@ Required properties:
- #clock-cells: Should be <1>. The permitted clock-specifier values can be
found in include/dt-bindings/clock/bcm2835.h
- reg: Specifies base physical address and size of the registers
-- clocks: The external oscillator clock phandle
+- clocks: phandles to the parent clocks used as input to the module, in
+ the following order:
+
+ - External oscillator
+ - DSI0 byte clock
+ - DSI0 DDR2 clock
+ - DSI0 DDR clock
+ - DSI1 byte clock
+ - DSI1 DDR2 clock
+ - DSI1 DDR clock
+
+ Only external oscillator is required. The DSI clocks may
+ not be present, in which case their children will be
+ unusable.
Example:
diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 3d0848d535d7..2e7423d8f5bb 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -297,11 +297,32 @@
#define LOCK_TIMEOUT_NS 100000000
#define BCM2835_MAX_FB_RATE 1750000000u
+/*
+ * Names of clocks used within the driver that need to be replaced
+ * with an external parent's name. This array is in the order that
+ * the clocks node in the DT references external clocks.
+ */
+static const char *const cprman_parent_names[] = {
+ "xosc",
+ "dsi0_byte",
+ "dsi0_ddr2",
+ "dsi0_ddr",
+ "dsi1_byte",
+ "dsi1_ddr2",
+ "dsi1_ddr",
+};
+
struct bcm2835_cprman {
struct device *dev;
void __iomem *regs;
spinlock_t regs_lock; /* spinlock for all clocks */
- const char *osc_name;
+
+ /*
+ * Real names of cprman clock parents looked up through
+ * of_clk_get_parent_name(), which will be used in the
+ * parent_names[] arrays for clock registration.
+ */
+ const char *real_parent_names[ARRAY_SIZE(cprman_parent_names)];
/* Must be last */
struct clk_hw_onecell_data onecell;
@@ -907,6 +928,9 @@ static long bcm2835_clock_rate_from_divisor(struct bcm2835_clock *clock,
const struct bcm2835_clock_data *data = clock->data;
u64 temp;
+ if (data->int_bits == 0 && data->frac_bits == 0)
+ return parent_rate;
+
/*
* The divisor is a 12.12 fixed point field, but only some of
* the bits are populated in any given clock.
@@ -930,7 +954,12 @@ static unsigned long bcm2835_clock_get_rate(struct clk_hw *hw,
struct bcm2835_clock *clock = bcm2835_clock_from_hw(hw);
struct bcm2835_cprman *cprman = clock->cprman;
const struct bcm2835_clock_data *data = clock->data;
- u32 div = cprman_read(cprman, data->div_reg);
+ u32 div;
+
+ if (data->int_bits == 0 && data->frac_bits == 0)
+ return parent_rate;
+
+ div = cprman_read(cprman, data->div_reg);
return bcm2835_clock_rate_from_divisor(clock, parent_rate, div);
}
@@ -1209,7 +1238,7 @@ static struct clk_hw *bcm2835_register_pll(struct bcm2835_cprman *cprman,
memset(&init, 0, sizeof(init));
/* All of the PLLs derive from the external oscillator. */
- init.parent_names = &cprman->osc_name;
+ init.parent_names = &cprman->real_parent_names[0];
init.num_parents = 1;
init.name = data->name;
init.ops = &bcm2835_pll_clk_ops;
@@ -1295,18 +1324,22 @@ static struct clk_hw *bcm2835_register_clock(struct bcm2835_cprman *cprman,
struct bcm2835_clock *clock;
struct clk_init_data init;
const char *parents[1 << CM_SRC_BITS];
- size_t i;
+ size_t i, j;
int ret;
/*
- * Replace our "xosc" references with the oscillator's
- * actual name.
+ * Replace our strings referencing parent clocks with the
+ * actual clock-output-name of the parent.
*/
for (i = 0; i < data->num_mux_parents; i++) {
- if (strcmp(data->parents[i], "xosc") == 0)
- parents[i] = cprman->osc_name;
- else
- parents[i] = data->parents[i];
+ parents[i] = data->parents[i];
+
+ for (j = 0; j < ARRAY_SIZE(cprman_parent_names); j++) {
+ if (strcmp(parents[i], cprman_parent_names[j]) == 0) {
+ parents[i] = cprman->real_parent_names[j];
+ break;
+ }
+ }
}
memset(&init, 0, sizeof(init));
@@ -1433,6 +1466,47 @@ static const char *const bcm2835_clock_vpu_parents[] = {
__VA_ARGS__)
/*
+ * DSI parent clocks. The DSI byte/DDR/DDR2 clocks come from the DSI
+ * analog PHY. The _inv variants are generated internally to cprman,
+ * but we don't use them so they aren't hooked up.
+ */
+static const char *const bcm2835_clock_dsi0_parents[] = {
+ "gnd",
+ "xosc",
+ "testdebug0",
+ "testdebug1",
+ "dsi0_ddr",
+ "dsi0_ddr_inv",
+ "dsi0_ddr2",
+ "dsi0_ddr2_inv",
+ "dsi0_byte",
+ "dsi0_byte_inv",
+};
+
+static const char *const bcm2835_clock_dsi1_parents[] = {
+ "gnd",
+ "xosc",
+ "testdebug0",
+ "testdebug1",
+ "dsi1_ddr",
+ "dsi1_ddr_inv",
+ "dsi1_ddr2",
+ "dsi1_ddr2_inv",
+ "dsi1_byte",
+ "dsi1_byte_inv",
+};
+
+#define REGISTER_DSI0_CLK(...) REGISTER_CLK( \
+ .num_mux_parents = ARRAY_SIZE(bcm2835_clock_dsi0_parents), \
+ .parents = bcm2835_clock_dsi0_parents, \
+ __VA_ARGS__)
+
+#define REGISTER_DSI1_CLK(...) REGISTER_CLK( \
+ .num_mux_parents = ARRAY_SIZE(bcm2835_clock_dsi1_parents), \
+ .parents = bcm2835_clock_dsi1_parents, \
+ __VA_ARGS__)
+
+/*
* the real definition of all the pll, pll_dividers and clocks
* these make use of the above REGISTER_* macros
*/
@@ -1895,6 +1969,18 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.div_reg = CM_DSI1EDIV,
.int_bits = 4,
.frac_bits = 8),
+ [BCM2835_CLOCK_DSI0P] = REGISTER_DSI0_CLK(
+ .name = "dsi0p",
+ .ctl_reg = CM_DSI0PCTL,
+ .div_reg = CM_DSI0PDIV,
+ .int_bits = 0,
+ .frac_bits = 0),
+ [BCM2835_CLOCK_DSI1P] = REGISTER_DSI1_CLK(
+ .name = "dsi1p",
+ .ctl_reg = CM_DSI1PCTL,
+ .div_reg = CM_DSI1PDIV,
+ .int_bits = 0,
+ .frac_bits = 0),
/* the gates */
@@ -1953,8 +2039,19 @@ static int bcm2835_clk_probe(struct platform_device *pdev)
if (IS_ERR(cprman->regs))
return PTR_ERR(cprman->regs);
- cprman->osc_name = of_clk_get_parent_name(dev->of_node, 0);
- if (!cprman->osc_name)
+ memcpy(cprman->real_parent_names, cprman_parent_names,
+ sizeof(cprman_parent_names));
+ of_clk_parent_fill(dev->of_node, cprman->real_parent_names,
+ ARRAY_SIZE(cprman_parent_names));
+
+ /*
+ * Make sure the external oscillator has been registered.
+ *
+ * The other (DSI) clocks are not present on older device
+ * trees, which we still need to support for backwards
+ * compatibility.
+ */
+ if (!cprman->real_parent_names[0])
return -ENODEV;
platform_set_drvdata(pdev, cprman);
diff --git a/include/dt-bindings/clock/bcm2835.h b/include/dt-bindings/clock/bcm2835.h
index 360e00cefd35..a0c812b0fa39 100644
--- a/include/dt-bindings/clock/bcm2835.h
+++ b/include/dt-bindings/clock/bcm2835.h
@@ -64,3 +64,5 @@
#define BCM2835_CLOCK_CAM1 46
#define BCM2835_CLOCK_DSI0E 47
#define BCM2835_CLOCK_DSI1E 48
+#define BCM2835_CLOCK_DSI0P 49
+#define BCM2835_CLOCK_DSI1P 50
--
2.11.0
^ permalink raw reply related
* [PATCH v2 3/3] clk: bcm2835: Add leaf clock measurement support, disabled by default
From: Eric Anholt @ 2017-01-17 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117203157.23822-1-eric@anholt.net>
This proved incredibly useful during debugging of the DSI driver, to
see if our clocks were running at rate we requested. Let's leave it
here for the next person interacting with clocks on the platform (and
so that hopefully we can just hook it up to debugfs some day).
Signed-off-by: Eric Anholt <eric@anholt.net>
---
drivers/clk/bcm/clk-bcm2835.c | 144 ++++++++++++++++++++++++++++++++++--------
1 file changed, 119 insertions(+), 25 deletions(-)
diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 2e7423d8f5bb..025853870619 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -39,6 +39,7 @@
#include <linux/clk.h>
#include <linux/clk/bcm2835.h>
#include <linux/debugfs.h>
+#include <linux/delay.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/platform_device.h>
@@ -98,7 +99,8 @@
#define CM_SMIDIV 0x0b4
/* no definition for 0x0b8 and 0x0bc */
#define CM_TCNTCTL 0x0c0
-#define CM_TCNTDIV 0x0c4
+# define CM_TCNT_SRC1_SHIFT 12
+#define CM_TCNTCNT 0x0c4
#define CM_TECCTL 0x0c8
#define CM_TECDIV 0x0cc
#define CM_TD0CTL 0x0d0
@@ -338,6 +340,61 @@ static inline u32 cprman_read(struct bcm2835_cprman *cprman, u32 reg)
return readl(cprman->regs + reg);
}
+/* Does a cycle of measuring a clock through the TCNT clock, which may
+ * source from many other clocks in the system.
+ */
+static unsigned long bcm2835_measure_tcnt_mux(struct bcm2835_cprman *cprman,
+ u32 tcnt_mux)
+{
+ u32 osccount = 19200; /* 1ms */
+ u32 count;
+ ktime_t timeout;
+
+ spin_lock(&cprman->regs_lock);
+
+ cprman_write(cprman, CM_TCNTCTL, CM_KILL);
+
+ cprman_write(cprman, CM_TCNTCTL,
+ (tcnt_mux & CM_SRC_MASK) |
+ (tcnt_mux >> CM_SRC_BITS) << CM_TCNT_SRC1_SHIFT);
+
+ cprman_write(cprman, CM_OSCCOUNT, osccount);
+
+ /* do a kind delay@the start */
+ mdelay(1);
+
+ /* Finish off whatever is left of OSCCOUNT */
+ timeout = ktime_add_ns(ktime_get(), LOCK_TIMEOUT_NS);
+ while (cprman_read(cprman, CM_OSCCOUNT)) {
+ if (ktime_after(ktime_get(), timeout)) {
+ dev_err(cprman->dev, "timeout waiting for OSCCOUNT\n");
+ count = 0;
+ goto out;
+ }
+ cpu_relax();
+ }
+
+ /* Wait for BUSY to clear. */
+ timeout = ktime_add_ns(ktime_get(), LOCK_TIMEOUT_NS);
+ while (cprman_read(cprman, CM_TCNTCTL) & CM_BUSY) {
+ if (ktime_after(ktime_get(), timeout)) {
+ dev_err(cprman->dev, "timeout waiting for !BUSY\n");
+ count = 0;
+ goto out;
+ }
+ cpu_relax();
+ }
+
+ count = cprman_read(cprman, CM_TCNTCNT);
+
+ cprman_write(cprman, CM_TCNTCTL, 0);
+
+out:
+ spin_unlock(&cprman->regs_lock);
+
+ return count * 1000;
+}
+
static int bcm2835_debugfs_regset(struct bcm2835_cprman *cprman, u32 base,
struct debugfs_reg32 *regs, size_t nregs,
struct dentry *dentry)
@@ -473,6 +530,8 @@ struct bcm2835_clock_data {
bool is_vpu_clock;
bool is_mash_clock;
+
+ u32 tcnt_mux;
};
struct bcm2835_gate_data {
@@ -1008,6 +1067,17 @@ static int bcm2835_clock_on(struct clk_hw *hw)
CM_GATE);
spin_unlock(&cprman->regs_lock);
+ /* Debug code to measure the clock once it's turned on to see
+ * if it's ticking at the rate we expect.
+ */
+ if (data->tcnt_mux && false) {
+ dev_info(cprman->dev,
+ "clk %s: rate %ld, measure %ld\n",
+ data->name,
+ clk_hw_get_rate(hw),
+ bcm2835_measure_tcnt_mux(cprman, data->tcnt_mux));
+ }
+
return 0;
}
@@ -1765,7 +1835,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.ctl_reg = CM_OTPCTL,
.div_reg = CM_OTPDIV,
.int_bits = 4,
- .frac_bits = 0),
+ .frac_bits = 0,
+ .tcnt_mux = 6),
/*
* Used for a 1Mhz clock for the system clocksource, and also used
* bythe watchdog timer and the camera pulse generator.
@@ -1799,13 +1870,15 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.ctl_reg = CM_H264CTL,
.div_reg = CM_H264DIV,
.int_bits = 4,
- .frac_bits = 8),
+ .frac_bits = 8,
+ .tcnt_mux = 1),
[BCM2835_CLOCK_ISP] = REGISTER_VPU_CLK(
.name = "isp",
.ctl_reg = CM_ISPCTL,
.div_reg = CM_ISPDIV,
.int_bits = 4,
- .frac_bits = 8),
+ .frac_bits = 8,
+ .tcnt_mux = 2),
/*
* Secondary SDRAM clock. Used for low-voltage modes when the PLL
@@ -1816,13 +1889,15 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.ctl_reg = CM_SDCCTL,
.div_reg = CM_SDCDIV,
.int_bits = 6,
- .frac_bits = 0),
+ .frac_bits = 0,
+ .tcnt_mux = 3),
[BCM2835_CLOCK_V3D] = REGISTER_VPU_CLK(
.name = "v3d",
.ctl_reg = CM_V3DCTL,
.div_reg = CM_V3DDIV,
.int_bits = 4,
- .frac_bits = 8),
+ .frac_bits = 8,
+ .tcnt_mux = 4),
/*
* VPU clock. This doesn't have an enable bit, since it drives
* the bus for everything else, and is special so it doesn't need
@@ -1836,7 +1911,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.int_bits = 12,
.frac_bits = 8,
.flags = CLK_IS_CRITICAL,
- .is_vpu_clock = true),
+ .is_vpu_clock = true,
+ .tcnt_mux = 5),
/* clocks with per parent mux */
[BCM2835_CLOCK_AVEO] = REGISTER_PER_CLK(
@@ -1844,19 +1920,22 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.ctl_reg = CM_AVEOCTL,
.div_reg = CM_AVEODIV,
.int_bits = 4,
- .frac_bits = 0),
+ .frac_bits = 0,
+ .tcnt_mux = 38),
[BCM2835_CLOCK_CAM0] = REGISTER_PER_CLK(
.name = "cam0",
.ctl_reg = CM_CAM0CTL,
.div_reg = CM_CAM0DIV,
.int_bits = 4,
- .frac_bits = 8),
+ .frac_bits = 8,
+ .tcnt_mux = 14),
[BCM2835_CLOCK_CAM1] = REGISTER_PER_CLK(
.name = "cam1",
.ctl_reg = CM_CAM1CTL,
.div_reg = CM_CAM1DIV,
.int_bits = 4,
- .frac_bits = 8),
+ .frac_bits = 8,
+ .tcnt_mux = 15),
[BCM2835_CLOCK_DFT] = REGISTER_PER_CLK(
.name = "dft",
.ctl_reg = CM_DFTCTL,
@@ -1868,7 +1947,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.ctl_reg = CM_DPICTL,
.div_reg = CM_DPIDIV,
.int_bits = 4,
- .frac_bits = 8),
+ .frac_bits = 8,
+ .tcnt_mux = 17),
/* Arasan EMMC clock */
[BCM2835_CLOCK_EMMC] = REGISTER_PER_CLK(
@@ -1876,7 +1956,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.ctl_reg = CM_EMMCCTL,
.div_reg = CM_EMMCDIV,
.int_bits = 4,
- .frac_bits = 8),
+ .frac_bits = 8,
+ .tcnt_mux = 39),
/* General purpose (GPIO) clocks */
[BCM2835_CLOCK_GP0] = REGISTER_PER_CLK(
@@ -1885,7 +1966,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.div_reg = CM_GP0DIV,
.int_bits = 12,
.frac_bits = 12,
- .is_mash_clock = true),
+ .is_mash_clock = true,
+ .tcnt_mux = 20),
[BCM2835_CLOCK_GP1] = REGISTER_PER_CLK(
.name = "gp1",
.ctl_reg = CM_GP1CTL,
@@ -1893,7 +1975,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.int_bits = 12,
.frac_bits = 12,
.flags = CLK_IS_CRITICAL,
- .is_mash_clock = true),
+ .is_mash_clock = true,
+ .tcnt_mux = 21),
[BCM2835_CLOCK_GP2] = REGISTER_PER_CLK(
.name = "gp2",
.ctl_reg = CM_GP2CTL,
@@ -1908,40 +1991,46 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.ctl_reg = CM_HSMCTL,
.div_reg = CM_HSMDIV,
.int_bits = 4,
- .frac_bits = 8),
+ .frac_bits = 8,
+ .tcnt_mux = 22),
[BCM2835_CLOCK_PCM] = REGISTER_PER_CLK(
.name = "pcm",
.ctl_reg = CM_PCMCTL,
.div_reg = CM_PCMDIV,
.int_bits = 12,
.frac_bits = 12,
- .is_mash_clock = true),
+ .is_mash_clock = true,
+ .tcnt_mux = 23),
[BCM2835_CLOCK_PWM] = REGISTER_PER_CLK(
.name = "pwm",
.ctl_reg = CM_PWMCTL,
.div_reg = CM_PWMDIV,
.int_bits = 12,
.frac_bits = 12,
- .is_mash_clock = true),
+ .is_mash_clock = true,
+ .tcnt_mux = 24),
[BCM2835_CLOCK_SLIM] = REGISTER_PER_CLK(
.name = "slim",
.ctl_reg = CM_SLIMCTL,
.div_reg = CM_SLIMDIV,
.int_bits = 12,
.frac_bits = 12,
- .is_mash_clock = true),
+ .is_mash_clock = true,
+ .tcnt_mux = 25),
[BCM2835_CLOCK_SMI] = REGISTER_PER_CLK(
.name = "smi",
.ctl_reg = CM_SMICTL,
.div_reg = CM_SMIDIV,
.int_bits = 4,
- .frac_bits = 8),
+ .frac_bits = 8,
+ .tcnt_mux = 27),
[BCM2835_CLOCK_UART] = REGISTER_PER_CLK(
.name = "uart",
.ctl_reg = CM_UARTCTL,
.div_reg = CM_UARTDIV,
.int_bits = 10,
- .frac_bits = 12),
+ .frac_bits = 12,
+ .tcnt_mux = 28),
/* TV encoder clock. Only operating frequency is 108Mhz. */
[BCM2835_CLOCK_VEC] = REGISTER_PER_CLK(
@@ -1954,7 +2043,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
* Allow rate change propagation only on PLLH_AUX which is
* assigned index 7 in the parent array.
*/
- .set_rate_parent = BIT(7)),
+ .set_rate_parent = BIT(7),
+ .tcnt_mux = 29),
/* dsi clocks */
[BCM2835_CLOCK_DSI0E] = REGISTER_PER_CLK(
@@ -1962,25 +2052,29 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.ctl_reg = CM_DSI0ECTL,
.div_reg = CM_DSI0EDIV,
.int_bits = 4,
- .frac_bits = 8),
+ .frac_bits = 8,
+ .tcnt_mux = 18),
[BCM2835_CLOCK_DSI1E] = REGISTER_PER_CLK(
.name = "dsi1e",
.ctl_reg = CM_DSI1ECTL,
.div_reg = CM_DSI1EDIV,
.int_bits = 4,
- .frac_bits = 8),
+ .frac_bits = 8,
+ .tcnt_mux = 19),
[BCM2835_CLOCK_DSI0P] = REGISTER_DSI0_CLK(
.name = "dsi0p",
.ctl_reg = CM_DSI0PCTL,
.div_reg = CM_DSI0PDIV,
.int_bits = 0,
- .frac_bits = 0),
+ .frac_bits = 0,
+ .tcnt_mux = 12),
[BCM2835_CLOCK_DSI1P] = REGISTER_DSI1_CLK(
.name = "dsi1p",
.ctl_reg = CM_DSI1PCTL,
.div_reg = CM_DSI1PDIV,
.int_bits = 0,
- .frac_bits = 0),
+ .frac_bits = 0,
+ .tcnt_mux = 13),
/* the gates */
--
2.11.0
^ permalink raw reply related
* [PATCH v13 0/7] Enable PMUs in ACPI systems
From: Jeremy Linton @ 2017-01-17 20:50 UTC (permalink / raw)
To: linux-arm-kernel
This patch expands and reworks the patches published by Mark Salter
in order to clean up a few of the previous review comments, as well as
add support for newer CPUs and big/little configurations.
v13:
- Correct int/bool conversion bug in pmu_acpi_init()
v12:
- Rebase to 4.10
- Removed lock in the hotplug path.
v11:
- Add is_smp() check to read_specific_cpuid() for arch/arm. Update
c_show() and various routines in arm_pmu_acpi() to use the macro.
- Moved the duplicate "generic" pmu detection code into its own
patch and hoist it into arm_pmu_device_probe() so it works
for DT based systems as well.
v10:
- Rebase to 4.9
- Rework the arm_perf_start_cpu changes to support the 4.9 hotplug
changes.
- Remove the call to acpi_register_gsi() from the cpu online code path.
Instead the GSI's are registered during the initcall. This changes
the error handling a bit because we now try to clean up the
previously registered GSIs in a couple important places. This
was also a result of the rebase.
- Dropped the MIDR partnumber usage, its no longer necessary to
differentiate by only the partnum, so this helps to clarify the code
a bit.
- Shuffle some code around and rename a few variables.
- Added a few comments to hopefully clarify some questions people have
previously had about unused MADT entries, skipping processing cores
with MIDR=0, etc.
v9:
- Add/cleanup an additional hotplug patch I've had sitting around. This
patch brings the ACPI PMU mostly on par with the DT functionality with
respect to having CPUs offline during boot. This should help clarify
some of the code structuring.
- Cleanup the list of PMU types early if we fail to allocate memory for an
additional pmu type.
v8:
- Rebase to 4.8rc4
- Assorted minor comment/hunk placement/etc tweaks per Punit Agrawal
v7:
- Rebase to 4.8rc3
- Remove cpu affinity sysfs entry. While providing a CPU mask for
ARMv8 PMU's is really helpful in big/little environments, reworking
the PMU code to support the cpumask attribute for !arm64 PMUs is out
of the scope of this patch set.
- Fix CPU miscount problem where an alloc failure followed by successfully
allocating the structure can result in under counting the CPUs associated
with the PMU. This bug was created in v6 with the conversion to a linked
list.
- Remove initial platform device creation code by Mark Salter, and re-squash
multiple platform device creation code together with helper routines.
Other minor tweakage.
Jeremy Linton (6):
arm64: Rename the common MADT parse routine
arm: arm64: Add routine to determine cpuid of other cpus
arm: arm64: pmu: Assign platform PMU CPU affinity
arm64: pmu: Detect multiple generic PMUs and append counter
arm64: pmu: Detect and enable multiple PMUs in an ACPI system
arm: pmu: Add PMU definitions for cores not initially online
Mark Salter (1):
arm64: pmu: Cache PMU interrupt numbers from MADT parse
arch/arm/include/asm/cputype.h | 4 +
arch/arm/kernel/setup.c | 2 +-
arch/arm64/include/asm/cputype.h | 3 +
arch/arm64/kernel/perf_event.c | 2 +-
arch/arm64/kernel/smp.c | 18 ++-
drivers/perf/Kconfig | 4 +
drivers/perf/Makefile | 1 +
drivers/perf/arm_pmu.c | 103 +++++++++++++--
drivers/perf/arm_pmu_acpi.c | 271 +++++++++++++++++++++++++++++++++++++++
include/linux/perf/arm_pmu.h | 12 ++
10 files changed, 400 insertions(+), 20 deletions(-)
create mode 100644 drivers/perf/arm_pmu_acpi.c
--
2.5.5
^ permalink raw reply
* [PATCH 1/2] dt-bindings: gpu: Add Mali Utgard bindings
From: Maxime Ripard @ 2017-01-17 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPe5AWTK+NuVpiObzjEG+CFWB5_AeYncNkbkSXRr+4RQUQ@mail.gmail.com>
On Tue, Jan 17, 2017 at 01:33:57PM +0200, Krzysztof Kozlowski wrote:
> On Tue, Jan 17, 2017 at 12:22 PM, Neil Armstrong
> <narmstrong@baylibre.com> wrote:
> > On 01/17/2017 10:38 AM, Maxime Ripard wrote:
> >> Hi,
> >>
> >> On Mon, Jan 16, 2017 at 08:49:06PM +0200, Krzysztof Kozlowski wrote:
> >>> On Mon, Jan 16, 2017 at 02:24:23PM +0100, Maxime Ripard wrote:
> >>>> The ARM Mali Utgard GPU family is embedded into a number of SoCs from
> >>>> Allwinner, Amlogic, Mediatek or Rockchip.
> >>>>
> >>>> Add a binding for the GPU of that family.
> >>>>
> >>>> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >>>> ---
> >>>> .../devicetree/bindings/gpu/arm,mali-utgard.txt | 76 ++++++++++++++++++++++
> >>>> 1 file changed, 76 insertions(+)
> >>>> create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> >>>
> >>> Do you have a driver in kernel which will implement these bindings?
> >>
> >> No, but we have bindings for out-of-tree drivers already.
> >>
> >>> Defining them for out-of-tree driver does not bring any benefits
> >>> (3rd party driver will not respect them anyway).
> >>
> >> You could see it the other way around too. The out-of-tree drivers
> >> don't respect it at the moment because there's no binding to respect.
> >>
> >> And at least for us, we definitely plan on doing that.
> >>
> >> Maxime
> >
> > Hi Maxime, Krzysztof,
> >
> > We hope this will be accepted so it will solve the same issue we have on Amlogic SoCs
> > and all the other mali powered SoCs.
>
> It will be helpful also for other SoCs using Mali 400 (e.g.
> Exynos3250, Exynos4412).
Yep, hence why you were in Cc :)
> > Having mainline bindings will forcre out-of-tree driver to respect those bindings
> > and remove a dts out-of-tree patch aswell.
>
> I would argue here over the word "force". Having bindings defined here
> does not force anyone into anything. The out-of-tree can do whatever
> they want. It is a wish from kernel side - it might be respected but
> it might not.
Well, that statement can be made for each line of the kernel itself,
nothing forces you to use the code as is, or to make any kind of
modifications, including to its ABI. You just have an incentive to
respect the various frameworks and ABI because it's the path of least
resistance and all the tools, libraries and applications already know
how to use those interfaces.
But that's just it, an incentive, that anyone is free or not to comply
to.
> Just to be sure - I am not opposed against. Some time ago I wanted
> Mali400 to be upstreamed but with current policy about user-space side
> it is not possible.
While I would also very much like to see the kernel driver upstreamed,
this is unreasonable at this point. But this patch is here only to add
a binding to it, so that the out-of-tree drivers can comply to it, and
this is something we already have done.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170117/9e0c63ec/attachment-0001.sig>
^ permalink raw reply
* [PATCH v13 1/7] arm64: Rename the common MADT parse routine
From: Jeremy Linton @ 2017-01-17 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484686210-7211-1-git-send-email-jeremy.linton@arm.com>
The MADT parser in smp.c is now being used to parse
out NUMA, PMU and ACPI parking protocol information as
well as the GIC information for which it was originally
created. Rename it to avoid a misleading name.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
arch/arm64/kernel/smp.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index cb87234..8ea244c 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -517,13 +517,14 @@ static unsigned int cpu_count = 1;
#ifdef CONFIG_ACPI
/*
- * acpi_map_gic_cpu_interface - parse processor MADT entry
+ * acpi_verify_and_map_madt - parse processor MADT entry
*
* Carry out sanity checks on MADT processor entry and initialize
- * cpu_logical_map on success
+ * cpu_logical_map, the ACPI parking protocol, NUMA mapping
+ * and the PMU interrupts on success
*/
static void __init
-acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
+acpi_verify_and_map_madt(struct acpi_madt_generic_interrupt *processor)
{
u64 hwid = processor->arm_mpidr;
@@ -577,7 +578,7 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
}
static int __init
-acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
+acpi_parse_madt_common(struct acpi_subtable_header *header,
const unsigned long end)
{
struct acpi_madt_generic_interrupt *processor;
@@ -588,7 +589,7 @@ acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
acpi_table_print_madt_entry(header);
- acpi_map_gic_cpu_interface(processor);
+ acpi_verify_and_map_madt(processor);
return 0;
}
@@ -672,7 +673,7 @@ void __init smp_init_cpus(void)
* we need for SMP init
*/
acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
- acpi_parse_gic_cpu_interface, 0);
+ acpi_parse_madt_common, 0);
if (cpu_count > nr_cpu_ids)
pr_warn("Number of cores (%d) exceeds configured maximum of %d - clipping\n",
--
2.5.5
^ permalink raw reply related
* [PATCH v13 2/7] arm: arm64: Add routine to determine cpuid of other cpus
From: Jeremy Linton @ 2017-01-17 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484686210-7211-1-git-send-email-jeremy.linton@arm.com>
It is helpful if we can read the cpuid/midr of other CPUs
in the system independent of arm/arm64.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
arch/arm/include/asm/cputype.h | 4 ++++
arch/arm/kernel/setup.c | 2 +-
arch/arm64/include/asm/cputype.h | 3 +++
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 522b5fe..1e87d06 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -235,6 +235,10 @@ static inline unsigned int __attribute_const__ read_cpuid_mpidr(void)
#define cpu_is_sa1100() (read_cpuid_part() == ARM_CPU_PART_SA1100)
#define cpu_is_sa1110() (read_cpuid_part() == ARM_CPU_PART_SA1110)
+#define read_specific_cpuid(cpu_num) (is_smp() ? \
+ per_cpu_ptr(&cpu_data, cpu_num)->cpuid \
+ : read_cpuid_id())
+
/*
* Intel's XScale3 core supports some v6 features (supersections, L2)
* but advertises itself as v5 as it does not support the v6 ISA. For
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 34e3f3c..d443c97 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -1217,7 +1217,7 @@ static int c_show(struct seq_file *m, void *v)
* "processor". Give glibc what it expects.
*/
seq_printf(m, "processor\t: %d\n", i);
- cpuid = is_smp() ? per_cpu(cpu_data, i).cpuid : read_cpuid_id();
+ cpuid = read_specific_cpuid(i);
seq_printf(m, "model name\t: %s rev %d (%s)\n",
cpu_name, cpuid & 15, elf_platform);
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 26a68dd..a6d26e1 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -124,6 +124,9 @@ static inline u32 __attribute_const__ read_cpuid_cachetype(void)
{
return read_cpuid(CTR_EL0);
}
+
+#define read_specific_cpuid(cpu_num) per_cpu_ptr(&cpu_data, cpu_num)->reg_midr
+
#endif /* __ASSEMBLY__ */
#endif
--
2.5.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox