* [PATCH] arm64: dts: mt8173: Fix cpu_thermal cooling-maps contributions
From: Daniel Kurtz @ 2017-01-13 2:30 UTC (permalink / raw)
To: linux-arm-kernel
According to [0], the contribution field for each cooling-device express
their relative power efficiency. Higher weights express higher power
efficiency. Weighting is relative such that if each cooling device has a
weight of 1 they are considered equal. This is particularly useful in
heterogeneous systems where two cooling devices may perform the same kind
of compute, but with different efficiency.
[0] Documentation/thermal/power_allocator.txt
According to Mediatek IC designer, the power efficiency ratio between the
LITTLE core cluster (cooling-device cpu0) and big core cluster
(cooling-device cpu1) is around 3:1 (3072:1024).
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 12e702771f5c..9a3b0d20f7a8 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -182,12 +182,12 @@
map at 0 {
trip = <&target>;
cooling-device = <&cpu0 0 0>;
- contribution = <1024>;
+ contribution = <3072>;
};
map at 1 {
trip = <&target>;
cooling-device = <&cpu2 0 0>;
- contribution = <2048>;
+ contribution = <1024>;
};
};
};
--
2.11.0.390.gc69c2f50cf-goog
^ permalink raw reply related
* [PATCH net-next v2 00/10] net: dsa: Support for pdata in dsa2
From: Vivien Didelot @ 2017-01-13 2:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112034121.27697-1-f.fainelli@gmail.com>
Hi Florian,
Florian Fainelli <f.fainelli@gmail.com> writes:
> Hi all,
>
> This is not exactly new, and was sent before, although back then, I did not
> have an user of the pre-declared MDIO board information, but now we do. Note
> that I have additional changes queued up to have b53 register platform data for
> MIPS bcm47xx and bcm63xx.
>
> Yes I know that we should have the Orion platforms eventually be converted to
> Device Tree, but until that happens, I don't want any remaining users of the
> old "dsa" platform device (hence the previous DTS submissions for ARM/mvebu)
> and, there will be platforms out there that most likely won't never see DT
> coming their way (BCM47xx is almost 100% sure, BCM63xx maybe not in a distant
> future).
>
> We would probably want the whole series to be merged via David Miller's tree
> to simplify things.
>
> Greg, can you Ack/Nack patch 5 since it touched the core LDD?
>
> Thanks!
I've tested this patchset on my mv88e6xxx (DTS) boards to make sure
nothing was broken, since it touches the driver. Looks good!
Tested-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Thanks,
Vivien
^ permalink raw reply
* [PATCH] arm64: hugetlb: fix the wrong return value for huge_ptep_set_access_flags
From: Huang Shijie @ 2017-01-13 2:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111101924.GA18044@e104818-lin.cambridge.arm.com>
On Wed, Jan 11, 2017 at 10:19:25AM +0000, Catalin Marinas wrote:
> The disclaimer is not the main issue. The patch that ended up on the
> list seems to have been corrupted probably by the SMTP server (all tabs
> converted to spaces).
Thanks for pointing this. I will change another SMTP server if the issue
still exists in future.
Thanks
Huang Shijie
^ permalink raw reply
* [PATCH v2 04/12] driver: clk: imx: Add clock driver for imx6sll
From: Jacky Bai @ 2017-01-13 3:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112220536.GP17126@codeaurora.org>
> Subject: Re: [PATCH v2 04/12] driver: clk: imx: Add clock driver for imx6sll
>
> > > > +
> > > > +static const char *pll_bypass_src_sels[] = { "osc", "dummy", };
> > >
> > > All these should be const char * const unless something is wrong.
> >
> > If changed to 'const char * const', it vill has argument type mismatch
> > error, as imx_clk_* wrapper function has argument type 'const char *'.
>
> Hmm that's unfortunate.
>
> >
> > >
> > > > +
> > > > + for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
> > > > + clk_prepare_enable(clks[clks_init_on[i]]);
> > >
> > > Critical clocks?
> >
> > Yes, these clocks must be always on.
> >
> > >
> > > > +
> > > > + if (IS_ENABLED(CONFIG_USB_MXS_PHY)) {
> > > > + clk_prepare_enable(clks[IMX6SLL_CLK_USBPHY1_GATE]);
> > > > + clk_prepare_enable(clks[IMX6SLL_CLK_USBPHY2_GATE]);
> > >
> > > The phy driver can't enable these?
> >
> > The reason why we enable these two clks here is in below commit commit
> > a5120e89e7e187a91852896f586876c7a2030804
> > Author: Peter Chen <peter.chen@freescale.com>
> > Date: Fri Jan 18 10:38:05 2013 +0800
> > ARM i.MX6: change mxs usbphy clock usage
> >
>
> So can we mark these clks with CLK_IS_CRITICAL flag then instead?
> Or are they disabled out of the bootloader?
>
Sure, using 'CLK_IS_CRITICAL' should be ok for clks_init_on clocks. But for USBPHY*_GATE, it is
only enabled when CONIG_USB_MXC_PHY is true. And another concern is if we need to add CLK_IS_CRITICAL
flag to clks_init_on clocks, we may need to add new wrapper function to register these critical clock. It is not very good.
> >
> > > > + }
> > > > +
> > > > + /* Lower the AHB clock rate before changing the clock source. */
> > > > + clk_set_rate(clks[IMX6SLL_CLK_AHB], 99000000);
> > > > +
> > > > + /* Change periph_pre clock to pll2_bus to adjust AXI rate to 264MHz */
> > > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH_CLK2_SEL],
> > > clks[IMX6SLL_CLK_PLL3_USB_OTG]);
> > > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH],
> > > clks[IMX6SLL_CLK_PERIPH_CLK2]);
> > > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH_PRE],
> > > clks[IMX6SLL_CLK_PLL2_BUS]);
> > > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH],
> > > > +clks[IMX6SLL_CLK_PERIPH_PRE]);
> > > > +
> > > > + clk_set_rate(clks[IMX6SLL_CLK_AHB], 132000000);
> > >
> > > assigned-clocks for rates now? Or perhaps we shouldn't be exposing
> > > these as clks if they have some sort of complicated rate sequence
> > > switch that we can't guarantee with the clk_ops we have today.
> >
> > These clks will be used by some peripherals, so we need to expose these
> clocks.
> > And the above parent and rate swith sequence is not very easy to be
> > handled in assigned-clocks, So we leave it in this place.
> >
>
> How do we guarantee that the rate switch doesn't happen later on, requiring
> this coordinated sequence of clk operations?
>
This clock sequence is used for increasing the AXI and AHB bus clock rate. In normal
use, it is very rarely that we need to change them again. If we really need to change
AXI and AHB bus clock later, a similar sequence must be used to do this.
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
^ permalink raw reply
* [PATCH v6 23/25] usb: chipidea: Pullup D+ in device mode via phy APIs
From: Peter Chen @ 2017-01-13 3:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148426139182.20672.2422337338087784924@sboyd-linaro>
On Thu, Jan 12, 2017 at 02:49:51PM -0800, Stephen Boyd wrote:
> Quoting Peter Chen (2017-01-12 01:50:40)
> > On Wed, Jan 11, 2017 at 04:19:53PM -0800, Stephen Boyd wrote:
> > > Quoting Peter Chen (2017-01-02 22:53:19)
> > > > On Wed, Dec 28, 2016 at 02:57:09PM -0800, Stephen Boyd wrote:
> > > > > If the phy supports it, call phy_set_mode() to pull up D+ when
> > > > > required by setting the mode to PHY_MODE_USB_DEVICE. If we want
> > > > > to remove the pullup, set the mode to PHY_MODE_USB_HOST.
> > > > >
> > > [..]
> > > > > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > > > > index 0d532a724d48..6d61fa0689b0 100644
> > > > > --- a/drivers/usb/chipidea/udc.c
> > > > > +++ b/drivers/usb/chipidea/udc.c
> > > > > @@ -1609,10 +1610,15 @@ static int ci_udc_pullup(struct usb_gadget *_gadget, int is_on)
> > > > > return 0;
> > > > >
> > > > > pm_runtime_get_sync(&ci->gadget.dev);
> > > > > - if (is_on)
> > > > > + if (is_on) {
> > > > > + if (ci->phy)
> > > > > + phy_set_mode(ci->phy, PHY_MODE_USB_DEVICE);
> > > > > hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
> > > > > - else
> > > > > + } else {
> > > > > hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
> > > > > + if (ci->phy)
> > > > > + phy_set_mode(ci->phy, PHY_MODE_USB_HOST);
> > > > > + }
> > > > > pm_runtime_put_sync(&ci->gadget.dev);
> > > > >
> > > > > return 0;
> > > >
> > > > Would you describe the use case for it? Why not adding it at
> > > > role switch routine?
> > > >
> > >
> > > This is about pulling up D+. The phy I have requires that we manually
> > > pull up D+ by writing a ULPI register before we set the run/stop bit.
> >
> > Afaik, only controller can pull up dp when it is at device mode by
> > setting USBCMD_RS. At host mode, clear USBCMD_RS will only stopping
> > sending SoF from controller side.
> >
> > I am puzzled why you can pull up D+ by writing an ULPI register, perhaps,
> > your phy needs DP to change before switching the mode? Would you
> > double confirm that?
>
> With the boards I have, vbus is not routed to the phy. Instead, there's
> a vbus comparator on the PMIC where the vbus line from the usb
> receptacle is sent. The vbus extcon driver probes the comparator on the
> PMIC to see if vbus is present or not and then notifies extcon users
> when vbus changes.
>
> The ULPI register we write in the phy is a vendor specific register
> (called MISC_A) that has two bits. If you look at
> qcom_usb_hs_phy_set_mode() in this series you'll see that we set
> VBUSVLDEXTSEL and VBUSVLDEXT. VBUSVLDEXTSEL controls a mux in the phy
> that chooses between an internal comparator, in the case where vbus goes
> to the phy, or an external signal input to the phy, VBUSVLDEXT, to
> consider as the "session valid" signal. It looks like the session valid
> signal drives the D+ pullup resistor in the phy. These bits in MISC_A
> don't matter when the phy is in host mode.
>
> So when the board doesn't route vbus to the phy, we have to toggle the
> VBUSVLDEXT bit to signal to the phy that the vbus is there or not. I
> also see that we're not supposed to toggle the VBUSVLDEXTSEL bit when in
> "normal" operating mode. So perhaps we should do everything in the
> qcom_usb_hs_phy_set_mode() routine during the role switch as you
> suggest, except toggle the VBUSVLDEXT bit. Toggling the VBUSVLDEXT bit
> can be done via some new phy op when the extcon triggers?
Why not call phy_set_mode(phy, DEVICE) directly at ci_handle_vbus_change when
you get extcon vbus event?
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH net-next v2 05/10] drivers: base: Add device_find_class()
From: David Miller @ 2017-01-13 4:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <81f5965c-3484-92d9-5c04-94c5b73735d0@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 12 Jan 2017 14:50:39 -0800
> Well, this is really so that we don't need to cast the arguments passed
> to device_find_child(), which takes a void *data as well.
Aha, I didn't catch that, my bad.
^ permalink raw reply
* [PATCH v5 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Appana Durga Kedareswara Rao @ 2017-01-13 4:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110062349.GY3573@localhost>
Hi Vinod,
Thanks for the review...
>
> On Sat, Jan 07, 2017 at 12:15:28PM +0530, Kedareswara rao Appana wrote:
> > Add channel idle state to ensure that dma descriptor is not
> > submitted when VDMA engine is in progress.
>
> any reason why you want to make your own varible and not use the HW to
> query
> as done earlier. It is not clear to me why that is removed from description
We need to poll for a bit in the status register to know the dma state.
We are currently doing that in the driver hot path
To avoid this using own variables.
Regards,
Kedar.
^ permalink raw reply
* [PATCH 2/5] clk: sunxi-ng: add support for V3s CCU
From: Icenowy Zheng @ 2017-01-13 4:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112174122.iqzrcyytfefqspwq@lukather>
13.01.2017, 01:41, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Fri, Jan 13, 2017 at 01:31:41AM +0800, Icenowy Zheng wrote:
>> ?2017?1?13? 01:19? Maxime Ripard <maxime.ripard@free-electrons.com>???
>> ?>
>> ?> On Thu, Jan 12, 2017 at 03:44:53AM +0800, Icenowy Zheng wrote:
>> ?> >
>> ?> >
>> ?> > 12.01.2017, 03:40, "Icenowy Zheng" <icenowy@aosc.xyz>:
>> ?> > > 11.01.2017, 02:10, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>> ?> > >> ?On Tue, Jan 03, 2017 at 11:16:26PM +0800, Icenowy Zheng wrote:
>> ?> > >>> ??V3s has a similar but cut-down CCU to H3.
>> ?> > >>>
>> ?> > >>> ??Add support for it.
>> ?> > >>>
>> ?> > >>> ??Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ?> > >>
>> ?> > >> ?It looks like there's nothing different but the clocks that you
>> ?> > >> ?register with the H3, please just use the H3 driver.
>> ?> > >
>> ?> > > Nope.
>> ?> > >
>> ?> > > It has a different PLL (PLL_ISP) at different address, and some
>> ?> > > different muxes.
>> ?> >
>> ?> > Forgot to mention the missing of PLL_DE and related misses.
>> ?>
>> ?> Those are not conflicting, it's just a slightly different set of
>> ?> clocks.
>>
>> ?If saying so, we can have only one ccu driver, and make every ccu
>> ?register different set ;-)
>>
>> ?V3s itself is a totally different SoC with H3.
>>
>> ?The relationship of V3s and H3 can be farther than the relationship
>> ?of A33 and H3?
>
> A33 and H3 are an entirely different story. The H3 and A33 have
> conflicting clocks (ie same clocks with different parameters). This is
> not your case.
I think V3s and H3 has also conflicting clocks, e.g. CLK_DE.
The mux of CLK_DE in V3s is PLL_PERIPHx2 and PLL_VIDEO, but on H3
it's PLL_PERIPHx2 and PLL_DE (V3s lacks PLL_DE).
(What I say that there's a PLL missing means that there will also be mux
changes... I think you can understand this... sorry.)
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH] PCI: iproc: fix kernel crash if dev->of_node not defined
From: Abylay Ospan @ 2017-01-13 4:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6cfba8af-1e9b-cb43-4898-61d6fb8f12ca@broadcom.com>
Hi Florian,
> Still, upstream Linux support for Northstar is Device Tree, and BCMA bus
> should fill in of_nodes accordingly, if not, that's a bug that must be
> fixed at the BCMA layer.
yes, this is a source of the problem. Devices allocated in
'bcma_bus_scan' but of_node doesn't assigned.
Is some code missing in drivers/bcma/ which should assign of_node ?
I can suggest following "hacky" patch for this (works for me):
Author: Abylay Ospan <aospan@netup.ru>
Date: Fri Jan 13 07:24:13 2017 +0300
bcma: force assign 'of_node' for devices on the bus
prevent other code to fail if no 'of_node' defined
Signed-off-by: Abylay Ospan <aospan@netup.ru>
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 2c1798e..4fe1c92 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -301,6 +301,11 @@ void bcma_init_bus(struct bcma_bus *bus)
static void bcma_register_core(struct bcma_bus *bus, struct bcma_device *core)
{
int err;
+ struct device * dev;
+
+ dev = bcma_bus_get_host_dev(bus);
+ if (dev && !core->dev.of_node)
+ core->dev.of_node = dev->of_node;
if it's ok I will send this patch in separate email.
>
>>
>>>
>>>>
>>>> Signed-off-by: Abylay Ospan <aospan@netup.ru>
>>>> ---
>>>> drivers/pci/host/pcie-iproc.c | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
>>>> index 3ebc025..f2836a9 100644
>>>> --- a/drivers/pci/host/pcie-iproc.c
>>>> +++ b/drivers/pci/host/pcie-iproc.c
>>>> @@ -952,6 +952,9 @@ static int pci_dma_range_parser_init(struct of_pci_range_parser *parser,
>>>> const int na = 3, ns = 2;
>>>> int rlen;
>>>>
>>>> + if (!node)
>>>> + return -ENOENT;
>>>> +
>>>> parser->node = node;
>>>> parser->pna = of_n_addr_cells(node);
>>>> parser->np = parser->pna + na + ns;
>>>>
>>>
>>>
>
>
> --
> Florian
--
Abylay Ospan,
NetUP Inc.
http://www.netup.tv
^ permalink raw reply related
* [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions
From: Guenter Roeck @ 2017-01-13 5:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111143917.hedhyfu6m5dopag7@pengutronix.de>
On 01/11/2017 06:39 AM, Uwe Kleine-K?nig wrote:
> On Wed, Jan 11, 2017 at 01:31:47PM +0100, Marc Gonzalez wrote:
>> On 11/01/2017 11:52, Guenter Roeck wrote:
>>
>>> On 01/11/2017 01:07 AM, Marc Gonzalez wrote:
>>>
>>>>> @@ -134,12 +134,15 @@ static int tangox_wdt_probe(struct platform_device *pdev)
>>>>> err = clk_prepare_enable(dev->clk);
>>>>> if (err)
>>>>> return err;
>>>>> + err = devm_add_action_or_reset(&pdev->dev,
>>>>> + (void(*)(void *))clk_disable_unprepare,
>>>>> + dev->clk);
>>>>> + if (err)
>>>>> + return err;
>
> This looks wrong. There is no clk_unprepare_disable when
> devm_add_action_or_reset fails.
>
>>>>
>>>> Hello Guenter,
>>>>
>>>> I would rather avoid the function pointer cast.
>>>> How about defining an auxiliary function for the cleanup action?
>>>>
>>>> clk_disable_unprepare() is static inline, so gcc will have to
>>>> define an auxiliary function either way. What do you think?
>>>
>>> Not really. It would just make it more complicated to replace the
>>> call with devm_clk_prepare_enable(), should it ever find its way
>>> into the light of day.
>>
>> More complicated, because the cleanup function will have to be deleted later?
>> The compiler will warn if someone forgets to do that.
>>
>> In my opinion, it's not a good idea to rely on the fact that casting
>> void(*)(struct clk *clk) to void(*)(void *) is likely to work as expected
>> on most platforms. (It has undefined behavior, strictly speaking.)
>
> I would expect it to work on all (Linux) platforms. Anyhow, I wonder if
> there couldn't be found a better solution.
>
> If in the end it looks like the following that would be good I think:
>
> clk = devm_clk_get(...);
> if (IS_ERR(clk))
> ...
>
> ret = devm_clk_prepare_enable(clk)
> if (ret)
> return ret;
>
It turns out that at least one static analyzer complains about different
parameter pointer types in situations like this, and at least one embedded
compiler manages to create function names with embedded parameter type
(eg it appends an 'i' to the function name for each integer parameter).
With that, I consider the typecast to be too risky after all. It may work
for all of today's Linux architectures and compilers, but who knows if I
get flooded with static analyzer warnings, and who knows if gcc version
18.0 or binutils 35.0 makes it truly incompatible (following the logic of
"we can, therefore we do"). Since I also dislike the stub function solution,
at least in this situation, I'll drop all patches touching clk_prepare_enable(),
and wait for devm_clk_prepare_enable() to be available.
Guenter
^ permalink raw reply
* [PATCH v5 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Vinod Koul @ 2017-01-13 5:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C246CAC1457055469EF09E3A7AC4E11A4A666658@XAP-PVEXMBX01.xlnx.xilinx.com>
On Fri, Jan 13, 2017 at 04:28:11AM +0000, Appana Durga Kedareswara Rao wrote:
> Hi Vinod,
>
> Thanks for the review...
> >
> > On Sat, Jan 07, 2017 at 12:15:28PM +0530, Kedareswara rao Appana wrote:
> > > Add channel idle state to ensure that dma descriptor is not
> > > submitted when VDMA engine is in progress.
> >
> > any reason why you want to make your own varible and not use the HW to
> > query
> > as done earlier. It is not clear to me why that is removed from description
>
> We need to poll for a bit in the status register to know the dma state.
> We are currently doing that in the driver hot path
> To avoid this using own variables.
It would be worthwhile to document these, down the line people may not
remeber the motivation
--
~Vinod
^ permalink raw reply
* [PATCH] PCI: iproc: fix resource allocation for BCMA PCIe
From: Abylay Ospan @ 2017-01-13 5:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <988ae7dc-ff41-0a06-903f-8681b8ddf13f@broadcom.com>
Hi Ray,
i'm not sure but looks so. Following drivers is doing same allocation on stack:
drivers/pci/host/pcie-designware.c
drivers/pci/host/pcie-rockchip.c
drivers/pci/host/pcie-xilinx.c
drivers/pci/host/pcie-xilinx-nwl.c
drivers/pci/host/pci-host-common.c
-> drivers/pci/host/pci-thunder-ecam.c
-> drivers/pci/host/pci-thunder-pem.c
-> drivers/pci/host/pci-host-generic.c
drivers/pci/host/pci-versatile.c
drivers/pci/host/pci-xgene.c
other drivers is ok. But need to double-check.
Below is more detailed description of the problem.
Problem is visible when second PCIe bridge registering (but can cause
kernel crash with only one PCIe bridge because broken pointer
introduced to 'iomem_resource' anyway). Here is my global
'iomem_resource' list dump:
after first PCIe bridge registered:
[ 3.578650] iomem_resource child=cb039d40 name=PCIe MEM space start=08000000
[ 3.585811] iomem_resource child=cb41da80 name=serial start=18000300
[ 3.592267] iomem_resource child=cb15ce80 name=serial start=18000400
[ 3.598719] iomem_resource child=cb57df00 name=nand start=18028000
[ 3.605001] iomem_resource child=cb57dc80 name=iproc-ext start=18028f00
[ 3.611723] iomem_resource child=cb57da00 name=iproc-idm start=1811a408
[ 3.618433] iomem_resource child=cbfffe80 name=System RAM start=80000000
this dump looks good but before registering second PCIe same dump looks broken:
[ 3.669225] iomem_resource child=cb039d40 name=PCIe MEM space start=40000000
[ 3.676395] iomem_resource child=cb5e3410 name=bcma0:8 start=cb0f6e10
[ 3.682948] iomem_resource child=cb061080 name= start=c1604b04
and second PCIe registration fail with:
[ 3.694207] pcie_iproc_bcma bcma0:8: resource collision: [mem
0x40000000-0x47ffffff] conflicts with PCIe MEM space [mem
0x40000000-0x47ffffff]
[ 3.707024] pcie_iproc_bcma bcma0:8: PCIe controller setup failed
address 0xcb039d40 from this dumps is allocated on stack and is not
valid after 'iproc_pcie_bcma_probe' exit.
Proposed patch is fixing this issue.
2017-01-12 19:40 GMT-05:00 Ray Jui <ray.jui@broadcom.com>:
> Hi Abylay,
>
> On 1/12/2017 3:58 PM, Abylay Ospan wrote:
>> Resource allocated on stack was saved by 'devm_request_resource' to
>> global 'iomem_resource' but become invalid after 'iproc_pcie_bcma_probe' exit.
>> So the global 'iomem_resource' was poisoned. This may cause kernel crash
>> or second PCIe bridge registration failure.
>>
>> Tested on Broadcom NorthStar machine ('Edgecore ECW7220-L') with two PCIe wifi
>> adapters (b43 BCM4331 and ath10k QCA988X).
>>
>> Signed-off-by: Abylay Ospan <aospan@netup.ru>
>
> I have not yet looked into this in great details. But if what you
> claimed is true, do we have the same problem with multiple PCIe host
> drivers that all have their resource allocated on the stack and have
> 'devm_request_resource' called to save it?
>
> Thanks,
>
> Ray
>
>> ---
>> drivers/pci/host/pcie-iproc-bcma.c | 18 ++++++++----------
>> drivers/pci/host/pcie-iproc.h | 2 ++
>> 2 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/pci/host/pcie-iproc-bcma.c b/drivers/pci/host/pcie-iproc-bcma.c
>> index bd4c9ec..28f9b89 100644
>> --- a/drivers/pci/host/pcie-iproc-bcma.c
>> +++ b/drivers/pci/host/pcie-iproc-bcma.c
>> @@ -44,8 +44,6 @@ static int iproc_pcie_bcma_probe(struct bcma_device *bdev)
>> {
>> struct device *dev = &bdev->dev;
>> struct iproc_pcie *pcie;
>> - LIST_HEAD(res);
>> - struct resource res_mem;
>> int ret;
>>
>> pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
>> @@ -62,21 +60,21 @@ static int iproc_pcie_bcma_probe(struct bcma_device *bdev)
>> }
>>
>> pcie->base_addr = bdev->addr;
>> + INIT_LIST_HEAD(&pcie->resources);
>>
>> - res_mem.start = bdev->addr_s[0];
>> - res_mem.end = bdev->addr_s[0] + SZ_128M - 1;
>> - res_mem.name = "PCIe MEM space";
>> - res_mem.flags = IORESOURCE_MEM;
>> - pci_add_resource(&res, &res_mem);
>> + pcie->res_mem.start = bdev->addr_s[0];
>> + pcie->res_mem.end = bdev->addr_s[0] + SZ_128M - 1;
>> + pcie->res_mem.name = "PCIe MEM space";
>> + pcie->res_mem.flags = IORESOURCE_MEM;
>> + pcie->res_mem.child = NULL;
>> + pci_add_resource(&pcie->resources, &pcie->res_mem);
>>
>> pcie->map_irq = iproc_pcie_bcma_map_irq;
>>
>> - ret = iproc_pcie_setup(pcie, &res);
>> + ret = iproc_pcie_setup(pcie, &pcie->resources);
>> if (ret)
>> dev_err(dev, "PCIe controller setup failed\n");
>>
>> - pci_free_resource_list(&res);
>> -
>> bcma_set_drvdata(bdev, pcie);
>> return ret;
>> }
>> diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h
>> index 04fed8e..866d649 100644
>> --- a/drivers/pci/host/pcie-iproc.h
>> +++ b/drivers/pci/host/pcie-iproc.h
>> @@ -105,6 +105,8 @@ struct iproc_pcie {
>>
>> bool need_msi_steer;
>> struct iproc_msi *msi;
>> + struct resource res_mem;
>> + struct list_head resources;
>> };
>>
>> int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res);
>>
--
Abylay Ospan,
NetUP Inc.
http://www.netup.tv
^ permalink raw reply
* [PATCH v5 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Appana Durga Kedareswara Rao @ 2017-01-13 5:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113052939.GP3573@localhost>
Hi Vinod,
Thanks for the review...
>
> On Fri, Jan 13, 2017 at 04:28:11AM +0000, Appana Durga Kedareswara Rao
> wrote:
> > Hi Vinod,
> >
> > Thanks for the review...
> > >
> > > On Sat, Jan 07, 2017 at 12:15:28PM +0530, Kedareswara rao Appana wrote:
> > > > Add channel idle state to ensure that dma descriptor is not
> > > > submitted when VDMA engine is in progress.
> > >
> > > any reason why you want to make your own varible and not use the HW
> > > to query as done earlier. It is not clear to me why that is removed
> > > from description
> >
> > We need to poll for a bit in the status register to know the dma state.
> > We are currently doing that in the driver hot path To avoid this using
> > own variables.
>
> It would be worthwhile to document these, down the line people may not
> remeber the motivation
Sure will add comments during the variable initialization
In the driver...
Regards,
Kedar.
>
>
> --
> ~Vinod
^ permalink raw reply
* [PATCH v5 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario
From: Vinod Koul @ 2017-01-13 5:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C246CAC1457055469EF09E3A7AC4E11A4A6662F1@XAP-PVEXMBX01.xlnx.xilinx.com>
On Thu, Jan 12, 2017 at 02:19:49PM +0000, Appana Durga Kedareswara Rao wrote:
> Hi Vinod,
>
> Thanks for the review...
>
> > On Sat, Jan 07, 2017 at 12:15:30PM +0530, Kedareswara rao Appana wrote:
> > > When driver is handling AXI DMA SoftIP When user submits multiple
> > > descriptors back to back on the S2MM(recv) side with the current
> > > driver flow the last buffer descriptor next bd points to a invalid
> > > location resulting the invalid data or errors in the DMA engine.
> >
> > Can you rephrase this, it a bit hard to understand.
>
> When DMA is receiving packets h/w expects the descriptors
> Should be in the form of a ring (I mean h/w buffer descriptor
> Next descriptor field should always point to valid address
> So that when DMA engine go and fetch that next descriptor it always
> Sees a valid address).
>
>
> But with the current driver implementation when user queues
> Multiple descriptors the last descriptor next descriptor field
> Pointing to an invalid location causing data corruption or
> Errors from the DMA h/w engine...
>
> To avoid this issue creating a Buffer descriptor Chain during
> Channel allocation and using those buffer descriptors for processing
> User requested data.
Is it not doable to to modify the next pointer to point to subsequent
transaction. IOW you are modifying tail descriptor to point to subsequent
descriptor.
Btw how and when does DMA stop, assuming it is circular it never would,
isn't there a valid/stop flag associated with a descriptor which tells DMA
engine what to do next
Btw there is something wrong with your MUA perhaps line are titlecased for
no reason. This is typically behavious of non linux tool which may not be
great tool for this work.
>
> Please let me know if the above explanation is not clear will explain in detail....
>
> >
> > >
> > > This patch fixes this issue by creating a BD Chain during
> >
> > whats a BD?
>
> Buffer descriptor.
Thats nowhere mentioned..
>
> >
> > > channel allocation itself and use those BD's.
> > >
> > > Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> > > ---
> > >
> > > drivers/dma/xilinx/xilinx_dma.c | 133
> > > +++++++++++++++++++++++++---------------
> > > 1 file changed, 83 insertions(+), 50 deletions(-)
> > >
> > > diff --git a/drivers/dma/xilinx/xilinx_dma.c
> > > b/drivers/dma/xilinx/xilinx_dma.c index 0e9c02e..af2159d 100644
> > > --- a/drivers/dma/xilinx/xilinx_dma.c
> > > +++ b/drivers/dma/xilinx/xilinx_dma.c
> > > @@ -163,6 +163,7 @@
> > > #define XILINX_DMA_BD_SOP BIT(27)
> > > #define XILINX_DMA_BD_EOP BIT(26)
> > > #define XILINX_DMA_COALESCE_MAX 255
> > > +#define XILINX_DMA_NUM_DESCS 255
> >
> > why 255?
>
> It is not an h/w limitation
> Allocating 255 descriptors (Each descriptor is capable of sending 7MB data)
> So roughly using allocated descriptors DMA engine can transfer 1GB data
> And in the driver we are reusing the allocated descriptors when they are free.
>
> Regards,
> Kedar.
--
~Vinod
^ permalink raw reply
* arm64: dts: mt8173: add node for thermal calibration
From: Dawei Chien @ 2017-01-13 5:52 UTC (permalink / raw)
To: linux-arm-kernel
From: "dawei.chien@mediatek.com" <dawei.chien@mediatek.com>
Add this for supporting thermal calibration by e-fuse data.
Signed-off-by: Dawei Chien <dawei.chien@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 12e7027..adfac1e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -401,6 +401,11 @@
efuse: efuse at 10206000 {
compatible = "mediatek,mt8173-efuse";
reg = <0 0x10206000 0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ thermal_calibration: calib at 528 {
+ reg = <0x528 0xc>;
+ };
};
apmixedsys: clock-controller at 10209000 {
@@ -574,6 +579,8 @@
resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
mediatek,auxadc = <&auxadc>;
mediatek,apmixedsys = <&apmixedsys>;
+ nvmem-cells = <&thermal_calibration>;
+ nvmem-cell-names = "calibration-data";
};
nor_flash: spi at 1100d000 {
--
1.9.1
^ permalink raw reply related
* [PATCH] PCI: iproc: fix kernel crash if dev->of_node not defined
From: Abylay Ospan @ 2017-01-13 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6891f43f-25e7-1411-800e-97e6788f2f27@gmail.com>
FYI,
here is my tree (based on linux-next):
https://github.com/aospan/linux-next-bcm4708-edgecore-ecw7220-l/commits/master
last patches adding defconfig and dts I'm using for this device. This
files are draft yet.
2017-01-12 19:22 GMT-05:00 Florian Fainelli <f.fainelli@gmail.com>:
> On 01/12/2017 04:20 PM, Abylay Ospan wrote:
>> pcie->dev->of_node not always defined (NULL) and can cause crash:
>>
>> [ 19.053195] Unable to handle kernel NULL pointer dereference at
>> virtual address 00000020
>> [<c0b0370c>] (of_n_addr_cells) from [<c06599c4>]
>> (iproc_pcie_setup+0x30c/0xce0)
>>
>> this patch adds sanity check to prevent crash.
>
> Humm, how can it not be defined based on your earlier comment that you
> are using this on NSP which is Device Tree exclusively? I would agree if
> this was seen on e.g: MIPS/BCMA (47xx).
>
>>
>> Signed-off-by: Abylay Ospan <aospan@netup.ru>
>> ---
>> drivers/pci/host/pcie-iproc.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
>> index 3ebc025..f2836a9 100644
>> --- a/drivers/pci/host/pcie-iproc.c
>> +++ b/drivers/pci/host/pcie-iproc.c
>> @@ -952,6 +952,9 @@ static int pci_dma_range_parser_init(struct of_pci_range_parser *parser,
>> const int na = 3, ns = 2;
>> int rlen;
>>
>> + if (!node)
>> + return -ENOENT;
>> +
>> parser->node = node;
>> parser->pna = of_n_addr_cells(node);
>> parser->np = parser->pna + na + ns;
>>
>
>
> --
> Florian
--
Abylay Ospan,
NetUP Inc.
http://www.netup.tv
^ permalink raw reply
* [PATCH] arm64/mm: use phys_addr_t
From: miles.chen at mediatek.com @ 2017-01-13 5:59 UTC (permalink / raw)
To: linux-arm-kernel
From: Miles Chen <miles.chen@mediatek.com>
Use phys_addr_t instead of unsigned long for the
return value of __pa(), make code easy to understand.
Signed-off-by: Miles Chen <miles.chen@mediatek.com>
---
arch/arm64/mm/mmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 17243e4..7eb7c21 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -359,8 +359,8 @@ static void create_mapping_late(phys_addr_t phys, unsigned long virt,
static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end)
{
- unsigned long kernel_start = __pa(_text);
- unsigned long kernel_end = __pa(__init_begin);
+ phys_addr_t kernel_start = __pa(_text);
+ phys_addr_t kernel_end = __pa(__init_begin);
/*
* Take care not to create a writable alias for the
--
1.9.1
^ permalink raw reply related
* [PATCH v5 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario
From: Appana Durga Kedareswara Rao @ 2017-01-13 6:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113053627.GQ3573@localhost>
Hi Vinod,
Thanks for the review...
[Snip]
> >
> > > On Sat, Jan 07, 2017 at 12:15:30PM +0530, Kedareswara rao Appana wrote:
> > > > When driver is handling AXI DMA SoftIP When user submits multiple
> > > > descriptors back to back on the S2MM(recv) side with the current
> > > > driver flow the last buffer descriptor next bd points to a invalid
> > > > location resulting the invalid data or errors in the DMA engine.
> > >
> > > Can you rephrase this, it a bit hard to understand.
> >
> > When DMA is receiving packets h/w expects the descriptors Should be in
> > the form of a ring (I mean h/w buffer descriptor Next descriptor field
> > should always point to valid address So that when DMA engine go and
> > fetch that next descriptor it always Sees a valid address).
> >
> >
> > But with the current driver implementation when user queues Multiple
> > descriptors the last descriptor next descriptor field Pointing to an
> > invalid location causing data corruption or Errors from the DMA h/w
> > engine...
> >
> > To avoid this issue creating a Buffer descriptor Chain during Channel
> > allocation and using those buffer descriptors for processing User
> > requested data.
>
> Is it not doable to to modify the next pointer to point to subsequent transaction.
> IOW you are modifying tail descriptor to point to subsequent descriptor.
>
> Btw how and when does DMA stop, assuming it is circular it never would, isn't
> there a valid/stop flag associated with a descriptor which tells DMA engine what
> to do next
There are two registers that controls the DMA transfers.
Current descriptor and tail descriptor register.
When current descriptor reaches tail descriptor dma engine will pause.
When reprogramming the tail descriptor the DMA engine will starts fetching descriptors again.
But with the existing driver flow if we reprogram the tail descriptor
The tail descriptor next descriptor field is pointing to an invalid location
Causing data corruption...
>
>
> Btw there is something wrong with your MUA perhaps line are titlecased for no
> reason. This is typically behavious of non linux tool which may not be great tool
> for this work.
Thanks for pointing it out.
I usually replies from outlook from a windows machine.
Will check with others in my team how they configured their mail client.
>
> >
> > Please let me know if the above explanation is not clear will explain in detail....
> >
> > >
> > > >
> > > > This patch fixes this issue by creating a BD Chain during
> > >
> > > whats a BD?
> >
> > Buffer descriptor.
>
> Thats nowhere mentioned..
Yep sorry I should have been mentioned it...
Regards,
Kedar.
^ permalink raw reply
* [PATCH v5 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario
From: Vinod Koul @ 2017-01-13 6:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C246CAC1457055469EF09E3A7AC4E11A4A6666CF@XAP-PVEXMBX01.xlnx.xilinx.com>
On Fri, Jan 13, 2017 at 06:00:44AM +0000, Appana Durga Kedareswara Rao wrote:
> Hi Vinod,
>
> Thanks for the review...
>
> [Snip]
> > >
> > > > On Sat, Jan 07, 2017 at 12:15:30PM +0530, Kedareswara rao Appana wrote:
> > > > > When driver is handling AXI DMA SoftIP When user submits multiple
> > > > > descriptors back to back on the S2MM(recv) side with the current
> > > > > driver flow the last buffer descriptor next bd points to a invalid
> > > > > location resulting the invalid data or errors in the DMA engine.
> > > >
> > > > Can you rephrase this, it a bit hard to understand.
> > >
> > > When DMA is receiving packets h/w expects the descriptors Should be in
> > > the form of a ring (I mean h/w buffer descriptor Next descriptor field
> > > should always point to valid address So that when DMA engine go and
> > > fetch that next descriptor it always Sees a valid address).
> > >
> > >
> > > But with the current driver implementation when user queues Multiple
> > > descriptors the last descriptor next descriptor field Pointing to an
> > > invalid location causing data corruption or Errors from the DMA h/w
> > > engine...
> > >
> > > To avoid this issue creating a Buffer descriptor Chain during Channel
> > > allocation and using those buffer descriptors for processing User
> > > requested data.
> >
> > Is it not doable to to modify the next pointer to point to subsequent transaction.
> > IOW you are modifying tail descriptor to point to subsequent descriptor.
> >
> > Btw how and when does DMA stop, assuming it is circular it never would, isn't
> > there a valid/stop flag associated with a descriptor which tells DMA engine what
> > to do next
>
> There are two registers that controls the DMA transfers.
> Current descriptor and tail descriptor register.
> When current descriptor reaches tail descriptor dma engine will pause.
>
> When reprogramming the tail descriptor the DMA engine will starts fetching descriptors again.
>
> But with the existing driver flow if we reprogram the tail descriptor
> The tail descriptor next descriptor field is pointing to an invalid location
> Causing data corruption...
So the solution is..?
> > Btw there is something wrong with your MUA perhaps line are titlecased for no
> > reason. This is typically behavious of non linux tool which may not be great tool
> > for this work.
>
> Thanks for pointing it out.
> I usually replies from outlook from a windows machine.
> Will check with others in my team how they configured their mail client.
Yeah that isnt right tool for the job. See
Documentation/process/email-clients.rst
FWIW, I use mutt, vim as editor with exchange servers, seems to work well
for me now.
--
~Vinod
^ permalink raw reply
* [PATCH v5 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario
From: Appana Durga Kedareswara Rao @ 2017-01-13 6:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113062225.GR3573@localhost>
Hi Vinod,
Thanks for the review...
[Snip]
> > > Btw how and when does DMA stop, assuming it is circular it never
> > > would, isn't there a valid/stop flag associated with a descriptor
> > > which tells DMA engine what to do next
> >
> > There are two registers that controls the DMA transfers.
> > Current descriptor and tail descriptor register.
> > When current descriptor reaches tail descriptor dma engine will pause.
> >
> > When reprogramming the tail descriptor the DMA engine will starts fetching
> descriptors again.
> >
> > But with the existing driver flow if we reprogram the tail descriptor
> > The tail descriptor next descriptor field is pointing to an invalid
> > location Causing data corruption...
>
> So the solution is..?
This patch.
I mean if we have a set of descriptors in chain (in circular manner last descriptor points to first descriptor)
It always points to valid descriptors.
Will update the patch commit description in the next version...
>
> > > Btw there is something wrong with your MUA perhaps line are
> > > titlecased for no reason. This is typically behavious of non linux
> > > tool which may not be great tool for this work.
> >
> > Thanks for pointing it out.
> > I usually replies from outlook from a windows machine.
> > Will check with others in my team how they configured their mail client.
>
> Yeah that isnt right tool for the job. See Documentation/process/email-
> clients.rst
>
> FWIW, I use mutt, vim as editor with exchange servers, seems to work well for
> me now.
Thanks for pointing it out will go through it.
Will install mutt in my Linux machine will start replying from that
Regards,
Kedar.
>
> --
> ~Vinod
^ permalink raw reply
* [PATCH] i2c: i2c-cadence: Don't register the adapter until it's ready
From: Mike Looijmans @ 2017-01-13 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <428e8fc8-8b23-8e2c-763e-d977aaa98691@mleia.com>
?On 06-01-17 22:34, Vladimir Zapolskiy wrote:
> Hello Mike,
>
> On 01/05/2017 12:47 PM, Mike Looijmans wrote:
>> The driver calls i2c_add_adapter before writing to config registers,
>> resulting in dmesg output like this, where devices fail to initialize:
>>
>> cdns-i2c ff030000.i2c: timeout waiting on completion
>> pca953x 1-0041: failed reading register
>> pca953x: probe of 1-0041 failed with error -110
>> at24 1-0050: 512 byte 24c04 EEPROM, writable, 1 bytes/write
>> cdns-i2c ff030000.i2c: 100 kHz mmio ff030000 irq 197
>>
>> The adapter is being used before it completed the "probe". To fix
>> this, make "i2c_add_adapter" the last thing it calls in probe.
>> It also makes sense to show the adapter initialization before
>> the devices on the bus.
>
> commonly "it also" in a commit message means a change, which should be done
> separately, and this is the case here as well.
>
> Because the adapter registration i2c_add_adapter() can fail, information
> about the adapter initialization would be expected only in case of
> successful registration.
I would argue that the "info" message means "the I2C adapter is ready for
transaction now, and we'll start initializing devices on the bus". That is the
case before it calls i2c_add_adapter().
When i2c_add_adapter() runs, it will start probing devices on the bus. This
yields very confusing output, as it will output things in a reversed order:
- device X on I2C bus
- device Y on I2C bus
- cdns-i2c ff030000.i2c: 100 kHz mmio ff030000 irq 197
This is especially confusing if there are multiple I2C adapters with muxes
behind them, the order then becomes like this:
- Device X on bus 0
- Mux A on bus 0 registering bus 2, 3 and 4
- I2C controller for bus 0
- Device Y on bus 1
- I2C controller for bus 1
- Device Z on bus 2
- etc..
> The information sent to the kernel log buffer here is quite trivial,
> probably dev_info() can be just removed, but in any case it should be
> a separate change.
Fine with me too.
>
>> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
>
> --
> With best wishes,
> Vladimir
>
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans at topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
^ permalink raw reply
* [PATCH v1 0/2] add nor flash node for mt2701
From: Guochun Mao @ 2017-01-13 7:13 UTC (permalink / raw)
To: linux-arm-kernel
This patch series based on v4.10-rc2, include MT2701 spinor node and bindings.
Dependent on "Add clock and power domain DT nodes for Mediatek MT2701"[1].
[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-December/007637.html
Guochun Mao (2):
Documentation: mtk-quadspi: update DT bindings
arm: dts: mt2701: add nor flash node
.../devicetree/bindings/mtd/mtk-quadspi.txt | 4 +++-
arch/arm/boot/dts/mt2701-evb.dts | 25 ++++++++++++++++++++++
arch/arm/boot/dts/mt2701.dtsi | 12 +++++++++++
3 files changed, 40 insertions(+), 1 deletion(-)
--
1.8.1.1.dirty
^ permalink raw reply
* [PATCH v1 1/2] Documentation: mtk-quadspi: update DT bindings
From: Guochun Mao @ 2017-01-13 7:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484291609-20195-1-git-send-email-guochun.mao@mediatek.com>
Add "mediatek,mt2701-nor" for nor flash node's compatible.
Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
---
.../devicetree/bindings/mtd/mtk-quadspi.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
index fb314f0..f83d31d 100644
--- a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
@@ -1,7 +1,9 @@
* Serial NOR flash controller for MTK MT81xx (and similar)
Required properties:
-- compatible: should be "mediatek,mt8173-nor";
+- compatible: should contain:
+ "mediatek,mt2701-nor" for MT2701,
+ "mediatek,mt8173-nor" for MT8173.
- reg: physical base address and length of the controller's register
- clocks: the phandle of the clocks needed by the nor controller
- clock-names: the names of the clocks
--
1.7.9.5
^ permalink raw reply related
* [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Guochun Mao @ 2017-01-13 7:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484291609-20195-1-git-send-email-guochun.mao@mediatek.com>
Add Mediatek nor flash node.
Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
---
arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
2 files changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
index 082ca88..85e5ae8 100644
--- a/arch/arm/boot/dts/mt2701-evb.dts
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -24,6 +24,31 @@
};
};
+&nor_flash {
+ pinctrl-names = "default";
+ pinctrl-0 = <&nor_pins_default>;
+ status = "okay";
+ flash at 0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ };
+};
+
+&pio {
+ nor_pins_default: nor {
+ pins1 {
+ pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
+ <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
+ <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
+ <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
+ <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
+ <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
+ drive-strength = <MTK_DRIVE_4mA>;
+ bias-pull-up;
+ };
+ };
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index bdf8954..1eefce4 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -227,6 +227,18 @@
status = "disabled";
};
+ nor_flash: spi at 11014000 {
+ compatible = "mediatek,mt2701-nor",
+ "mediatek,mt8173-nor";
+ reg = <0 0x11014000 0 0xe0>;
+ clocks = <&pericfg CLK_PERI_FLASH>,
+ <&topckgen CLK_TOP_FLASH_SEL>;
+ clock-names = "spi", "sf";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
mmsys: syscon at 14000000 {
compatible = "mediatek,mt2701-mmsys", "syscon";
reg = <0 0x14000000 0 0x1000>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 18/18] insert build break
From: Greg KH @ 2017-01-13 7:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484260655-80477-1-git-send-email-christopher.lee.bostic@gmail.com>
On Thu, Jan 12, 2017 at 04:37:35PM -0600, christopher.lee.bostic at gmail.com wrote:
> From: Chris Bostic <cbostic@us.ibm.com>
>
> Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
I can not accept patches that have no changelog text, and this one is
very odd:
> ---
> drivers/fsi/fsi-core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
> index 28b82d1..db09836 100644
> --- a/drivers/fsi/fsi-core.c
> +++ b/drivers/fsi/fsi-core.c
> @@ -42,6 +42,7 @@
>
> static DEFINE_IDA(master_ida);
>
> +
Huh?
Did something go wrong with your scripts?
greg k-h
^ 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