Hi, Daniel
> Subject: Re: [PATCH V4 0/9] Support i.MX8 SoCs pinctrl drivers built as module
>
> Hi Anson,
>
> Patch series mostly looks good to me. I have a comment about adding
>
> the MODULE_LICENSE. This is a pretty important change.
>
>
> Can you please add this change in a separate
Maybe this is obvious but I would really like to see an explanation
of why we are switching from arch_initcall to platform_init.
Commit message act as documentation for the reviewers.
On 10.06.2020 10:57, Anson Huang wrote:
Support building i.MX8MN pinctrl driver as module.
Signed-off-by:
On Wed, Jun 10, 2020 at 08:01:18PM +0200, Alexandre Belloni wrote:
> My point was that if we were to keep that driver, the goal would be to
> have it out of staging instead of simply making it compile.
Yes, definitely - that should be the goal for anything in staging.
signature.asc
…
> +++ b/fs/exfat/namei.c
> @@ -1077,10 +1077,14 @@ static int exfat_rename_file(struct inode *inode,
> struct exfat_chain *p_dir,
>
> epold = exfat_get_dentry(sb, p_dir, oldentry + 1, _bh,
> _old);
> + if (!epold)
> + return
On Wed, Jun 10, 2020 at 09:45:55PM -0500, Jassi Brar wrote:
> On Wed, Jun 10, 2020 at 10:56 AM Sudeep Holla wrote:
>
> [I admit you can write bigger posts than me, so I am not going to
> write a passionate response to each of your paragraphs.
> Let's keep it to the point.]
>
> > > > > if
On Wed, Jun 10, 2020 at 04:58:23PM -0700, Ian Rogers wrote:
> These are broadly useful but required to handle TMA metrics. For
> example encoding Ports_Utilization from:
> https://download.01.org/perfmon/TMA_Metrics.csv
> requires '<'.
>
> {
> "BriefDescription": "This metric estimates fraction
Hi Linus,
This is the update of the pull I sent earlier today, it's got a couple
of more fixes along with the i915 fixes. One sun4i fix and a connector
hotplug race The ast fix is for a regression in 5.6, and as mentioned
previously one of the i915 ones fixes an oops reported by dhowells.
On Wed, Jun 10, 2020 at 04:58:22PM -0700, Ian Rogers wrote:
> d_ratio avoids division by 0 yielding infinity, such as when a counter
> doesn't get scheduled. An example usage is:
>
> {
> "BriefDescription": "DCache L1 misses",
> "MetricExpr": "d_ratio(MEM_LOAD_RETIRED.L1_MISS,
Fix typo: "Tigger" --> "Trigger"
Signed-off-by: Flavio Suligoi
Reviewed-by: Alexander Dahl
---
drivers/leds/led-triggers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index 79e30d2cb7a5..0836bf7631ea 100644
---
Hi Andy,
Thank you so much for the review comments...
On 11/6/2020 4:12 pm, Andy Shevchenko wrote:
On Thu, Jun 11, 2020 at 10:12:46AM +0800, Ramuthevar,Vadivel MuruganX wrote:
From: Ramuthevar Vadivel Murugan
Add support for USB PHY on Intel LGM SoC.
...
+static int get_flipped(struct
Hi Anson,
Patch series mostly looks good to me. I have a comment about adding
the MODULE_LICENSE. This is a pretty important change.
Can you please add this change in a separate patch with a proper explanation
of why it is needed.
Most likely it is because it was forgotten in the previous
On Thu, Jun 11, 2020 at 09:30:12AM +0200, Thomas Hellström (Intel) wrote:
>
> On 6/4/20 10:12 AM, Daniel Vetter wrote:
> > Two in one go:
> > - it is allowed to call dma_fence_wait() while holding a
> >dma_resv_lock(). This is fundamental to how eviction works with ttm,
> >so required.
>
On Thu, Jun 11, 2020 at 10:25:30AM +0200, Lukas Wunner wrote:
> [cc += Heiko]
>
> On Wed, Jun 10, 2020 at 05:51:21PM +0200, Johan Hovold wrote:
> > Drop the recently added gpio include from the serial-core header in
> > favour of a forward declaration and instead include the gpio header only
> >
On 11. 06. 20, 10:30, SeongJae Park wrote:
> For example, as it seems at least you and I agree on the f-word to hug
> replacement, we could add ``fuck||hug`` in the `deprecated_terms.txt` file to
> avoid future spread of the f-words.
You will likely get my ACK on that, if that helps.
thanks,
--
Sean Christopherson writes:
>
> I'd also be in favor of changing the return type to a boolean. I think
> you alluded to it earlier, the current semantics are quite confusing as they
> invert the normal "return 0 on success".
Yes, will do a follow-up.
KVM/x86 code has an intertwined mix of:
-
> Subject: RE: [PATCH V3 0/9] Support i.MX8 SoCs pinctrl drivers built as module
>
>
>
>
> > Subject: RE: [PATCH V3 0/9] Support i.MX8 SoCs pinctrl drivers built
> > as module
> >
> > > From: Anson Huang
> > > Sent: Tuesday, June 9, 2020 10:21 PM
> > >
> > > There are more and mroe
On Thu, 11 Jun 2020 10:16:09 +0200 Jiri Slaby wrote:
> On 11. 06. 20, 9:38, SeongJae Park wrote:
> > On Wed, 10 Jun 2020 23:35:24 -0700 Joe Perches wrote:
> >
> >> On Thu, 2020-06-11 at 08:25 +0200, SeongJae Park wrote:
> >>> From: SeongJae Park
> >>>
> >>> This patchset 1) adds support of
On Wed, Jun 10, 2020 at 11:53:24PM +0530, Vaibhav Agarwal wrote:
> With patch#6 in this series, I'm proposing some of the (dummy) helper
> APIs required to link DAPM DAI widgets for the GB Audio modules
> added/removed dynamically.
> Eventually, I would like to propose relevant changes in
Add driver for cros-ec-regulator, representing a voltage regulator that
is connected and controlled by ChromeOS EC, and is controlled by kernel
with EC host commands.
Signed-off-by: Pi-Hsun Shih
---
Changes from v4:
* Change compatible name from regulator-cros-ec to cros-ec-regulator.
Changes
Add DT binding documentation for cros-ec-regulator, a voltage regulator
controlled by ChromeOS EC.
Signed-off-by: Pi-Hsun Shih
---
Changes from v4:
* Change compatible name from regulator-cros-ec to cros-ec-regulator.
Changes from v3:
* Fix dt bindings file name.
* Add full example.
Changes
[cc += Heiko]
On Wed, Jun 10, 2020 at 05:51:21PM +0200, Johan Hovold wrote:
> Drop the recently added gpio include from the serial-core header in
> favour of a forward declaration and instead include the gpio header only
> where needed.
Hm, but why? Are there adverse effects if this is included
Add support for controlling voltage regulator that is connected and
controlled by ChromeOS EC. Kernel controls these regulators through
newly added EC host commands.
Changes from v4:
* Change compatible name from regulator-cros-ec to cros-ec-regulator.
Changes from v3:
* Fix dt bindings file
Hi Peter,
On Wed, Jun 10, 2020 at 5:52 PM Peter Zijlstra wrote:
>
> On Wed, Jun 10, 2020 at 04:35:02PM +0800, kernel test robot wrote:
> > Greeting,
> >
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: b2a02fc43a1f40ef4eb2fb2b06357382608d4d84 ("smp: Optimize
> >
On 11. 06. 20, 9:38, SeongJae Park wrote:
> On Wed, 10 Jun 2020 23:35:24 -0700 Joe Perches wrote:
>
>> On Thu, 2020-06-11 at 08:25 +0200, SeongJae Park wrote:
>>> From: SeongJae Park
>>>
>>> This patchset 1) adds support of deprecated terms in the 'checkpatch.pl'
>>> and 2) set the 'blacklist'
Vivek Goyal writes:
> On Wed, Jun 10, 2020 at 07:55:32PM +0200, Vitaly Kuznetsov wrote:
>> 'Page not present' event may or may not get injected depending on
>> guest's state. If the event wasn't injected, there is no need to
>> inject the corresponding 'page ready' event as the guest may get
>>
Hi Pi-Hsun,
Thank you for the patch, one minor nitpick that in my opinion would be good to
address.
On 11/6/20 10:04, Pi-Hsun Shih wrote:
> Add DT binding documentation for cros-ec-regulator, a voltage regulator
> controlled by ChromeOS EC.
>
> Signed-off-by: Pi-Hsun Shih
> ---
> Changes from
On Thu, Jun 11, 2020 at 10:12:46AM +0800, Ramuthevar,Vadivel MuruganX wrote:
> From: Ramuthevar Vadivel Murugan
>
> Add support for USB PHY on Intel LGM SoC.
...
> +static int get_flipped(struct tca_apb *ta, bool *flipped)
> +{
> + union extcon_property_value property;
> + int ret;
> +
Hi
With Kernel 5.7.0, nouveau drivers 1.0.15-r1
sudo `lshw -C display`
will show me:
*-display UNCLAIMED
Also `xrandr -q` will not work:
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 1680 x 1050, current 1680 x 1050, maximum 1680 x 1050
default connected primary
Hi Sean,
On 2020-06-05 22:38, Sean Christopherson wrote:
This series resurrects Christoffer Dall's series[1] to provide a common
MMU memory cache implementation that can be shared by x86, arm64 and
MIPS.
It also picks up a suggested change from Ben Gardon[2] to clear shadow
page tables
Add DT binding documentation for cros-ec-regulator, a voltage regulator
controlled by ChromeOS EC.
Signed-off-by: Pi-Hsun Shih
---
Changes from v3:
* Fix dt bindings file name.
* Add full example.
Changes from v2:
* No change
Changes from v1:
* Change compatible string to
Add driver for cros-ec-regulator, representing a voltage regulator that
is connected and controlled by ChromeOS EC, and is controlled by kernel
with EC host commands.
Signed-off-by: Pi-Hsun Shih
---
Changes from v3:
* Remove check around CONFIG_OF.
* Add new host commands to cros_ec_trace.
* Use
Add support for controlling voltage regulator that is connected and
controlled by ChromeOS EC. Kernel controls these regulators through
newly added EC host commands.
Changes from v3:
* Fix dt bindings file name.
* Remove check around CONFIG_OF in driver.
* Add new host commands to cros_ec_trace.
>
> The UFS load calculation is based on "total_time" and "busy_time" in a
> devfreq window. However, the source of time is different for both
> parameters: "busy_time" is assigned from "jiffies" thus has different
> accuracy from "total_time" which is assigned from ktime_get().
>
> Besides,
Hi Qing,
Thanks for your patch!
On Thu, Jun 11, 2020 at 5:43 AM Qing Zhang wrote:
> Fix the following build errors:
>
> include/linux/spi 2>&1 || true
> ln -sf
> /home/zhangqing/spi.git2/tools/spi/../../include/uapi/linux/spi/spidev.h
> include/linux/spi/spidev.h
> make -f
…
> +++ b/fs/exfat/namei.c
> @@ -1077,10 +1077,14 @@ static int exfat_rename_file(struct inode *inode,
> struct exfat_chain *p_dir,
>
> epold = exfat_get_dentry(sb, p_dir, oldentry + 1, _bh,
> _old);
> + if (!epold)
> + return
On 2020-06-05 22:38, Sean Christopherson wrote:
Move to the common MMU memory cache implementation now that the common
code and arm64's existing code are semantically compatible.
No functional change intended.
Suggested-by: Christoffer Dall
Signed-off-by: Sean Christopherson
---
On Fri, 2020-05-29 at 13:24 -0600, Rob Herring wrote:
> On Thu, May 28, 2020 at 05:57:09PM +0800, EastL wrote:
> > Document the devicetree bindings for MediaTek Command-Queue DMA controller
> > which could be found on MT6779 SoC or other similar Mediatek SoCs.
> >
> > Signed-off-by: EastL
>
>
Hi Sean,
On 2020-06-05 22:38, Sean Christopherson wrote:
Add a "gfp_zero" member to arm64's 'struct kvm_mmu_memory_cache' to
make
the struct and its usage compatible with the common 'struct
kvm_mmu_memory_cache' in linux/kvm_host.h. This will minimize code
churn when arm64 moves to the common
On Wed 2020-06-10 17:41:40, Daniel Thompson wrote:
> On Sat, May 16, 2020 at 01:36:38AM +0900, Sergey Senozhatsky wrote:
> > On (20/05/15 17:32), Sumit Garg wrote:
> > > > Can I please have some context what problem does this solve?
> > >
> > > You can find the problem description here [1] which
Trying to build the kernel with CONFIG_INFINIBAND_USER_ACCESS enabled fails
ERROR: "__get_user_unknown" [drivers/infiniband/core/ib_uverbs.ko]
undefined!
with on SH since the kernel misses a 64-bit implementation of get_user().
Implement the missing 64-bit get_user() as __get_user_u64(),
Hi!
This is version 3 of my patch to implement __get_user_u64() for SH.
I have asked both Yutaka Niibe and Yoshinori Sato to look over my changes and
they
both agreed that an entry in __ex_tables for the second access was missing, so I
add the missing ".long 1b+2, 3b\n\t".
The changes should
Commit a84d01647989 ("mld: fix memory leak in mld_del_delrec()") fixed
the memory leak of MLD, but missing the ipv6_mc_destroy_dev() path, in
which mca_sources are leaked after ma_put().
Using ip6_mc_clear_src() to take care of the missing free.
BUG: memory leak
unreferenced object
On Thu, Jun 11, 2020 at 05:43:32PM +1000, Herbert Xu wrote:
>
> Finally the prototype of the function has been changed to avoid
> the unnecessary use of a void pointer.
OK that doesn't quite work. Let me respin without it and instead
add some missing inclusions of crypto/hash.h in files that
Hi Álvaro,
Álvaro Fernández Rojas wrote on Mon, 8 Jun 2020
18:06:49 +0200:
> Instead of trying to parse CFE version string, which is customized by some
> vendors, let's just check that "CFE1" was passed on argument 3.
>
> Signed-off-by: Álvaro Fernández Rojas
> Signed-off-by: Jonas Gorski
>
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: b29482fde649c72441d5478a4ea2c52c56d97a5e
commit: 738b0ca55f4f6ae1035262c2a2a605d2e9085031 mtd: rawnand: Add Macronix raw
NAND controller driver
date: 10 months ago
config: m68k-randconfig-s031-20200611
Hi Yifeng,
[...]
> +static void rk_nfc_disable_clk(struct rk_nfc_clk *clk)
> +{
> + if (!IS_ERR(clk->nfc_clk))
> + clk_disable_unprepare(clk->nfc_clk);
> + clk_disable_unprepare(clk->ahb_clk);
> +}
> +
> +static int rk_nfc_ooblayout_free(struct mtd_info *mtd, int section,
>
On Thu, 11 Jun 2020 at 13:56, Dave Airlie wrote:
>
> Hi Linus,
Hey actually skip this one in favour of the later one, one of the ast
fixes needs to get into stable as well.
Dave.
From: Kees Cook
> Sent: 11 June 2020 04:03
...
> > IIRC other kernels (eg NetBSD) do the copies for ioctl() requests
> > in the ioctl syscall wrapper.
> > The IOW/IOR/IOWR flags have to be right.
>
> Yeah, this seems like it'd make a lot more sense (and would have easily
> caught the IOR/IOW
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu
b/Documentation/ABI/testing/sysfs-devices-system-cpu
index b41046b5713b..a5225df4a070 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -358,6 +358,7 @@ What:
I'm announcing the release of the 4.9.227 kernel.
All users of the 4.9 kernel series must upgrade.
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu
b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 9ebca6a750f3..5abe1cc9f068 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -381,6 +381,7 @@ What:
I'm announcing the release of the 4.14.184 kernel.
All users of the 4.14 kernel series must upgrade.
The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.14.y
and can be browsed at the normal kernel.org git web
I'm announcing the release of the 4.4.227 kernel.
All users of the 4.4 kernel series must upgrade.
The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu
b/Documentation/ABI/testing/sysfs-devices-system-cpu
index f97d1aaec1f9..e9f9ce0688bc 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -279,6 +279,7 @@ What:
On Thu, Jun 11, 2020 at 4:33 AM Waiman Long wrote:
>
> On 4/4/20 1:55 AM, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:bef7b2a7 Merge tag 'devicetree-for-5.7' of git://git.kerne..
> > git tree: upstream
> > console output:
The header file linux/uio.h includes crypto/hash.h which pulls in
most of the Crypto API. Since linux/uio.h is used throughout the
kernel this means that every tiny bit of change to the Crypto API
causes the entire kernel to get rebuilt.
This patch fixes this by moving it into lib/iov_iter.c
Hi Sean,
On 2020-06-05 22:38, Sean Christopherson wrote:
Move x86's 'struct kvm_mmu_memory_cache' to common code in anticipation
of moving the entire x86 implementation code to common KVM and reusing
it for arm64 and MIPS. Add a new architecture specific asm/kvm_types.h
to control the
> On Jun 10, 2020, at 23:58, Mathias Nyman
> wrote:
>
> On 10.6.2020 18.43, Kai-Heng Feng wrote:
>>
>>
>>> On Jun 10, 2020, at 22:32, Alan Stern wrote:
>>>
>>> On Wed, Jun 10, 2020 at 02:42:30PM +0800, Kai-Heng Feng wrote:
xHCI spec "4.15.1 Port Suspend" states that port can be put
On Wed, 10 Jun 2020 23:35:24 -0700 Joe Perches wrote:
> On Thu, 2020-06-11 at 08:25 +0200, SeongJae Park wrote:
> > From: SeongJae Park
> >
> > This patchset 1) adds support of deprecated terms in the 'checkpatch.pl'
> > and 2) set the 'blacklist' and 'whitelist' as deprecated with
> >
Lontium LT9611 is a DSI to HDMI bridge which supports 2 DSI ports
and I2S port as input and one HDMI port as output
Reviewed-by: Rob Herring
Signed-off-by: Vinod Koul
---
.../display/bridge/lontium,lt9611.yaml| 176 ++
1 file changed, 176 insertions(+)
create mode
Hi,
> How about putting the file you frob in
> /sys/kernel/debug/selftest_helpers/something_or_other. The idea would
> be that /sys/kernel/debug/selftest_helpers would be a general place
> for kernel helpers needed to make selftests work.
Seems like this is the consensus for now.
Any opinions
Hi,
This series adds driver and bindings for Lontium LT9611 bridge chip which
takes MIPI DSI as input and HDMI as output.
This chip can be found in 96boards RB3 platform [1] commonly called DB845c.
[1]: https://www.96boards.org/product/rb3-platform/
Changes in v2:
- Add acks by Rob
- Fix
Add prefix for Lontium Semiconductor Corporation
Acked-by: Rob Herring
Signed-off-by: Vinod Koul
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
Lontium Lt9611 is a DSI to HDMI bridge which supports two DSI ports and
I2S port as an input and HDMI port as output
Co-developed-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
Co-developed-by: Srinivas Kandagatla
Signed-off-by: Srinivas Kandagatla
Signed-off-by: Vinod Koul
---
Hi Ansuel,
Sorry that I didn't make this comment earlier.
The subject and description are misleading. The patch itself is not
forcing anything (the DT is filling the gen to 1), so please fix that.
On 6/10/20 7:06 PM, Ansuel Smith wrote:
> From: Sham Muthayyan
>
> Add Force GEN1 support needed
The current firmware clock driver for the RaspberryPi can only be probed by
manually registering an associated platform_device.
While this works fine for cpufreq where the device gets attached a clkdev
lookup, it would be tedious to maintain a table of all the devices using
one of the clocks
The pllb_arm clock was created at probe time, but was never removed if
something went wrong later in probe, or if the driver was ever removed from
the system.
Now that we are using clk_hw_register(), we can just use its managed variant
to take care of that for us.
Cc: Michael Turquette
Cc:
Now that we have a clock driver for the clocks exposed by the firmware,
let's add the device tree nodes for it.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
Instead of declaring the clk_init_data and then calling memset on it, just
initialise properly.
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Reviewed-by: Stephen Boyd
Acked-by: Nicolas Saenz Julienne
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c
While some clock types allow for each clock to specify its own custom
flags, the PLLs can't. We will need this for the PLLB, so let's add it.
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-bcm2835.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
The clkdev lookup created for the cpufreq device is never removed if
there's an issue later in probe or at module removal time.
Let's convert to the managed variant of the clk_hw_register_clkdev function
to make sure it happens.
Cc: Michael Turquette
Cc: linux-...@vger.kernel.org
Acked-by:
The raspberrypi_register_pllb has been returning an integer so far to
notify whether the functions has exited successfully or not.
However, the OF provider functions in the clock framework require access to
the clk_hw structure so that we can expose those clocks to device tree
consumers.
Since
So far the driver has really only been providing a single clock, and stored
both the data associated to that clock in particular with the data
associated to the "controller".
Since we will change that in the future, let's decouple the clock data from
the provider data.
Cc: Michael Turquette
Cc:
The pllb_arm clock is defined as a fixed factor clock with the pllb
clock as a parent. However, all its configuration is entirely static,
and thus we don't really need to call clk_hw_register_fixed_factor() but
can simply call clk_hw_register() with a static clk_fixed_factor
structure.
Cc:
The PLLB rate will be changed through the firmware clocks drivers and will
change behind this drivers' back, so we don't want to cache the rate.
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-bcm2835.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
The pllb_arm_lookup pointer in the struct raspberrypi_clk is not used for
anything but to store the returned pointer to clkdev_hw_create, and is not
used anywhere else in the driver.
Let's remove that global pointer from the structure.
Cc: Michael Turquette
Cc: linux-...@vger.kernel.org
Since we don't care about retrieving the clk_lookup structure pointer
returned by clkdev_hw_create, we can just use the clk_hw_register_clkdev
function.
Cc: Michael Turquette
Cc: linux-...@vger.kernel.org
Acked-by: Nicolas Saenz Julienne
Reviewed-by: Stephen Boyd
Signed-off-by: Maxime Ripard
While the firmware allows us to discover the available clocks, we need to
discriminate those clocks to only register the ones meaningful to Linux.
The firmware also doesn't provide a clock name, so having a list of the ID
will help us to give clocks a proper name later on.
Acked-by: Nicolas Saenz
We've registered the firmware clocks using their ID as name, but it's much
more convenient to register them using their proper name. Since the
firmware doesn't provide it, we have to duplicate it.
Acked-by: Nicolas Saenz Julienne
Signed-off-by: Maxime Ripard
---
For the upcoming registration of the clocks provided by the firmware, make
sure it's exposed to the device tree providers.
Cc: Michael Turquette
Cc: linux-...@vger.kernel.org
Acked-by: Nicolas Saenz Julienne
Reviewed-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
This reverts commit 2256d89333bd17b8b56b42734a7e1046d52f7fc3. Since we
will be expanding the firmware clock driver, we'll need to remove the
quirks to deal with the PLLB. However, we still want to expose the clock
tree properly, so having that clock in the MMIO driver will allow that.
The driver has really only supported one clock so far and has hardcoded the
ID used in communications with the firmware in all the functions
implementing the clock framework hooks. Let's store that in the clock data
structure so that we can support more clocks later on.
Cc: Michael Turquette
Cc:
The RaspberryPi4 firmware actually exposes more clocks than are currently
handled by the driver and we will need to change some of them directly
based on the pixel rate for the display related clocks, or the load for the
GPU.
Since the firmware implements DVFS, this rate change can have a number
The raspberrypi firmware clock driver has a min_rate / max_rate clamping by
storing the info it needs in a private structure.
However, the CCF already provides such a facility, so we can switch to it
to remove the boilerplate.
Reviewed-by: Nicolas Saenz Julienne
Signed-off-by: Maxime Ripard
The firmware clocks driver was previously probed through a platform_device
created by the firmware driver.
Since we will now have a node for that clocks driver, we need to create the
device only in the case where there's no node for it already.
Reviewed-by: Nicolas Saenz Julienne
Signed-off-by:
The raspberry_clock_property only takes the clock ID as an argument, but
now that we have a clock data structure it makes more sense to just pass
that structure instead.
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Reviewed-by: Stephen Boyd
Acked-by: Nicolas Saenz
The CPU clock has had so far a bunch of quirks to expose the clock tree
properly, but since we reverted to exposing them through the MMIO driver,
we can remove that code from the firmware driver.
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 164
The driver only supports the pllb for now and all the clock framework hooks
are a mix of the generic firmware interface and the specifics of the pllb.
Since we will support more clocks in the future let's split the generic and
specific hooks
Cc: Michael Turquette
Cc: linux-...@vger.kernel.org
The raspberrypi_fw_pll_is_on function doesn't only apply to PLL
registered in the driver, but any clock exposed by the firmware.
Since we also implement the is_prepared hook, make the function
consistent with the other function names.
Cc: Michael Turquette
Cc: linux-...@vger.kernel.org
From: Florian Fainelli
Convert the Raspberry Pi BCM2835 firmware binding document to YAML.
Verified with dt_binding_check and dtbs_check.
Signed-off-by: Florian Fainelli
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt |
14
The firmware running on the RPi VideoCore can be used to discover and
change the various clocks running in the BCM2711. Since devices will
need to use them through the DT, let's add a pretty simple binding.
Cc: Michael Turquette
Cc: linux-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
The pllb_arm clk_hw pointer in the raspberry_clk structure isn't used
anywhere but in the raspberrypi_register_pllb_arm.
Let's remove it, this will make our lives easier in future patches.
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Reviewed-by: Stephen Boyd
Acked-by:
Hi,
Since the whole DRM/HDMI support began to grow fairly big, I've chosen
to split away the two discussions between the firmware clocks and the
HDMI support.
Let me know what you think,
Maxime
Cc: bcm-kernel-feedback-l...@broadcom.com
Cc: devicet...@vger.kernel.org
Cc: Kamal Dasu
Cc:
On 6/4/20 10:12 AM, Daniel Vetter wrote:
Two in one go:
- it is allowed to call dma_fence_wait() while holding a
dma_resv_lock(). This is fundamental to how eviction works with ttm,
so required.
- it is allowed to call dma_fence_wait() from memory reclaim contexts,
specifically from
On (20/06/10 17:41), Daniel Thompson wrote:
> > Thanks for the link. I'm slightly surprised it took so many years
> > to notice the addition of printk_nmi/printk_safe :)
>
> Rather by coincidence (at least I think its a coincidence) the problem
> has recently become much more obvious.
>
>
Hi Kamal,
Kamal Dasu wrote on Thu, 11 Jun 2020 01:44:54
-0400:
> Implemented ECC correctable and uncorrectable error handling for EDU
Implement?
> reads. If ECC correctable bitflips are encountered on EDU transfer,
extra space ^
> read page again
DMA_REMAP is an unnecessary requirement for AMD SEV, which requires
DMA_COHERENT_POOL, so avoid selecting it when it is otherwise unnecessary.
The only other requirement for DMA coherent pools is DMA_DIRECT_REMAP, so
ensure that properly selects the config option when needed.
Fixes:
On Thu, Jun 11, 2020 at 1:06 AM Wei Yang wrote:
> On Wed, Jun 10, 2020 at 01:17:28PM +0300, Andy Shevchenko wrote:
> >On Wed, Jun 10, 2020 at 2:06 AM Wei Yang wrote:
> >> On Tue, Jun 09, 2020 at 12:16:49PM +0300, Andy Shevchenko wrote:
> >> >On Mon, Jun 08, 2020 at 10:31:12PM +, Wei Yang
> On Jun 11, 2020, at 01:41, Alex Hung wrote:
>
> On 2020-06-10 9:49 a.m., mario.limoncie...@dell.com wrote:
>>> -Original Message-
>>> From: platform-driver-x86-ow...@vger.kernel.org >> ow...@vger.kernel.org> On Behalf Of Kai-Heng Feng
>>> Sent: Wednesday, June 10, 2020 10:38 AM
>>>
On Thu, Jun 11, 2020 at 06:51:15AM +, Chris Paterson wrote:
> Hello Greg,
>
> > From: stable-ow...@vger.kernel.org On
> > Behalf Of Greg Kroah-Hartman
> > Sent: 09 June 2020 20:18
> >
> > This is the start of the stable review cycle for the 4.4.227 release.
> > There are 36 patches in this
901 - 1000 of 1062 matches
Mail list logo
