* centralize SWIOTLB config symbol and misc other cleanups V3
From: Christoph Hellwig @ 2018-05-09 5:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180502124617.GA22001@infradead.org>
On Wed, May 02, 2018 at 05:46:17AM -0700, Christoph Hellwig wrote:
> Any more comments? Especially from the x86, mips and powerpc arch
> maintainers? I'd like to merge this in a few days as various other
> patches depend on it.
I've pulled it in to make forward progress. Any additional comments
will have to be sent in the form of incremental patches.
^ permalink raw reply
* [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules
From: Eric W. Biederman @ 2018-05-09 4:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508140640.0e312dba025df75cbf205cdb@arm.com>
Kim Phillips <kim.phillips@arm.com> writes:
> This patch is in the context of allowing the Coresight h/w
> trace driver suite to be loaded as modules. Coresight uses
> find_task_by_vpid when running in direct capture mode (via sysfs)
> when getting/setting the context ID comparator to trigger on
> (/sys/bus/coresight/devices/<x>.etm/ctxid_pid).
Aside from my objection about how bad an interface a pid in sysfs is.
The implementation of coresight_vpid_to_pid is horrible.
The code should be just:
static inline pid_t coresight_vpid_to_pid(pid_t vpid)
{
rcu_read_lock();
pid = pid_nr(find_vpid(vpid));
rcu_read_unlock();
return pid;
}
Which takes find_task_by_vpid out of the picture.
But reading further I am seeing code writing a pid to hardware. That is
broken. That is a layering violation of the first order. Giving
implementation details like that to hardware.
Any chance while you are working on this you can modify this code so
that it does something sensible and defensible instead of every line of
code I read be wrong in at least one detail?
Thank you,
Eric
^ permalink raw reply
* [PATCH] Kirin-PCIe: Add kirin pcie msi feature.
From: Shawn Guo @ 2018-05-09 4:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508125658.GK161390@bhelgaas-glaptop.roam.corp.google.com>
Hi Bjorn,
On Tue, May 08, 2018 at 07:56:58AM -0500, Bjorn Helgaas wrote:
...
> > + return ret;
> > + }
> > + }
> > +
> > + pci->pp.root_bus_nr = -1;
>
> Setting root_bus_nr looks like an unrelated change that should be in a
> separate patch.
>
> But I'm not sure why you need to set root_bus_nr at all, since
> dw_pcie_host_init() always sets it.
>
> Some other callers of dw_pcie_host_init() do set it:
>
> exynos_add_pcie_port()
> imx6_add_pcie_port()
> armada8k_add_pcie_port()
> artpec6_add_pcie_port()
> dw_plat_add_pcie_port()
> histb_pcie_probe()
> qcom_pcie_probe()
> spear13xx_add_pcie_port()
>
> But I don't see *why* any of these need to set it. If they don't need to
> set it, they shouldn't.
Mostly it's a blind copy of unnecessary code. I tested histb driver
by dropping the line, and did not see anything broken. I will cook up
a series to remove the code from all above drivers, and copy
corresponding driver owner to comment.
> And it would be nice if histb and qcom followed the structure and naming
> conventions of the other drivers, i.e., they should have
> histb_add_pcie_port() and qcom_add_pcie_port().
I can create a patch for histb driver, but will leave qcom one to
Stanimir to decide.
Shawn
>
> > pci->pp.ops = &kirin_pcie_host_ops;
> >
> > return dw_pcie_host_init(&pci->pp);
> > --
> > 1.9.1
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V4] clk: at91: PLL recalc_rate() now using cached MUL and DIV values
From: Marcin Ziemianowicz @ 2018-05-09 4:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180430075847.29706679@bbrezillon>
On Mon, Apr 30, 2018 at 07:58:47AM +0200, Boris Brezillon wrote:
> On Sun, 29 Apr 2018 15:01:11 -0400
> Marcin Ziemianowicz <marcin@ziemianowicz.com> wrote:
>
> > When a USB device is connected to the USB host port on the SAM9N12 then
> > you get "-62" error which seems to indicate USB replies from the device
> > are timing out. Based on a logic sniffer, I saw the USB bus was running
> > at half speed.
> >
> > The PLL code uses cached MUL and DIV values which get set in set_rate()
> > and applied in prepare(), but the recalc_rate() function instead
> > queries the hardware instead of using these cached values. Therefore,
> > if recalc_rate() is called between a set_rate() and prepare(), the
> > wrong frequency is calculated and later the USB clock divider for the
> > SAM9N12 SOC will be configured for an incorrect clock.
> >
> > In my case, the PLL hardware was set to 96 Mhz before the OHCI
> > driver loads, and therefore the usb clock divider was being set
> > to /2 even though the OHCI driver set the PLL to 48 Mhz.
> >
> > As an alternative explanation, I noticed this was fixed in the past by
> > 87e2ed338f1b ("clk: at91: fix recalc_rate implementation of PLL
> > driver") but the bug was later re-introduced by 1bdf02326b71 ("clk:
> > at91: make use of syscon/regmap internally").
> >
> > Fixes: 1bdf02326b71 ("clk: at91: make use of syscon/regmap internally)
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Marcin Ziemianowicz <marcin@ziemianowicz.com>
>
> Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
Apologies for being a bother, but since it's been a bit over a week,
should I do something with this now that it has been ACK'd? I was thinking
I would see it somewhere on the git group repo but am not seeing it there
yet. Googling says that there is a "review cycle" for some maintainers, but
I am not clear on if I need to initiate it manually or anything of the sort.
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/
>
> > ---
> > Thank you for bearing with me about this Boris.
> >
> > Changes since V3:
> > Fix for double returns found by kbluild test robot
> > > Comments by Boris Brezillon about email formatting issues
> > Changes since V2:
> > Removed all logging/debug messages I added
> > > Comment by Boris Brezillon about my fix being wrong addressed
> > Changes since V1:
> > Added patch set cover letter
> > Shortened lines which were over >80 characters long
> > > Comment by Greg Kroah-Hartman about "from" field in email addressed
> > > Comment by Alan Stern about redundant debug lines addressed
> >
> > drivers/clk/at91/clk-pll.c | 13 +------------
> > 1 file changed, 1 insertion(+), 12 deletions(-)
> >
> > diff --git a/drivers/clk/at91/clk-pll.c b/drivers/clk/at91/clk-pll.c
> > index 7d3223fc..72b6091e 100644
> > --- a/drivers/clk/at91/clk-pll.c
> > +++ b/drivers/clk/at91/clk-pll.c
> > @@ -132,19 +132,8 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
> > unsigned long parent_rate)
> > {
> > struct clk_pll *pll = to_clk_pll(hw);
> > - unsigned int pllr;
> > - u16 mul;
> > - u8 div;
> > -
> > - regmap_read(pll->regmap, PLL_REG(pll->id), &pllr);
> > -
> > - div = PLL_DIV(pllr);
> > - mul = PLL_MUL(pllr, pll->layout);
> > -
> > - if (!div || !mul)
> > - return 0;
> >
> > - return (parent_rate / div) * (mul + 1);
> > + return (parent_rate / pll->div) * (pll->mul + 1);
> > }
> >
> > static long clk_pll_get_best_div_mul(struct clk_pll *pll, unsigned long rate,
>
^ permalink raw reply
* [PATCH v7 12/24] ASoC: qdsp6: q6afe: Add support to MI2S sysclks
From: Banajit Goswami @ 2018-05-09 4:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180501120820.11016-13-srinivas.kandagatla@linaro.org>
On 5/1/2018 5:08 AM, Srinivas Kandagatla wrote:
> This patch adds support to LPASS Bit clock, LPASS Digital
> core clock and OSR clock. These clocks are required for both
> MI2S and PCM setup.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Reviewed-and-tested-by: Rohit kumar <rohitkr@codeaurora.org>
> ---
> sound/soc/qcom/qdsp6/q6afe.c | 171 +++++++++++++++++++++++++++++++++++++++++--
> sound/soc/qcom/qdsp6/q6afe.h | 131 +++++++++++++++++++++++++++++++++
> 2 files changed, 295 insertions(+), 7 deletions(-)
>
>
Acked-by: Banajit Goswami <bgoswami@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 2/2] perf cs-etm: Remove redundant space
From: Leo Yan @ 2018-05-09 4:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525839312-20544-1-git-send-email-leo.yan@linaro.org>
There have two spaces ahead function name cs_etm__set_pid_tid_cpu(), so
remove one space and correct indentation.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
tools/perf/util/cs-etm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 69f21de..822ba91 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -611,8 +611,8 @@ cs_etm__get_trace(struct cs_etm_buffer *buff, struct cs_etm_queue *etmq)
return buff->len;
}
-static void cs_etm__set_pid_tid_cpu(struct cs_etm_auxtrace *etm,
- struct auxtrace_queue *queue)
+static void cs_etm__set_pid_tid_cpu(struct cs_etm_auxtrace *etm,
+ struct auxtrace_queue *queue)
{
struct cs_etm_queue *etmq = queue->priv;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/2] perf cs-etm: Support unknown_thread in cs_etm_auxtrace
From: Leo Yan @ 2018-05-09 4:15 UTC (permalink / raw)
To: linux-arm-kernel
CoreSight doesn't allocate thread structure for unknown_thread in etm
auxtrace, so unknown_thread is NULL pointer. If the perf data doesn't
contain valid tid and then cs_etm__mem_access() uses unknown_thread
instead as thread handler, this results in segmentation fault when
thread__find_addr_map() accesses thread handler.
This commit creates new thread data which is used by unknown_thread, so
CoreSight tracing can roll back to use unknown_thread if perf data
doesn't include valid thread info. This commit also releases thread
data for initialization failure case and for normal auxtrace free flow.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
tools/perf/util/cs-etm.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 6533b1a..69f21de 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -239,6 +239,7 @@ static void cs_etm__free(struct perf_session *session)
for (i = 0; i < aux->num_cpu; i++)
zfree(&aux->metadata[i]);
+ thread__zput(aux->unknown_thread);
zfree(&aux->metadata);
zfree(&aux);
}
@@ -1355,6 +1356,23 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
etm->auxtrace.free = cs_etm__free;
session->auxtrace = &etm->auxtrace;
+ etm->unknown_thread = thread__new(999999999, 999999999);
+ if (!etm->unknown_thread)
+ goto err_free_queues;
+
+ /*
+ * Initialize list node so that at thread__zput() we can avoid
+ * segmentation fault at list_del_init().
+ */
+ INIT_LIST_HEAD(&etm->unknown_thread->node);
+
+ err = thread__set_comm(etm->unknown_thread, "unknown", 0);
+ if (err)
+ goto err_delete_thread;
+
+ if (thread__init_map_groups(etm->unknown_thread, etm->machine))
+ goto err_delete_thread;
+
if (dump_trace) {
cs_etm__print_auxtrace_info(auxtrace_info->priv, num_cpu);
return 0;
@@ -1369,16 +1387,18 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
err = cs_etm__synth_events(etm, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
err = auxtrace_queues__process_index(&etm->queues, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
etm->data_queued = etm->queues.populated;
return 0;
+err_delete_thread:
+ thread__zput(etm->unknown_thread);
err_free_queues:
auxtrace_queues__free(&etm->queues);
session->auxtrace = NULL;
--
2.7.4
^ permalink raw reply related
* [PATCH] hwmon: (aspeed-pwm-tacho) Use 24MHz clock
From: Benjamin Herrenschmidt @ 2018-05-09 4:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAARXrt=ZA7sz_CvNUxHRvie3YfErU-5d5ewHry=mgxb6Uz-+TA@mail.gmail.com>
On Wed, 2018-05-09 at 11:50 +0800, Lei YU wrote:
> On Wed, May 9, 2018 at 11:43 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > I am not going to accept this change, period. This is not one, it is five
> > steps
> > backward. If "aspeed_set_clock_source(priv->regmap, 0)" changes the clock
> > speed,
> > or the clock source, read it later, and attach to the correct clock. If that
> > doesn't work, fix the problem in the clock subsystem. Hacking the driver is
> > just
> > plain wrong.
> >
> > Also, if the idea in DT is to provide a different clock to the watchdog on
> > purpose,
> > maybe the call to "aspeed_set_clock_source(priv->regmap, 0)" is wrong.
>
> Exactly!
> My first change (not sent to mailing list) is to remove the call of
> "aspeed_set_clock_source(priv->regmap, 0)", instead, checking the clock
> source, and use either 24M or the memory controller clock.
> But that make things a bit more complicated and Aspeed suggests to use 24M
> clock. So I sent this simplified change.
>
> It's OK to not accept this change, the fix in DT will fix the issue as well.
Another option is to give *both* clock sources in the DT, since in HW
they both eventually reach the IP block, and have the driver select
which one it wants to use (that itself can also be in the DT).
That way you can select 0 if you want and still use clk_get_rate() to
know how fast it's ticking.
Cheers,
Ben.
^ permalink raw reply
* [PATCH 5/5] hisi: Consolidate the Kconfigs for the CLOCK_STUB and the MAILBOX
From: Leo Yan @ 2018-05-09 4:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABb+yY2ke__W2ZW4c_Z9CejZzup52ykRDyNecTs0+nkvf5cbNA@mail.gmail.com>
On Wed, May 09, 2018 at 09:19:13AM +0530, Jassi Brar wrote:
> On Wed, Apr 4, 2018 at 8:44 AM, Leo Yan <leo.yan@linaro.org> wrote:
> > From: Daniel Lezcano <daniel.lezcano@linaro.org>
> >
> > The current defconfig is inconsistent as it selects the mailbox and
> > the clock for the hi6220 and the hi3660 without having their Kconfigs
> > making sure the dependencies are correct. It ends up when selecting
> > different versions for the kernel (for example when git bisecting)
> > those options disappear and they don't get back, leading to unexpected
> > behaviors. In our case, the cpufreq driver does no longer work because
> > the clock fails to initialize due to the clock stub and the mailbox
> > missing.
> >
> > In order to have the dependencies correctly set when defaulting, let's
> > do the same as commit 3a49afb84ca074e ("clk: enable hi655x common clk
> > automatically") where we select automatically the driver when the
> > parent driver is selected. With sensible defaults in place, we can leave
> > other choices for EXPERT.
> >
> Acked-by: Jassi Brar <jaswinder.singh@linaro.org>
Thanks Jassi & Stephen.
Wei, could you pick this patch?
Thanks,
Leo Yan
^ permalink raw reply
* [PATCH] hwmon: (aspeed-pwm-tacho) Use 24MHz clock
From: Lei YU @ 2018-05-09 3:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c5770e4a-9445-d4ef-cc1f-a7a84599c4a1@roeck-us.net>
On Wed, May 9, 2018 at 11:43 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>
> I am not going to accept this change, period. This is not one, it is five
> steps
> backward. If "aspeed_set_clock_source(priv->regmap, 0)" changes the clock
> speed,
> or the clock source, read it later, and attach to the correct clock. If that
> doesn't work, fix the problem in the clock subsystem. Hacking the driver is
> just
> plain wrong.
>
> Also, if the idea in DT is to provide a different clock to the watchdog on
> purpose,
> maybe the call to "aspeed_set_clock_source(priv->regmap, 0)" is wrong.
Exactly!
My first change (not sent to mailing list) is to remove the call of
"aspeed_set_clock_source(priv->regmap, 0)", instead, checking the clock
source, and use either 24M or the memory controller clock.
But that make things a bit more complicated and Aspeed suggests to use 24M
clock. So I sent this simplified change.
It's OK to not accept this change, the fix in DT will fix the issue as well.
Please drop this.
Thanks!
^ permalink raw reply
* [PATCH 5/5] hisi: Consolidate the Kconfigs for the CLOCK_STUB and the MAILBOX
From: Jassi Brar @ 2018-05-09 3:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1522811675-12741-6-git-send-email-leo.yan@linaro.org>
On Wed, Apr 4, 2018 at 8:44 AM, Leo Yan <leo.yan@linaro.org> wrote:
> From: Daniel Lezcano <daniel.lezcano@linaro.org>
>
> The current defconfig is inconsistent as it selects the mailbox and
> the clock for the hi6220 and the hi3660 without having their Kconfigs
> making sure the dependencies are correct. It ends up when selecting
> different versions for the kernel (for example when git bisecting)
> those options disappear and they don't get back, leading to unexpected
> behaviors. In our case, the cpufreq driver does no longer work because
> the clock fails to initialize due to the clock stub and the mailbox
> missing.
>
> In order to have the dependencies correctly set when defaulting, let's
> do the same as commit 3a49afb84ca074e ("clk: enable hi655x common clk
> automatically") where we select automatically the driver when the
> parent driver is selected. With sensible defaults in place, we can leave
> other choices for EXPERT.
>
Acked-by: Jassi Brar <jaswinder.singh@linaro.org>
^ permalink raw reply
* [PATCH] hwmon: (aspeed-pwm-tacho) Use 24MHz clock
From: Guenter Roeck @ 2018-05-09 3:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAARXrtmO=wsPK6bfO0E7fvAkqEJUV1kQSYK1gWXkUhmKytq42A@mail.gmail.com>
On 05/08/2018 08:18 PM, Lei YU wrote:
> On Tue, May 8, 2018 at 9:51 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>> No mixed C/C++ comments in hwmon drivers.
>>
>>> aspeed_set_clock_source(priv->regmap, 0);
>>> + priv->clk_freq = 24000000;
>>>
>>
>>
>> Are you saying that clk_get_rate() is wrong ? Anyway, if the DT is bad, it
>> should be fixed.
> Nope, clk_get_rate() is OK.
> The reason I make this change is because the PWM supports two types of clock
> source, the 24MHz or the clock from memory controller.
> If the DT uses 24MHz clock, this code is OK.
> But if the DT configs this pwm to use mclk (memory controller clk), this piece
> of code becomes wrong, because the code
> `aspeed_set_clock_source(priv->regmap, 0)` configs the device to use the 24MHz
> clock.
> So no matter what DT configs the clk, this driver *always* uses 24MHz clock.
>
> That's why I want to make this change.
>
>> I am not a friend of hacking drivers to fix up bad DTs, and much less so
>> without explanation.
>> Plus, how do we know that the next chip supported by the driver doesn't have
>> a 32MHz clock ?
> This driver currently supports ast2400 and ast2500, and they both use 24MHz
> clock.
> In case future device uses a different clock, we can update this code, right?
>
I am not going to accept this change, period. This is not one, it is five steps
backward. If "aspeed_set_clock_source(priv->regmap, 0)" changes the clock speed,
or the clock source, read it later, and attach to the correct clock. If that
doesn't work, fix the problem in the clock subsystem. Hacking the driver is just
plain wrong.
Also, if the idea in DT is to provide a different clock to the watchdog on purpose,
maybe the call to "aspeed_set_clock_source(priv->regmap, 0)" is wrong.
Guenter
>> Really, please fix the DT.
> Sure, I will send patch to config the clock to use fixed 24MHz clock as well.
>
>>
>> Guenter
>>
>>> aspeed_create_type(priv);
>>>
>>
>>
>
^ permalink raw reply
* [PATCH] Kirin-PCIe: Add kirin pcie msi feature.
From: Yao Chen @ 2018-05-09 3:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH7ZN-zOwCqzzmKxkCeLt+z2FCpMrxnu5a8s8Os-fSsuS2R01w@mail.gmail.com>
On 2018/5/9 5:31, Dmitry Shmidt wrote:
> On Tue, May 8, 2018 at 12:03 AM, Yao Chen <chenyao11@huawei.com> wrote:
>> This patch adds kirin pcie msi feature.
>>
>> Signed-off-by: Yao Chen <chenyao11@huawei.com>
>> ---
>> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 2 ++
>> drivers/pci/dwc/pcie-kirin.c | 38 +++++++++++++++++++++++++++++++
>> 2 files changed, 40 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
>> index ec3eb8e..4ef684f 100644
>> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
>> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
>> @@ -872,6 +872,8 @@
>> 0x0 0x02000000>;
>> num-lanes = <1>;
>> #interrupt-cells = <1>;
>> + interrupts = <0 283 4>;
>> + interrupts-names = "msi";
>
> Possible typo? Should be interrupt-names = "msi";
Yes, you're right. It should be interrupt-names = "msi". I will fix it. Thanks.
>
>> interrupt-map-mask = <0xf800 0 0 7>;
>> interrupt-map = <0x0 0 0 1
>> &gic GIC_SPI 282 IRQ_TYPE_LEVEL_HIGH>,
>> diff --git a/drivers/pci/dwc/pcie-kirin.c b/drivers/pci/dwc/pcie-kirin.c
>> index d2970a0..2319c9c 100644
>> --- a/drivers/pci/dwc/pcie-kirin.c
>> +++ b/drivers/pci/dwc/pcie-kirin.c
>> @@ -426,9 +426,28 @@ static int kirin_pcie_establish_link(struct pcie_port *pp)
>> return 0;
>> }
>>
>> +static irqreturn_t kirin_pcie_msi_irq_handler(int irq, void *arg)
>> +{
>> + struct pcie_port *pp = arg;
>> +
>> + return dw_handle_msi_irq(pp);
>> +}
>> +
>> +static void kirin_pcie_msi_init(struct pcie_port *pp)
>> +{
>> + dw_pcie_msi_init(pp);
>> +}
>> +
>> +static void kirin_pcie_enable_interrupts(struct pcie_port *pp)
>> +{
>> + if (IS_ENABLED(CONFIG_PCI_MSI))
>> + kirin_pcie_msi_init(pp);
>> +}
>> +
>> static int kirin_pcie_host_init(struct pcie_port *pp)
>> {
>> kirin_pcie_establish_link(pp);
>> + kirin_pcie_enable_interrupts(pp);
>>
>> return 0;
>> }
>> @@ -448,6 +467,25 @@ static int kirin_pcie_host_init(struct pcie_port *pp)
>> static int __init kirin_add_pcie_port(struct dw_pcie *pci,
>> struct platform_device *pdev)
>> {
>> + int ret;
>> +
>> + if (IS_ENABLED(CONFIG_PCI_MSI)) {
>> + pci->pp.msi_irq = platform_get_irq(pdev, 0);
>> + if (!pci->pp.msi_irq) {
>> + dev_err(&pdev->dev, "failed to get msi irq\n");
>> + return -ENODEV;
>> + }
>> + ret = devm_request_irq(&pdev->dev, pci->pp.msi_irq,
>> + kirin_pcie_msi_irq_handler,
>> + IRQF_SHARED | IRQF_NO_THREAD,
>> + "kirin_pcie_msi", &pci->pp);
>> + if (ret) {
>> + dev_err(&pdev->dev, "failed to request msi irq\n");
>> + return ret;
>> + }
>> + }
>> +
>> + pci->pp.root_bus_nr = -1;
>> pci->pp.ops = &kirin_pcie_host_ops;
>>
>> return dw_pcie_host_init(&pci->pp);
>> --
>> 1.9.1
>>
>
> .
>
^ permalink raw reply
* [PATCH 2/4] phy: rockchip-typec: support variable phy config value
From: hl @ 2018-05-09 3:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFqH_511VgKG+_rqPNGf5Ez2+tc_ijqNQA_rYW1xr6903BSSoA@mail.gmail.com>
On Monday, May 07, 2018 09:59 PM, Enric Balletbo Serra wrote:
> Hi Lin,
>
> Thanks for the patch, apart from the new build warnings introduced
> some more comments below.
>
> 2018-05-04 10:08 GMT+02:00 Lin Huang <hl@rock-chips.com>:
>> the phy config values used to fix in dp firmware, but some boards
>> need change these values to do training and get the better eye diagram
>> result. So support that in phy driver.
>>
>> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
>> Signed-off-by: Lin Huang <hl@rock-chips.com>
>> ---
>> drivers/phy/rockchip/phy-rockchip-typec.c | 286 +++++++++++++++++++-----------
>> include/soc/rockchip/rockchip_phy_typec.h | 72 ++++++++
>> 2 files changed, 259 insertions(+), 99 deletions(-)
>> create mode 100644 include/soc/rockchip/rockchip_phy_typec.h
>>
>> diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c b/drivers/phy/rockchip/phy-rockchip-typec.c
>> index 76a4b58..831a93b 100644
>> --- a/drivers/phy/rockchip/phy-rockchip-typec.c
>> +++ b/drivers/phy/rockchip/phy-rockchip-typec.c
>> @@ -63,6 +63,7 @@
>>
>> #include <linux/mfd/syscon.h>
>> #include <linux/phy/phy.h>
>> +#include <soc/rockchip/rockchip_phy_typec.h>
>>
>> #define CMN_SSM_BANDGAP (0x21 << 2)
>> #define CMN_SSM_BIAS (0x22 << 2)
>> @@ -323,23 +324,31 @@
>> * clock 0: PLL 0 div 1
>> * clock 1: PLL 1 div 2
>> */
>> -#define CLK_PLL_CONFIG 0X30
>> +#define CLK_PLL1_DIV1 0x20
>> +#define CLK_PLL1_DIV2 0x30
>> #define CLK_PLL_MASK 0x33
>>
>> #define CMN_READY BIT(0)
>>
>> +#define DP_PLL_CLOCK_ENABLE_ACK BIT(3)
>> #define DP_PLL_CLOCK_ENABLE BIT(2)
>> +#define DP_PLL_ENABLE_ACK BIT(1)
>> #define DP_PLL_ENABLE BIT(0)
>> #define DP_PLL_DATA_RATE_RBR ((2 << 12) | (4 << 8))
>> #define DP_PLL_DATA_RATE_HBR ((2 << 12) | (4 << 8))
>> #define DP_PLL_DATA_RATE_HBR2 ((1 << 12) | (2 << 8))
>> +#define DP_PLL_DATA_RATE_MASK 0xff00
>>
>> -#define DP_MODE_A0 BIT(4)
>> -#define DP_MODE_A2 BIT(6)
>> -#define DP_MODE_ENTER_A0 0xc101
>> -#define DP_MODE_ENTER_A2 0xc104
>> +#define DP_MODE_MASK 0xf
>> +#define DP_MODE_ENTER_A0 BIT(0)
>> +#define DP_MODE_ENTER_A2 BIT(2)
>> +#define DP_MODE_ENTER_A3 BIT(3)
>> +#define DP_MODE_A0_ACK BIT(4)
>> +#define DP_MODE_A2_ACK BIT(6)
>> +#define DP_MODE_A3_ACK BIT(7)
>> +#define DP_LINK_RESET_DEASSERTED BIT(8)
>>
>> -#define PHY_MODE_SET_TIMEOUT 100000
>> +#define PHY_MODE_SET_TIMEOUT 1000000
>>
> Why do you need to increase this timeout? Is because the software link
> training timed out using the old value?
That for debug, will fix it in next version.
>
>
>> #define PIN_ASSIGN_C_E 0x51d9
>> #define PIN_ASSIGN_D_F 0x5100
>> @@ -349,51 +358,7 @@
>> #define MODE_DFP_USB BIT(1)
>> #define MODE_DFP_DP BIT(2)
>>
>> -struct usb3phy_reg {
>> - u32 offset;
>> - u32 enable_bit;
>> - u32 write_enable;
>> -};
>> -
>> -/**
>> - * struct rockchip_usb3phy_port_cfg: usb3-phy port configuration.
>> - * @reg: the base address for usb3-phy config.
>> - * @typec_conn_dir: the register of type-c connector direction.
>> - * @usb3tousb2_en: the register of type-c force usb2 to usb2 enable.
>> - * @external_psm: the register of type-c phy external psm clock.
>> - * @pipe_status: the register of type-c phy pipe status.
>> - * @usb3_host_disable: the register of type-c usb3 host disable.
>> - * @usb3_host_port: the register of type-c usb3 host port.
>> - * @uphy_dp_sel: the register of type-c phy DP select control.
>> - */
>> -struct rockchip_usb3phy_port_cfg {
>> - unsigned int reg;
>> - struct usb3phy_reg typec_conn_dir;
>> - struct usb3phy_reg usb3tousb2_en;
>> - struct usb3phy_reg external_psm;
>> - struct usb3phy_reg pipe_status;
>> - struct usb3phy_reg usb3_host_disable;
>> - struct usb3phy_reg usb3_host_port;
>> - struct usb3phy_reg uphy_dp_sel;
>> -};
>> -
>> -struct rockchip_typec_phy {
>> - struct device *dev;
>> - void __iomem *base;
>> - struct extcon_dev *extcon;
>> - struct regmap *grf_regs;
>> - struct clk *clk_core;
>> - struct clk *clk_ref;
>> - struct reset_control *uphy_rst;
>> - struct reset_control *pipe_rst;
>> - struct reset_control *tcphy_rst;
>> - const struct rockchip_usb3phy_port_cfg *port_cfgs;
>> - /* mutex to protect access to individual PHYs */
>> - struct mutex lock;
>> -
>> - bool flip;
>> - u8 mode;
>> -};
>> +#define DEFAULT_RATE 162000
>>
> DEFAULT_RATE seems a very common name for me, maybe add a prefix?
Okay, will fix it.
>
>
>> struct phy_reg {
>> u16 value;
>> @@ -417,15 +382,15 @@ struct phy_reg usb3_pll_cfg[] = {
>> { 0x8, CMN_DIAG_PLL0_LF_PROG },
>> };
>>
>> -struct phy_reg dp_pll_cfg[] = {
>> +struct phy_reg dp_pll_rbr_cfg[] = {
>> { 0xf0, CMN_PLL1_VCOCAL_INIT },
>> { 0x18, CMN_PLL1_VCOCAL_ITER },
>> { 0x30b9, CMN_PLL1_VCOCAL_START },
>> - { 0x21c, CMN_PLL1_INTDIV },
>> + { 0x87, CMN_PLL1_INTDIV },
>> { 0, CMN_PLL1_FRACDIV },
>> - { 0x5, CMN_PLL1_HIGH_THR },
>> - { 0x35, CMN_PLL1_SS_CTRL1 },
>> - { 0x7f1e, CMN_PLL1_SS_CTRL2 },
>> + { 0x22, CMN_PLL1_HIGH_THR },
>> + { 0x8000, CMN_PLL1_SS_CTRL1 },
>> + { 0, CMN_PLL1_SS_CTRL2 },
>> { 0x20, CMN_PLL1_DSM_DIAG },
>> { 0, CMN_PLLSM1_USER_DEF_CTRL },
>> { 0, CMN_DIAG_PLL1_OVRD },
>> @@ -436,9 +401,52 @@ struct phy_reg dp_pll_cfg[] = {
>> { 0x8, CMN_DIAG_PLL1_LF_PROG },
>> { 0x100, CMN_DIAG_PLL1_PTATIS_TUNE1 },
>> { 0x7, CMN_DIAG_PLL1_PTATIS_TUNE2 },
>> - { 0x4, CMN_DIAG_PLL1_INCLK_CTRL },
>> + { 0x1, CMN_DIAG_PLL1_INCLK_CTRL },
>> +};
>> +
>> +struct phy_reg dp_pll_hbr_cfg[] = {
>> + { 0xf0, CMN_PLL1_VCOCAL_INIT },
>> + { 0x18, CMN_PLL1_VCOCAL_ITER },
>> + { 0x30b4, CMN_PLL1_VCOCAL_START },
>> + { 0xe1, CMN_PLL1_INTDIV },
>> + { 0, CMN_PLL1_FRACDIV },
>> + { 0x5, CMN_PLL1_HIGH_THR },
>> + { 0x8000, CMN_PLL1_SS_CTRL1 },
>> + { 0, CMN_PLL1_SS_CTRL2 },
>> + { 0x20, CMN_PLL1_DSM_DIAG },
>> + { 0x1000, CMN_PLLSM1_USER_DEF_CTRL },
>> + { 0, CMN_DIAG_PLL1_OVRD },
>> + { 0, CMN_DIAG_PLL1_FBH_OVRD },
>> + { 0, CMN_DIAG_PLL1_FBL_OVRD },
>> + { 0x7, CMN_DIAG_PLL1_V2I_TUNE },
>> + { 0x45, CMN_DIAG_PLL1_CP_TUNE },
>> + { 0x8, CMN_DIAG_PLL1_LF_PROG },
>> + { 0x1, CMN_DIAG_PLL1_PTATIS_TUNE1 },
>> + { 0x1, CMN_DIAG_PLL1_PTATIS_TUNE2 },
>> + { 0x1, CMN_DIAG_PLL1_INCLK_CTRL },
>> };
>>
>> +struct phy_reg dp_pll_hbr2_cfg[] = {
>> + { 0xf0, CMN_PLL1_VCOCAL_INIT },
>> + { 0x18, CMN_PLL1_VCOCAL_ITER },
>> + { 0x30b4, CMN_PLL1_VCOCAL_START },
>> + { 0xe1, CMN_PLL1_INTDIV },
>> + { 0, CMN_PLL1_FRACDIV },
>> + { 0x5, CMN_PLL1_HIGH_THR },
>> + { 0x8000, CMN_PLL1_SS_CTRL1 },
>> + { 0, CMN_PLL1_SS_CTRL2 },
>> + { 0x20, CMN_PLL1_DSM_DIAG },
>> + { 0x1000, CMN_PLLSM1_USER_DEF_CTRL },
>> + { 0, CMN_DIAG_PLL1_OVRD },
>> + { 0, CMN_DIAG_PLL1_FBH_OVRD },
>> + { 0, CMN_DIAG_PLL1_FBL_OVRD },
>> + { 0x7, CMN_DIAG_PLL1_V2I_TUNE },
>> + { 0x45, CMN_DIAG_PLL1_CP_TUNE },
>> + { 0x8, CMN_DIAG_PLL1_LF_PROG },
>> + { 0x1, CMN_DIAG_PLL1_PTATIS_TUNE1 },
>> + { 0x1, CMN_DIAG_PLL1_PTATIS_TUNE2 },
>> + { 0x1, CMN_DIAG_PLL1_INCLK_CTRL },
>> +};
>> static const struct rockchip_usb3phy_port_cfg rk3399_usb3phy_port_cfgs[] = {
>> {
>> .reg = 0xff7c0000,
>> @@ -484,7 +492,7 @@ static void tcphy_cfg_24m(struct rockchip_typec_phy *tcphy)
>>
>> rdata = readl(tcphy->base + CMN_DIAG_HSCLK_SEL);
>> rdata &= ~CLK_PLL_MASK;
>> - rdata |= CLK_PLL_CONFIG;
>> + rdata |= CLK_PLL1_DIV2;
>> writel(rdata, tcphy->base + CMN_DIAG_HSCLK_SEL);
>> }
>>
>> @@ -498,17 +506,44 @@ static void tcphy_cfg_usb3_pll(struct rockchip_typec_phy *tcphy)
>> tcphy->base + usb3_pll_cfg[i].addr);
>> }
>>
>> -static void tcphy_cfg_dp_pll(struct rockchip_typec_phy *tcphy)
>> +static void tcphy_cfg_dp_pll(struct rockchip_typec_phy *tcphy, int link_rate)
>> {
>> - u32 i;
>> + struct phy_reg *phy_cfg;
>> + u32 clk_ctrl;
>> + u32 i, cfg_size, hsclk_sel;
>> +
>> + hsclk_sel = readl(tcphy->base + CMN_DIAG_HSCLK_SEL);
>> + hsclk_sel &= ~CLK_PLL_MASK;
>> +
>> + switch (link_rate) {
>> + case 162000:
>> + clk_ctrl = DP_PLL_DATA_RATE_RBR;
>> + hsclk_sel |= CLK_PLL1_DIV2;
>> + phy_cfg = dp_pll_rbr_cfg;
>> + cfg_size = ARRAY_SIZE(dp_pll_rbr_cfg);
>> + break;
>> + case 270000:
>> + clk_ctrl = DP_PLL_DATA_RATE_HBR;
>> + hsclk_sel |= CLK_PLL1_DIV2;
>> + phy_cfg = dp_pll_hbr_cfg;
>> + cfg_size = ARRAY_SIZE(dp_pll_hbr_cfg);
>> + break;
>> + case 540000:
>> + clk_ctrl = DP_PLL_DATA_RATE_HBR2;
>> + hsclk_sel |= CLK_PLL1_DIV1;
>> + phy_cfg = dp_pll_hbr2_cfg;
>> + cfg_size = ARRAY_SIZE(dp_pll_hbr2_cfg);
>> + break;
>> + }
>> +
>> + clk_ctrl |= DP_PLL_CLOCK_ENABLE | DP_PLL_ENABLE;
>> + writel(clk_ctrl, tcphy->base + DP_CLK_CTL);
>>
>> - /* set the default mode to RBR */
>> - writel(DP_PLL_CLOCK_ENABLE | DP_PLL_ENABLE | DP_PLL_DATA_RATE_RBR,
>> - tcphy->base + DP_CLK_CTL);
>> + writel(hsclk_sel, tcphy->base + CMN_DIAG_HSCLK_SEL);
>>
>> /* load the configuration of PLL1 */
>> - for (i = 0; i < ARRAY_SIZE(dp_pll_cfg); i++)
>> - writel(dp_pll_cfg[i].value, tcphy->base + dp_pll_cfg[i].addr);
>> + for (i = 0; i < cfg_size; i++)
>> + writel(phy_cfg[i].value, tcphy->base + phy_cfg[i].addr);
>> }
>>
>> static void tcphy_tx_usb3_cfg_lane(struct rockchip_typec_phy *tcphy, u32 lane)
>> @@ -535,9 +570,10 @@ static void tcphy_rx_usb3_cfg_lane(struct rockchip_typec_phy *tcphy, u32 lane)
>> writel(0xfb, tcphy->base + XCVR_DIAG_BIDI_CTRL(lane));
>> }
>>
>> -static void tcphy_dp_cfg_lane(struct rockchip_typec_phy *tcphy, u32 lane)
>> +static void tcphy_dp_cfg_lane(struct rockchip_typec_phy *tcphy, int link_rate,
>> + u8 swing, u8 pre_emp, u32 lane)
>> {
>> - u16 rdata;
>> + u16 val;
> >From what I see you are only renaming rdata to val, there is any reason?
not reason, just rename a new variable :)
>
>> writel(0xbefc, tcphy->base + XCVR_PSM_RCTRL(lane));
>> writel(0x6799, tcphy->base + TX_PSC_A0(lane));
>> @@ -545,25 +581,31 @@ static void tcphy_dp_cfg_lane(struct rockchip_typec_phy *tcphy, u32 lane)
>> writel(0x98, tcphy->base + TX_PSC_A2(lane));
>> writel(0x98, tcphy->base + TX_PSC_A3(lane));
>>
>> - writel(0, tcphy->base + TX_TXCC_MGNFS_MULT_000(lane));
>> - writel(0, tcphy->base + TX_TXCC_MGNFS_MULT_001(lane));
>> - writel(0, tcphy->base + TX_TXCC_MGNFS_MULT_010(lane));
>> - writel(0, tcphy->base + TX_TXCC_MGNFS_MULT_011(lane));
>> - writel(0, tcphy->base + TX_TXCC_MGNFS_MULT_100(lane));
>> - writel(0, tcphy->base + TX_TXCC_MGNFS_MULT_101(lane));
>> - writel(0, tcphy->base + TX_TXCC_MGNFS_MULT_110(lane));
>> - writel(0, tcphy->base + TX_TXCC_MGNFS_MULT_111(lane));
>> - writel(0, tcphy->base + TX_TXCC_CPOST_MULT_10(lane));
>> - writel(0, tcphy->base + TX_TXCC_CPOST_MULT_01(lane));
>> - writel(0, tcphy->base + TX_TXCC_CPOST_MULT_00(lane));
>> - writel(0, tcphy->base + TX_TXCC_CPOST_MULT_11(lane));
>> -
>> - writel(0x128, tcphy->base + TX_TXCC_CAL_SCLR_MULT(lane));
>> - writel(0x400, tcphy->base + TX_DIAG_TX_DRV(lane));
>> -
>> - rdata = readl(tcphy->base + XCVR_DIAG_PLLDRC_CTRL(lane));
>> - rdata = (rdata & 0x8fff) | 0x6000;
>> - writel(rdata, tcphy->base + XCVR_DIAG_PLLDRC_CTRL(lane));
>> + writel(tcphy->config[swing][pre_emp].swing,
>> + tcphy->base + TX_TXCC_MGNFS_MULT_000(lane));
>> + writel(tcphy->config[swing][pre_emp].pe,
>> + tcphy->base + TX_TXCC_CPOST_MULT_00(lane));
>> +
>> + if (swing == 2 && pre_emp == 0 && link_rate != 540000) {
>> + writel(0x700, tcphy->base + TX_DIAG_TX_DRV(lane));
>> + writel(0x13c, tcphy->base + TX_TXCC_CAL_SCLR_MULT(lane));
>> + } else {
>> + writel(0x128, tcphy->base + TX_TXCC_CAL_SCLR_MULT(lane));
>> + writel(0x0400, tcphy->base + TX_DIAG_TX_DRV(lane));
>> + }
>> +
>> + val = readl(tcphy->base + XCVR_DIAG_PLLDRC_CTRL(lane));
>> + val = val & 0x8fff;
>> + switch (link_rate) {
>> + case 162000:
>> + case 270000:
>> + val |= (6 << 12);
>> + break;
>> + case 540000:
>> + val |= (4 << 12);
>> + break;
>> + }
>> + writel(val, tcphy->base + XCVR_DIAG_PLLDRC_CTRL(lane));
>> }
>>
>> static inline int property_enable(struct rockchip_typec_phy *tcphy,
>> @@ -754,30 +796,33 @@ static int tcphy_phy_init(struct rockchip_typec_phy *tcphy, u8 mode)
>> tcphy_cfg_24m(tcphy);
>>
>> if (mode == MODE_DFP_DP) {
>> - tcphy_cfg_dp_pll(tcphy);
>> + tcphy_cfg_dp_pll(tcphy, DEFAULT_RATE);
>> for (i = 0; i < 4; i++)
>> - tcphy_dp_cfg_lane(tcphy, i);
>> + tcphy_dp_cfg_lane(tcphy, DEFAULT_RATE, 0, 0, i);
>>
>> writel(PIN_ASSIGN_C_E, tcphy->base + PMA_LANE_CFG);
>> } else {
>> tcphy_cfg_usb3_pll(tcphy);
>> - tcphy_cfg_dp_pll(tcphy);
>> + tcphy_cfg_dp_pll(tcphy, DEFAULT_RATE);
>> if (tcphy->flip) {
>> tcphy_tx_usb3_cfg_lane(tcphy, 3);
>> tcphy_rx_usb3_cfg_lane(tcphy, 2);
>> - tcphy_dp_cfg_lane(tcphy, 0);
>> - tcphy_dp_cfg_lane(tcphy, 1);
>> + tcphy_dp_cfg_lane(tcphy, DEFAULT_RATE, 0, 0, 0);
>> + tcphy_dp_cfg_lane(tcphy, DEFAULT_RATE, 0, 0, 1);
>> } else {
>> tcphy_tx_usb3_cfg_lane(tcphy, 0);
>> tcphy_rx_usb3_cfg_lane(tcphy, 1);
>> - tcphy_dp_cfg_lane(tcphy, 2);
>> - tcphy_dp_cfg_lane(tcphy, 3);
>> + tcphy_dp_cfg_lane(tcphy, DEFAULT_RATE, 0, 0, 2);
>> + tcphy_dp_cfg_lane(tcphy, DEFAULT_RATE, 0, 0, 3);
>> }
>>
>> writel(PIN_ASSIGN_D_F, tcphy->base + PMA_LANE_CFG);
>> }
>>
>> - writel(DP_MODE_ENTER_A2, tcphy->base + DP_MODE_CTL);
>> + val = readl(tcphy->base + DP_MODE_CTL);
>> + val &= ~DP_MODE_MASK;
>> + val |= DP_MODE_ENTER_A2 | DP_LINK_RESET_DEASSERTED;
>> + writel(val, tcphy->base + DP_MODE_CTL);
>>
>> reset_control_deassert(tcphy->uphy_rst);
>>
>> @@ -990,7 +1035,7 @@ static int rockchip_dp_phy_power_on(struct phy *phy)
>> property_enable(tcphy, &cfg->uphy_dp_sel, 1);
>>
>> ret = readx_poll_timeout(readl, tcphy->base + DP_MODE_CTL,
>> - val, val & DP_MODE_A2, 1000,
>> + val, val & DP_MODE_A2_ACK, 1000,
>> PHY_MODE_SET_TIMEOUT);
>> if (ret < 0) {
>> dev_err(tcphy->dev, "failed to wait TCPHY enter A2\n");
>> @@ -999,13 +1044,19 @@ static int rockchip_dp_phy_power_on(struct phy *phy)
>>
>> tcphy_dp_aux_calibration(tcphy);
>>
>> - writel(DP_MODE_ENTER_A0, tcphy->base + DP_MODE_CTL);
>> + /* enter A0 mode */
>> + val = readl(tcphy->base + DP_MODE_CTL);
>> + val &= ~DP_MODE_MASK;
>> + val |= DP_MODE_ENTER_A0;
>> + writel(val, tcphy->base + DP_MODE_CTL);
>>
>> ret = readx_poll_timeout(readl, tcphy->base + DP_MODE_CTL,
>> - val, val & DP_MODE_A0, 1000,
>> + val, val & DP_MODE_A0_ACK, 1000,
>> PHY_MODE_SET_TIMEOUT);
>> if (ret < 0) {
>> - writel(DP_MODE_ENTER_A2, tcphy->base + DP_MODE_CTL);
>> + val &= ~DP_MODE_MASK;
>> + val |= DP_MODE_ENTER_A2;
>> + writel(val, tcphy->base + DP_MODE_CTL);
>> dev_err(tcphy->dev, "failed to wait TCPHY enter A0\n");
>> goto power_on_finish;
>> }
>> @@ -1023,6 +1074,7 @@ static int rockchip_dp_phy_power_on(struct phy *phy)
>> static int rockchip_dp_phy_power_off(struct phy *phy)
>> {
>> struct rockchip_typec_phy *tcphy = phy_get_drvdata(phy);
>> + u32 val;
>>
>> mutex_lock(&tcphy->lock);
>>
>> @@ -1031,7 +1083,10 @@ static int rockchip_dp_phy_power_off(struct phy *phy)
>>
>> tcphy->mode &= ~MODE_DFP_DP;
>>
>> - writel(DP_MODE_ENTER_A2, tcphy->base + DP_MODE_CTL);
>> + val = readl(tcphy->base + DP_MODE_CTL);
>> + val &= ~DP_MODE_MASK;
>> + val |= DP_MODE_ENTER_A2;
>> + writel(val, tcphy->base + DP_MODE_CTL);
>>
>> if (tcphy->mode == MODE_DISCONNECT)
>> tcphy_phy_deinit(tcphy);
>> @@ -1047,6 +1102,30 @@ static const struct phy_ops rockchip_dp_phy_ops = {
>> .owner = THIS_MODULE,
>> };
>>
>> +static int type_c_dp_phy_config(struct phy *phy, int link_rate,
> s/type_c/typec/ to be coherent with the rest of the code.
>
>> + int lanes, u8 swing, u8 pre_emp)
>> +{
>> + struct rockchip_typec_phy *tcphy = phy_get_drvdata(phy);
>> + u8 i;
>> +
>> + tcphy_cfg_dp_pll(tcphy, link_rate);
>> +
>> + if (tcphy->mode == MODE_DFP_DP) {
>> + for (i = 0; i < 4; i++)
>> + tcphy_dp_cfg_lane(tcphy, link_rate, swing, pre_emp, i);
>> + } else {
>> + if (tcphy->flip) {
>> + tcphy_dp_cfg_lane(tcphy, link_rate, swing, pre_emp, 0);
>> + tcphy_dp_cfg_lane(tcphy, link_rate, swing, pre_emp, 1);
>> + } else {
>> + tcphy_dp_cfg_lane(tcphy, link_rate, swing, pre_emp, 2);
>> + tcphy_dp_cfg_lane(tcphy, link_rate, swing, pre_emp, 3);
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static int tcphy_parse_dt(struct rockchip_typec_phy *tcphy,
>> struct device *dev)
>> {
>> @@ -1087,6 +1166,14 @@ static int tcphy_parse_dt(struct rockchip_typec_phy *tcphy,
>> return PTR_ERR(tcphy->tcphy_rst);
>> }
>>
>> + /*
>> + * check if phy_config pass from dts, if yes,
>> + * need to use this phy config to do software training later
>> + */
>> + if (!of_property_read_u32_array(dev->of_node, "rockchip,phy_config",
>> + (u32 *)tcphy->config, sizeof(tcphy->config) / sizeof(u32)))
>> + tcphy->need_software_training = 1;
>> +
>> return 0;
>> }
>>
>> @@ -1171,6 +1258,7 @@ static int rockchip_typec_phy_probe(struct platform_device *pdev)
>> }
>> }
>>
>> + tcphy->typec_phy_config = type_c_dp_phy_config;
> type_c_dp_phy_config -> typec_dp_phy_config
>
>> pm_runtime_enable(dev);
>>
>> for_each_available_child_of_node(np, child_np) {
>> diff --git a/include/soc/rockchip/rockchip_phy_typec.h b/include/soc/rockchip/rockchip_phy_typec.h
>> new file mode 100644
>> index 0000000..e25840e
>> --- /dev/null
>> +++ b/include/soc/rockchip/rockchip_phy_typec.h
>> @@ -0,0 +1,72 @@
>> +/*
> Add the SPDX License identifier ...
>
>> + * Copyright (c) 2018, Fuzhou Rockchip Electronics Co., Ltd
>> + * Author: Lin Huang <hl@rock-chips.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
>> + * more details.
> ... and remove the above notice.
>
>> + */
>> +#ifndef __SOC_ROCKCHIP_PHY_TYPEC_H
>> +#define __SOC_ROCKCHIP_PHY_TYPEC_H
>> +
>> +
> Remove the extra new line.
>
>> +struct usb3phy_reg {
>> + u32 offset;
>> + u32 enable_bit;
>> + u32 write_enable;
>> +};
>> +
>> +/**
>> + * struct rockchip_usb3phy_port_cfg: usb3-phy port configuration.
>> + * @reg: the base address for usb3-phy config.
>> + * @typec_conn_dir: the register of type-c connector direction.
>> + * @usb3tousb2_en: the register of type-c force usb2 to usb2 enable.
>> + * @external_psm: the register of type-c phy external psm clock.
>> + * @pipe_status: the register of type-c phy pipe status.
>> + * @usb3_host_disable: the register of type-c usb3 host disable.
>> + * @usb3_host_port: the register of type-c usb3 host port.
>> + * @uphy_dp_sel: the register of type-c phy DP select control.
>> + */
>> +struct rockchip_usb3phy_port_cfg {
>> + unsigned int reg;
>> + struct usb3phy_reg typec_conn_dir;
>> + struct usb3phy_reg usb3tousb2_en;
>> + struct usb3phy_reg external_psm;
>> + struct usb3phy_reg pipe_status;
>> + struct usb3phy_reg usb3_host_disable;
>> + struct usb3phy_reg usb3_host_port;
>> + struct usb3phy_reg uphy_dp_sel;
>> +};
>> +
>> +struct phy_config {
>> + int swing;
>> + int pe;
>> +};
>> +
>> +struct rockchip_typec_phy {
>> + struct device *dev;
>> + void __iomem *base;
>> + struct extcon_dev *extcon;
>> + struct regmap *grf_regs;
>> + struct clk *clk_core;
>> + struct clk *clk_ref;
>> + struct reset_control *uphy_rst;
>> + struct reset_control *pipe_rst;
>> + struct reset_control *tcphy_rst;
>> + struct rockchip_usb3phy_port_cfg *port_cfgs;
>> + /* mutex to protect access to individual PHYs */
>> + struct mutex lock;
>> + struct phy_config config[3][4];
>> + u8 need_software_training;
>> + bool flip;
>> + u8 mode;
>> + int (*typec_phy_config)(struct phy *phy, int link_rate,
>> + int lanes, u8 swing, u8 pre_emp);
>> +};
>> +
>> +#endif
> Best regards,
> Enric
>
>> --
>> 2.7.4
>>
>>
>> _______________________________________________
>> Linux-rockchip mailing list
>> Linux-rockchip at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
>
>
^ permalink raw reply
* [PATCH v7 11/24] ASoC: qdsp6: q6afe: Add support to MI2S ports
From: Banajit Goswami @ 2018-05-09 3:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180501120820.11016-12-srinivas.kandagatla@linaro.org>
On 5/1/2018 5:08 AM, Srinivas Kandagatla wrote:
> This patch adds support to 4 MI2S ports on LPASS.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Reviewed-and-tested-by: Rohit kumar <rohitkr@codeaurora.org>
> ---
> sound/soc/qcom/qdsp6/q6afe.c | 224 +++++++++++++++++++++++++++++++++++++++++++
> sound/soc/qcom/qdsp6/q6afe.h | 13 +++
> 2 files changed, 237 insertions(+)
>
> diff --git a/sound/soc/qcom/qdsp6/q6afe.c b/sound/soc/qcom/qdsp6/q6afe.c
> index be55b3ab045f..ceb18aaa5af4 100644
> --- a/sound/soc/qcom/qdsp6/q6afe.c
> +++ b/sound/soc/qcom/qdsp6/q6afe.c
> @@ -14,6 +14,10 @@
> #include <linux/spinlock.h>
> #include <linux/delay.h>
> #include <linux/soc/qcom/apr.h>
> +#include <sound/soc.h>
> +#include <sound/soc-dai.h>
> +#include <sound/pcm.h>
<snip>
> union afe_port_config {
> struct afe_param_id_hdmi_multi_chan_audio_cfg hdmi_multi_ch;
> struct afe_param_id_slimbus_cfg slim_cfg;
> + struct afe_param_id_i2s_cfg i2s_cfg;
> } __packed;
>
> struct q6afe_port {
> @@ -210,6 +264,22 @@ static struct afe_port_map port_maps[AFE_PORT_MAX] = {
> SLIMBUS_4_RX, 1, 1},
> [SLIMBUS_5_RX] = { AFE_PORT_ID_SLIMBUS_MULTI_CHAN_5_RX,
> SLIMBUS_5_RX, 1, 1},
> + [QUATERNARY_MI2S_RX] = { AFE_PORT_ID_QUATERNARY_MI2S_RX,
> + QUATERNARY_MI2S_RX, 1, 1},
> + [QUATERNARY_MI2S_TX] = { AFE_PORT_ID_QUATERNARY_MI2S_TX,
> + QUATERNARY_MI2S_TX, 0, 1},
> + [SECONDARY_MI2S_RX] = { AFE_PORT_ID_SECONDARY_MI2S_RX,
> + SECONDARY_MI2S_RX, 1, 1},
> + [SECONDARY_MI2S_TX] = { AFE_PORT_ID_SECONDARY_MI2S_TX,
> + SECONDARY_MI2S_TX, 0, 1},
> + [TERTIARY_MI2S_RX] = { AFE_PORT_ID_TERTIARY_MI2S_RX,
> + TERTIARY_MI2S_RX, 1, 1},
> + [TERTIARY_MI2S_TX] = { AFE_PORT_ID_TERTIARY_MI2S_TX,
> + TERTIARY_MI2S_TX, 0, 1},
> + [PRIMARY_MI2S_RX] = { AFE_PORT_ID_PRIMARY_MI2S_RX,
> + PRIMARY_MI2S_RX, 1, 1},
> + [PRIMARY_MI2S_TX] = { AFE_PORT_ID_PRIMARY_MI2S_TX,
> + PRIMARY_MI2S_RX, 0, 1},
Can these be added after SLIMBUS_6_RX?
Also, for better arrangement, please add the port_maps from
PRIMARY_MI2S_RX to QUATERNARY_MI2S_TX in the same sequence of definition
of AFE ports.
Otherwise LGTM.
Once fixed the above comment add-
Acked-by: Banajit Goswami <bgoswami@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] hwmon: (aspeed-pwm-tacho) Use 24MHz clock
From: Lei YU @ 2018-05-09 3:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8a801894-4293-d2e8-4673-3d9ff5c2a5bb@roeck-us.net>
On Tue, May 8, 2018 at 9:51 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> No mixed C/C++ comments in hwmon drivers.
>
>> aspeed_set_clock_source(priv->regmap, 0);
>> + priv->clk_freq = 24000000;
>>
>
>
> Are you saying that clk_get_rate() is wrong ? Anyway, if the DT is bad, it
> should be fixed.
Nope, clk_get_rate() is OK.
The reason I make this change is because the PWM supports two types of clock
source, the 24MHz or the clock from memory controller.
If the DT uses 24MHz clock, this code is OK.
But if the DT configs this pwm to use mclk (memory controller clk), this piece
of code becomes wrong, because the code
`aspeed_set_clock_source(priv->regmap, 0)` configs the device to use the 24MHz
clock.
So no matter what DT configs the clk, this driver *always* uses 24MHz clock.
That's why I want to make this change.
> I am not a friend of hacking drivers to fix up bad DTs, and much less so
> without explanation.
> Plus, how do we know that the next chip supported by the driver doesn't have
> a 32MHz clock ?
This driver currently supports ast2400 and ast2500, and they both use 24MHz
clock.
In case future device uses a different clock, we can update this code, right?
> Really, please fix the DT.
Sure, I will send patch to config the clock to use fixed 24MHz clock as well.
>
> Guenter
>
>> aspeed_create_type(priv);
>>
>
>
^ permalink raw reply
* [PATCH 1/4] drm/rockchip: add transfer function for cdn-dp
From: hl @ 2018-05-09 2:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFqH_522eDgyknF+sRGyZzusL7Ld0o_N-SP1jXCG1iwmav-n0Q@mail.gmail.com>
Hi Enric,
On Monday, May 07, 2018 07:27 PM, Enric Balletbo Serra wrote:
> Hi Lin,
>
> I am interested in these patches, could you cc me on newer versions? Thanks.
>
> Some comments below.
Sure, will cc to you next version.
>
> 2018-05-04 10:08 GMT+02:00 Lin Huang <hl@rock-chips.com>:
>> From: Chris Zhong <zyw@rock-chips.com>
>>
>> We may support training outside firmware, so we need support
>> dpcd read/write to get the message or do some setting with
>> display.
>>
>> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
>> Signed-off-by: Lin Huang <hl@rock-chips.com>
>> ---
>> drivers/gpu/drm/rockchip/cdn-dp-core.c | 55 ++++++++++++++++++++++++----
>> drivers/gpu/drm/rockchip/cdn-dp-core.h | 1 +
>> drivers/gpu/drm/rockchip/cdn-dp-reg.c | 66 +++++++++++++++++++++++++++++-----
>> drivers/gpu/drm/rockchip/cdn-dp-reg.h | 14 ++++++--
>> 4 files changed, 119 insertions(+), 17 deletions(-)
>>
> In general, for this patch and all the other patches in the series I
> saw that checkpatch spits out some warnings, could you fix these and
> ideally run checkpatch with the --strict --subjective option?
Okay.
>
>> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c
>> index c6fbdcd..268c190 100644
>> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
>> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
>> @@ -176,8 +176,8 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device *dp, u8 *sink_count)
>> u8 value;
>>
>> *sink_count = 0;
>> - ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, &value, 1);
>> - if (ret)
>> + ret = drm_dp_dpcd_read(&dp->aux, DP_SINK_COUNT, &value, 1);
>> + if (ret < 0)
>> return ret;
>>
>> *sink_count = DP_GET_SINK_COUNT(value);
>> @@ -374,9 +374,9 @@ static int cdn_dp_get_sink_capability(struct cdn_dp_device *dp)
>> if (!cdn_dp_check_sink_connection(dp))
>> return -ENODEV;
>>
>> - ret = cdn_dp_dpcd_read(dp, DP_DPCD_REV, dp->dpcd,
>> - DP_RECEIVER_CAP_SIZE);
>> - if (ret) {
>> + ret = drm_dp_dpcd_read(&dp->aux, DP_DPCD_REV, dp->dpcd,
>> + sizeof(dp->dpcd));
>> + if (ret < 0) {
>> DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
>> return ret;
>> }
>> @@ -582,8 +582,8 @@ static bool cdn_dp_check_link_status(struct cdn_dp_device *dp)
>> if (!port || !dp->link.rate || !dp->link.num_lanes)
>> return false;
>>
>> - if (cdn_dp_dpcd_read(dp, DP_LANE0_1_STATUS, link_status,
>> - DP_LINK_STATUS_SIZE)) {
>> + if (drm_dp_dpcd_read_link_status(&dp->aux, link_status) !=
>> + DP_LINK_STATUS_SIZE) {
>> DRM_ERROR("Failed to get link status\n");
>> return false;
>> }
>> @@ -1012,6 +1012,40 @@ static int cdn_dp_pd_event(struct notifier_block *nb,
>> return NOTIFY_DONE;
>> }
>>
>> +static ssize_t cdn_dp_aux_transfer(struct drm_dp_aux *aux,
>> + struct drm_dp_aux_msg *msg)
>> +{
>> + struct cdn_dp_device *dp = container_of(aux, struct cdn_dp_device, aux);
>> + int ret;
>> + u8 status;
>> +
>> + switch (msg->request & ~DP_AUX_I2C_MOT) {
>> + case DP_AUX_NATIVE_WRITE:
>> + case DP_AUX_I2C_WRITE:
>> + case DP_AUX_I2C_WRITE_STATUS_UPDATE:
>> + ret = cdn_dp_dpcd_write(dp, msg->address, msg->buffer,
>> + msg->size);
>> + break;
>> + case DP_AUX_NATIVE_READ:
>> + case DP_AUX_I2C_READ:
>> + ret = cdn_dp_dpcd_read(dp, msg->address, msg->buffer,
>> + msg->size);
>> + break;
>> + default:
>> + return -EINVAL;
>> + }
>> +
>> + status = cdn_dp_get_aux_status(dp);
>> + if (status == AUX_STAUS_ACK)
>> + msg->reply = DP_AUX_NATIVE_REPLY_ACK;
>> + else if (status == AUX_STAUS_NACK)
>> + msg->reply = DP_AUX_NATIVE_REPLY_NACK;
>> + else if (status == AUX_STAUS_DEFER)
>> + msg->reply = DP_AUX_NATIVE_REPLY_DEFER;
>> +
> I think that you would mean STATUS instead of STAUS on these defines.
>
> What happens if the status is AUX_STATUS_SINK_ERROR or AUX_STATUS_BUS_ERROR?
drm_dp_i2c_do_msg() will mark it as invalid i2c relay and return error.
>
>> + return ret;
>> +}
>> +
>> static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
>> {
>> struct cdn_dp_device *dp = dev_get_drvdata(dev);
>> @@ -1030,6 +1064,13 @@ static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
>> dp->active = false;
>> dp->active_port = -1;
>> dp->fw_loaded = false;
>> + dp->aux.name = "DP-AUX";
>> + dp->aux.transfer = cdn_dp_aux_transfer;
>> + dp->aux.dev = dev;
>> +
>> + ret = drm_dp_aux_register(&dp->aux);
>> + if (ret)
>> + return ret;
>>
>> INIT_WORK(&dp->event_work, cdn_dp_pd_event_work);
>>
>> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h b/drivers/gpu/drm/rockchip/cdn-dp-core.h
>> index f57e296..46159b2 100644
>> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
>> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
>> @@ -78,6 +78,7 @@ struct cdn_dp_device {
>> struct platform_device *audio_pdev;
>> struct work_struct event_work;
>> struct edid *edid;
>> + struct drm_dp_aux aux;
>>
>> struct mutex lock;
>> bool connected;
>> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
>> index eb3042c..b2f532a 100644
>> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
>> +++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
>> @@ -221,7 +221,11 @@ static int cdn_dp_reg_write_bit(struct cdn_dp_device *dp, u16 addr,
>> sizeof(field), field);
>> }
>>
>> -int cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
>> +/*
>> + * Returns the number of bytes transferred on success, or a negative error
>> + * code on failure. -ETIMEDOUT is returned if mailbox message not send success;
>> + */
> Returns the number of bytes or -ETIMEDOUT, no other negative errors
> can be returned, right?
>
> I am not English native but the last phrase sounds incorrect to me,
> I'd rephrase it: (open to suggestions)
>
> -ETIMEDOUT if fails to receive the mailbox message.
>
>> +ssize_t cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
>> {
>> u8 msg[5], reg[5];
>> int ret;
>> @@ -247,24 +251,40 @@ int cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
>> goto err_dpcd_read;
>>
>> ret = cdn_dp_mailbox_read_receive(dp, data, len);
>> + if (!ret)
>> + return len;
>>
>> err_dpcd_read:
>> + DRM_DEV_ERROR(dp->dev, "dpcd read failed: %d\n", ret);
>> return ret;
>> }
>>
>> -int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value)
>> +#define CDN_AUX_HEADER_SIZE 5
>> +#define CDN_AUX_MSG_SIZE 20
>> +/*
>> + * Returns the number of bytes transferred on success, or a negative error
>> + * code on failure. -ETIMEDOUT is returned if mailbox message not send success;
> Same as above. Sounds incorrect to me.
>
>> + * -EINVAL is return if get the wrong data size after message send.
> Same here.
>
>> + */
>> +ssize_t cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
>> {
>> - u8 msg[6], reg[5];
>> + u8 msg[CDN_AUX_MSG_SIZE + CDN_AUX_HEADER_SIZE];
>> + u8 reg[CDN_AUX_HEADER_SIZE];
>> int ret;
>>
>> - msg[0] = 0;
>> - msg[1] = 1;
>> + if (WARN_ON(len > CDN_AUX_MSG_SIZE) || WARN_ON(len <= 0))
>> + return -EINVAL;
>> +
>> + msg[0] = (len >> 8) & 0xff;
>> + msg[1] = len & 0xff;
>> msg[2] = (addr >> 16) & 0xff;
>> msg[3] = (addr >> 8) & 0xff;
>> msg[4] = addr & 0xff;
>> - msg[5] = value;
>> +
>> + memcpy(msg + CDN_AUX_HEADER_SIZE, data, len);
>> +
>> ret = cdn_dp_mailbox_send(dp, MB_MODULE_ID_DP_TX, DPTX_WRITE_DPCD,
>> - sizeof(msg), msg);
>> + CDN_AUX_HEADER_SIZE + len, msg);
>> if (ret)
>> goto err_dpcd_write;
>>
>> @@ -277,8 +297,12 @@ int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value)
>> if (ret)
>> goto err_dpcd_write;
>>
>> - if (addr != (reg[2] << 16 | reg[3] << 8 | reg[4]))
>> + if ((len != (reg[0] << 8 | reg[1])) ||
>> + (addr != (reg[2] << 16 | reg[3] << 8 | reg[4]))) {
>> ret = -EINVAL;
>> + } else {
>> + return len;
>> + }
>>
>> err_dpcd_write:
>> if (ret)
>> @@ -286,6 +310,32 @@ int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value)
>> return ret;
>> }
>>
>> +int cdn_dp_get_aux_status(struct cdn_dp_device *dp)
>> +{
>> + u8 status;
>> + int ret;
>> +
>> + ret = cdn_dp_mailbox_send(dp, MB_MODULE_ID_DP_TX, DPTX_GET_LAST_AUX_STAUS,
>> + 0, NULL);
>> + if (ret)
>> + goto err_get_hpd;
>> +
>> + ret = cdn_dp_mailbox_validate_receive(dp, MB_MODULE_ID_DP_TX,
>> + DPTX_GET_LAST_AUX_STAUS, sizeof(status));
>> + if (ret)
>> + goto err_get_hpd;
>> +
>> + ret = cdn_dp_mailbox_read_receive(dp, &status, sizeof(status));
>> + if (ret)
>> + goto err_get_hpd;
>> +
>> + return status;
>> +
>> +err_get_hpd:
>> + DRM_DEV_ERROR(dp->dev, "get aux status failed: %d\n", ret);
>> + return ret;
>> +}
>> +
>> int cdn_dp_load_firmware(struct cdn_dp_device *dp, const u32 *i_mem,
>> u32 i_size, const u32 *d_mem, u32 d_size)
>> {
>> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.h b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
>> index c4bbb4a83..aedf2dc 100644
>> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.h
>> +++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
>> @@ -328,6 +328,13 @@
>> #define GENERAL_BUS_SETTINGS 0x03
>> #define GENERAL_TEST_ACCESS 0x04
>>
>> +/* AUX status*/
>> +#define AUX_STAUS_ACK 0
>> +#define AUX_STAUS_NACK 1
>> +#define AUX_STAUS_DEFER 2
>> +#define AUX_STAUS_SINK_ERROR 3
>> +#define AUX_STAUS_BUS_ERROR 4
>> +
> For the five defines, s/STAUS/STATUS/
will fix it.
>
>> #define DPTX_SET_POWER_MNG 0x00
>> #define DPTX_SET_HOST_CAPABILITIES 0x01
>> #define DPTX_GET_EDID 0x02
>> @@ -469,8 +476,11 @@ int cdn_dp_set_host_cap(struct cdn_dp_device *dp, u8 lanes, bool flip);
>> int cdn_dp_event_config(struct cdn_dp_device *dp);
>> u32 cdn_dp_get_event(struct cdn_dp_device *dp);
>> int cdn_dp_get_hpd_status(struct cdn_dp_device *dp);
>> -int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value);
>> -int cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len);
>> +ssize_t cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr,
>> + u8 *data, u16 len);
>> +ssize_t cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr,
>> + u8 *data, u16 len);
>> +int cdn_dp_get_aux_status(struct cdn_dp_device *dp);
>> int cdn_dp_get_edid_block(void *dp, u8 *edid,
>> unsigned int block, size_t length);
>> int cdn_dp_train_link(struct cdn_dp_device *dp);
>> --
>> 2.7.4
>>
>>
>> _______________________________________________
>> Linux-rockchip mailing list
>> Linux-rockchip at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
>
>
^ permalink raw reply
* [PATCH] alpha: io: reorder barriers to guarantee writeX() and iowriteX() ordering #2
From: Matt Turner @ 2018-05-09 2:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2fd54f7c-ff73-5935-a253-c924f4373cc6@codeaurora.org>
On Fri, Apr 20, 2018 at 9:20 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
> Hi Matt,
>
> On 4/17/2018 2:43 PM, Sinan Kaya wrote:
>> On 4/16/2018 6:16 PM, Sinan Kaya wrote:
>>> memory-barriers.txt has been updated with the following requirement.
>>>
>>> "When using writel(), a prior wmb() is not needed to guarantee that the
>>> cache coherent memory writes have completed before writing to the MMIO
>>> region."
>>>
>>> Current writeX() and iowriteX() implementations on alpha are not
>>> satisfying this requirement as the barrier is after the register write.
>>>
>>> Move mb() in writeX() and iowriteX() functions to guarantee that HW
>>> observes memory changes before performing register operations.
>>>
>>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>>> Reported-by: Arnd Bergmann <arnd@arndb.de>
>>> ---
>>> arch/alpha/kernel/io.c | 14 +++++++-------
>>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> Sorry for catching this late but this also needs to go to 4.17 after
>> review.
>>
>> I missed the writel() implementation on arch/alpha/kernel/io.c file
>> on my first patch.
>>
>
> Can you also queue this for 4.17?
>
> There are already drivers checked into 4.17 that dropped the unnecessary
> barriers.
>
> I really hate to see Alpha broken because of this.
Yes, I will pick it up for 4.17.
Thanks for the patch.
^ permalink raw reply
* [PATCH v7 10/24] ASoC: qdsp6: qdafe: Add SLIMBus port Support
From: Banajit Goswami @ 2018-05-09 2:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180501120820.11016-11-srinivas.kandagatla@linaro.org>
On 5/1/2018 5:08 AM, Srinivas Kandagatla wrote:
> This patch adds support to 6 SLIMBus AFE ports, which are used as
> backend dais.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Reviewed-and-tested-by: Rohit kumar <rohitkr@codeaurora.org>
> ---
> sound/soc/qcom/qdsp6/q6afe.c | 129 +++++++++++++++++++++++++++++++++++++++++++
> sound/soc/qcom/qdsp6/q6afe.h | 14 +++++
> 2 files changed, 143 insertions(+)
>
>
Acked-by: Banajit Goswami <bgoswami@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v7 09/24] ASoC: qdsp6: q6afe: Add q6afe driver
From: Banajit Goswami @ 2018-05-09 2:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180501120820.11016-10-srinivas.kandagatla@linaro.org>
On 5/1/2018 5:08 AM, Srinivas Kandagatla wrote:
> This patch adds support to Q6AFE (Audio Front End) module on Q6DSP.
>
> AFE module sits right at the other end of cpu where the codec/audio
> devices are connected.
>
> AFE provides abstraced interfaces to both hardware and virtual devices.
> Each AFE tx/rx port can be configured to connect to one of the hardware
> devices like codec, hdmi, slimbus, i2s and so on. AFE services include
> starting, stopping, and if needed, any configurations of the ports.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Reviewed-and-tested-by: Rohit kumar <rohitkr@codeaurora.org>
> ---
> sound/soc/qcom/Kconfig | 4 +
> sound/soc/qcom/qdsp6/Makefile | 1 +
> sound/soc/qcom/qdsp6/q6afe.c | 536 ++++++++++++++++++++++++++++++++++++++++++
> sound/soc/qcom/qdsp6/q6afe.h | 35 +++
> 4 files changed, 576 insertions(+)
> create mode 100644 sound/soc/qcom/qdsp6/q6afe.c
> create mode 100644 sound/soc/qcom/qdsp6/q6afe.h
>
Acked-by: Banajit Goswami <bgoswami@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability
From: JeffyChen @ 2018-05-09 2:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=W_v+aoNT09k-2exVABTFzOp0heY-XWcLi95uPisZhiGQ@mail.gmail.com>
Hi Doug,
On 05/09/2018 03:46 AM, Doug Anderson wrote:
> One note is that in the case Brian points at (where we need to
> simulate EDGE_BOTH by swapping edges) we purposely ignored the TRM and
> we needed to do that to avoid losing interrupts. For details, see
> commit 53b1bfc76df2 ("pinctrl: rockchip: Avoid losing interrupts when
> supporting both edges"). We did this because:
>
> 1. We believed that the IP block in Rockchip SoCs has nearly the same
> logic as "gpio-dwapb.c" and that's what "gpio-dwapb.c" did.
>
hmm, but i saw the gpio-dwapb.c actually toggle trigger after handle
irq, which might avoid the race Brian mentioned:
+ generic_handle_irq(gpio_irq);
+ irq_status &= ~BIT(hwirq);
+
+ if ((irq_get_trigger_type(gpio_irq) & IRQ_TYPE_SENSE_MASK)
+ == IRQ_TYPE_EDGE_BOTH)
+ dwapb_toggle_trigger(gpio, hwirq);
and i also saw ./qcom/pinctrl-msm.c do the
toggle(msm_gpio_update_dual_edge_pos) at the end of
msm_gpio_irq_set_type and msm_gpio_irq_ack, that seems can avoid the
polarity races too.
> 2. We were actually losing real interrupts and this was the only way
> we could figure out how to fix it.
>
> When I tested that back in the day I was fairly convinced that we
> weren't losing any interrupts in the EDGE_BOTH case after my fix, but
> I certainly could have messed up.
>
>
> For the EDGE_BOTH case it was important not to lose an interrupt
> because, as you guys are talking about, we could end up configured the
> wrong way. I think in your case where you're just picking one
> polarity losing an interrupt shouldn't matter since it's undefined
> exactly if an edge happens while you're in the middle of executing
> rockchip_irq_set_type(). Is that right?
right, so we now have 2 cases: rockchip_irq_demux/ rockchip_irq_set_type
if i'm right about the spurious irq(only happen when set rising for a
high gpio, or set falling for a low gpio), then:
1/ rockchip_irq_demux
it's important to not losing irqs in this case, maybe we can
a) ack irq
b) update polarity for edge both irq
we don't need to disable irq in b), since we would not hit the spurious
irq cases here(always check gpio level to toggle it)
2/ rockchip_irq_set_type
it's important to not having spurious irqs
so we can disable irq during changing polarity only in these case:
((rising && gpio is heigh) || (falling && gpio is low))
i'm still confirming the spurious irq with IC guys.
>
>
> -Doug
>
>
>
^ permalink raw reply
* [PATCH] arm64: dts: sprd: fix typo in 'remote-endpoint'
From: Chunyan Zhang @ 2018-05-09 1:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508150952.24562-4-robh@kernel.org>
Hi Rob,
On 8 May 2018 at 23:09, Rob Herring <robh@kernel.org> wrote:
> dtc now warns on incomplete OF graph endpoint connections:
>
> arch/arm64/boot/dts/sprd/sp9860g-1h10.dtb: Warning (graph_endpoint): /soc/stm at 10006000/port/endpoint: graph connection to node '/soc/funnel at 10001000/ports/port at 2/endpoint' is not bidirectional
>
> The cause is a typo in 'remote-endpoint'.
Thanks for fixing this and,
Acked-by: Chunyan Zhang <zhang.lyra@gmail.com>
>
> Cc: Orson Zhai <orsonzhai@gmail.com>
> Cc: Baolin Wang <baolin.wang@linaro.org>
> Cc: Chunyan Zhang <zhang.lyra@gmail.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> arch/arm64/boot/dts/sprd/sc9860.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi b/arch/arm64/boot/dts/sprd/sc9860.dtsi
> index 5dbfb796d9f9..dcd03ffcda03 100644
> --- a/arch/arm64/boot/dts/sprd/sc9860.dtsi
> +++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
> @@ -326,7 +326,7 @@
> reg = <4>;
> soc_funnel_in_port1: endpoint {
> slave-mode;
> - remote-endpioint =
> + remote-endpoint =
> <&stm_out_port>;
> };
> };
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH] clk: imx6ull: use OSC clock during AXI rate change
From: Jacky Bai @ 2018-05-09 1:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152580354289.138124.13657232356773397650@swboyd.mtv.corp.google.com>
> Subject: Re: [PATCH] clk: imx6ull: use OSC clock during AXI rate change
>
> Quoting Stefan Agner (2018-05-08 06:20:03)
> > On 08.05.2018 09:32, Jacky Bai wrote:
> > >
> > > I have tried two 6ULL board, I don't meet such issue. System can
> > > boot up successfully with commit 6f9575e55632 included.
> > > Anyway, the change in this patch is ok for me. it is no harm to the
> > > BUS clock change flow.
> >
> > Hm, that is interesting, maybe it is because we use a different SKU?
> > Or maybe bootloader?
> >
> > I tested here with a 800 MHz clocked variant on a Colibri iMX6ULL
> > using U-Boot 2016.11.
> >
>
> I'll throw this into fixes today because it fixes something to be useful. It's still
> interesting to see what's different between the two setups though.
Thanks.
I will find some 800MHz parts and have a try with different bootloader later.
Will let you know, when I have some results.
Jacky
^ permalink raw reply
* [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules
From: Eric W. Biederman @ 2018-05-09 1:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508140640.0e312dba025df75cbf205cdb@arm.com>
Kim Phillips <kim.phillips@arm.com> writes:
> This patch is in the context of allowing the Coresight h/w
> trace driver suite to be loaded as modules. Coresight uses
> find_task_by_vpid when running in direct capture mode (via sysfs)
> when getting/setting the context ID comparator to trigger on
> (/sys/bus/coresight/devices/<x>.etm/ctxid_pid).
Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
There is no way to implement a sysfs file that takes a pid correctly.
Don't do it.
Pids are tied to pid namespaces and sysfs deliberately does not do
anything remotely resembly a pid namespace.
Eric
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Oleg Nesterov <oleg@redhat.com>
> Cc: Gargi Sharma <gs051095@gmail.com>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: Pavel Tatashin <pasha.tatashin@oracle.com>
> Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
> Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
> Cc: David Howells <dhowells@redhat.com>
> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> Signed-off-by: Kim Phillips <kim.phillips@arm.com>
> ---
> Current CoreSight callsite:
>
> https://lxr.missinglinkelectronics.com/linux/include/linux/coresight.h#L285
>
> A quick look didn't find anything, but if Coresight needs to do
> something differently, please comment.
>
> kernel/pid.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/pid.c b/kernel/pid.c
> index 157fe4b19971..92b1b623f3e0 100644
> --- a/kernel/pid.c
> +++ b/kernel/pid.c
> @@ -342,6 +342,7 @@ struct task_struct *find_task_by_vpid(pid_t vnr)
> {
> return find_task_by_pid_ns(vnr, task_active_pid_ns(current));
> }
> +EXPORT_SYMBOL_GPL(find_task_by_vpid);
>
> struct task_struct *find_get_task_by_vpid(pid_t nr)
> {
^ permalink raw reply
* [PATCH v7 7/7] arm64: defconfig: update config for Rockchip PCIe
From: Shawn Lin @ 2018-05-09 1:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525828278-69800-1-git-send-email-shawn.lin@rock-chips.com>
Now Rockchip PCIe drivers could support both of RC mode and EP
mode, so we need rename the config name. This patch updates
defconfig to reflect the fact that we want to build Rockchip PCIe
controller as RC mode, into a module as before.
Cc: linux-arm-kernel at lists.infradead.org
Cc: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
arch/arm64/configs/defconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 1d3b406..8fd8bae 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -78,7 +78,8 @@ CONFIG_PCIE_ARMADA_8K=y
CONFIG_PCI_AARDVARK=y
CONFIG_PCI_TEGRA=y
CONFIG_PCIE_RCAR=y
-CONFIG_PCIE_ROCKCHIP=m
+CONFIG_PCIE_ROCKCHIP=y
+CONFIG_PCIE_ROCKCHIP_HOST=m
CONFIG_PCI_HOST_GENERIC=y
CONFIG_PCI_XGENE=y
CONFIG_PCI_HOST_THUNDER_PEM=y
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox