On Tuesday 20 April 2021 12:01:10 Marc Zyngier wrote:
> On Tue, 20 Apr 2021 10:44:02 +0100,
> Pali Rohár wrote:
> >
> > Hello!
> >
> > On Tuesday 20 April 2021 14:17:21 Jianjun Wang wrote:
> > > +static void mtk_pcie_enable_msi(struct mtk_pcie_port *port)
Hello!
On Tuesday 20 April 2021 14:17:21 Jianjun Wang wrote:
> +static void mtk_pcie_enable_msi(struct mtk_pcie_port *port)
> +{
> + int i;
> + u32 val;
> +
> + for (i = 0; i < PCIE_MSI_SET_NUM; i++) {
> + struct mtk_msi_set *msi_set = >msi_sets[i];
> +
> +
On Saturday 17 April 2021 17:19:38 Andrew Lunn wrote:
> > Currently this code is implemented in pci_bus_find_domain_nr() function.
> > IIRC domain number is 16bit integer, so plain bitmap would consume 8 kB
> > of memory. I'm not sure if it is fine or some other tree-based structure
> > for
On Thursday 15 April 2021 10:13:17 Rob Herring wrote:
> On Thu, Apr 15, 2021 at 3:45 AM Marek Behun wrote:
> >
> > On Thu, 15 Apr 2021 10:36:40 +0200
> > Pali Rohár wrote:
> >
> > > On Tuesday 13 April 2021 13:17:29 Rob Herring wrote:
> > > > O
On Wednesday 14 April 2021 16:20:51 bpe...@marvell.com wrote:
> From: Ben Peled
>
> In PCIE ISR routine caused by RST_LINK_DOWN
> we schedule work to handle the link-down procedure.
> Link-down procedure will:
> 1. Remove PCIe bus
> 2. Reset the MAC
> 3. Reconfigure link back up
> 4. Rescan PCIe
Hello!
On Thursday 15 April 2021 13:01:19 Alex Williamson wrote:
> [cc +Pali]
>
> On Thu, 15 Apr 2021 20:02:23 +0200
> Ingmar Klein wrote:
>
> > First thanks to you both, Alex and Bjorn!
> > I am in no way an expert on this topic, so I have to fully rely on your
> > feedback, concerning this
On Tuesday 13 April 2021 13:17:29 Rob Herring wrote:
> On Mon, Apr 12, 2021 at 7:41 AM Pali Rohár wrote:
> >
> > Since commit 526a76991b7b ("PCI: aardvark: Implement driver 'remove'
> > function and allow to build it as module") PCIe controller driver for
> >
On Wednesday 14 April 2021 15:23:09 Bjorn Helgaas wrote:
> On Tue, Apr 13, 2021 at 10:39:16AM +0200, Pali Rohár wrote:
> > On Monday 12 April 2021 14:27:40 Bjorn Helgaas wrote:
> > > On Mon, Apr 12, 2021 at 02:46:02PM +0200, Pali Rohár wrote:
> > > > Define new P
On Monday 12 April 2021 14:27:40 Bjorn Helgaas wrote:
> On Mon, Apr 12, 2021 at 02:46:02PM +0200, Pali Rohár wrote:
> > Define new PCI_EXP_DEVCTL_PAYLOAD_* macros in linux/pci_regs.h header file
> > for Max Payload Size. Macros are defined in the same style as exis
y] (irq=63)
Signed-off-by: Pali Rohár
BugLink: https://github.com/globalscaletechnologies/linux/issues/1
Fixes: fee2d546414d ("net: phy: marvell: mv88e6390 temperature sensor reading")
Reviewed-by: Marek Behún
---
Changes since v1:
* create direct mapping table between family and prod
On Monday 12 April 2021 18:12:35 Andrew Lunn wrote:
> On Mon, Apr 12, 2021 at 05:52:39PM +0200, Pali Rohár wrote:
> > On Monday 12 April 2021 17:32:33 Andrew Lunn wrote:
> > > > Anyway, now I'm looking at phy/marvell.c driver again and it supports
> > > > only
On Monday 12 April 2021 17:32:33 Andrew Lunn wrote:
> > Anyway, now I'm looking at phy/marvell.c driver again and it supports
> > only 88E6341 and 88E6390 families from whole 88E63xxx range.
> >
> > So do we need to define for now table for more than
> > MV88E6XXX_FAMILY_6341 and
On Monday 12 April 2021 16:44:11 Andrew Lunn wrote:
> On Mon, Apr 12, 2021 at 03:34:47PM +0200, Pali Rohár wrote:
> > On Monday 12 April 2021 15:15:07 Andrew Lunn wrote:
> > > > +static u16 mv88e6xxx_physid_for_family(enum mv88e6xxx_family family);
> > > > +
&g
On Monday 12 April 2021 16:30:03 Andrew Lunn wrote:
> > > > +/* This table contains representative model for every family */
> > > > +static const enum mv88e6xxx_model family_model_table[] = {
> > > > + [MV88E6XXX_FAMILY_6095] = MV88E6095,
> > > > + [MV88E6XXX_FAMILY_6097] = MV88E6097,
On Monday 12 April 2021 15:15:07 Andrew Lunn wrote:
> > +static u16 mv88e6xxx_physid_for_family(enum mv88e6xxx_family family);
> > +
>
> No forward declaration please. Move the code around. It is often best
> to do that in a patch which just moves code, no other changes. It
> makes it easier to
Define new PCI_EXP_DEVCTL_PAYLOAD_* macros in linux/pci_regs.h header file
for Max Payload Size. Macros are defined in the same style as existing
macros PCI_EXP_DEVCTL_READRQ_* macros.
Signed-off-by: Pali Rohár
---
include/uapi/linux/pci_regs.h | 6 ++
1 file changed, 6 insertions(+)
diff
ted unbind and bind operations.
Signed-off-by: Pali Rohár
Fixes: 526a76991b7b ("PCI: aardvark: Implement driver 'remove' function and
allow to build it as module")
---
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/marv
mily] (irq=63)
Signed-off-by: Pali Rohár
BugLink: https://github.com/globalscaletechnologies/linux/issues/1
Fixes: fee2d546414d ("net: phy: marvell: mv88e6390 temperature sensor reading")
Reviewed-by: Marek Behún
---
drivers/net/dsa/mv88e6xxx/chip.c | 56 ++---
On Sunday 11 April 2021 11:57:41 Sebastian Oechsle wrote:
> Allow manual PWM control on Dell Latitude E7440.
>
> Signed-off-by: Sebastian Oechsle
Reviewed-by: Pali Rohár
>
> Changes in v2:
> - Fix spelling
> - Fix format
> ---
> drivers/hwmon/dell-smm-hwmon.c | 8
On Wednesday 07 April 2021 16:25:46 Petr Štetiar wrote:
> Pali Rohár [2020-10-07 10:12:27]:
>
> Hi,
>
> [adding Koen to Cc:]
>
> > I'm hitting these race conditions randomly on pci aardvark controller
> > driver- I prepared patch which speed up initializatio
On Thursday 16 July 2020 13:04:23 Pali Rohár wrote:
> Hello Bjorn!
>
> I see following error message in dmesg which looks like a race condition:
>
> sysfs: cannot create duplicate filename
> '/devices/platform/soc/d007.pcie/pci:00/:00:00.0/config'
>
&g
led
[ 45.579924] CPU features: 0x00040002,200c
[ 45.584416] Memory Limit: none
[ 45.587564] Rebooting in 3 seconds..
Signed-off-by: Pali Rohár
Cc: sta...@vger.kernel.org
---
drivers/net/wireless/ath/ath9k/main.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/
On Thursday 01 April 2021 01:51:28 Hermes Zhang wrote:
> On 3/31/21 10:02 PM, Pali Rohár wrote:
> > @@ -1655,9 +1655,6 @@ static int bq27xxx_battery_read_time(struct
> > bq27xxx_device_info *di, u8 reg)
> > return tval;
> > }
> >
> > - if
On Wednesday 31 March 2021 21:51:41 Hermes Zhang wrote:
> From: Hermes Zhang
>
> It might be better to return value (e.g. 65535) instead of an error
> (e.g. No data available) for the time property.
>
> Normally a common function will handle the read string and parse to
> integer for all the
On Tuesday 30 March 2021 19:02:55 Sebastian Oechsle wrote:
> Allow manual PWM control on Dell Latitude 7440.
>
> Signed-off-by: Sebastian Oechsle <mailto:setbool...@icloud.com>>
Reviewed-by: Pali Rohár
(Btw, in commit message is small typo, model name is E7440, not 7440)
On Tuesday 30 March 2021 16:34:47 Maciej W. Rozycki wrote:
> On Tue, 30 Mar 2021, Pali Rohár wrote:
>
> > > If I were to implement this stuff, for good measure I'd give it a safety
> > > margin beyond what the spec requires and use a timeout of say 2-4s while
> >
On Tuesday 30 March 2021 15:04:02 Maciej W. Rozycki wrote:
> On Thu, 25 Mar 2021, David Laight wrote:
>
> > I can't see the value in the (nice bound) copy of the PCI 2.0 spec I have.
> > But IIRC it is 100ms (it might just me 500ms).
> > While this might seem like ages it can be problematic if
On Thursday 18 March 2021 13:48:07 Jianjun Wang wrote:
> On Thu, 2021-03-18 at 01:02 +0100, Pali Rohár wrote:
> > On Saturday 13 March 2021 15:43:14 Jianjun Wang wrote:
> > > On Thu, 2021-03-11 at 13:38 +0100, Pali Rohár wrote:
> > > > On Wednesday 24 February 20
On Friday 26 March 2021 11:43:10 Don Bollinger wrote:
> > Hello Don!
> >
> > I have read whole discussion and your EEPROM patch proposal. But for me it
> > looks like some kernel glue code for some old legacy / proprietary access
> > method which does not have any usage outside of that old code.
On Friday 12 March 2021 10:12:06 Gregory CLEMENT wrote:
> Hello Pali,
>
> > Hello Gregory!
> >
> > Patches are the for almost two months and more people have tested them.
> > They are marked with Fixed/CC-stable tags, they should go also into
> > stable trees as they are fixing CPU scaling and
On Saturday 27 March 2021 19:44:30 Marc Zyngier wrote:
> On Sat, 27 Mar 2021 19:28:37 +,
> Pali Rohár wrote:
> >
> > On Wednesday 24 March 2021 11:05:08 Jianjun Wang wrote:
> > > +static void mtk_pcie_msi_handler(struct mtk_pcie_port *port, int set_idx)
> >
On Wednesday 24 March 2021 11:05:08 Jianjun Wang wrote:
> +static void mtk_pcie_msi_handler(struct mtk_pcie_port *port, int set_idx)
> +{
> + struct mtk_msi_set *msi_set = >msi_sets[set_idx];
> + unsigned long msi_enable, msi_status;
> + unsigned int virq;
> + irq_hw_number_t bit,
On Saturday 27 March 2021 15:42:13 Marek Behún wrote:
> On Sat, 27 Mar 2021 14:29:59 +0100
> Pali Rohár wrote:
>
> > I can change this to 'if (!ret)' if needed, no problem.
> >
> > I use 'if (!val)' mostly for boolean and pointer variables. If
> > variable can c
Hello!
On Saturday 27 March 2021 01:14:10 Krzysztof Wilczyński wrote:
> Hi Pali,
>
> Thank you for sending the patch over!
>
> [...]
> > +static int pcie_change_tls_to_gen1(struct pci_dev *parent)
>
> Just a nitpick, so feel free to ignore it. I would just call the
> variable "dev" as we pass
SPM kernel code triggers this PCI_EXP_LNKCTL_RL bit,
so quirk check is added only into pcie/aspm.c file.
Signed-off-by: Pali Rohár
Reported-by: Toke Høiland-Jørgensen
Tested-by: Marek Behún
Link: https://lore.kernel.org/linux-pci/87h7l8axqp@toke.dk/
Cc: sta...@vger.kernel.org # c80851f6ce63a
On Wednesday 24 March 2021 11:05:05 Jianjun Wang wrote:
> This interface will be used by PCI host drivers for PIO translation,
> export it to support compiling those drivers as kernel modules.
>
> Signed-off-by: Jianjun Wang
> ---
> drivers/pci/pci.c | 1 +
> 1 file changed, 1 insertion(+)
>
>
On Tuesday 23 March 2021 10:20:27 Florian Fainelli wrote:
> On 3/15/2021 2:50 AM, Pali Rohár wrote:
> > On Friday 12 March 2021 12:54:18 Alexander Lobakin wrote:
> >> From: Florian Fainelli
> >> Date: Thu, 11 Mar 2021 09:41:27 -0800
> >>
> >> Hi Fl
On Tuesday 23 March 2021 21:49:41 Amey Narkhede wrote:
> On 21/03/10 12:05PM, Pali Rohár wrote:
> > Hello!
> >
> > I would like to open a question about PCIe Warm Reset. Warm Reset of
> > PCIe card is triggered by asserting PERST# signal and in most cases
> > PE
On Tuesday 23 March 2021 09:31:34 Jianjun Wang wrote:
> One more question, is there any chance that we can put this linkup flow
> to a more "standard" way, such as drivers provides the ops of the PERST#
> pin and let the framework to decide how to start a link training, or we
> just use macro to
On Thursday 18 March 2021 20:01:55 Amey Narkhede wrote:
> On 21/03/17 09:13PM, Pali Rohár wrote:
> > On Wednesday 17 March 2021 14:00:20 Alex Williamson wrote:
> > > On Wed, 17 Mar 2021 20:40:24 +0100
> > > Pali Rohár wrote:
> > >
> > > > On Wednes
Hello Don!
I have read whole discussion and your EEPROM patch proposal. But for me
it looks like some kernel glue code for some old legacy / proprietary
access method which does not have any usage outside of that old code.
Your code does not contain any quirks which are needed to read different
On Thursday 18 March 2021 13:48:07 Jianjun Wang wrote:
> On Thu, 2021-03-18 at 01:02 +0100, Pali Rohár wrote:
> > On Saturday 13 March 2021 15:43:14 Jianjun Wang wrote:
> > > On Thu, 2021-03-11 at 13:38 +0100, Pali Rohár wrote:
> > > > On Wednesday 24 February 20
On Saturday 13 March 2021 15:43:14 Jianjun Wang wrote:
> On Thu, 2021-03-11 at 13:38 +0100, Pali Rohár wrote:
> > On Wednesday 24 February 2021 14:11:28 Jianjun Wang wrote:
> > > +static int mtk_pcie_startup_port(struct mtk_pcie_port *port)
> > > +{
> > ...
>
On Wednesday 17 March 2021 14:00:20 Alex Williamson wrote:
> On Wed, 17 Mar 2021 20:40:24 +0100
> Pali Rohár wrote:
>
> > On Wednesday 17 March 2021 13:32:45 Alex Williamson wrote:
> > > On Wed, 17 Mar 2021 20:24:24 +0100
> > > Pali Rohár wrote:
> > >
On Wednesday 17 March 2021 13:32:45 Alex Williamson wrote:
> On Wed, 17 Mar 2021 20:24:24 +0100
> Pali Rohár wrote:
>
> > On Wednesday 17 March 2021 13:15:36 Alex Williamson wrote:
> > > On Wed, 17 Mar 2021 20:02:06 +0100
> > > Pali Rohár wrote:
> > >
On Wednesday 17 March 2021 13:15:36 Alex Williamson wrote:
> On Wed, 17 Mar 2021 20:02:06 +0100
> Pali Rohár wrote:
>
> > On Monday 15 March 2021 09:03:39 Alex Williamson wrote:
> > > On Mon, 15 Mar 2021 15:52:38 +0100
> > > Pali Rohár wrote:
> > >
On Monday 15 March 2021 09:03:39 Alex Williamson wrote:
> On Mon, 15 Mar 2021 15:52:38 +0100
> Pali Rohár wrote:
>
> > On Monday 15 March 2021 08:34:09 Alex Williamson wrote:
> > > On Mon, 15 Mar 2021 14:52:26 +0100
> > > Pali Rohár wrote:
> > >
>
On Wednesday 17 March 2021 14:48:44 Sebastian Reichel wrote:
> Convert the binding to DT schema format.
>
> Cc: Pali Rohár
Rejected-by: Pali Rohár
> Signed-off-by: Sebastian Reichel
Hello Sebastian! I'm really really sorry, I have nothing against you,
but personally I canno
On Monday 15 March 2021 08:34:09 Alex Williamson wrote:
> On Mon, 15 Mar 2021 14:52:26 +0100
> Pali Rohár wrote:
>
> > On Monday 15 March 2021 19:13:23 Amey Narkhede wrote:
> > > slot reset (pci_dev_reset_slot_function) and secondary bus
> > > reset(pci_parent
On Monday 15 March 2021 19:13:23 Amey Narkhede wrote:
> slot reset (pci_dev_reset_slot_function) and secondary bus
> reset(pci_parent_bus_reset) which I think are hot reset and
> warm reset respectively.
No. PCI secondary bus reset = PCIe Hot Reset. Slot reset is just another
type of reset, which
On Friday 12 March 2021 12:54:18 Alexander Lobakin wrote:
> From: Florian Fainelli
> Date: Thu, 11 Mar 2021 09:41:27 -0800
>
> Hi Florian,
>
> > On 3/11/21 9:40 AM, Greg KH wrote:
> > > On Thu, Mar 11, 2021 at 09:23:56AM -0800, Florian Fainelli wrote:
> > >> On 3/11/21 5:08 AM, Greg KH wrote:
>
On Friday 12 March 2021 23:04:52 ameynarkhed...@gmail.com wrote:
> From: Amey Narkhede
>
> Add reset_methods_enabled bitmap to struct pci_dev to
> keep track of user preferred device reset mechanisms.
> Add reset_method sysfs attribute to query and set
> user preferred device reset mechanisms.
>
On Friday 12 March 2021 23:04:51 ameynarkhed...@gmail.com wrote:
> From: Amey Narkhede
>
> reset_fn field is used to indicate whether the
> device supports any reset mechanism or not.
> Deprecate use of reset_fn in favor of new
> reset_methods bitmap which can be used to keep
> track of all
On Friday 12 March 2021 23:04:50 ameynarkhed...@gmail.com wrote:
> From: Amey Narkhede
>
> Introduce a new bitmap reset_methods in struct pci_dev
> to keep track of reset mechanisms supported by the
> device. Also refactor probing and reset functions
> to take advantage of calling convention of
On Thursday 11 March 2021 19:53:26 Vidya Sagar wrote:
> On 3/3/2021 11:26 PM, Pali Rohár wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Tuesday 02 March 2021 12:58:29 Alex Williamson wrote:
> > > On Mon, 1 Mar 2021 14:28
On Wednesday 24 February 2021 14:11:28 Jianjun Wang wrote:
> +static int mtk_pcie_startup_port(struct mtk_pcie_port *port)
> +{
...
> +
> + /* Delay 100ms to wait the reference clocks become stable */
> + msleep(100);
> +
> + /* De-assert PERST# signal */
> + val &= ~PCIE_PE_RSTB;
On Wednesday 24 February 2021 14:11:30 Jianjun Wang wrote:
> +static int mtk_msi_bottom_domain_alloc(struct irq_domain *domain,
> +unsigned int virq, unsigned int nr_irqs,
> +void *arg)
> +{
> + struct mtk_pcie_port *port
Hello!
I would like to open a question about PCIe Warm Reset. Warm Reset of
PCIe card is triggered by asserting PERST# signal and in most cases
PERST# signal is controlled by GPIO.
Basically every native Linux PCIe controller driver is doing this Warm
Reset of connected PCIe card during native
On Thursday 04 March 2021 17:33:01 Sasha Levin wrote:
> On Thu, Feb 25, 2021 at 08:03:06PM +0100, Pali Rohár wrote:
> > On Wednesday 24 February 2021 07:49:34 Sasha Levin wrote:
> > > From: Pali Rohár
> > >
> > > [ Upstream commit f0b4f847673299577c29b
On Tuesday 02 March 2021 12:58:29 Alex Williamson wrote:
> On Mon, 1 Mar 2021 14:28:17 -0600
> Bjorn Helgaas wrote:
>
> > [+cc Alex, reset expert]
> >
> > On Mon, Mar 01, 2021 at 06:12:21PM +0100, Pali Rohár wrote:
> > > Hello!
> > >
> > &g
IRQ domain alloc function should return zero on success. Non-zero value
indicates failure.
Signed-off-by: Pali Rohár
Fixes: fc54bae28818 ("PCI: iproc: Allow allocation of multiple MSIs")
---
drivers/pci/controller/pcie-iproc-msi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
them for upcoming Linux version?
On Monday 22 February 2021 20:41:48 Pali Rohár wrote:
> Hello!
>
> This is third version of patches for Armada 37xx cpufreq driver which
> fix CPU scaling with 1 GHz base frequency.
>
> The only change in this third version is modified patc
Hello!
PCIe card can be reset via in-band Hot Reset signal which can be
triggered by PCIe bridge via Secondary Bus Reset bit in PCI config
space.
Kernel already exports sysfs node "reset" for triggering Functional
Reset of particular function of PCI device. But in some cases Functional
Reset is
On Wednesday 24 February 2021 07:49:34 Sasha Levin wrote:
> From: Pali Rohár
>
> [ Upstream commit f0b4f847673299577c29b71d3f3acd3c313d81b7 ]
Hello! This commit requires also commit~1 from that patch series:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/c
On Tuesday 23 February 2021 15:49:46 Andreas Kemnade wrote:
> On Tue, 23 Feb 2021 15:11:20 +0100
> Matthias Schiffer wrote:
>
> > Commit cd060b4d0868 ("power: supply: bq27xxx: fix polarity of current_now")
> > changed the sign of current_now for all bq27xxx variants, but on BQ28Z610
> > I'm now
This driver is missing module_exit hook. Add proper driver exit function
which unregisters the platform device and cleans up the data.
Signed-off-by: Pali Rohár
Tested-by: Tomasz Maciej Nowak
Tested-by: Anders Trier Olesen
Tested-by: Philip Soares
---
drivers/cpufreq/armada-37xx-cpufreq.c
ation for opp"), but only for calculating
CPU frequency for opp.
Fix this also for determination of base CPU frequency.
Signed-off-by: Pali Rohár
Tested-by: Tomasz Maciej Nowak
Tested-by: Anders Trier Olesen
Tested-by: Philip Soares
Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for A
tion fails.
This fixes the issue by using the same frequency in both calls.
Signed-off-by: Pali Rohár
Tested-by: Tomasz Maciej Nowak
Tested-by: Anders Trier Olesen
Tested-by: Philip Soares
Fixes: 8db82563451f ("cpufreq: armada-37xx: fix frequency calculation for opp")
Cc: sta...@vger.ker
reproduced with userspace governor. In most cases it causes CPU
to crash.
This change fixes the above issue and ensures that the CPU always stays in
L1 for at least 20ms when switching from any state to L0.
Signed-off-by: Marek Behún
Signed-off-by: Pali Rohár
Acked-by: Stephen Boyd
Tested
Variable cur_frequency in armada37xx_cpufreq_driver_init() is unused.
Signed-off-by: Pali Rohár
Tested-by: Tomasz Maciej Nowak
Tested-by: Anders Trier Olesen
Tested-by: Philip Soares
---
drivers/cpufreq/armada-37xx-cpufreq.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions
2 (250 MHz) to L0 (1 GHz) causes a crash.
When base CPU frequency is just 800 MHz no crashed were observed during
switch from L2 to L0.
Signed-off-by: Pali Rohár
Acked-by: Stephen Boyd
Tested-by: Tomasz Maciej Nowak
Tested-by: Anders Trier Olesen
Tested-by: Philip Soares
Fixes: 2089dc33ea0e (&
.
Signed-off-by: Marek Behún
Acked-by: Stephen Boyd
Tested-by: Pali Rohár
Tested-by: Tomasz Maciej Nowak
Tested-by: Anders Trier Olesen
Tested-by: Philip Soares
Fixes: 2089dc33ea0e ("clk: mvebu: armada-37xx-periph: add DVFS support for cpu
clocks")
---
drivers/clk/mvebu/armada-37x
ation of CPU TBG
index cannot be done via the common clock framework, therefore we need
to access the North Bridge Peripheral Clock registers directly in this
driver.
[1] https://github.com/wtarreau/mhz
Signed-off-by: Marek Behún
Tested-by: Pali Rohár
Tested-by: Tomasz Maciej Nowak
Tested-by: And
://forum.armbian.com/topic/10429-how-to-make-espressobin-v7-stable/
Signed-off-by: Pali Rohár
Tested-by: Tomasz Maciej Nowak
Tested-by: Anders Trier Olesen
Tested-by: Philip Soares
Fixes: 1c3528232f4b ("cpufreq: armada-37xx: Add AVS support")
Cc: sta...@vger.kernel.org
---
drivers/cpufreq/armada-37xx
riph: remove .set_parent method for CPU PM
clock
Pali Rohár (7):
cpufreq: armada-37xx: Fix the AVS value for load L1
clk: mvebu: armada-37xx-periph: Fix switching CPU freq from 250 Mhz to
1 GHz
clk: mvebu: armada-37xx-periph: Fix workaround for switching from L1
to L0
cpufreq: ar
From: Marek Behún
Add "syscon" compatible to the North Bridge clocks node to allow the
cpufreq driver to access these registers via syscon API.
This is needed for a fix of cpufreq driver.
Signed-off-by: Marek Behún
Tested-by: Pali Rohár
Tested-by: Tomasz Maciej Nowak
Tested-by: An
On Sunday 21 February 2021 19:17:40 nnet wrote:
> > Could you test if 1.155V voltage for L1 is stable on 1.2 GHz variant?
>
> ++#define MIN_VOLT_MV_FOR_L1_1200MHZ 1155
> ...
> ++ if (avs_min_l1 > dvfs->avs[0])
> ++ avs_min_l1 = dvfs->avs[0];
> ++
> ++
On Monday 22 February 2021 00:07:40 Randy Dunlap wrote:
> On 2/21/21 11:54 PM, Bhaskar Chowdhury wrote:
> >
> > s/postive/positive/
> >
> > Signed-off-by: Bhaskar Chowdhury
>
> Acked-by: Randy Dunlap
Reviewed-by: Pali Rohár
> > ---
> > drivers/
> This one has gone away.
...
> --- a/Documentation/arm/marvell.rst
> +++ b/Documentation/arm/marvell.rst
> @@ -399,7 +399,6 @@ Berlin family (Multimedia Solutions)
>- Flavors:
> - 88DE3010, Armada 1000 (no Linux support)
> - Core: Marvell PJ1 (ARMv5TE), Dual-core
>
On Tuesday 16 February 2021 08:27:10 nnet wrote:
> > Therefore I'm thinking if the correct way is instead to use L1 := L0
> > voltage value for 1/1.2 GHz mode.
>
> This latest 04/10 works fine for me going 600MHz <-> 1.2GHz under with and
> without load.
Ok, thanks for testing! Just to note
On Monday 15 February 2021 21:48:08 nnet wrote:
> > Could you test following change instead of PATCH 04/10? I added here also
> > logic for 1.2 GHz variant with 1.132 V value another change is that
> > value for load L0 is not touched as it is stable.
>
> These changes to patch 04/10 worked going
> According to Errata #23 "The per-CPU GbE interrupt is limited to Core
> 0", we can't use the per-cpu interrupt mechanism on the Armada 3700
> familly.
>
> This is correctly checked for RSS configuration, but the initial queue
> mapping is still done by having the queues spread across all the
On Saturday 13 February 2021 10:30:19 nnet wrote:
> On Sat, Feb 13, 2021, at 2:01 AM, Pali Rohár wrote:
> > On Thursday 11 February 2021 16:41:13 nnet wrote:
> > > On Thu, Feb 11, 2021, at 3:44 PM, Pali Rohár wrote:
> > > > On Thursday 11 February 2021 12:22:52 nnet w
On Thursday 11 February 2021 16:41:13 nnet wrote:
> On Thu, Feb 11, 2021, at 3:44 PM, Pali Rohár wrote:
> > On Thursday 11 February 2021 12:22:52 nnet wrote:
> > > On Thu, Feb 11, 2021, at 11:55 AM, Pali Rohár wrote:
> > > > On Wednesday 10 February 2021 11:08:59 nne
On Thursday 11 February 2021 12:22:52 nnet wrote:
> On Thu, Feb 11, 2021, at 11:55 AM, Pali Rohár wrote:
> > On Wednesday 10 February 2021 11:08:59 nnet wrote:
> > > On Wed, Feb 10, 2021, at 10:03 AM, Pali Rohár wrote:
> > > > > > Hello! Could you please ena
On Wednesday 10 February 2021 16:09:42 kos...@marvell.com wrote:
> From: Grzegorz Jaszczyk
>
> Adding phy description to pcie, sata and usb will allow appropriate drivers
> to configure marvell comphy-a3700 accordingly.
>
> Signed-off-by: Grzegorz Jaszczyk
> Signed-off-by: Konstantin
On Wednesday 10 February 2021 16:09:43 kos...@marvell.com wrote:
> From: Grzegorz Jaszczyk
>
> Add "phys" entries pointing to COMPHYs to PCIe and USB3 nodes
>
> Signed-off-by: Grzegorz Jaszczyk
> Signed-off-by: Konstantin Porotchkin
Hello! This patch is not needed and now does nothing.
>
On Wednesday 10 February 2021 11:08:59 nnet wrote:
> On Wed, Feb 10, 2021, at 10:03 AM, Pali Rohár wrote:
> > > > Hello! Could you please enable userspace governor during kernel
> > > > compilation?
> > > >
> > > > CONFIG_CPU_FREQ_GOV_U
On Wednesday 10 February 2021 09:34:07 nnet wrote:
> On Wed, Feb 10, 2021, at 1:23 AM, Pali Rohár wrote:
> > On Tuesday 09 February 2021 18:07:41 nnet wrote:
> > > On Tue, Feb 9, 2021, at 5:51 PM, nnet wrote:
> > > > On Tue, Feb 9, 2021, at 5:31 PM, nnet wrote:
>
On Tuesday 09 February 2021 18:07:41 nnet wrote:
> On Tue, Feb 9, 2021, at 5:51 PM, nnet wrote:
> > On Tue, Feb 9, 2021, at 5:31 PM, nnet wrote:
> > > On Tue, Feb 9, 2021, at 3:26 PM, Marek Behún wrote:
> > > > On Tue, 09 Feb 2021 15:16:45 -0800
> > > > nnet wrote:
> > > >
> > > > > I've two of
On Tuesday 09 February 2021 14:52:56 nnet wrote:
> On Tue, Feb 9, 2021, at 2:42 PM, Pali Rohár wrote:
> > On Tuesday 09 February 2021 13:45:08 nnet wrote:
> > > On Tue, Feb 9, 2021, at 1:33 PM, Pali Rohár wrote:
> > > > On Tuesday 09 February 2021 13:00:26 nnet wrote:
On Tuesday 09 February 2021 13:45:08 nnet wrote:
> On Tue, Feb 9, 2021, at 1:33 PM, Pali Rohár wrote:
> > On Tuesday 09 February 2021 13:00:26 nnet wrote:
> > > > If you have other Armada 3720 boards (Espressobin v5/v7, uDPU, Devel
> > > > Board, ...) then it
On Tuesday 09 February 2021 13:00:26 nnet wrote:
> > If you have other Armada 3720 boards (Espressobin v5/v7, uDPU, Devel Board,
> > ...) then it will be nice to do an additional tests and check if
> > instability issues are finally fixed.
>
> These patches applied to the 5.4.96 in OpenWrt
On Friday 05 February 2021 10:59:50 Daniel Vetter wrote:
> On Thu, Feb 4, 2021 at 11:24 PM Pali Rohár wrote:
> >
> > On Thursday 04 February 2021 15:50:19 Bjorn Helgaas wrote:
> > > [+cc Oliver, Pali, Krzysztof]
> >
> > Just to note that extending or using sysf
On Friday 05 February 2021 11:16:00 Daniel Vetter wrote:
> On Fri, Feb 5, 2021 at 11:04 AM Pali Rohár wrote:
> >
> > On Friday 05 February 2021 10:59:50 Daniel Vetter wrote:
> > > On Thu, Feb 4, 2021 at 11:24 PM Pali Rohár wrote:
> > > >
> > >
On Thursday 04 February 2021 15:50:19 Bjorn Helgaas wrote:
> [+cc Oliver, Pali, Krzysztof]
Just to note that extending or using sysfs_initialized introduces
another race condition into kernel code which results in PCI fatal
errors. Details are in email discussion which Bjorn already sent.
>
On Tuesday 26 January 2021 10:06:06 Pali Rohár wrote:
> On Tuesday 26 January 2021 04:27:37 Yoshihiro Shimoda wrote:
> > Hi Pali,
> > > > I can see the benefit in this.
> > > > In the xhci-plat case usb_create_hcd and usb_add_hcd are separate
> > &g
rusted Firmware without SMC call for USB 3.0 phy power.
This is regression introduced in commit bd3d25b07342 ("arm64: dts: marvell:
armada-37xx: link USB hosts with their PHYs") where USB 3.0 phy was defined
and therefore xhci-hcd on Espressobin with older ATF started failing.
Signed-of
On Saturday 30 January 2021 17:31:41 Tomasz Maciej Nowak wrote:
> W dniu 23.12.2020 o 17:24, Pali Rohár pisze:
> > Older ATF does not provide SMC call for USB 3.0 phy power on functionality
> > and therefore initialization of xhci-hcd is failing when older version of
> > ATF
On Monday 25 January 2021 21:21:30 Pali Rohár wrote:
> On Monday 25 January 2021 12:19:38 Guenter Roeck wrote:
> > On Mon, Jan 25, 2021 at 11:05:40AM +0100, Pali Rohár wrote:
> > > On Saturday 23 January 2021 18:46:08 Thomas Hebb wrote:
> > > > It has been reported
1 - 100 of 4324 matches
Mail list logo
