* Adding a .platform_init callback to sdhci_arasan_ops
From: Sebastian Frias @ 2016-12-05 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=UhVtQQ1PPtLrvra20ja1k9GKs9hyFcrjBUYmyUmQK45Q@mail.gmail.com>
Hi Doug,
On 28/11/16 19:02, Doug Anderson wrote:
> Hi,
>
> On Mon, Nov 28, 2016 at 5:28 AM, Sebastian Frias <sf84@laposte.net> wrote:
>> +static void sdhci_tango4_platform_init(struct sdhci_host *host)
>> +{
>> + printk("%s\n", __func__);
>> +
>> + /*
>> + pad_mode[2:0]=0 must be 0
>> + sel_sdio[3]=1 must be 1 for SDIO
>> + inv_sdwp_pol[4]=0 if set inverts the SD write protect polarity
>> + inv_sdcd_pol[5]=0 if set inverts the SD card present polarity
>> + */
>> + sdhci_writel(host, 0x00000008, 0x100 + 0x0);
>
> If I were doing this, I'd probably actually add these fields to the
> "sdhci_arasan_soc_ctl_map", then add a 3rd option to
> sdhci_arasan_syscon_write(). Right now it has 2 modes: "hiword
> update" and "non-hiword update". You could add a 3rd indicating that
> you set config registers by just writing at some offset of the main
> SDHCI registers space.
>
> So you'd add 4 fields:
>
> .tango_pad_mode = { .reg = 0x0000, .width = 3, .shift = 0 },
> .sel_sdio = { .reg = 0x0000, .width = 1, .shift = 3},
> .inv_sdwp_pol = { .reg = 0x0000, .width = 1, .shift = 4},
> .inv_sdcd_pol = { .reg = 0x0000, .width = 1, .shift = 5},
Right now I'm using something like:
+ val = 0;
+ val |= PAD_MODE(0); /* must be 0 */
+ val |= SEL_SDIO; /* enable SDIO */
+ sdhci_writel(host, val, 0x100 + 0x0);
+
+ val = 0;
+ val |= TIMEOUT_CLK_UNIT_MHZ; /* unit: MHz */
+ val |= TIMEOUT_CLK_FREQ(52); /* timeout clock: 52MHz */
+ val |= BUS_CLK_FREQ_FOR_SD_CLK(200); /* SDIO clock: 200MHz (TODO: get from DT) */
+ val |= MAX_BLOCK_LENGTH(3); /* max block size: 4096 bytes */
+ val |= EXTENDED_MEDIA_BUS_SUPPORTED; /* DT? */
+ val |= ADMA2_SUPPORTED; /* DT? */
+ val |= HIGH_SPEED_SUPPORTED; /* DT? */
+ val |= SDMA_SUPPORTED; /* DT? */
+ val |= SUSPEND_RESUME_SUPPORTED; /* DT? */
+ val |= VOLTAGE_3_3_V_SUPPORTED; /* DT? */
+#if 0
+ val |= VOLTAGE_1_8_V_SUPPORTED; /* DT? */
+#endif
+ val |= ASYNCHRONOUS_IRQ_SUPPORTED; /* DT? */
+ val |= SLOT_TYPE_REMOVABLE; /* DT? */
+ val |= SDR50_SUPPORTED; /* DT? */
+ sdhci_writel(host, val, 0x100 + 0x40);
+
+ val = 0;
+ val |= TIMER_COUNT_FOR_RETUNING(1); /* DT? */
+ val |= CLOCK_MULTIPLIER(0); /* DT? */
+ val |= SPI_MODE_SUPPORTED; /* DT? */
+ val |= SPI_BLOCK_MODE_SUPPORTED; /* DT? */
+ sdhci_writel(host, val, 0x100 + 0x44);
+
+ sdhci_writel(host, 0x0004022c, 0x100 + 0x28);
+ sdhci_writel(host, 0x00000002, 0x100 + 0x2c);
+
+ sdhci_writel(host, 0x00600000, 0x100 + 0x50);
which seems much easier to handle (and portable).
At any rate, one thing to note from this is that many of these
bits should probably be initialised based on DT, right?
For example, the DT has a "non-removable" property, which I think
should be used to setup SLOT_TYPE_EMBEDDED (if the property is
present) or SLOT_TYPE_REMOVABLE (if the property is not present)
Looking at Documentation/devicetree/bindings/mmc/mmc.txt we can see
more related properties:
Optional properties:
- bus-width: Number of data lines, can be <1>, <4>, or <8>. The default
will be <1> if the property is absent.
- wp-gpios: Specify GPIOs for write protection, see gpio binding
- cd-inverted: when present, polarity on the CD line is inverted. See the note
below for the case, when a GPIO is used for the CD line
- wp-inverted: when present, polarity on the WP line is inverted. See the note
below for the case, when a GPIO is used for the WP line
- disable-wp: When set no physical WP line is present. This property should
only be specified when the controller has a dedicated write-protect
detection logic. If a GPIO is always used for the write-protect detection
logic it is sufficient to not specify wp-gpios property in the absence of a WP
line.
- max-frequency: maximum operating clock frequency
- no-1-8-v: when present, denotes that 1.8v card voltage is not supported on
this system, even if the controller claims it is.
- cap-sd-highspeed: SD high-speed timing is supported
- cap-mmc-highspeed: MMC high-speed timing is supported
- sd-uhs-sdr12: SD UHS SDR12 speed is supported
- sd-uhs-sdr25: SD UHS SDR25 speed is supported
- sd-uhs-sdr50: SD UHS SDR50 speed is supported
- sd-uhs-sdr104: SD UHS SDR104 speed is supported
- sd-uhs-ddr50: SD UHS DDR50 speed is supported
...
which makes me wonder, what is the recommended way of dealing with this?
- Should I use properties on the DT? If so, then I need to add code to set
up the register properly.
- Should I hardcode these values use a minimal DT? If so, then I need an
init function to put all this.
- Should I hardcode stuff at u-Boot level? If so, nothing is required and
should work without any modifications to the Arasan Linux driver.
It appears that the Linux driver is expecting most of these fields to be
hardcoded and "pre-set" before (maybe by the bootloader) it starts, hence
the lack of any "init" function so far.
>
> In your platform-specific init you're proposing you could set
> tango_pad_mode to 0. That seems tango-specific.
>
> You'd want to hook into "set_ios" for setting sel_sdio or not. That's
> important if anyone ever wants to plug in an external SDIO card to
> your slot. This one good argument for putting this in
> sdhci_arasan_soc_ctl_map, since you wouldn't want to do a
> compatibility matching every time set_ios is called.
Thanks for the advice, I will look into that.
>
> I'd have to look more into the whole SD/WP polarity issue. There are
> already so many levels of inversion for these signals in Linux that
> it's confusing. It seems like you might just want to hardcode them to
> "0" and let users use all the existing ways to invert things... You
> could either put that hardcoding into your platform init code or (if
> you're using sdhci_arasan_soc_ctl_map) put it in the main init code so
> that if anyone else needs to init similar signals then they can take
> advantage of it.
Yes, I think I will leave them to 0.
>
> --
>
> One random side note is that as currently documented you need to
> specify a "shift" of -1 for any sdhci_arasan_soc_ctl_map fields you
> aren't using. That seems stupid--not sure why I did that. It seems
> better to clue off "width = 0" so that you could just freely not init
> any fields you don't need.
I see.
So far I'm not really convinced about using "soc_ctl_map" because what I
have so far is more portable, and can easily be put as is somewhere else
(i.e.: in different flavors of bootloaders)
Best regards,
Sebastian
^ permalink raw reply
* [PATCH v2] crypto: sun4i-ss: support the Security System PRNG
From: Herbert Xu @ 2016-12-05 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480934922-20732-1-git-send-email-clabbe.montjoie@gmail.com>
On Mon, Dec 05, 2016 at 11:48:42AM +0100, Corentin Labbe wrote:
> From: LABBE Corentin <clabbe.montjoie@gmail.com>
>
> The Security System have a PRNG.
> This patch add support for it as an hwrng.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Please don't add PRNGs to hwrng. If we have existing PRNGs in
there please let me know so that we can remove them.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v10 12/13] drm/mediatek: update DSI sub driver flow for sending commands to panel
From: YT Shen @ 2016-12-05 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480492728.32217.20.camel@mtksdaap41>
Hi CK,
On Wed, 2016-11-30 at 15:58 +0800, CK Hu wrote:
> Hi, YT:
>
> some comments inline.
>
> On Fri, 2016-11-25 at 18:34 +0800, YT Shen wrote:
> > This patch update enable/disable flow of DSI module.
> > Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> > In this case: DSI -> panel, the DSI sub driver flow should be updated.
> > We need to initialize DSI first so that we can send commands to panel.
> >
> > Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> > Signed-off-by: YT Shen <yt.shen@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 101 +++++++++++++++++++++++++++++--------
> > 1 file changed, 80 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > index ded4202..0569f2e 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > @@ -126,6 +126,10 @@
> > #define CLK_HS_POST (0xff << 8)
> > #define CLK_HS_EXIT (0xff << 16)
> >
> > +#define DSI_VM_CMD_CON 0x130
> > +#define VM_CMD_EN BIT(0)
> > +#define TS_VFP_EN BIT(5)
> > +
> > #define DSI_CMDQ0 0x180
> > #define CONFIG (0xff << 0)
> > #define SHORT_PACKET 0
> > @@ -249,7 +253,9 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> > * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
> > * we set mipi_ratio is 1.05.
> > */
> > - dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
> > + dsi->data_rate = dsi->vm.pixelclock * 12 * 21;
> > + dsi->data_rate /= (dsi->lanes * 1000 * 10);
>
> This looks like a bug fix that use lanes to calculate data rate.
This part add support when dsi->lanes != 4.
>
> > + DRM_DEBUG_DRIVER("set mipitx's data rate: %dMHz\n", dsi->data_rate);
> >
> > ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
> > if (ret < 0) {
> > @@ -333,16 +339,23 @@ static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
> > u32 vid_mode = CMD_MODE;
> >
> > if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
> > - vid_mode = SYNC_PULSE_MODE;
> > -
> > - if ((dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) &&
> > - !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
> > + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
> > vid_mode = BURST_MODE;
> > + else if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> > + vid_mode = SYNC_PULSE_MODE;
> > + else
> > + vid_mode = SYNC_EVENT_MODE;
> > }
> >
> > writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
> > }
> >
> > +static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
> > +{
> > + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, VM_CMD_EN, VM_CMD_EN);
> > + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
> > +}
> > +
> > static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
> > {
> > struct videomode *vm = &dsi->vm;
> > @@ -480,6 +493,16 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
> > writel(1, dsi->regs + DSI_START);
> > }
> >
> > +static void mtk_dsi_stop(struct mtk_dsi *dsi)
> > +{
> > + writel(0, dsi->regs + DSI_START);
> > +}
> > +
> > +static void mtk_dsi_set_cmd_mode(struct mtk_dsi *dsi)
> > +{
> > + writel(CMD_MODE, dsi->regs + DSI_MODE_CTRL);
> > +}
> > +
> > static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
> > {
> > u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> > @@ -538,6 +561,19 @@ static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
> > return IRQ_HANDLED;
> > }
> >
> > +static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 t)
> > +{
> > + mtk_dsi_irq_data_clear(dsi, irq_flag);
> > + mtk_dsi_set_cmd_mode(dsi);
> > +
> > + if (!mtk_dsi_wait_for_irq_done(dsi, irq_flag, t)) {
> > + DRM_ERROR("failed to switch cmd mode\n");
> > + return -ETIME;
> > + } else {
> > + return 0;
> > + }
> > +}
> > +
> > static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> > {
> > if (WARN_ON(dsi->refcount == 0))
> > @@ -546,11 +582,6 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> > if (--dsi->refcount != 0)
> > return;
> >
> > - mtk_dsi_lane0_ulp_mode_enter(dsi);
> > - mtk_dsi_clk_ulp_mode_enter(dsi);
> > -
> > - mtk_dsi_disable(dsi);
> > -
> > clk_disable_unprepare(dsi->engine_clk);
> > clk_disable_unprepare(dsi->digital_clk);
> >
> > @@ -564,13 +595,6 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> > if (dsi->enabled)
> > return;
> >
> > - if (dsi->panel) {
> > - if (drm_panel_prepare(dsi->panel)) {
> > - DRM_ERROR("failed to setup the panel\n");
> > - return;
> > - }
> > - }
> > -
> > ret = mtk_dsi_poweron(dsi);
> > if (ret < 0) {
> > DRM_ERROR("failed to power on dsi\n");
> > @@ -578,21 +602,43 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> > }
> >
> > mtk_dsi_rxtx_control(dsi);
> > + mtk_dsi_ps_control_vact(dsi);
> > + mtk_dsi_set_vm_cmd(dsi);
>
> Even though dsi does not directly connect to panel, you newly set vm cmd
> here. This looks like a bug fix.
We will remove this if it is not necessary.
>
> > + mtk_dsi_config_vdo_timing(dsi);
> > + mtk_dsi_set_interrupt_enable(dsi);
> >
> > mtk_dsi_clk_ulp_mode_leave(dsi);
> > mtk_dsi_lane0_ulp_mode_leave(dsi);
> > mtk_dsi_clk_hs_mode(dsi, 0);
> > - mtk_dsi_set_mode(dsi);
> >
> > - mtk_dsi_ps_control_vact(dsi);
> > - mtk_dsi_config_vdo_timing(dsi);
> > - mtk_dsi_set_interrupt_enable(dsi);
> > + if (dsi->panel) {
> > + if (drm_panel_prepare(dsi->panel)) {
> > + DRM_ERROR("failed to prepare the panel\n");
> > +
> > + mtk_dsi_stop(dsi);
>
> You never start dsi before here, why do you stop dsi here?
>
> > + mtk_dsi_poweroff(dsi);
>
> Refer to next comment, you may goto undo item in bottom of this
> function.
>
> > + return;
> > + }
> > + }
> >
> > mtk_dsi_set_mode(dsi);
> > mtk_dsi_clk_hs_mode(dsi, 1);
> >
> > mtk_dsi_start(dsi);
> >
> > + if (dsi->panel) {
> > + if (drm_panel_enable(dsi->panel)) {
> > + DRM_ERROR("failed to enable the panel\n");
> > +
> > + if (drm_panel_unprepare(dsi->panel))
> > + DRM_ERROR("failed to unprepare the panel\n");
> > +
> > + mtk_dsi_stop(dsi);
>
> I think you should stop dsi before panel unprepare. Otherwise, why not
> move these undo item to the bottom of this function. For example:
>
> if (drm_panel_enable(dsi->panel)) {
> DRM_ERROR("failed to enable the panel\n");
> goto stop_dsi;
>
> ...
>
> dsi->enabled = true;
> return;
>
> stop_dsi:
> mtk_dsi_stop(dsi);
> if (drm_panel_unprepare(dsi->panel))
> DRM_ERROR("failed to unprepare the panel\n");
> poweroff_dsi:
> mtk_dsi_poweroff(dsi);
> return;
>
We will move the error handling to the bottom of this function.
> > + mtk_dsi_poweroff(dsi);
> > + return;
> > + }
> > + }
> > +
> > dsi->enabled = true;
> > }
> >
> > @@ -608,6 +654,19 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> > }
> > }
> >
> > + mtk_dsi_stop(dsi);
>
> Even though dsi does not directly connect to panel, you newly stop dsi
> here. This looks like a bug fix.
>
> > + if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
>
> ditto.
>
> > + if (dsi->panel) {
> > + if (drm_panel_unprepare(dsi->panel))
> > + DRM_ERROR("failed to unprepare the panel\n");
> > + }
> > + }
> > +
> > + mtk_dsi_reset_engine(dsi);
>
> ditto.
>
> > + mtk_dsi_lane0_ulp_mode_enter(dsi);
> > + mtk_dsi_clk_ulp_mode_enter(dsi);
> > + mtk_dsi_disable(dsi);
> > +
> > mtk_dsi_poweroff(dsi);
> >
> > dsi->enabled = false;
>
> Regards,
> CK
>
^ permalink raw reply
* [stable:PATCH 0/3] PAN fixes backport for v4.4.35
From: Greg KH @ 2016-12-05 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <584538CC.50807@arm.com>
On Mon, Dec 05, 2016 at 09:52:12AM +0000, James Morse wrote:
> Hi Greg,
>
> On 02/12/16 17:23, Greg KH wrote:
> > On Fri, Dec 02, 2016 at 04:42:44PM +0000, James Morse wrote:
> >> Hi linux-stable,
> >>
> >> This is the backport of the recent PAN fixes series for v4.4.35.
> >> Original series:
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461806.html
> >
> > Why just 4.4-stable? What about 4.8-stable?
>
> Patch 1 doesn't backport easily. I was going to do v4.8 next, but thought one at
> a time would be the least confusing...
>
> (I don't seem to be very good at predicting what is confusing!)
Adding a patch to an "old" stable kernel would be odd if the latest
stable kernel also doesn't have it, right? I need for it to be in 4.8
before I can take it into 4.4, sorry.
So I'll hold off on applying these until that happens.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v3 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node
From: Tomi Valkeinen @ 2016-12-05 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480420624-23544-2-git-send-email-bgolaszewski@baylibre.com>
On 29/11/16 13:57, Bartosz Golaszewski wrote:
> Add the dumb-vga-dac node to the board DT together with corresponding
> ports and vga connector. This allows to retrieve the edid info from
> the display automatically.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/boot/dts/da850-lcdk.dts | 58 ++++++++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/da850.dtsi | 17 ++++++++++++
> 2 files changed, 75 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
> index 711b9ad..d864f11 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -50,6 +50,53 @@
> system-clock-frequency = <24576000>;
> };
> };
> +
> + vga_bridge {
> + compatible = "dumb-vga-dac";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_pins>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + vga_bridge_in: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&display_out_vga>;
> + };
> + };
> +
> + port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + vga_bridge_out: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&vga_con_in>;
> + };
> + };
> + };
> + };
> +
> + vga {
> + compatible = "vga-connector";
> +
> + ddc-i2c-bus = <&i2c0>;
> +
> + port {
> + vga_con_in: endpoint {
> + remote-endpoint = <&vga_bridge_out>;
> + };
> + };
> + };
> };
>
> &pmx_core {
> @@ -235,3 +282,14 @@
> &memctrl {
> status = "okay";
> };
> +
> +&display {
> + status = "okay";
> +};
> +
> +&display_out {
> + display_out_vga: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&vga_bridge_in>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 4070619..5f4ba2e 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -454,6 +454,23 @@
> reg = <0x213000 0x1000>;
> interrupts = <52>;
> status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + display_in: port at 0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> + };
> +
> + display_out: port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> + };
> + };
> };
It's a bit difficult to follow this as there's been so many patches
going around. But I take the above is the LCDC node in the base da850
dtsi file? In that case, what is the display_in supposed to present?
It's the first node in the "display chain", so it has no input.
Also, don't touch da850.dtsi here, just add the "ports" node in the
da850-lcdk.dts file.
If the da850.dtsi has not been merged yet, I'd change the name of the
lcdc node to something else than "display". It's rather vague. If it's
named "lcdc", reading da850-lcdk.dts becomes much easier, as you'll
refer to "lcdc".
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161205/8a7836a6/attachment.sig>
^ permalink raw reply
* [PATCH v10 02/13] drm/mediatek: add *driver_data for different hardware settings
From: YT Shen @ 2016-12-05 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGS+omDmMq7AEnyDzo4Oih_f+g4DE1Jz6xiV=+_3JGtSAfd+-Q@mail.gmail.com>
Hi Daniel,
On Wed, 2016-11-30 at 14:42 +0800, Daniel Kurtz wrote:
> Hi YT,
>
>
> On Fri, Nov 25, 2016 at 6:34 PM, YT Shen <yt.shen@mediatek.com> wrote:
> >
> > There are some hardware settings changed, between MT8173 & MT2701:
> > DISP_OVL address offset changed, color format definition changed.
> > DISP_RDMA fifo size changed.
> > DISP_COLOR offset changed.
> > MIPI_TX pll setting changed.
> > And add prefix for mtk_ddp_main & mtk_ddp_ext & mutex_mod.
>
> Sorry, I have not had time to thoroughly review the new patch set, but
> one quick comment:
>
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > index 22a33ee..cfaa760 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > @@ -78,6 +78,10 @@ struct mtk_ddp_comp_funcs {
> > struct drm_crtc_state *state);
> > };
> >
> > +struct mtk_ddp_comp_driver_data {
> > + unsigned int color_offset;
> > +};
> > +
> > struct mtk_ddp_comp {
> > struct clk *clk;
> > void __iomem *regs;
> > @@ -85,6 +89,7 @@ struct mtk_ddp_comp {
> > struct device *larb_dev;
> > enum mtk_ddp_comp_id id;
> > const struct mtk_ddp_comp_funcs *funcs;
> > + const struct mtk_ddp_comp_driver_data *data;
>
> I want to avoid adding this generic pointer here to all mtk_ddp_comp,
> since this is only used by the color component.
> Instead, define color specific types:
>
> struct mtk_disp_color_data {
> unsigned int offset;
> };
>
> struct mtk_disp_color {
> struct mtk_ddp_comp ddp_comp;
> const struct mtk_disp_color_data *data;
> };
>
> Then, add another comp_type check and fetch the dev data in
> mtk_drm_probe() or maybe mtk_ddp_comp_init().
>
> -Dan
OK, we will remove the color data pointer from generic mtk_ddp_comp.
Thanks.
Regards,
yt.shen
^ permalink raw reply
* [PATCH v2] crypto: sun4i-ss: support the Security System PRNG
From: Corentin Labbe @ 2016-12-05 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205123705.GA10732@gondor.apana.org.au>
On Mon, Dec 05, 2016 at 08:37:05PM +0800, Herbert Xu wrote:
> On Mon, Dec 05, 2016 at 11:48:42AM +0100, Corentin Labbe wrote:
> > From: LABBE Corentin <clabbe.montjoie@gmail.com>
> >
> > The Security System have a PRNG.
> > This patch add support for it as an hwrng.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
>
> Please don't add PRNGs to hwrng. If we have existing PRNGs in
> there please let me know so that we can remove them.
>
So how to expose PRNG to user space ? or more generally how to "use" a PRNG ?
I found hisi-rng, crypto4xx_ and exynos-rng which seems to be PRNG used as hwrng.
Regards
^ permalink raw reply
* [PATCH v10 13/13] drm/mediatek: add support for Mediatek SoC MT2701
From: YT Shen @ 2016-12-05 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1be9b66b-eff2-4232-fe17-5d1735999d0b@gmail.com>
On Wed, 2016-11-30 at 15:03 +0100, Matthias Brugger wrote:
>
> On 25/11/16 11:34, YT Shen wrote:
>
> > static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
> > + { .compatible = "mediatek,mt2701-disp-rdma",
> > + .data = &mt2701_rdma_driver_data},
> > { .compatible = "mediatek,mt8173-disp-rdma",
> > .data = &mt8173_rdma_driver_data},
> > {},
>
> [...]
>
> > static const struct of_device_id ddp_driver_dt_match[] = {
> > + { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
> > { .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
> > {},
> > };
>
> [...]
>
> >
> > static const struct of_device_id mtk_disp_color_driver_dt_match[] = {
> > + { .compatible = "mediatek,mt2701-disp-color",
> > + .data = &mt2701_color_driver_data},
> > { .compatible = "mediatek,mt8173-disp-color",
> > .data = &mt8173_color_driver_data},
> > {},
>
> [...]
>
> > static const struct of_device_id mtk_drm_of_ids[] = {
> > + { .compatible = "mediatek,mt2701-mmsys",
> > + .data = &mt2701_mmsys_driver_data},
> > { .compatible = "mediatek,mt8173-mmsys",
> > .data = &mt8173_mmsys_driver_data},
> > { }
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > index 0569f2e..f63cc91 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > @@ -1203,6 +1203,7 @@ static int mtk_dsi_remove(struct platform_device *pdev)
> > }
> >
> > static const struct of_device_id mtk_dsi_of_match[] = {
> > + { .compatible = "mediatek,mt2701-dsi" },
> > { .compatible = "mediatek,mt8173-dsi" },
> > { },
> > };
>
> [...]
>
> >
> > static const struct of_device_id mtk_mipi_tx_match[] = {
> > + { .compatible = "mediatek,mt2701-mipi-tx",
> > + .data = &mt2701_mipitx_data },
> > { .compatible = "mediatek,mt8173-mipi-tx",
> > .data = &mt8173_mipitx_data },
> > {},
>
> I'm not sure if I missed some, but you should update the binding
> description for newly added bindings.
>
> Thanks a lot,
> Matthias
Oh, you are right. I thought there is already sent binding description
but actually no. I will update this part for newly added bindings.
Thanks for informing.
yt.shen
^ permalink raw reply
* [LINUX RFC v4 3/4] mtd: spi-nor: add stripe support
From: Cyrille Pitchen @ 2016-12-05 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DA6901612C71B84D91459DE817C418AE26E0C110@XAP-PVEXMBX01.xlnx.xilinx.com>
Hi Naga,
Le 05/12/2016 ? 08:02, Naga Sureshkumar Relli a ?crit :
> Hi Cyrille,
>
>>> Hi Cyrille,
>>>
>>>> I have not finished to review the whole series yet but here some
>>>> first
>>>> comments:
>>>
>>> Thanks for reviewing these patch series.
>>>
>>>>
>>>> Le 27/11/2016 ? 09:33, Naga Sureshkumar Relli a ?crit :
>>>>> This patch adds stripe support and it is needed for GQSPI parallel
>>>>> configuration mode by:
>>>>>
>>>>> - Adding required parameters like stripe and shift to spi_nor
>>>>> structure.
>>>>> - Initializing all added parameters in spi_nor_scan()
>>>>> - Updating read_sr() and read_fsr() for getting status from both
>>>>> flashes
>>>>> - Increasing page_size, sector_size, erase_size and toatal flash
>>>>> size as and when required.
>>>>> - Dividing address by 2
>>>>> - Updating spi->master->flags for qspi driver to change CS
>>>>>
>>>>> Signed-off-by: Naga Sureshkumar Relli <nagasure@xilinx.com>
>>>>> ---
>>>>> Changes for v4:
>>>>> - rename isparallel to stripe
>>>>> Changes for v3:
>>>>> - No change
>>>>> Changes for v2:
>>>>> - Splitted to separate MTD layer changes from SPI core changes
>>>>> ---
>>>>> drivers/mtd/spi-nor/spi-nor.c | 130
>>>> ++++++++++++++++++++++++++++++++----------
>>>>> include/linux/mtd/spi-nor.h | 2 +
>>>>> 2 files changed, 103 insertions(+), 29 deletions(-)
>>>>>
>>>>> diff --git a/drivers/mtd/spi-nor/spi-nor.c
>>>>> b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..4252239 100644
>>>>> --- a/drivers/mtd/spi-nor/spi-nor.c
>>>>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>>>>> @@ -22,6 +22,7 @@
>>>>> #include <linux/of_platform.h>
>>>>> #include <linux/spi/flash.h>
>>>>> #include <linux/mtd/spi-nor.h>
>>>>> +#include <linux/spi/spi.h>
>>>>>
>>>>> /* Define max times to check status register before we give up. */
>>>>>
>>>>> @@ -89,15 +90,24 @@ static const struct flash_info
>>>>> *spi_nor_match_id(const char *name); static int read_sr(struct
>>>>> spi_nor *nor) {
>>>>> int ret;
>>>>> - u8 val;
>>>>> + u8 val[2];
>>>>>
>>>>> - ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val, 1);
>>>>> - if (ret < 0) {
>>>>> - pr_err("error %d reading SR\n", (int) ret);
>>>>> - return ret;
>>>>> + if (nor->stripe) {
>>>>> + ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val[0], 2);
>>>>> + if (ret < 0) {
>>>>> + pr_err("error %d reading SR\n", (int) ret);
>>>>> + return ret;
>>>>> + }
>>>>> + val[0] |= val[1];
>>>> Why '|' rather than '&' ?
>>>> I guess because of the 'Write In Progress/Busy' bit: when called by
>>>> spi_nor_sr_ready(), you want to be sure that this 'BUSY' bit is
>>>> cleared on both memories.
>>>>
>>>> But what about when the Status Register is read for purpose other
>>>> than checking the state of the 'BUSY' bit?
>>>>
>>> Yes you are correct, I will change this.
>>>
>>>> What about SPI controllers supporting more than 2 memories in parallel?
>>>>
>>>> This solution might fit the ZynqMP controller but doesn't look so generic.
>>>>
>>>>> + } else {
>>>>> + ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val[0], 1);
>>>>> + if (ret < 0) {
>>>>> + pr_err("error %d reading SR\n", (int) ret);
>>>>> + return ret;
>>>>> + }
>>>>> }
>>>>>
>>>>> - return val;
>>>>> + return val[0];
>>>>> }
>>>>>
>>>>> /*
>>>>> @@ -108,15 +118,24 @@ static int read_sr(struct spi_nor *nor)
>>>>> static int read_fsr(struct spi_nor *nor) {
>>>>> int ret;
>>>>> - u8 val;
>>>>> + u8 val[2];
>>>>>
>>>>> - ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val, 1);
>>>>> - if (ret < 0) {
>>>>> - pr_err("error %d reading FSR\n", ret);
>>>>> - return ret;
>>>>> + if (nor->stripe) {
>>>>> + ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val[0], 2);
>>>>> + if (ret < 0) {
>>>>> + pr_err("error %d reading FSR\n", ret);
>>>>> + return ret;
>>>>> + }
>>>>> + val[0] &= val[1];
>>>> Same comment here: why '&' rather than '|'?
>>>> Surely because of the the 'READY' bit which should be set for both
>> memories.
>>> I will update this also.
>>>>
>>>>> + } else {
>>>>> + ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val[0], 1);
>>>>> + if (ret < 0) {
>>>>> + pr_err("error %d reading FSR\n", ret);
>>>>> + return ret;
>>>>> + }
>>>>> }
>>>>>
>>>>> - return val;
>>>>> + return val[0];
>>>>> }
>>>>>
>>>>> /*
>>>>> @@ -290,9 +309,16 @@ static int spi_nor_wait_till_ready(struct
>>>>> spi_nor
>>>> *nor)
>>>>> */
>>>>> static int erase_chip(struct spi_nor *nor) {
>>>>> + u32 ret;
>>>>> +
>>>>> dev_dbg(nor->dev, " %lldKiB\n", (long long)(nor->mtd.size >> 10));
>>>>>
>>>>> - return nor->write_reg(nor, SPINOR_OP_CHIP_ERASE, NULL, 0);
>>>>> + ret = nor->write_reg(nor, SPINOR_OP_CHIP_ERASE, NULL, 0);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> +
>>>>> + return ret;
>>>>> +
>>>>
>>>> if (ret)
>>>> return ret;
>>>> else
>>>> return ret;
>>>>
>>>> This chunk should be removed, it doesn't ease the patch review ;)
>>> Ok, I will remove.
>>>>
>>>>> }
>>>>>
>>>>> static int spi_nor_lock_and_prep(struct spi_nor *nor, enum
>>>>> spi_nor_ops ops) @@ -349,7 +375,7 @@ static int
>>>>> spi_nor_erase_sector(struct spi_nor *nor, u32 addr) static int
>>>>> spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr) {
>>>>> struct spi_nor *nor = mtd_to_spi_nor(mtd);
>>>>> - u32 addr, len;
>>>>> + u32 addr, len, offset;
>>>>> uint32_t rem;
>>>>> int ret;
>>>>>
>>>>> @@ -399,9 +425,13 @@ static int spi_nor_erase(struct mtd_info *mtd,
>>>> struct erase_info *instr)
>>>>> /* "sector"-at-a-time erase */
>>>>> } else {
>>>>> while (len) {
>>>>> +
>>>>> write_enable(nor);
>>>>> + offset = addr;
>>>>> + if (nor->stripe)
>>>>> + offset /= 2;
>>>>
>>>> I guess this should be /= 4 for controllers supporting 4 memories in
>> parallel.
>>>> Shouldn't you use nor->shift and define shift as an unsigned int
>>>> instead of a bool?
>>>> offset >>= nor->shift;
>>>>
>>> Yes we can use this shift, I will update
>>>
>>>> Anyway, by tuning the address here in spi-nor.c rather than in the
>>>> SPI controller driver, you impose a model to support parallel
>>>> memories that might not be suited to other controllers.
>>>
>>> For this ZynqMP GQSPI controller parallel configuration, globally
>>> spi-nor should know about this stripe feature And based on that address
>> has to change.
>>> As I mentioned in cover letter, this controller in parallel configuration will
>> work with even addresses only.
>>> i.e. Before creating address format(m25p_addr2cmd) in mtd layer, spi-nor
>> should change that address based on stripe option.
>>>
>>> I am updating this offset based on stripe option, and stripe option will
>> update by reading dt property in nor_scan().
>>> So the controller which doesn't support, then the stripe will be zero.
>>> Or Can you please suggest any other way?
>>>
>>>>
>>>>>
>>>>> - ret = spi_nor_erase_sector(nor, addr);
>>>>> + ret = spi_nor_erase_sector(nor, offset);
>>>>> if (ret)
>>>>> goto erase_err;
>>>>>
>>>>> @@ -525,6 +555,8 @@ static int stm_lock(struct spi_nor *nor, loff_t
>>>>> ofs,
>>>> uint64_t len)
>>>>> bool use_top;
>>>>> int ret;
>>>>>
>>>>> + ofs = ofs >> nor->shift;
>>>>> +
>>>>> status_old = read_sr(nor);
>>>>> if (status_old < 0)
>>>>> return status_old;
>>>>> @@ -610,6 +642,8 @@ static int stm_unlock(struct spi_nor *nor,
>>>>> loff_t ofs,
>>>> uint64_t len)
>>>>> bool use_top;
>>>>> int ret;
>>>>>
>>>>> + ofs = ofs >> nor->shift;
>>>>> +
>>>>> status_old = read_sr(nor);
>>>>> if (status_old < 0)
>>>>> return status_old;
>>>>> @@ -709,6 +743,8 @@ static int spi_nor_lock(struct mtd_info *mtd,
>>>>> loff_t
>>>> ofs, uint64_t len)
>>>>> if (ret)
>>>>> return ret;
>>>>>
>>>>> + ofs = ofs >> nor->shift;
>>>>> +
>>>>> ret = nor->flash_lock(nor, ofs, len);
>>>>>
>>>>> spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_UNLOCK); @@ -
>>>> 724,6 +760,8
>>>>> @@ static int spi_nor_unlock(struct mtd_info *mtd, loff_t ofs,
>>>>> uint64_t
>>>> len)
>>>>> if (ret)
>>>>> return ret;
>>>>>
>>>>> + ofs = ofs >> nor->shift;
>>>>> +
>>>>> ret = nor->flash_unlock(nor, ofs, len);
>>>>>
>>>>> spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_LOCK); @@ -
>>>> 1018,6 +1056,9
>>>>> @@ static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
>>>>> u8 id[SPI_NOR_MAX_ID_LEN];
>>>>> const struct flash_info *info;
>>>>>
>>>>> + nor->spi->master->flags &= ~(SPI_MASTER_BOTH_CS |
>>>>> + SPI_MASTER_DATA_STRIPE);
>>>>> +
>>>>> tmp = nor->read_reg(nor, SPINOR_OP_RDID, id,
>>>> SPI_NOR_MAX_ID_LEN);
>>>>> if (tmp < 0) {
>>>>> dev_dbg(nor->dev, "error %d reading JEDEC ID\n", tmp);
>>>> @@ -1041,6
>>>>> +1082,7 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t
>>>>> +from,
>>>>> size_t len, {
>>>>> struct spi_nor *nor = mtd_to_spi_nor(mtd);
>>>>> int ret;
>>>>> + u32 offset = from;
>>>>>
>>>>> dev_dbg(nor->dev, "from 0x%08x, len %zd\n", (u32)from, len);
>>>>>
>>>>> @@ -1049,7 +1091,13 @@ static int spi_nor_read(struct mtd_info *mtd,
>>>> loff_t from, size_t len,
>>>>> return ret;
>>>>>
>>>>> while (len) {
>>>>> - ret = nor->read(nor, from, len, buf);
>>>>> +
>>>>> + offset = from;
>>>>> +
>>>>> + if (nor->stripe)
>>>>> + offset /= 2;
>>>>> +
>>>>> + ret = nor->read(nor, offset, len, buf);
>>>>> if (ret == 0) {
>>>>> /* We shouldn't see 0-length reads */
>>>>> ret = -EIO;
>>>>> @@ -1161,6 +1209,7 @@ static int spi_nor_write(struct mtd_info *mtd,
>>>> loff_t to, size_t len,
>>>>> struct spi_nor *nor = mtd_to_spi_nor(mtd);
>>>>> size_t page_offset, page_remain, i;
>>>>> ssize_t ret;
>>>>> + u32 offset;
>>>>>
>>>>> dev_dbg(nor->dev, "to 0x%08x, len %zd\n", (u32)to, len);
>>>>>
>>>>> @@ -1178,9 +1227,13 @@ static int spi_nor_write(struct mtd_info
>>>>> *mtd,
>>>> loff_t to, size_t len,
>>>>> /* the size of data remaining on the first page */
>>>>> page_remain = min_t(size_t,
>>>>> nor->page_size - page_offset, len - i);
>>>>> + offset = (to + i);
>>>>> +
>>>>> + if (nor->stripe)
>>>>> + offset /= 2;
>>>>>
>>>>> write_enable(nor);
>>>>> - ret = nor->write(nor, to + i, page_remain, buf + i);
>>>>> + ret = nor->write(nor, (offset), page_remain, buf + i);
>>>>> if (ret < 0)
>>>>> goto write_err;
>>>>> written = ret;
>>>>> @@ -1302,22 +1355,22 @@ static int spi_nor_check(struct spi_nor
>>>>> *nor)
>>>>>
>>>>> int spi_nor_scan(struct spi_nor *nor, const char *name, enum
>>>>> read_mode mode) {
>>>>> - const struct flash_info *info = NULL;
>>>>> + struct flash_info *info = NULL;
>>>>
>>>> You should not remove the const and should not try to modify members
>>>> of *info.
>>>>
>>>>> struct device *dev = nor->dev;
>>>>> struct mtd_info *mtd = &nor->mtd;
>>>>> struct device_node *np = spi_nor_get_flash_node(nor);
>>>>> - int ret;
>>>>> - int i;
>>>>> + struct device_node *np_spi;
>>>>> + int ret, i, xlnx_qspi_mode;
>>>>>
>>>>> ret = spi_nor_check(nor);
>>>>> if (ret)
>>>>> return ret;
>>>>>
>>>>> if (name)
>>>>> - info = spi_nor_match_id(name);
>>>>> + info = (struct flash_info *)spi_nor_match_id(name);
>>>>> /* Try to auto-detect if chip name wasn't specified or not found */
>>>>> if (!info)
>>>>> - info = spi_nor_read_id(nor);
>>>>> + info = (struct flash_info *)spi_nor_read_id(nor);
>>>>> if (IS_ERR_OR_NULL(info))
>>>>> return -ENOENT;
>>>>>
>>>> Both spi_nor_match_id() and spi_nor_read_id(), when they succeed,
>>>> return a pointer to an entry of the spi_nor_ids[] array, which is
>>>> located in a read- only memory area.
>>>>
>>>> Since your patch doesn't remove the const attribute of the
>>>> spi_nor_ids[], I wonder whether it has been tested. I expect it not
>>>> to work on most architecture.
>>>>
>>>> Anyway spi_nor_ids[] should remain const. Let's take the case of
>>>> eXecution In Place (XIP) from an external memory: if spi_nor_ids[] is
>>>> const, it can be read directly from this external (read-only) memory
>>>> and we never need to copy the array in RAM, so we save some KB of
>> RAM.
>>>> This is just an example but I guess we can find other reasons to keep
>>>> this array const.
>>>>
>>>>> @@ -1341,7 +1394,7 @@ int spi_nor_scan(struct spi_nor *nor, const
>>>>> char
>>>> *name, enum read_mode mode)
>>>>> */
>>>>> dev_warn(dev, "found %s, expected %s\n",
>>>>> jinfo->name, info->name);
>>>>> - info = jinfo;
>>>>> + info = (struct flash_info *)jinfo;
>>>>> }
>>>>> }
>>>>>
>>>>> @@ -1370,6 +1423,27 @@ int spi_nor_scan(struct spi_nor *nor, const
>>>>> char
>>>> *name, enum read_mode mode)
>>>>> mtd->size = info->sector_size * info->n_sectors;
>>>>> mtd->_erase = spi_nor_erase;
>>>>> mtd->_read = spi_nor_read;
>>>>> +#ifdef CONFIG_OF
>>>>> + np_spi = of_get_next_parent(np);
>>>>> +
>>>>> + if (of_property_read_u32(np_spi, "xlnx,qspi-mode",
>>>>> + &xlnx_qspi_mode) < 0) {
>>>> This really looks controller specific so should not be placed in the
>>>> generic spi- nor.c file.
>>>
>>> Const is removed in info struct, because to update info members based
>> parallel configuration.
>>> As I mentioned above, for this parallel configuration, mtd and
>>> spi-nor should know the details like
>>> mtd->size, info->sectors, sector_size and page_size.
>>
>> You can tune the values of nor->mtd.size, nor->mtd.erasesize, nor-
>>> page_size or whatever member of nor/nor.mtd as needed without ever
>> modifying members of *info.
>>
>> If you modify *info then spi_nor_scan() is called a 2nd time to probe and
>> configure SPI memories of the same part but connected to another
>> controller, the values of the modified members in this *info would not be
>> those expected.
>> So *info and the spi_nor_ids[] array must remain const.
>>
>> The *info structure is not used outside spi_nor_scan(); none of
>> spi_nor_read(),
>> spi_nor_write() and spi_nor_erase() refers to *info hence every relevant
>> value can be set only nor or nor->mtd members.
>>
>>
>> Anyway, I think OR'ing or AND'ing values of memory registers depending on
>> the relevant bit we want to check is not the right solution.
>> If done in spi-nor.c, there would be a specific case for each memory register
>> we read, each register bit would have to be handled differently.
>>
>> spi-nor.c tries to support as much memory parts as possible, it deals with
>> many registers and bits: Status/Control registers, Quad Enable bits...
>>
>> If we start to OR or AND each of these register values to support the
>> stripping mode, spi-nor will become really hard to maintain.
>>
>> I don't know whether it could be done with the xilinx controller but I thought
>> about first configuring the two memories independently calling
>> spi_nor_scan() twice; one call for each memory.
>>
>> Then the xilinx driver could register only one struct mtd_info, overriding
>> mtd->_read() [and likely mtd->_write() and mtd->_erase() too] set by
>> spi_nor_scan() with a xilinx driver custom implementation so this driver
>> supports its controller stripping mode as it wants.
>>
>> Of course, this solution assumes that the SPI controller has one dedicated
>> chip-select line for each memory and not a single chip-select line shared by
>> both memories. The memories should be configured independently: you
>> can't assume multiple instances of the very same memory part always return
>> the exact same value when reading one of their register. Logical AND/OR is
>> not a generic solution, IMHO.
>>
>> If the xilinx controller has only one shared chip-select line then let's see
>> whether 2 GPIO lines could be used as independent chip-select lines.
>>
>>
> In parallel configuration, Physically we have two flashes but mtd will see as single flash memory (sum of both memories)
> If we call spi_nor_scan(), twice then read/write will override but nor->mtd.size, nor->mtd.erasesize, nor->page_size will remain same, I,e they will also override, they won't append.
> I tried calling spi_nor_scan() twice by some hacks but nor->mtd.size, nor->mtd.erasesize, nor->page_size are not changing
> Also the same issue we are getting for flash address, need to shift the address to work in this configuration.
> Also to tune nor->mtd.size, nor->mtd.erasesize, nor->page_size, we need to touch this spi-nor.c
>
> Please kindly suggest, if I am wrong.
>
What I've been suggesting is:
{
struct spi_nor *nor1, *nor2;
struct mtd_info *mtd;
enum read_mode mode = SPI_NOR_QUAD;
int err;
[...]
err = spi_nor_scan(nor1, NULL, mode);
if (err)
return err; /* or handle error properly. */
err = spi_nor_scan(nor2, NULL, mode);
if (err)
return err;
mtd = &nor1->mtd;
mtd->erasesize <<= 1;
mtd->size <<= 1;
mtd->writebufsize <<= 1;
nor1->page_size <<= 1;
/* tune all other relevant members of nor1/mtd. */
/* override relevant mtd hooks. */
mtd->_read = stripping_read;
mtd->_erase = stripping_erase;
mtd->_write = stripping_write;
mtd->_lock = ...;
mtd->_unlock = ...;
mtd->_is_lock = ...;
/* register a single mtd_info structure. */
err = mtd_device_register(mtd, NULL, 0);
if (err)
return err;
[...]
}
Best regards,
Cyrille
> Thanks,
> Naga Sureshkumar Relli
>
>> Best regards,
>>
>> Cyrille
>
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
>
^ permalink raw reply
* [PATCH v3 2/5] spi: armada-3700: Add support for the FIFO mode
From: Mark Brown @ 2016-12-05 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201102719.4291-3-romain.perier@free-electrons.com>
On Thu, Dec 01, 2016 at 11:27:16AM +0100, Romain Perier wrote:
> Changes in v3:
> - Don't enable the fifo mode based on the compatible string, we introduce
> a module parameter "pio_mode". By default this option is set to zero, so
> the fifo mode is enabled. Pass pio_mode=1 to the driver enables the PIO
> mode.
Why? If the hardware supports a more efficient mode of operation it
doesn't seem sensible not to use it.
> - int i;
> + int i, ret = 0;
Coding style - don't combine initialized and non-initalized variables on
one line.
> static int a3700_spi_transfer_one(struct spi_master *master,
> struct spi_device *spi,
> struct spi_transfer *xfer)
> {
> struct a3700_spi *a3700_spi = spi_master_get_devdata(master);
> - int ret = 0;
> + int ret;
>
> a3700_spi_transfer_setup(spi, xfer);
>
> @@ -505,6 +737,151 @@ static int a3700_spi_transfer_one(struct spi_master *master,
> return ret;
> }
This appears to be a random unrelated change, should probably be part of
the initial driver commit.
> +static int a3700_spi_fifo_transfer_one(struct spi_master *master,
> + struct spi_device *spi,
> + struct spi_transfer *xfer)
> +{
> + struct a3700_spi *a3700_spi = spi_master_get_devdata(master);
> + int ret = 0, timeout = A3700_SPI_TIMEOUT;
> + unsigned int nbits = 0;
> + u32 val;
> +
> + a3700_spi_transfer_setup(spi, xfer);
> +
> + a3700_spi->tx_buf = xfer->tx_buf;
> + a3700_spi->rx_buf = xfer->rx_buf;
> + a3700_spi->buf_len = xfer->len;
> +
> + /* SPI transfer headers */
> + a3700_spi_header_set(a3700_spi);
> +
> + if (xfer->tx_buf)
> + nbits = xfer->tx_nbits;
> + else if (xfer->rx_buf)
> + nbits = xfer->rx_nbits;
> +
> + a3700_spi_pin_mode_set(a3700_spi, nbits);
> +
> + if (xfer->rx_buf) {
> + /* Set read data length */
> + spireg_write(a3700_spi, A3700_SPI_IF_DIN_CNT_REG,
> + a3700_spi->buf_len);
> + /* Start READ transfer */
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + val &= ~A3700_SPI_RW_EN;
> + val |= A3700_SPI_XFER_START;
> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> + } else if (xfer->tx_buf) {
> + /* Start Write transfer */
So this only supports single duplex transfers but there doesn't seem to
be anything that enforces this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161205/39205c21/attachment.sig>
^ permalink raw reply
* [PATCH 3/3] USB: OHCI: nxp: remove useless extern declaration
From: Greg Kroah-Hartman @ 2016-12-05 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480735523-23950-4-git-send-email-csmanjuvijay@gmail.com>
On Sat, Dec 03, 2016 at 03:25:23AM +0000, csmanjuvijay at gmail.com wrote:
> From: Manjunath Goudar <csmanjuvijay@gmail.com>
>
> Remove usb_disabled() extern declaration as it is already declared
> as EXPORT_SYMBOL_GPL declaration.
And same thing again...
^ permalink raw reply
* [PATCH 2/3] serial: st-asc: Provide RTS functionality
From: Patrice Chotard @ 2016-12-05 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202141146.31281-2-lee.jones@linaro.org>
Hi Lee
On 12/02/2016 03:11 PM, Lee Jones wrote:
> Until this point, it has not been possible for serial applications
> to toggle the UART RTS line. This can be useful with certain
> configurations. For example, when using a Mezzanine on a Linaro
> 96board, RTS line is used to take the the on-board microcontroller
typo "the the on"
> in and out of reset.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/tty/serial/st-asc.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
> index 379e5bd..ce46898 100644
> --- a/drivers/tty/serial/st-asc.c
> +++ b/drivers/tty/serial/st-asc.c
> @@ -30,6 +30,7 @@
> #include <linux/of_platform.h>
> #include <linux/serial_core.h>
> #include <linux/clk.h>
> +#include <linux/gpio/consumer.h>
>
> #define DRIVER_NAME "st-asc"
> #define ASC_SERIAL_NAME "ttyAS"
> @@ -38,6 +39,7 @@
>
> struct asc_port {
> struct uart_port port;
> + struct gpio_desc *rts;
> struct clk *clk;
> unsigned int hw_flow_control:1;
> unsigned int force_m1:1;
> @@ -381,12 +383,16 @@ static unsigned int asc_tx_empty(struct uart_port *port)
>
> static void asc_set_mctrl(struct uart_port *port, unsigned int mctrl)
> {
> + struct asc_port *ascport = to_asc_port(port);
> +
> /*
> * This routine is used for seting signals of: DTR, DCD, CTS/RTS
> * We use ASC's hardware for CTS/RTS, so don't need any for that.
> * Some boards have DTR and DCD implemented using PIO pins,
> * code to do this should be hooked in here.
> */
> +
> + gpiod_set_value(ascport->rts, mctrl & TIOCM_RTS);
> }
>
> static unsigned int asc_get_mctrl(struct uart_port *port)
> @@ -731,12 +737,20 @@ MODULE_DEVICE_TABLE(of, asc_match);
> static int asc_serial_probe(struct platform_device *pdev)
> {
> int ret;
> + struct device_node *np = pdev->dev.of_node;
> struct asc_port *ascport;
> + struct gpio_desc *gpiod;
>
> ascport = asc_of_get_asc_port(pdev);
> if (!ascport)
> return -ENODEV;
>
> + gpiod = devm_get_gpiod_from_child(&pdev->dev, "rts", &np->fwnode);
> + if (!IS_ERR(gpiod)) {
> + gpiod_direction_output(gpiod, 0);
> + ascport->rts = gpiod;
> + }
> +
> ret = asc_init_port(ascport, pdev);
> if (ret)
> return ret;
>
^ permalink raw reply
* [PATCH 3/3] USB: OHCI: nxp: remove useless extern declaration
From: Greg Kroah-Hartman @ 2016-12-05 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480735523-23950-4-git-send-email-csmanjuvijay@gmail.com>
On Sat, Dec 03, 2016 at 03:25:23AM +0000, csmanjuvijay at gmail.com wrote:
> From: Manjunath Goudar <csmanjuvijay@gmail.com>
>
> Remove usb_disabled() extern declaration as it is already declared
> as EXPORT_SYMBOL_GPL declaration.
merge this with your first patch please, it belongs with it.
^ permalink raw reply
* ILP32 for ARM64 - testing with lmbench
From: Catalin Marinas @ 2016-12-05 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0adfca97-1624-8eac-8149-da447525ad65@huawei.com>
On Mon, Dec 05, 2016 at 06:16:09PM +0800, Zhangjian (Bamvor) wrote:
> Do you have suggestion of next move of upstreaming ILP32?
I mentioned the steps a few time before. I'm pasting them again here:
1. Complete the review of the Linux patches and ABI (no merge yet)
2. Review the corresponding glibc patches (no merge yet)
3. Ask (Linaro, Cavium) for toolchain + filesystem (pre-built and more
than just busybox) to be able to reproduce the testing in ARM
4. More testing (LTP, trinity, performance regressions etc.)
5. Move the ILP32 PCS out of beta (based on the results from 4)
6. Check the market again to see if anyone still needs ILP32
7. Based on 6, decide whether to merge the kernel and glibc patches
What's not explicitly mentioned in step 4 is glibc testing. Point 5 is
ARM's responsibility (toolchain folk).
> There are already the test results of lmbench and specint. Do you they
> are ok or need more data to prove no regression?
I would need to reproduce the tests myself, see step 3.
> I have also noticed that there are ILP32 failures in glibc testsuite.
> Is it the only blocker for merge ILP32(in technology part)?
It's probably not the only blocker but I have to review the kernel
patches again to make sure. I'd also like to see whether the libc-alpha
community is ok with the glibc counterpart (but don't merge the patches
until the ABI is agreed on both sides).
On performance, I want to make sure there are no regressions on
AArch32/compat and AArch64/LP64.
--
Catalin
^ permalink raw reply
* [PATCH v5] ARM: davinci: da8xx: Fix sleeping function called from invalid context
From: Alexandre Bailon @ 2016-12-05 14:13 UTC (permalink / raw)
To: linux-arm-kernel
Everytime the usb20 phy is enabled, there is a
"sleeping function called from invalid context" BUG.
clk_enable() from arch/arm/mach-davinci/clock.c uses spin_lock_irqsave()
before to invoke the callback usb20_phy_clk_enable().
usb20_phy_clk_enable() uses clk_get() and clk_enable_prepapre()
which may sleep.
Move clk_get() to da8xx_register_usb20_phy_clk() and
replace clk_prepare_enable() by clk_enable().
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
---
arch/arm/mach-davinci/usb-da8xx.c | 29 +++++++++++++++--------------
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-davinci/usb-da8xx.c b/arch/arm/mach-davinci/usb-da8xx.c
index b010e5f..f62f9c2 100644
--- a/arch/arm/mach-davinci/usb-da8xx.c
+++ b/arch/arm/mach-davinci/usb-da8xx.c
@@ -22,6 +22,8 @@
#define DA8XX_USB0_BASE 0x01e00000
#define DA8XX_USB1_BASE 0x01e25000
+static struct clk *usb20_clk;
+
static struct platform_device da8xx_usb_phy = {
.name = "da8xx-usb-phy",
.id = -1,
@@ -158,24 +160,16 @@ int __init da8xx_register_usb_refclkin(int rate)
static void usb20_phy_clk_enable(struct clk *clk)
{
- struct clk *usb20_clk;
int err;
u32 val;
u32 timeout = 500000; /* 500 msec */
val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
- usb20_clk = clk_get(&da8xx_usb20_dev.dev, "usb20");
- if (IS_ERR(usb20_clk)) {
- pr_err("could not get usb20 clk: %ld\n", PTR_ERR(usb20_clk));
- return;
- }
-
/* The USB 2.O PLL requires that the USB 2.O PSC is enabled as well. */
- err = clk_prepare_enable(usb20_clk);
+ err = clk_enable(usb20_clk);
if (err) {
pr_err("failed to enable usb20 clk: %d\n", err);
- clk_put(usb20_clk);
return;
}
@@ -197,8 +191,7 @@ static void usb20_phy_clk_enable(struct clk *clk)
pr_err("Timeout waiting for USB 2.0 PHY clock good\n");
done:
- clk_disable_unprepare(usb20_clk);
- clk_put(usb20_clk);
+ clk_disable(usb20_clk);
}
static void usb20_phy_clk_disable(struct clk *clk)
@@ -285,11 +278,19 @@ static struct clk_lookup usb20_phy_clk_lookup =
int __init da8xx_register_usb20_phy_clk(bool use_usb_refclkin)
{
struct clk *parent;
- int ret = 0;
+ int ret;
+
+ usb20_clk = clk_get(&da8xx_usb20_dev.dev, "usb20");
+ ret = PTR_ERR_OR_ZERO(usb20_clk);
+ if (ret)
+ return ret;
parent = clk_get(NULL, use_usb_refclkin ? "usb_refclkin" : "pll0_aux");
- if (IS_ERR(parent))
- return PTR_ERR(parent);
+ ret = PTR_ERR_OR_ZERO(parent);
+ if (ret) {
+ clk_put(usb20_clk);
+ return ret;
+ }
usb20_phy_clk.parent = parent;
ret = clk_register(&usb20_phy_clk);
--
2.7.3
^ permalink raw reply related
* [PATCH v3 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node
From: Rob Herring @ 2016-12-05 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480420624-23544-2-git-send-email-bgolaszewski@baylibre.com>
On Tue, Nov 29, 2016 at 5:57 AM, Bartosz Golaszewski
<bgolaszewski@baylibre.com> wrote:
> Add the dumb-vga-dac node to the board DT together with corresponding
> ports and vga connector. This allows to retrieve the edid info from
> the display automatically.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/boot/dts/da850-lcdk.dts | 58 ++++++++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/da850.dtsi | 17 ++++++++++++
> 2 files changed, 75 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
> index 711b9ad..d864f11 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -50,6 +50,53 @@
> system-clock-frequency = <24576000>;
> };
> };
> +
> + vga_bridge {
s/_/-/
> + compatible = "dumb-vga-dac";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_pins>;
Are these pins from the LCD controller? They should be part of the LCD
controller node.
Rob
^ permalink raw reply
* [PATCH v3 1/3] ARM: dts: vf610-zii-dev-rev-b: Remove leftover PWM pingroup
From: Andrey Smirnov @ 2016-12-05 14:38 UTC (permalink / raw)
To: linux-arm-kernel
Remove pwm0grp since it is:
a) Not referenced anywhere in the DTS file (unlike Tower board it
is based on, this board does not use/expose FTM0)
b) Configures PTB2 and PTB3 in a way that contradicts
pinctrl-mdio-mux
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
Changes since v2:
- None
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index fa19cfd..2210811 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -677,15 +677,6 @@
>;
};
- pinctrl_pwm0: pwm0grp {
- fsl,pins = <
- VF610_PAD_PTB0__FTM0_CH0 0x1582
- VF610_PAD_PTB1__FTM0_CH1 0x1582
- VF610_PAD_PTB2__FTM0_CH2 0x1582
- VF610_PAD_PTB3__FTM0_CH3 0x1582
- >;
- };
-
pinctrl_qspi0: qspi0grp {
fsl,pins = <
VF610_PAD_PTD7__QSPI0_B_QSCK 0x31c3
--
2.5.5
^ permalink raw reply related
* [PATCH v3 2/3] ARM: dts: vf610-zii-dev: Add .dts file for rev. C
From: Andrey Smirnov @ 2016-12-05 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480948716-17744-1-git-send-email-andrew.smirnov@gmail.com>
Add .dts file for rev. C of the board by factoring out commonalities
into a shared include file (vf610-zii-dev-rev-b-c.dtsi) and deriving
revision specific file from it (vf610-zii-dev-rev-b.dts and
vf610-zii-dev-reb-c.dts).
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
Changes since v2:
- Removed unnecessary "ethernet-phy-id0022.1550" string from
ethernet-phy at 0 node
- Correctecd IRQ_TYPE_EDGE_FALLING to IRQ_TYPE_LEVEL_LOW in
ethernet-phy at 0, since that's what KS8091 corresponding to
that node uses
- Changed PTB28's pinmux configuration to include a 47kOhm
pullup to pull aforementioned PHY IRQ line to unasserted
level by default
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 300 +----------------------
arch/arm/boot/dts/vf610-zii-dev-rev-c.dts | 394 ++++++++++++++++++++++++++++++
arch/arm/boot/dts/vf610-zii-dev.dtsi | 383 +++++++++++++++++++++++++++++
4 files changed, 780 insertions(+), 300 deletions(-)
create mode 100644 arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
create mode 100644 arch/arm/boot/dts/vf610-zii-dev.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..9f0d2a1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -442,7 +442,8 @@ dtb-$(CONFIG_SOC_VF610) += \
vf610-cosmic.dtb \
vf610m4-cosmic.dtb \
vf610-twr.dtb \
- vf610-zii-dev-rev-b.dtb
+ vf610-zii-dev-rev-b.dtb \
+ vf610-zii-dev-rev-c.dtb
dtb-$(CONFIG_ARCH_MXS) += \
imx23-evk.dtb \
imx23-olinuxino.dtb \
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index 2210811..c0fc3f2 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -43,32 +43,12 @@
*/
/dts-v1/;
-#include "vf610.dtsi"
+#include "vf610-zii-dev.dtsi"
/ {
model = "ZII VF610 Development Board, Rev B";
compatible = "zii,vf610dev-b", "zii,vf610dev", "fsl,vf610";
- chosen {
- stdout-path = "serial0:115200n8";
- };
-
- memory {
- reg = <0x80000000 0x20000000>;
- };
-
- gpio-leds {
- compatible = "gpio-leds";
- pinctrl-0 = <&pinctrl_leds_debug>;
- pinctrl-names = "default";
-
- debug {
- label = "zii:green:debug1";
- gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "heartbeat";
- };
- };
-
mdio-mux {
compatible = "mdio-mux-gpio";
pinctrl-0 = <&pinctrl_mdio_mux>;
@@ -281,25 +261,6 @@
};
};
- reg_vcc_3v3_mcu: regulator-vcc-3v3-mcu {
- compatible = "regulator-fixed";
- regulator-name = "vcc_3v3_mcu";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-
- usb0_vbus: regulator-usb0-vbus {
- compatible = "regulator-fixed";
- pinctrl-0 = <&pinctrl_usb_vbus>;
- regulator-name = "usb_vbus";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- enable-active-high;
- regulator-always-on;
- regulator-boot-on;
- gpio = <&gpio0 6 0>;
- };
-
spi0 {
compatible = "spi-gpio";
pinctrl-0 = <&pinctrl_gpio_spi0>;
@@ -336,49 +297,6 @@
};
};
-&adc0 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_adc0_ad5>;
- vref-supply = <®_vcc_3v3_mcu>;
- status = "okay";
-};
-
-&edma0 {
- status = "okay";
-};
-
-&esdhc1 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_esdhc1>;
- bus-width = <4>;
- status = "okay";
-};
-
-&fec0 {
- phy-mode = "rmii";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_fec0>;
- status = "okay";
-};
-
-&fec1 {
- phy-mode = "rmii";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_fec1>;
- status = "okay";
-
- fixed-link {
- speed = <100>;
- full-duplex;
- };
-
- mdio1: mdio {
- #address-cells = <1>;
- #size-cells = <0>;
- status = "okay";
- };
-};
-
&i2c0 {
clock-frequency = <100000>;
pinctrl-names = "default";
@@ -403,33 +321,6 @@
interrupt-parent = <&gpio2>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
};
-
- lm75 at 48 {
- compatible = "national,lm75";
- reg = <0x48>;
- };
-
- at24c04 at 50 {
- compatible = "atmel,24c04";
- reg = <0x50>;
- };
-
- at24c04 at 52 {
- compatible = "atmel,24c04";
- reg = <0x52>;
- };
-
- ds1682 at 6b {
- compatible = "dallas,ds1682";
- reg = <0x6b>;
- };
-};
-
-&i2c1 {
- clock-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c1>;
- status = "okay";
};
&i2c2 {
@@ -499,120 +390,8 @@
};
};
-&uart0 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart0>;
- status = "okay";
-};
-
-&uart1 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart1>;
- status = "okay";
-};
-
-&uart2 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart2>;
- status = "okay";
-};
-
-&usbdev0 {
- disable-over-current;
- vbus-supply = <&usb0_vbus>;
- dr_mode = "host";
- status = "okay";
-};
-
-&usbh1 {
- disable-over-current;
- status = "okay";
-};
-
-&usbmisc0 {
- status = "okay";
-};
-
-&usbmisc1 {
- status = "okay";
-};
-
-&usbphy0 {
- status = "okay";
-};
-
-&usbphy1 {
- status = "okay";
-};
&iomuxc {
- pinctrl_adc0_ad5: adc0ad5grp {
- fsl,pins = <
- VF610_PAD_PTC30__ADC0_SE5 0x00a1
- >;
- };
-
- pinctrl_dspi0: dspi0grp {
- fsl,pins = <
- VF610_PAD_PTB18__DSPI0_CS1 0x1182
- VF610_PAD_PTB19__DSPI0_CS0 0x1182
- VF610_PAD_PTB20__DSPI0_SIN 0x1181
- VF610_PAD_PTB21__DSPI0_SOUT 0x1182
- VF610_PAD_PTB22__DSPI0_SCK 0x1182
- >;
- };
-
- pinctrl_dspi2: dspi2grp {
- fsl,pins = <
- VF610_PAD_PTD31__DSPI2_CS1 0x1182
- VF610_PAD_PTD30__DSPI2_CS0 0x1182
- VF610_PAD_PTD29__DSPI2_SIN 0x1181
- VF610_PAD_PTD28__DSPI2_SOUT 0x1182
- VF610_PAD_PTD27__DSPI2_SCK 0x1182
- >;
- };
-
- pinctrl_esdhc1: esdhc1grp {
- fsl,pins = <
- VF610_PAD_PTA24__ESDHC1_CLK 0x31ef
- VF610_PAD_PTA25__ESDHC1_CMD 0x31ef
- VF610_PAD_PTA26__ESDHC1_DAT0 0x31ef
- VF610_PAD_PTA27__ESDHC1_DAT1 0x31ef
- VF610_PAD_PTA28__ESDHC1_DATA2 0x31ef
- VF610_PAD_PTA29__ESDHC1_DAT3 0x31ef
- VF610_PAD_PTA7__GPIO_134 0x219d
- >;
- };
-
- pinctrl_fec0: fec0grp {
- fsl,pins = <
- VF610_PAD_PTC0__ENET_RMII0_MDC 0x30d2
- VF610_PAD_PTC1__ENET_RMII0_MDIO 0x30d3
- VF610_PAD_PTC2__ENET_RMII0_CRS 0x30d1
- VF610_PAD_PTC3__ENET_RMII0_RXD1 0x30d1
- VF610_PAD_PTC4__ENET_RMII0_RXD0 0x30d1
- VF610_PAD_PTC5__ENET_RMII0_RXER 0x30d1
- VF610_PAD_PTC6__ENET_RMII0_TXD1 0x30d2
- VF610_PAD_PTC7__ENET_RMII0_TXD0 0x30d2
- VF610_PAD_PTC8__ENET_RMII0_TXEN 0x30d2
- >;
- };
-
- pinctrl_fec1: fec1grp {
- fsl,pins = <
- VF610_PAD_PTA6__RMII_CLKIN 0x30d1
- VF610_PAD_PTC9__ENET_RMII1_MDC 0x30d2
- VF610_PAD_PTC10__ENET_RMII1_MDIO 0x30d3
- VF610_PAD_PTC11__ENET_RMII1_CRS 0x30d1
- VF610_PAD_PTC12__ENET_RMII1_RXD1 0x30d1
- VF610_PAD_PTC13__ENET_RMII1_RXD0 0x30d1
- VF610_PAD_PTC14__ENET_RMII1_RXER 0x30d1
- VF610_PAD_PTC15__ENET_RMII1_TXD1 0x30d2
- VF610_PAD_PTC16__ENET_RMII1_TXD0 0x30d2
- VF610_PAD_PTC17__ENET_RMII1_TXEN 0x30d2
- >;
- };
-
pinctrl_gpio_e6185_eeprom_sel: pinctrl-gpio-e6185-eeprom-spi0 {
fsl,pins = <
VF610_PAD_PTE27__GPIO_132 0x33e2
@@ -629,39 +408,6 @@
>;
};
- pinctrl_i2c_mux_reset: pinctrl-i2c-mux-reset {
- fsl,pins = <
- VF610_PAD_PTE14__GPIO_119 0x31c2
- >;
- };
-
- pinctrl_i2c0: i2c0grp {
- fsl,pins = <
- VF610_PAD_PTB14__I2C0_SCL 0x37ff
- VF610_PAD_PTB15__I2C0_SDA 0x37ff
- >;
- };
-
- pinctrl_i2c1: i2c1grp {
- fsl,pins = <
- VF610_PAD_PTB16__I2C1_SCL 0x37ff
- VF610_PAD_PTB17__I2C1_SDA 0x37ff
- >;
- };
-
- pinctrl_i2c2: i2c2grp {
- fsl,pins = <
- VF610_PAD_PTA22__I2C2_SCL 0x37ff
- VF610_PAD_PTA23__I2C2_SDA 0x37ff
- >;
- };
-
- pinctrl_leds_debug: pinctrl-leds-debug {
- fsl,pins = <
- VF610_PAD_PTD20__GPIO_74 0x31c2
- >;
- };
-
pinctrl_mdio_mux: pinctrl-mdio-mux {
fsl,pins = <
VF610_PAD_PTA18__GPIO_8 0x31c2
@@ -676,48 +422,4 @@
VF610_PAD_PTB28__GPIO_98 0x219d
>;
};
-
- pinctrl_qspi0: qspi0grp {
- fsl,pins = <
- VF610_PAD_PTD7__QSPI0_B_QSCK 0x31c3
- VF610_PAD_PTD8__QSPI0_B_CS0 0x31ff
- VF610_PAD_PTD9__QSPI0_B_DATA3 0x31c3
- VF610_PAD_PTD10__QSPI0_B_DATA2 0x31c3
- VF610_PAD_PTD11__QSPI0_B_DATA1 0x31c3
- VF610_PAD_PTD12__QSPI0_B_DATA0 0x31c3
- >;
- };
-
- pinctrl_uart0: uart0grp {
- fsl,pins = <
- VF610_PAD_PTB10__UART0_TX 0x21a2
- VF610_PAD_PTB11__UART0_RX 0x21a1
- >;
- };
-
- pinctrl_uart1: uart1grp {
- fsl,pins = <
- VF610_PAD_PTB23__UART1_TX 0x21a2
- VF610_PAD_PTB24__UART1_RX 0x21a1
- >;
- };
-
- pinctrl_uart2: uart2grp {
- fsl,pins = <
- VF610_PAD_PTD0__UART2_TX 0x21a2
- VF610_PAD_PTD1__UART2_RX 0x21a1
- >;
- };
-
- pinctrl_usb_vbus: pinctrl-usb-vbus {
- fsl,pins = <
- VF610_PAD_PTA16__GPIO_6 0x31c2
- >;
- };
-
- pinctrl_usb0_host: usb0-host-grp {
- fsl,pins = <
- VF610_PAD_PTD6__GPIO_85 0x0062
- >;
- };
};
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
new file mode 100644
index 0000000..4d38f41
--- /dev/null
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
@@ -0,0 +1,394 @@
+/*
+ * Copyright (C) 2015, 2016 Zodiac Inflight Innovations
+ *
+ * Based on an original 'vf610-twr.dts' which is Copyright 2015,
+ * Freescale Semiconductor, Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "vf610-zii-dev.dtsi"
+
+/ {
+ model = "ZII VF610 Development Board, Rev C";
+ compatible = "zii,vf610dev-c", "zii,vf610dev", "fsl,vf610";
+
+ mdio-mux {
+ compatible = "mdio-mux-gpio";
+ pinctrl-0 = <&pinctrl_mdio_mux>;
+ pinctrl-names = "default";
+ gpios = <&gpio0 8 GPIO_ACTIVE_HIGH
+ &gpio0 9 GPIO_ACTIVE_HIGH
+ &gpio0 25 GPIO_ACTIVE_HIGH>;
+ mdio-parent-bus = <&mdio1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio_mux_1: mdio at 1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch0: switch0 at 0 {
+ compatible = "marvell,mv88e6190";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ dsa,member = <0 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&fec1>;
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ label = "lan1";
+ };
+
+ port at 2 {
+ reg = <2>;
+ label = "lan2";
+ };
+
+ port at 3 {
+ reg = <3>;
+ label = "lan3";
+ };
+
+ port at 4 {
+ reg = <4>;
+ label = "lan4";
+ };
+
+ switch0port10: port at 10 {
+ reg = <10>;
+ label = "dsa";
+ phy-mode = "xgmii";
+ link = <&switch1port10>;
+ };
+ };
+ };
+ };
+
+ mdio_mux_2: mdio at 2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch1: switch1 at 0 {
+ compatible = "marvell,mv88e6190";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ dsa,member = <0 1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 1 {
+ reg = <1>;
+ label = "lan5";
+ };
+
+ port at 2 {
+ reg = <2>;
+ label = "lan6";
+ };
+
+ port at 3 {
+ reg = <3>;
+ label = "lan7";
+ };
+
+ port at 4 {
+ reg = <4>;
+ label = "lan8";
+ };
+
+
+ switch1port10: port at 10 {
+ reg = <10>;
+ label = "dsa";
+ phy-mode = "xgmii";
+ link = <&switch0port10>;
+ };
+ };
+ };
+ };
+
+ mdio_mux_4: mdio at 4 {
+ reg = <4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
+
+&dspi0 {
+ bus-num = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_dspi0>;
+ status = "okay";
+ spi-num-chipselects = <2>;
+
+ m25p128 at 0 {
+ compatible = "m25p128", "jedec,spi-nor";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+};
+
+&i2c0 {
+ /*
+ * U712
+ *
+ * Exposed signals:
+ * P1 - WE2_CMD
+ * P2 - WE2_CLK
+ */
+ gpio5: pca9557 at 18 {
+ compatible = "nxp,pca9557";
+ reg = <0x18>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ /*
+ * U121
+ *
+ * Exposed signals:
+ * I/O0 - ENET_SWR_EN
+ * I/O1 - ESW1_RESETn
+ * I/O2 - ARINC_RESET
+ * I/O3 - DD1_IO_RESET
+ * I/O4 - ESW2_RESETn
+ * I/O5 - ESW3_RESETn
+ * I/O6 - ESW4_RESETn
+ * I/O8 - TP909
+ * I/O9 - FEM_SEL
+ * I/O10 - WIFI_RESETn
+ * I/O11 - PHY_RSTn
+ * I/O12 - OPT1_SD
+ * I/O13 - OPT2_SD
+ * I/O14 - OPT1_TX_DIS
+ * I/O15 - OPT2_TX_DIS
+ */
+ gpio6: sx1503 at 20 {
+ compatible = "semtech,sx1503q";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sx1503_20>;
+ #gpio-cells = <2>;
+ #interrupt-cells = <2>;
+ reg = <0x20>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <23 IRQ_TYPE_EDGE_FALLING>;
+ gpio-controller;
+ interrupt-controller;
+
+ enet_swr_en {
+ gpio-hog;
+ gpios = <0 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "enet-swr-en";
+ };
+ };
+
+ /*
+ * U715
+ *
+ * Exposed signals:
+ * IO0 - WE1_CLK
+ * IO1 - WE1_CMD
+ */
+ gpio7: pca9554 at 22 {
+ compatible = "nxp,pca9554";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ };
+};
+
+&i2c1 {
+ at24mac602 at 00 {
+ compatible = "atmel,24c02";
+ reg = <0x50>;
+ read-only;
+ };
+};
+
+&i2c2 {
+ tca9548 at 70 {
+ compatible = "nxp,pca9548";
+ pinctrl-0 = <&pinctrl_i2c_mux_reset>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x70>;
+ reset-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>;
+
+ i2c at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ i2c at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ sfp2: at24c04 at 50 {
+ compatible = "atmel,24c02";
+ reg = <0x50>;
+ };
+ };
+
+ i2c at 2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+
+ sfp3: at24c04 at 50 {
+ compatible = "atmel,24c02";
+ reg = <0x50>;
+ };
+ };
+
+ i2c at 3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+ };
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ status = "okay";
+};
+
+&gpio0 {
+ eth0_intrp {
+ gpio-hog;
+ gpios = <23 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "sx1503-irq";
+ };
+};
+
+&gpio3 {
+ eth0_intrp {
+ gpio-hog;
+ gpios = <2 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "eth0-intrp";
+ };
+};
+
+&fec0 {
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ ethernet-phy at 0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec0_phy_int>;
+
+ interrupt-parent = <&gpio3>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+ reg = <0>;
+ };
+ };
+};
+
+&iomuxc {
+ pinctr_atzb_rf_233: pinctrl-atzb-rf-233 {
+ fsl,pins = <
+ VF610_PAD_PTB2__GPIO_24 0x31c2
+ VF610_PAD_PTE27__GPIO_132 0x33e2
+ >;
+ };
+
+
+ pinctrl_sx1503_20: pinctrl-sx1503-20 {
+ fsl,pins = <
+ VF610_PAD_PTB1__GPIO_23 0x219d
+ >;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ VF610_PAD_PTA20__UART3_TX 0x21a2
+ VF610_PAD_PTA21__UART3_RX 0x21a1
+ >;
+ };
+
+ pinctrl_mdio_mux: pinctrl-mdio-mux {
+ fsl,pins = <
+ VF610_PAD_PTA18__GPIO_8 0x31c2
+ VF610_PAD_PTA19__GPIO_9 0x31c2
+ VF610_PAD_PTB3__GPIO_25 0x31c2
+ >;
+ };
+
+ pinctrl_fec0_phy_int: pinctrl-fec0-phy-int {
+ fsl,pins = <
+ VF610_PAD_PTB28__GPIO_98 0x219d
+ >;
+ };
+};
diff --git a/arch/arm/boot/dts/vf610-zii-dev.dtsi b/arch/arm/boot/dts/vf610-zii-dev.dtsi
new file mode 100644
index 0000000..9f5e2e7
--- /dev/null
+++ b/arch/arm/boot/dts/vf610-zii-dev.dtsi
@@ -0,0 +1,383 @@
+/*
+ * Copyright (C) 2015, 2016 Zodiac Inflight Innovations
+ *
+ * Based on an original 'vf610-twr.dts' which is Copyright 2015,
+ * Freescale Semiconductor, Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+n * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "vf610.dtsi"
+
+/ {
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0x80000000 0x20000000>;
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <&pinctrl_leds_debug>;
+ pinctrl-names = "default";
+
+ debug {
+ label = "zii:green:debug1";
+ gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ reg_vcc_3v3_mcu: regulator-vcc-3v3-mcu {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_3v3_mcu";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ usb0_vbus: regulator-usb0-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-0 = <&pinctrl_usb_vbus>;
+ regulator-name = "usb_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ enable-active-high;
+ regulator-always-on;
+ regulator-boot-on;
+ gpio = <&gpio0 6 0>;
+ };
+};
+
+&adc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_adc0_ad5>;
+ vref-supply = <®_vcc_3v3_mcu>;
+ status = "okay";
+};
+
+&edma0 {
+ status = "okay";
+};
+
+&esdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_esdhc1>;
+ bus-width = <4>;
+ status = "okay";
+};
+
+&fec0 {
+ phy-mode = "rmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec0>;
+ status = "okay";
+};
+
+&fec1 {
+ phy-mode = "rmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec1>;
+ status = "okay";
+
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+
+ mdio1: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+ };
+};
+
+&i2c0 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c0>;
+ pinctrl-1 = <&pinctrl_i2c0_gpio>;
+ scl-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ sda-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+
+ lm75 at 48 {
+ compatible = "national,lm75";
+ reg = <0x48>;
+ };
+
+ at24c04 at 50 {
+ compatible = "atmel,24c04";
+ reg = <0x50>;
+ };
+
+ at24c04 at 52 {
+ compatible = "atmel,24c04";
+ reg = <0x52>;
+ };
+
+ ds1682 at 6b {
+ compatible = "dallas,ds1682";
+ reg = <0x6b>;
+ };
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart0>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+&usbdev0 {
+ disable-over-current;
+ vbus-supply = <&usb0_vbus>;
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usbh1 {
+ disable-over-current;
+ status = "okay";
+};
+
+&usbmisc0 {
+ status = "okay";
+};
+
+&usbmisc1 {
+ status = "okay";
+};
+
+&usbphy0 {
+ status = "okay";
+};
+
+&usbphy1 {
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_adc0_ad5: adc0ad5grp {
+ fsl,pins = <
+ VF610_PAD_PTC30__ADC0_SE5 0x00a1
+ >;
+ };
+
+ pinctrl_dspi0: dspi0grp {
+ fsl,pins = <
+ VF610_PAD_PTB18__DSPI0_CS1 0x1182
+ VF610_PAD_PTB19__DSPI0_CS0 0x1182
+ VF610_PAD_PTB20__DSPI0_SIN 0x1181
+ VF610_PAD_PTB21__DSPI0_SOUT 0x1182
+ VF610_PAD_PTB22__DSPI0_SCK 0x1182
+ >;
+ };
+
+ pinctrl_dspi2: dspi2grp {
+ fsl,pins = <
+ VF610_PAD_PTD31__DSPI2_CS1 0x1182
+ VF610_PAD_PTD30__DSPI2_CS0 0x1182
+ VF610_PAD_PTD29__DSPI2_SIN 0x1181
+ VF610_PAD_PTD28__DSPI2_SOUT 0x1182
+ VF610_PAD_PTD27__DSPI2_SCK 0x1182
+ >;
+ };
+
+ pinctrl_esdhc1: esdhc1grp {
+ fsl,pins = <
+ VF610_PAD_PTA24__ESDHC1_CLK 0x31ef
+ VF610_PAD_PTA25__ESDHC1_CMD 0x31ef
+ VF610_PAD_PTA26__ESDHC1_DAT0 0x31ef
+ VF610_PAD_PTA27__ESDHC1_DAT1 0x31ef
+ VF610_PAD_PTA28__ESDHC1_DATA2 0x31ef
+ VF610_PAD_PTA29__ESDHC1_DAT3 0x31ef
+ VF610_PAD_PTA7__GPIO_134 0x219d
+ >;
+ };
+
+ pinctrl_fec0: fec0grp {
+ fsl,pins = <
+ VF610_PAD_PTC0__ENET_RMII0_MDC 0x30d2
+ VF610_PAD_PTC1__ENET_RMII0_MDIO 0x30d3
+ VF610_PAD_PTC2__ENET_RMII0_CRS 0x30d1
+ VF610_PAD_PTC3__ENET_RMII0_RXD1 0x30d1
+ VF610_PAD_PTC4__ENET_RMII0_RXD0 0x30d1
+ VF610_PAD_PTC5__ENET_RMII0_RXER 0x30d1
+ VF610_PAD_PTC6__ENET_RMII0_TXD1 0x30d2
+ VF610_PAD_PTC7__ENET_RMII0_TXD0 0x30d2
+ VF610_PAD_PTC8__ENET_RMII0_TXEN 0x30d2
+ >;
+ };
+
+ pinctrl_fec1: fec1grp {
+ fsl,pins = <
+ VF610_PAD_PTA6__RMII_CLKIN 0x30d1
+ VF610_PAD_PTC9__ENET_RMII1_MDC 0x30d2
+ VF610_PAD_PTC10__ENET_RMII1_MDIO 0x30d3
+ VF610_PAD_PTC11__ENET_RMII1_CRS 0x30d1
+ VF610_PAD_PTC12__ENET_RMII1_RXD1 0x30d1
+ VF610_PAD_PTC13__ENET_RMII1_RXD0 0x30d1
+ VF610_PAD_PTC14__ENET_RMII1_RXER 0x30d1
+ VF610_PAD_PTC15__ENET_RMII1_TXD1 0x30d2
+ VF610_PAD_PTC16__ENET_RMII1_TXD0 0x30d2
+ VF610_PAD_PTC17__ENET_RMII1_TXEN 0x30d2
+ >;
+ };
+
+ pinctrl_gpio_spi0: pinctrl-gpio-spi0 {
+ fsl,pins = <
+ VF610_PAD_PTB22__GPIO_44 0x33e2
+ VF610_PAD_PTB21__GPIO_43 0x33e2
+ VF610_PAD_PTB20__GPIO_42 0x33e1
+ VF610_PAD_PTB19__GPIO_41 0x33e2
+ VF610_PAD_PTB18__GPIO_40 0x33e2
+ >;
+ };
+
+ pinctrl_i2c_mux_reset: pinctrl-i2c-mux-reset {
+ fsl,pins = <
+ VF610_PAD_PTE14__GPIO_119 0x31c2
+ >;
+ };
+
+ pinctrl_i2c0: i2c0grp {
+ fsl,pins = <
+ VF610_PAD_PTB14__I2C0_SCL 0x37ff
+ VF610_PAD_PTB15__I2C0_SDA 0x37ff
+ >;
+ };
+
+ pinctrl_i2c0_gpio: i2c0grp-gpio {
+ fsl,pins = <
+ VF610_PAD_PTB14__GPIO_36 0x31c2
+ VF610_PAD_PTB15__GPIO_37 0x31c2
+ >;
+ };
+
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ VF610_PAD_PTB16__I2C1_SCL 0x37ff
+ VF610_PAD_PTB17__I2C1_SDA 0x37ff
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ VF610_PAD_PTA22__I2C2_SCL 0x37ff
+ VF610_PAD_PTA23__I2C2_SDA 0x37ff
+ >;
+ };
+
+ pinctrl_leds_debug: pinctrl-leds-debug {
+ fsl,pins = <
+ VF610_PAD_PTD20__GPIO_74 0x31c2
+ >;
+ };
+
+ pinctrl_qspi0: qspi0grp {
+ fsl,pins = <
+ VF610_PAD_PTD7__QSPI0_B_QSCK 0x31c3
+ VF610_PAD_PTD8__QSPI0_B_CS0 0x31ff
+ VF610_PAD_PTD9__QSPI0_B_DATA3 0x31c3
+ VF610_PAD_PTD10__QSPI0_B_DATA2 0x31c3
+ VF610_PAD_PTD11__QSPI0_B_DATA1 0x31c3
+ VF610_PAD_PTD12__QSPI0_B_DATA0 0x31c3
+ >;
+ };
+
+ pinctrl_uart0: uart0grp {
+ fsl,pins = <
+ VF610_PAD_PTB10__UART0_TX 0x21a2
+ VF610_PAD_PTB11__UART0_RX 0x21a1
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ VF610_PAD_PTB23__UART1_TX 0x21a2
+ VF610_PAD_PTB24__UART1_RX 0x21a1
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ VF610_PAD_PTD0__UART2_TX 0x21a2
+ VF610_PAD_PTD1__UART2_RX 0x21a1
+ >;
+ };
+
+ pinctrl_usb_vbus: pinctrl-usb-vbus {
+ fsl,pins = <
+ VF610_PAD_PTA16__GPIO_6 0x31c2
+ >;
+ };
+
+ pinctrl_usb0_host: usb0-host-grp {
+ fsl,pins = <
+ VF610_PAD_PTD6__GPIO_85 0x0062
+ >;
+ };
+};
--
2.5.5
^ permalink raw reply related
* [PATCH v3 3/3] ARM: dts: vf610-zii-dev-rev-b: Remove 'fixed-link' from DSA ports
From: Andrey Smirnov @ 2016-12-05 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480948716-17744-1-git-send-email-andrew.smirnov@gmail.com>
Remove 'fixed-link' nodes from DSA ports since they are not needed (they
are not limiting link's speed and the ports will be configured to their
maximux speed as a default)
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
Changes since v2:
- None
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index c0fc3f2..646c90c 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -97,10 +97,6 @@
phy-mode = "rgmii-txid";
link = <&switch1port6
&switch2port9>;
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
};
port at 6 {
@@ -165,10 +161,6 @@
label = "dsa";
phy-mode = "rgmii-txid";
link = <&switch0port5>;
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
};
};
mdio {
--
2.5.5
^ permalink raw reply related
* [PATCH net-next v4 2/4] dt-bindings: net: add EEE capability constants
From: Rob Herring @ 2016-12-05 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480348229-25672-3-git-send-email-jbrunet@baylibre.com>
On Mon, Nov 28, 2016 at 04:50:26PM +0100, Jerome Brunet wrote:
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
> Tested-by: Andreas F?rber <afaerber@suse.de>
> Tested-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> include/dt-bindings/net/mdio.h | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
> create mode 100644 include/dt-bindings/net/mdio.h
Seems changes are wanted on this, but patches 2 and 3 should be
combined. The header is part of the binding doc.
Rob
^ permalink raw reply
* [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
From: Dave Martin @ 2016-12-05 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0293f7d3-b3d3-1a68-5b99-75db195eb796@redhat.com>
On Mon, Dec 05, 2016 at 11:44:38AM +0100, Florian Weimer wrote:
> On 12/01/2016 11:30 AM, Dave Martin wrote:
>
> >>The VL value is implicitly thread-local data, and the encoded state may have
> >>an implicit dependency on it, although it does not contain vector registers
> >>as such.
> >
> >This doesn't sound like an absolute requirement to me.
> >
> >If we presume that the SVE registers never need to get saved or
> >restored, what stops the context data format being VL-independent?
>
> I'm concerned the suspended computation has code which has been selected to
> fit a particular VL value.
>
> > If the save/restore logic doesn't touch SVE, which would its
> > implementation be VL-dependent?
>
> Because it has been optimized for a certain vector length?
I'll respond to these via Szabolcs' reply.
> >>>Because the SVE procedure call standard determines that the SVE
> >>>registers are caller-save,
> >>
> >>By the way, how is this implemented? Some of them overlap existing
> >>callee-saved registers.
> >
> >Basically, all the *new* state is caller-save.
> >
> >The Neon/FPSIMD regs V8-V15 are callee-save, so in the SVE view
> >Zn[bits 127:0] is callee-save for all n = 8..15.
>
> Are the extension parts of registers v8 to v15 used for argument passing?
No -- the idea is to be directly compatible with the existing PCS.
> If not, we should be able to use the existing dynamic linker trampoline.
Yes, I believe so.
Cheers
---Dave
^ permalink raw reply
* [PATCH 09/18] arm64: introduce binfmt_elf32.c
From: Catalin Marinas @ 2016-12-05 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477081997-4770-10-git-send-email-ynorov@caviumnetworks.com>
On Fri, Oct 21, 2016 at 11:33:08PM +0300, Yury Norov wrote:
> As we support more than one compat formats, it looks more reasonable
> to not use fs/compat_binfmt.c. Custom binfmt_elf32.c allows to move aarch32
> specific definitions there and make code more maintainable and readable.
Can you remind me why we need this patch (rather than using the default
fs/compat_binfmt_elf.c which you include here anyway)?
> --- /dev/null
> +++ b/arch/arm64/kernel/binfmt_elf32.c
> @@ -0,0 +1,31 @@
> +/*
> + * Support for AArch32 Linux ELF binaries.
> + */
> +
> +/* AArch32 EABI. */
> +#define EF_ARM_EABI_MASK 0xff000000
> +
> +#define compat_start_thread compat_start_thread
> +#define COMPAT_SET_PERSONALITY(ex) \
> +do { \
> + clear_thread_flag(TIF_32BIT_AARCH64); \
> + set_thread_flag(TIF_32BIT); \
> +} while (0)
You introduce this here but it seems to still be present in asm/elf.h.
--
Catalin
^ permalink raw reply
* [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
From: Dave Martin @ 2016-12-05 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202215646.s2xymph6d6jlyrv3@localhost>
On Fri, Dec 02, 2016 at 09:56:46PM +0000, Yao Qi wrote:
> On 16-11-30 12:06:54, Dave Martin wrote:
> > So, my key goal is to support _per-process_ vector length control.
> >
> > From the kernel perspective, it is easiest to achieve this by providing
> > per-thread control since that is the unit that context switching acts
> > on.
> >
>
> Hi, Dave,
> Thanks for the explanation.
>
> > How useful it really is to have threads with different VLs in the same
> > process is an open question. It's theoretically useful for runtime
> > environments, which may want to dispatch code optimised for different
> > VLs -- changing the VL on-the-fly within a single thread is not
> > something I want to encourage, due to overhead and ABI issues, but
> > switching between threads of different VLs would be more manageable.
>
> This is a weird programming model.
I may not have explained that very well.
What I meant is, you have two threads communicating with one another,
say. Providing that they don't exchange data using a VL-dependent
representation, it should not matter that the two threads are running
with different VLs.
This may make sense if a particular piece of work was optimised for a
particular VL: you can pick a worker thread with the correct VL and
dispatch the job there for best performance.
I wouldn't expect this ability to be exploited except by specialised
frameworks.
> > However, I expect mixing different VLs within a single process to be
> > very much a special case -- it's not something I'd expect to work with
> > general-purpose code.
> >
> > Since the need for indepent VLs per thread is not proven, we could
> >
> > * forbid it -- i.e., only a thread-group leader with no children is
> > permitted to change the VL, which is then inherited by any child threads
> > that are subsequently created
> >
> > * permit it only if a special flag is specified when requesting the VL
> > change
> >
> > * permit it and rely on userspace to be sensible -- easiest option for
> > the kernel.
>
> Both the first and the third one is reasonable to me, but the first one
> fit well in existing GDB design. I don't know how useful it is to have
> per-thread VL, there may be some workloads can be implemented that way.
> GDB needs some changes to support "per-thread" target description.
OK -- I'll implement for per-thread for now, but this can be clarified
later.
Cheers
---Dave
^ permalink raw reply
* [PATCHv4 11/15] clk: ti: clockdomain: add clock provider support to clockdomains
From: Tony Lindgren @ 2016-12-05 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ed253013-1f12-9fd8-d007-400a6c6fd427@ti.com>
* Tero Kristo <t-kristo@ti.com> [161205 02:09]:
> On 03/12/16 02:18, Tony Lindgren wrote:
> > * Michael Turquette <mturquette@baylibre.com> [161202 15:52]:
> > > Quoting Tony Lindgren (2016-12-02 15:12:40)
> > > > * Michael Turquette <mturquette@baylibre.com> [161202 14:34]:
> > > > > Quoting Tony Lindgren (2016-10-28 16:54:48)
> > > > > > * Stephen Boyd <sboyd@codeaurora.org> [161028 16:37]:
> > > > > > > On 10/28, Tony Lindgren wrote:
> > > > > > > > * Tero Kristo <t-kristo@ti.com> [161028 00:43]:
> > > > > > > > > On 28/10/16 03:50, Stephen Boyd wrote:
> > > > > > > > > > I suppose a PRCM is
> > > > > > > > > > like an MFD that has clocks and resets under it? On other
> > > > > > > > > > platforms we've combined that all into one node and just had
> > > > > > > > > > #clock-cells and #reset-cells in that node. Is there any reason
> > > > > > > > > > we can't do that here?
> > > > > > > > >
> > > > > > > > > For OMAPs, there are typically multiple instances of the PRCM around; OMAP4
> > > > > > > > > for example has:
> > > > > > > > >
> > > > > > > > > cm1 @ 0x4a004000 (clocks + clockdomains)
> > > > > > > > > cm2 @ 0x4a008000 (clocks + clockdomains)
> > > > > > > > > prm @ 0x4a306000 (few clocks + resets + power state handling)
> > > > > > > > > scrm @ 0x4a30a000 (few external clocks + plenty of misc stuff)
> > > > > > > > >
> > > > > > > > > These instances are also under different power/voltage domains which means
> > > > > > > > > their PM behavior is different.
> > > > > > > > >
> > > > > > > > > The idea behind having a clockdomain as a provider was mostly to have the
> > > > > > > > > topology visible : prcm-instance -> clockdomain -> clocks
> > > > > > > >
> > > > > > > > Yeah that's needed to get the interconnect hierarchy right for
> > > > > > > > genpd :)
> > > > > > > >
> > > > > > > > > ... but basically I think it would be possible to drop the clockdomain
> > > > > > > > > representation and just mark the prcm-instance as a clock provider. Tony,
> > > > > > > > > any thoughts on that?
> > > > > > > >
> > > > > > > > No let's not drop the clockdomains as those will be needed when we
> > > > > > > > move things into proper hierarchy within the interconnect instances.
> > > > > > > > This will then help with getting things right with genpd.
> > > > > > > >
> > > > > > > > In the long run we just want to specify clockdomain and the offset of
> > > > > > > > the clock instance within the clockdomain in the dts files.
> > > > > > > >
> > > > > > >
> > > > > > > Sorry, I have very little idea how OMAP hardware works. Do you
> > > > > > > mean that you will have different nodes for each clockdomain so
> > > > > > > that genpd can map 1:1 to the node in dts? But in hardware
> > > > > > > there's a prcm that allows us to control many clock domains
> > > > > > > through register read/writes? How is the interconnect involved?
> > > > > >
> > > > > > There are multiple clockdomains, at least one for each interconnect
> > > > > > instance. Once a clockdomain is idle, the related interconnect can
> > > > > > idle too. So yeah genpd pretty much maps 1:1 with the clockdomains.
> > > > > >
> > > > > > There's more info in for example omap4 TRM section "3.4.1 Device
> > > > > > Power-Management Layout" that shows the voltage/power/clock domains.
> > > > > > The interconnect instances are mostly named there too looking at
> > > > > > the L4/L3 naming.
> > > > >
> > > > > I'm confused on two points:
> > > > >
> > > > > 1) why are the clkdm's acting as clock providers? I've always hated the
> > > > > name "clock domain" since those bits are for managing module state, not
> > > > > clock state. The PRM, CM1 and CM2 provide the clocks, not the
> > > > > clockdomains.
> > > >
> > > > The clock domains have multiple clock inputs that are routed to multiple
> > > > child clocks. So it is a clock :)
> > > >
> > > > See for example omap4430 TRM "3.6.4 CD_WKUP Clock Domain" on page
> > > > 393 in my revision here.
> > > >
> > > > On that page "Figure 3-48" shows CD_WKUP with the four input clocks.
> > > > And then "Table 3-84. CD_WKUP Control and Status Parameters" shows
> > > > the CD_WKUP clock domain specific registers. These registers show
> > > > the status, I think they are all read-only registers. Then CD_WKUP
> > > > has multiple child clocks with configurable registers.
> > > >
> > > > From hardware register point of view, each clock domain has:
> > > >
> > > > - Read-only clockdomain status registers in the beginning of
> > > > the address space
> > > >
> > > > - Multiple similar clock instances register instances each
> > > > mapping to a specific interconnect target module
> > > >
> > > > These are documented in "3.11.16.1 WKUP_CM Register Summary".
> > >
> > > Oh, this is because you are treating the MODULEMODE bits like gate
> > > clocks. I never really figured out if this was the best way to model
> > > those bits since they do more than control a line toggling at a rate.
> > > For instance this bit will affect the master/slave IDLE protocol between
> > > the module and the PRCM.
> >
> > Yes seems like there is some negotiation going on there with the
> > target module. But from practical point of view the CLKCTRL
> > register is the gate for a module functional clock.
>
> There's some confusion on this, clockdomain is effectively a collection of
> clocks, and can be used to force control that collection if needed. Chapter
> "3.1.1.1.3 Clock Domain" in some OMAP4 TRM shows the relationship neatly.
Yeah that's my understanding too.
> > > > From hardware point of view, we ideally want to map interconnect
> > > > target modules to the clock instance offset from the clock domain
> > > > for that interconnect segment. For example gptimer1 clocks would
> > > > be just:
> > > >
> > > > clocks = <&cd_wkup 0x40>;
> > > >
> > > > > 2) why aren't the clock domains modeled as genpds with their associated
> > > > > devices attached to them? Note that it is possible to "nest" genpd
> > > > > objects. This would also allow for the "Clockdomain Dependency"
> > > > > relationships to be properly modeled (see section 3.1.1.1.7 Clock Domain
> > > > > Dependency in the OMAP4 TRM).
> > > >
> > > > Clock domains only route clocks to child clocks. Power domains
> > > > are different registers. The power domains map roughly to
> > > > interconnect instances, there we have registers to disable the
> > > > whole interconnect when idle.
> > >
> > > I'm not talking about power islands at all, but the genpd object in
> > > Linux. For instance, if we treat each clock domain like a clock
> > > provider, how could the functional dependency between clkdm_A and
> > > clkdm_B be asserted?
> >
> > To me it seems that some output of a clockdomain is just a input
> > of another clockdomain? So it's just the usual parent child
> > relationship once we treat a clockdomain just as a clock. Tero
> > probably has some input here.
>
> A clockdomain should be modelled as a genpd, that I agree. However, it
> doesn't prevent it from being a clock provider also, or does it?
>
> > > There is certainly no API for that in the clock framework, but for genpd
> > > your runtime_pm_get() callback for clkdm_A could call runtime_pm_get
> > > against clkdm_B, which would satisfy the requirement. See section
> > > 3.1.1.1.7 Clock Domain Dependency in the OMAP4 TRM, version AB.
>
> For static dependencies the apis genpd_add/remove_subdomain could probably
> be used.
>
> > To me it seems the API is just clk_get() :) Do you have some
> > specific example we can use to check? My guess is that the
> > TRM "Clock Domain Dependency" is just the usual parent child
> > relationship between clocks that are the clockdomains..
> >
> > If there is something more magical there certainly that should
> > be considered though.
>
> The hwmods could be transformed to individual genpds also I guess. On DT
> level though, we would still need a clock pointer to the main clock and a
> genpd pointer in addition to that.
Hmm a genpd pointer to where exactly? AFAIK each interconnect
instance should be a genpd provider, and the individual interconnect
target modules should be consumers for that genpd.
> Tony, any thoughts on that? Would this break up the plans for the
> interconnect completely?
Does using genpd for clockdomains cause issues for using genpd for
interconnect instances and the target modules?
The thing I'd be worried about there is that the clockdomains and
their child clocks are just devices sitting on the interconnect,
so we could easily end up with genpd modeling something that does
not represent the hardware.
For example, on 4430 we have:
l4_cfg interconnect
...
segment at 0
...
target_module at 4000
cm1: cm1 at 0
...
...
target_module at 8000
cm2: cm2 at 0
...
l4_wkup interonnect
...
segment at 0
...
target_module at 6000
prm: prm at 0
...
target_module at a000
scrm: scrm at 0
...
So what do you guys have in mind for using genpd in the above
example for the clockdomains?
To me it seems that the interconnect instances like l4_cfg and
l4_wkup above should be genpd providers. I don't at least yet
follow what we need to do with the clockdomains with genpd :)
Wouldn't just doing clk_get() from one clockdomain clock to
another clockdomain clock (or it's output) be enough to
represent the clockdomain dependencies?
Regards,
Tony
^ permalink raw reply
* [PATCH 10/18] arm64: ilp32: introduce binfmt_ilp32.c
From: Catalin Marinas @ 2016-12-05 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477081997-4770-11-git-send-email-ynorov@caviumnetworks.com>
On Fri, Oct 21, 2016 at 11:33:09PM +0300, Yury Norov wrote:
> binfmt_ilp32.c is needed to handle ILP32 binaries
>
> Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
> Signed-off-by: Bamvor Zhang Jian <bamvor.zhangjian@linaro.org>
> ---
> arch/arm64/include/asm/elf.h | 6 +++
> arch/arm64/kernel/Makefile | 1 +
> arch/arm64/kernel/binfmt_ilp32.c | 97 ++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 104 insertions(+)
> create mode 100644 arch/arm64/kernel/binfmt_ilp32.c
>
> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> index f259fe8..be29dde 100644
> --- a/arch/arm64/include/asm/elf.h
> +++ b/arch/arm64/include/asm/elf.h
> @@ -175,10 +175,16 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
>
> #define COMPAT_ELF_ET_DYN_BASE (2 * TASK_SIZE_32 / 3)
>
> +#ifndef USE_AARCH64_GREG
> /* AArch32 registers. */
> #define COMPAT_ELF_NGREG 18
> typedef unsigned int compat_elf_greg_t;
> typedef compat_elf_greg_t compat_elf_gregset_t[COMPAT_ELF_NGREG];
> +#else /* AArch64 registers for AARCH64/ILP32 */
> +#define COMPAT_ELF_NGREG ELF_NGREG
> +#define compat_elf_greg_t elf_greg_t
> +#define compat_elf_gregset_t elf_gregset_t
> +#endif
I think you only need compat_elf_gregset_t definition here and leave the
other two undefined.
--
Catalin
^ 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