* Re: [PATCH v4 2/6] dt-bindings: interrupt-controller: Add Loongson HTVEC
From: Marc Zyngier @ 2020-05-26 9:53 UTC (permalink / raw)
To: Jiaxun Yang
Cc: Rob Herring, Thomas Gleixner, Jason Cooper, Huacai Chen,
linux-kernel, devicetree, linux-mips
In-Reply-To: <20200526172653.0a19f375@halation.net.flygoat.com>
On 2020-05-26 10:26, Jiaxun Yang wrote:
> On Mon, 25 May 2020 11:12:26 +0100
> Marc Zyngier <maz@kernel.org> wrote:
>
>> On Sat, 16 May 2020 09:29:02 +0100,
>> Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>> >
>> > Add binding for Loongson-3 HyperTransport Interrupt Vector
>> > Controller.
>> >
>> > Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
>> > --
>> > v4: Drop ref, '|', add additionalProperties, fix example
>>
>> Rob, do you have any input on this?
>
> Oops, looks like I was in-reply into wrong patch topic for this patch,
> should I resend this series into correct thread?
No, this series is fine as it is. TBH, your practice of sending
a series in reply to the previous version is not that useful
(I personally find it very annoying).
It would also be a big improvement if you sent a cover letter
with your patches (using --cover-letter when generating the patches).
I'll wait for Rob to comment on this patch as well as patch #4.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [GIT PULL] Immutable branch between MFD, IIO and Power due for the v5.8 merge window
From: Lee Jones @ 2020-05-26 9:47 UTC (permalink / raw)
To: Saravanan Sekar
Cc: andy.shevchenko, robh+dt, jic23, knaack.h, lars, pmeerw, sre,
devicetree, linux-kernel, linux-iio, linux-pm
In-Reply-To: <20200526090646.25827-1-sravanhome@gmail.com>
Enjoy!
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git tags/ib-mfd-iio-power-v5.8
for you to fetch changes up to 904ac71f4b0c1c26ec47ff597cb3d3c7d36e618d:
MAINTAINERS: Add entry for mp2629 Battery Charger driver (2020-05-26 10:42:02 +0100)
----------------------------------------------------------------
Immutable branch between MFD, IIO and Power due for the v5.8 merge window
----------------------------------------------------------------
Saravanan Sekar (6):
dt-bindings: mfd: Add document bindings for mp2629
mfd: mp2629: Add support for mps battery charger
iio: adc: mp2629: Add support for mp2629 ADC driver
power: supply: Add support for mps mp2629 battery charger
power: supply: mp2629: Add impedance compensation config
MAINTAINERS: Add entry for mp2629 Battery Charger driver
Documentation/ABI/testing/sysfs-class-power-mp2629 | 8 +
.../devicetree/bindings/mfd/mps,mp2629.yaml | 62 ++
MAINTAINERS | 5 +
drivers/iio/adc/Kconfig | 10 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/mp2629_adc.c | 208 +++++++
drivers/mfd/Kconfig | 9 +
drivers/mfd/Makefile | 2 +
drivers/mfd/mp2629.c | 79 +++
drivers/power/supply/Kconfig | 10 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/mp2629_charger.c | 669 +++++++++++++++++++++
include/linux/mfd/mp2629.h | 26 +
13 files changed, 1090 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-power-mp2629
create mode 100644 Documentation/devicetree/bindings/mfd/mps,mp2629.yaml
create mode 100644 drivers/iio/adc/mp2629_adc.c
create mode 100644 drivers/mfd/mp2629.c
create mode 100644 drivers/power/supply/mp2629_charger.c
create mode 100644 include/linux/mfd/mp2629.h
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v5 2/2] clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller
From: Konrad Dybcio @ 2020-05-26 9:46 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Bryan O'Donoghue, Andy Gross, Bjorn Andersson,
Michael Turquette, Stephen Boyd, Rob Herring, linux-arm-msm,
linux-clk, Linux Kernel Mailing List, DTML, Shawn Guo, p.zabel,
Vincent Knecht
In-Reply-To: <af35d732-08bf-fe95-3c98-063b32fe992a@nexus-software.ie>
Just adding my few cents, working fine on Asus Zenfone 2 Z00T, MSM8939.
Tested-by: Konrad Dybcio <konradybcio@gmail.com>
^ permalink raw reply
* Re: [PATCH v5 2/2] clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller
From: Bryan O'Donoghue @ 2020-05-26 9:38 UTC (permalink / raw)
To: Bryan O'Donoghue, agross, bjorn.andersson, mturquette, sboyd,
robh+dt
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, shawn.guo,
p.zabel, vincent.knecht, konradybcio
In-Reply-To: <20200517131348.688405-3-bryan.odonoghue@linaro.org>
On 17/05/2020 14:13, Bryan O'Donoghue wrote:
> This patch adds support for the MSM8939 GCC. The MSM8939 is based on the
> MSM8916. MSM8939 is compatible in several ways with MSM8916 but, has
> additional functional blocks added which require additional PLL sources. In
> some cases functional blocks from the MSM8916 have different clock sources
> or different supported frequencies.
>
> Cc: Andy Gross <agross@kernel.org>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: linux-arm-msm@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Co-developed-by: Shawn Guo <shawn.guo@linaro.org>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> Tested-by: Vincent Knecht <vincent.knecht@mailoo.org>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
ping
just sending a reminder on this one
^ permalink raw reply
* Re: [PATCH v12 0/6] Add battery charger driver support for MP2629
From: Lee Jones @ 2020-05-26 9:34 UTC (permalink / raw)
To: Saravanan Sekar
Cc: andy.shevchenko, robh+dt, jic23, knaack.h, lars, pmeerw, sre,
devicetree, linux-kernel, linux-iio, linux-pm
In-Reply-To: <20200526090646.25827-1-sravanhome@gmail.com>
On Tue, 26 May 2020, Saravanan Sekar wrote:
> changes in v12:
> - added SOB Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
Looks like you added my Acked-by to every patch, when actually I only
Acked the MFD one. Fortunately, as I'm the one applying these, I can
strip them off, but please be more careful about which *-bys you apply
to which patches in the future.
> changes in v11:
> - module_remove part replaced by devm_add_action_or_reset in charger patch
> - minor review comments solved in mfd and adc patch
>
> I expect, that Lee will provide an immutable branch for me and
> Jonathan once the MFD bits have been reviewed. Please tell me,
> if I should prepare one instead.
I'll do this now.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* RE: [PATCH] dt-bindings: leds: fix macro names for pca955x
From: Flavio Suligoi @ 2020-05-26 9:31 UTC (permalink / raw)
To: Pavel Machek
Cc: Jacek Anaszewski, Dan Murphy, Rob Herring,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20200526092808.GC12838@amd>
> Subject: Re: [PATCH] dt-bindings: leds: fix macro names for pca955x
>
> On Tue 2020-05-26 09:25:58, Flavio Suligoi wrote:
> > > Subject: Re: [PATCH] dt-bindings: leds: fix macro names for pca955x
> > >
> > > On Tue 2020-05-26 11:20:52, Flavio Suligoi wrote:
> > > > The documentation reports the wrong macro names
> > > > related to the pca9532 instead of the pca955x
> > > >
> > > > Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
> > >
> > > Nothing obviously wrong, but why did you send it twice within half an
> > > hour?
> > > Pavel
> >
> > Sorry Pavel, with the first email I forgot to subscribe
> > to the linux-leds mailing list! 😊
>
> You really don't need to be subscribed on a list for trivial
> cleanups... Normally people would reply-all, anyway.
>
> BR,
> Pavel
Thanks for the explanation!
Regards,
Flavio
^ permalink raw reply
* Re: [PATCH] dt-bindings: leds: fix macro names for pca955x
From: Pavel Machek @ 2020-05-26 9:28 UTC (permalink / raw)
To: Flavio Suligoi
Cc: Jacek Anaszewski, Dan Murphy, Rob Herring,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <b58a76bed46141a1a7952303ec466f66@asem.it>
[-- Attachment #1: Type: text/plain, Size: 853 bytes --]
On Tue 2020-05-26 09:25:58, Flavio Suligoi wrote:
> > Subject: Re: [PATCH] dt-bindings: leds: fix macro names for pca955x
> >
> > On Tue 2020-05-26 11:20:52, Flavio Suligoi wrote:
> > > The documentation reports the wrong macro names
> > > related to the pca9532 instead of the pca955x
> > >
> > > Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
> >
> > Nothing obviously wrong, but why did you send it twice within half an
> > hour?
> > Pavel
>
> Sorry Pavel, with the first email I forgot to subscribe
> to the linux-leds mailing list! 😊
You really don't need to be subscribed on a list for trivial
cleanups... Normally people would reply-all, anyway.
BR,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v3 05/10] media: i2c: imx290: Add configurable link frequency and pixel rate
From: Andrey Konovalov @ 2020-05-26 9:27 UTC (permalink / raw)
To: Sakari Ailus
Cc: mchehab, manivannan.sadhasivam, linux-media, linux-kernel,
devicetree, linux-arm-kernel, c.barrett, a.brela, peter.griffin
In-Reply-To: <20200526091234.GH8214@valkosipuli.retiisi.org.uk>
Hi Sakari,
Thank you for the review!
On 26.05.2020 12:12, Sakari Ailus wrote:
> Hi Andrey,
>
> On Sun, May 24, 2020 at 10:25:00PM +0300, Andrey Konovalov wrote:
>> From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>>
>> IMX290 operates with multiple link frequency and pixel rate combinations.
>> The initial driver used a single setting for both but since we now have
>> the lane count support in place, let's add configurable link frequency
>> and pixel rate.
>>
>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
>> ---
>> drivers/media/i2c/imx290.c | 100 ++++++++++++++++++++++++-------------
>> 1 file changed, 66 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
>> index a361c9ac8bd5..e800557cf423 100644
>> --- a/drivers/media/i2c/imx290.c
>> +++ b/drivers/media/i2c/imx290.c
>> @@ -38,8 +38,6 @@
>> #define IMX290_HMAX_2_720 0x19C8
>> #define IMX290_HMAX_4_720 0x0CE4
>>
>> -#define IMX290_DEFAULT_LINK_FREQ 445500000
>> -
>> static const char * const imx290_supply_name[] = {
>> "vdda",
>> "vddd",
>> @@ -56,8 +54,6 @@ struct imx290_regval {
>> struct imx290_mode {
>> u32 width;
>> u32 height;
>> - u32 pixel_rate;
>> - u32 link_freq_index;
>>
>> const struct imx290_regval *data;
>> u32 data_size;
>> @@ -248,8 +244,13 @@ static const struct imx290_regval imx290_10bit_settings[] = {
>> };
>>
>> /* supported link frequencies */
>> -static const s64 imx290_link_freq[] = {
>> - IMX290_DEFAULT_LINK_FREQ,
>> +static const s64 imx290_link_freq_2lanes[] = {
>> + 891000000, /* 1920x1080 - 2 lane */
>> + 594000000, /* 1280x720 - 2 lane */
>> +};
>> +static const s64 imx290_link_freq_4lanes[] = {
>> + 445500000, /* 1920x1080 - 4 lane */
>> + 297000000, /* 1280x720 - 4 lane */
>> };
>>
>> /* Mode configs */
>> @@ -259,16 +260,12 @@ static const struct imx290_mode imx290_modes[] = {
>> .height = 1080,
>> .data = imx290_1080p_settings,
>> .data_size = ARRAY_SIZE(imx290_1080p_settings),
>> - .pixel_rate = 178200000,
>> - .link_freq_index = 0,
>> },
>> {
>> .width = 1280,
>> .height = 720,
>> .data = imx290_720p_settings,
>> .data_size = ARRAY_SIZE(imx290_720p_settings),
>> - .pixel_rate = 178200000,
>> - .link_freq_index = 0,
>> },
>> };
>>
>> @@ -442,6 +439,32 @@ static int imx290_get_fmt(struct v4l2_subdev *sd,
>> return 0;
>> }
>>
>> +static u8 imx290_get_link_freq_index(struct imx290 *imx290)
>> +{
>> + const struct imx290_mode *cur_mode = imx290->current_mode;
>> +
>> + return (cur_mode->width == 1920) ? 0 : 1;
>
> Could you use (imx290->current_mode - imx290_modes) / sizeof(*imx290_modes)
> or something like that? It'd have fewer chances of breaking if new modes
> are added.
>
>> +}
>> +
>> +static s64 imx290_get_link_freq(struct imx290 *imx290)
>> +{
>> + u8 index = imx290_get_link_freq_index(imx290);
>> +
>> + if (imx290->nlanes == 4)
>> + return imx290_link_freq_4lanes[index];
>> + else
>> + return imx290_link_freq_2lanes[index];
>
> Or even better: store the link frequencies to the modes themselves. They
> are a property of the modes after all.
Then we will get two sets (for 2 lanes and for 4 lanes) of two modes (1080p and 720p), right?
>> +}
>> +
>> +static u64 imx290_calc_pixel_rate(struct imx290 *imx290)
>> +{
>> + s64 link_freq = imx290_get_link_freq(imx290);
>> + u8 nlanes = imx290->nlanes;
>> +
>> + /* pixel rate = link_freq * 2 * nr_of_lanes / bits_per_sample */
>> + return (link_freq * 2 * nlanes / 10);
>> +}
>> +
>> static int imx290_set_fmt(struct v4l2_subdev *sd,
>> struct v4l2_subdev_pad_config *cfg,
>> struct v4l2_subdev_format *fmt)
>> @@ -475,10 +498,14 @@ static int imx290_set_fmt(struct v4l2_subdev *sd,
>> format = v4l2_subdev_get_try_format(sd, cfg, fmt->pad);
>> } else {
>> format = &imx290->current_format;
>> - __v4l2_ctrl_s_ctrl(imx290->link_freq, mode->link_freq_index);
>> - __v4l2_ctrl_s_ctrl_int64(imx290->pixel_rate, mode->pixel_rate);
>> -
>> imx290->current_mode = mode;
>> +
>> + if (imx290->link_freq)
>> + __v4l2_ctrl_s_ctrl(imx290->link_freq,
>> + imx290_get_link_freq_index(imx290));
>> + if (imx290->pixel_rate)
>> + __v4l2_ctrl_s_ctrl_int64(imx290->pixel_rate,
>> + imx290_calc_pixel_rate(imx290));
>> }
>>
>> *format = fmt->format;
>> @@ -502,12 +529,11 @@ static int imx290_entity_init_cfg(struct v4l2_subdev *subdev,
>> return 0;
>> }
>>
>> -static int imx290_write_current_format(struct imx290 *imx290,
>> - struct v4l2_mbus_framefmt *format)
>> +static int imx290_write_current_format(struct imx290 *imx290)
>> {
>> int ret;
>>
>> - switch (format->code) {
>> + switch (imx290->current_format.code) {
>> case MEDIA_BUS_FMT_SRGGB10_1X10:
>> ret = imx290_set_register_array(imx290, imx290_10bit_settings,
>> ARRAY_SIZE(
>> @@ -558,8 +584,8 @@ static int imx290_start_streaming(struct imx290 *imx290)
>> return ret;
>> }
>>
>> - /* Set current frame format */
>> - ret = imx290_write_current_format(imx290, &imx290->current_format);
>> + /* Apply the register values related to current frame format */
>> + ret = imx290_write_current_format(imx290);
>> if (ret < 0) {
>> dev_err(imx290->dev, "Could not set frame format\n");
>> return ret;
>> @@ -821,12 +847,6 @@ static int imx290_probe(struct i2c_client *client)
>> goto free_err;
>> }
>>
>> - if (imx290->ep.link_frequencies[0] != IMX290_DEFAULT_LINK_FREQ) {
>
> This check needs to be modified to correspond to the driver's new
> capabilities, not removed.
Agreed.
Do I understand correct that as the driver uses two link frequencies
for a given number of lanes now, it must check that *the both* frequencies
(for the given number of lanes) are listed in the device tree node?
Thanks,
Andrey
>> - dev_err(dev, "Unsupported link frequency\n");
>> - ret = -EINVAL;
>> - goto free_err;
>> - }
>> -
>> /* Only CSI2 is supported for now */
>> if (imx290->ep.bus_type != V4L2_MBUS_CSI2_DPHY) {
>> dev_err(dev, "Unsupported bus type, should be CSI2\n");
>> @@ -879,23 +899,38 @@ static int imx290_probe(struct i2c_client *client)
>>
>> mutex_init(&imx290->lock);
>>
>> + /*
>> + * Initialize the frame format. In particular, imx290->current_mode
>> + * and imx290->bpp are set to defaults: imx290_calc_pixel_rate() call
>> + * below relies on these fields.
>> + */
>> + imx290_entity_init_cfg(&imx290->sd, NULL);
>> +
>> v4l2_ctrl_handler_init(&imx290->ctrls, 3);
>>
>> v4l2_ctrl_new_std(&imx290->ctrls, &imx290_ctrl_ops,
>> V4L2_CID_GAIN, 0, 72, 1, 0);
>> - imx290->link_freq =
>> - v4l2_ctrl_new_int_menu(&imx290->ctrls,
>> - &imx290_ctrl_ops,
>> - V4L2_CID_LINK_FREQ,
>> - ARRAY_SIZE(imx290_link_freq) - 1,
>> - 0, imx290_link_freq);
>> + if (imx290->nlanes == 4)
>> + imx290->link_freq =
>> + v4l2_ctrl_new_int_menu(&imx290->ctrls,
>> + &imx290_ctrl_ops,
>> + V4L2_CID_LINK_FREQ,
>> + ARRAY_SIZE(imx290_link_freq_4lanes) - 1,
>> + 0, imx290_link_freq_4lanes);
>> + else
>> + imx290->link_freq =
>> + v4l2_ctrl_new_int_menu(&imx290->ctrls,
>> + &imx290_ctrl_ops,
>> + V4L2_CID_LINK_FREQ,
>> + ARRAY_SIZE(imx290_link_freq_2lanes) - 1,
>> + 0, imx290_link_freq_2lanes);
>> if (imx290->link_freq)
>> imx290->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
>>
>> imx290->pixel_rate = v4l2_ctrl_new_std(&imx290->ctrls, &imx290_ctrl_ops,
>> V4L2_CID_PIXEL_RATE, 1,
>> INT_MAX, 1,
>> - imx290_modes[0].pixel_rate);
>> + imx290_calc_pixel_rate(imx290));
>>
>> imx290->sd.ctrl_handler = &imx290->ctrls;
>>
>> @@ -919,9 +954,6 @@ static int imx290_probe(struct i2c_client *client)
>> goto free_ctrl;
>> }
>>
>> - /* Initialize the frame format (this also sets imx290->current_mode) */
>> - imx290_entity_init_cfg(&imx290->sd, NULL);
>> -
>> ret = v4l2_async_register_subdev(&imx290->sd);
>> if (ret < 0) {
>> dev_err(dev, "Could not register v4l2 device\n");
>
^ permalink raw reply
* Re: [PATCH v4 2/6] dt-bindings: interrupt-controller: Add Loongson HTVEC
From: Jiaxun Yang @ 2020-05-26 9:26 UTC (permalink / raw)
To: Marc Zyngier
Cc: Rob Herring, Thomas Gleixner, Jason Cooper, Huacai Chen,
linux-kernel, devicetree, linux-mips
In-Reply-To: <87v9kkz5kl.wl-maz@kernel.org>
On Mon, 25 May 2020 11:12:26 +0100
Marc Zyngier <maz@kernel.org> wrote:
> On Sat, 16 May 2020 09:29:02 +0100,
> Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
> >
> > Add binding for Loongson-3 HyperTransport Interrupt Vector
> > Controller.
> >
> > Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> > --
> > v4: Drop ref, '|', add additionalProperties, fix example
>
> Rob, do you have any input on this?
Oops, looks like I was in-reply into wrong patch topic for this patch,
should I resend this series into correct thread?
Thanks.
>
> Thanks,
>
> M.
>
---
Jiaxun Yang
^ permalink raw reply
* RE: [PATCH] dt-bindings: leds: fix macro names for pca955x
From: Flavio Suligoi @ 2020-05-26 9:25 UTC (permalink / raw)
To: Pavel Machek
Cc: Jacek Anaszewski, Dan Murphy, Rob Herring,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20200526092250.GB12838@amd>
> Subject: Re: [PATCH] dt-bindings: leds: fix macro names for pca955x
>
> On Tue 2020-05-26 11:20:52, Flavio Suligoi wrote:
> > The documentation reports the wrong macro names
> > related to the pca9532 instead of the pca955x
> >
> > Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
>
> Nothing obviously wrong, but why did you send it twice within half an
> hour?
> Pavel
Sorry Pavel, with the first email I forgot to subscribe
to the linux-leds mailing list! 😊
Flavio
^ permalink raw reply
* [PATCH v11 5/5] MIPS: Loongson64: Switch to generic PCI driver
From: Jiaxun Yang @ 2020-05-26 9:21 UTC (permalink / raw)
To: linux-pci
Cc: Jiaxun Yang, Bjorn Helgaas, Rob Herring, Thomas Bogendoerfer,
Huacai Chen, Lorenzo Pieralisi, Paul Burton, devicetree,
linux-kernel, linux-mips
In-Reply-To: <20200526092130.145550-1-jiaxun.yang@flygoat.com>
We can now enable generic PCI driver in Kconfig, and remove legacy
PCI driver code.
Radeon vbios quirk is moved to the platform folder to fit the
new structure.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
--
v9: Fix licenses tag
---
arch/mips/Kconfig | 1 +
arch/mips/loongson64/Makefile | 2 +-
arch/mips/loongson64/vbios_quirk.c | 29 ++++++++
arch/mips/pci/Makefile | 1 -
arch/mips/pci/fixup-loongson3.c | 71 ------------------
arch/mips/pci/ops-loongson3.c | 116 -----------------------------
6 files changed, 31 insertions(+), 189 deletions(-)
create mode 100644 arch/mips/loongson64/vbios_quirk.c
delete mode 100644 arch/mips/pci/fixup-loongson3.c
delete mode 100644 arch/mips/pci/ops-loongson3.c
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 0519ca9f00f9..7a4fcc4ade1f 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -480,6 +480,7 @@ config MACH_LOONGSON64
select IRQ_MIPS_CPU
select NR_CPUS_DEFAULT_64
select USE_GENERIC_EARLY_PRINTK_8250
+ select PCI_DRIVERS_GENERIC
select SYS_HAS_CPU_LOONGSON64
select SYS_HAS_EARLY_PRINTK
select SYS_SUPPORTS_SMP
diff --git a/arch/mips/loongson64/Makefile b/arch/mips/loongson64/Makefile
index 6f3c2b47f66f..6f81b822aeae 100644
--- a/arch/mips/loongson64/Makefile
+++ b/arch/mips/loongson64/Makefile
@@ -8,5 +8,5 @@ obj-$(CONFIG_MACH_LOONGSON64) += cop2-ex.o platform.o dma.o \
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_NUMA) += numa.o
obj-$(CONFIG_RS780_HPET) += hpet.o
-obj-$(CONFIG_PCI) += pci.o
obj-$(CONFIG_SUSPEND) += pm.o
+obj-$(CONFIG_PCI_QUIRKS) += vbios_quirk.o
diff --git a/arch/mips/loongson64/vbios_quirk.c b/arch/mips/loongson64/vbios_quirk.c
new file mode 100644
index 000000000000..9a29e94d3db1
--- /dev/null
+++ b/arch/mips/loongson64/vbios_quirk.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include <linux/pci.h>
+#include <loongson.h>
+
+static void pci_fixup_radeon(struct pci_dev *pdev)
+{
+ struct resource *res = &pdev->resource[PCI_ROM_RESOURCE];
+
+ if (res->start)
+ return;
+
+ if (!loongson_sysconf.vgabios_addr)
+ return;
+
+ pci_disable_rom(pdev);
+ if (res->parent)
+ release_resource(res);
+
+ res->start = virt_to_phys((void *) loongson_sysconf.vgabios_addr);
+ res->end = res->start + 256*1024 - 1;
+ res->flags = IORESOURCE_MEM | IORESOURCE_ROM_SHADOW |
+ IORESOURCE_PCI_FIXED;
+
+ dev_info(&pdev->dev, "BAR %d: assigned %pR for Radeon ROM\n",
+ PCI_ROM_RESOURCE, res);
+}
+DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_ATI, 0x9615,
+ PCI_CLASS_DISPLAY_VGA, 8, pci_fixup_radeon);
diff --git a/arch/mips/pci/Makefile b/arch/mips/pci/Makefile
index 342ce10ef593..438f10955d89 100644
--- a/arch/mips/pci/Makefile
+++ b/arch/mips/pci/Makefile
@@ -35,7 +35,6 @@ obj-$(CONFIG_LASAT) += pci-lasat.o
obj-$(CONFIG_MIPS_COBALT) += fixup-cobalt.o
obj-$(CONFIG_LEMOTE_FULOONG2E) += fixup-fuloong2e.o ops-loongson2.o
obj-$(CONFIG_LEMOTE_MACH2F) += fixup-lemote2f.o ops-loongson2.o
-obj-$(CONFIG_MACH_LOONGSON64) += fixup-loongson3.o ops-loongson3.o
obj-$(CONFIG_MIPS_MALTA) += fixup-malta.o pci-malta.o
obj-$(CONFIG_PMC_MSP7120_GW) += fixup-pmcmsp.o ops-pmcmsp.o
obj-$(CONFIG_PMC_MSP7120_EVAL) += fixup-pmcmsp.o ops-pmcmsp.o
diff --git a/arch/mips/pci/fixup-loongson3.c b/arch/mips/pci/fixup-loongson3.c
deleted file mode 100644
index 8a741c2c6685..000000000000
--- a/arch/mips/pci/fixup-loongson3.c
+++ /dev/null
@@ -1,71 +0,0 @@
-/*
- * fixup-loongson3.c
- *
- * Copyright (C) 2012 Lemote, Inc.
- * Author: Xiang Yu, xiangy@lemote.com
- * Chen Huacai, chenhc@lemote.com
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
- * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
- * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
- * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
- * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- */
-
-#include <linux/pci.h>
-#include <boot_param.h>
-
-static void print_fixup_info(const struct pci_dev *pdev)
-{
- dev_info(&pdev->dev, "Device %x:%x, irq %d\n",
- pdev->vendor, pdev->device, pdev->irq);
-}
-
-int pcibios_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
-{
- print_fixup_info(dev);
- return dev->irq;
-}
-
-static void pci_fixup_radeon(struct pci_dev *pdev)
-{
- struct resource *res = &pdev->resource[PCI_ROM_RESOURCE];
-
- if (res->start)
- return;
-
- if (!loongson_sysconf.vgabios_addr)
- return;
-
- pci_disable_rom(pdev);
- if (res->parent)
- release_resource(res);
-
- res->start = virt_to_phys((void *) loongson_sysconf.vgabios_addr);
- res->end = res->start + 256*1024 - 1;
- res->flags = IORESOURCE_MEM | IORESOURCE_ROM_SHADOW |
- IORESOURCE_PCI_FIXED;
-
- dev_info(&pdev->dev, "BAR %d: assigned %pR for Radeon ROM\n",
- PCI_ROM_RESOURCE, res);
-}
-
-DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_ATI, PCI_ANY_ID,
- PCI_CLASS_DISPLAY_VGA, 8, pci_fixup_radeon);
-
-/* Do platform specific device initialization at pci_enable_device() time */
-int pcibios_plat_dev_init(struct pci_dev *dev)
-{
- return 0;
-}
diff --git a/arch/mips/pci/ops-loongson3.c b/arch/mips/pci/ops-loongson3.c
deleted file mode 100644
index 2f6ad36bdea6..000000000000
--- a/arch/mips/pci/ops-loongson3.c
+++ /dev/null
@@ -1,116 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include <linux/types.h>
-#include <linux/pci.h>
-#include <linux/kernel.h>
-
-#include <asm/mips-boards/bonito64.h>
-
-#include <loongson.h>
-
-#define PCI_ACCESS_READ 0
-#define PCI_ACCESS_WRITE 1
-
-#define HT1LO_PCICFG_BASE 0x1a000000
-#define HT1LO_PCICFG_BASE_TP1 0x1b000000
-
-static int loongson3_pci_config_access(unsigned char access_type,
- struct pci_bus *bus, unsigned int devfn,
- int where, u32 *data)
-{
- unsigned char busnum = bus->number;
- int function = PCI_FUNC(devfn);
- int device = PCI_SLOT(devfn);
- int reg = where & ~3;
- void *addrp;
- u64 addr;
-
- if (where < PCI_CFG_SPACE_SIZE) { /* standard config */
- addr = (busnum << 16) | (device << 11) | (function << 8) | reg;
- if (busnum == 0) {
- if (device > 31)
- return PCIBIOS_DEVICE_NOT_FOUND;
- addrp = (void *)TO_UNCAC(HT1LO_PCICFG_BASE | addr);
- } else {
- addrp = (void *)TO_UNCAC(HT1LO_PCICFG_BASE_TP1 | addr);
- }
- } else if (where < PCI_CFG_SPACE_EXP_SIZE) { /* extended config */
- struct pci_dev *rootdev;
-
- rootdev = pci_get_domain_bus_and_slot(0, 0, 0);
- if (!rootdev)
- return PCIBIOS_DEVICE_NOT_FOUND;
-
- addr = pci_resource_start(rootdev, 3);
- if (!addr)
- return PCIBIOS_DEVICE_NOT_FOUND;
-
- addr |= busnum << 20 | device << 15 | function << 12 | reg;
- addrp = (void *)TO_UNCAC(addr);
- } else {
- return PCIBIOS_DEVICE_NOT_FOUND;
- }
-
- if (access_type == PCI_ACCESS_WRITE)
- writel(*data, addrp);
- else {
- *data = readl(addrp);
- if (*data == 0xffffffff) {
- *data = -1;
- return PCIBIOS_DEVICE_NOT_FOUND;
- }
- }
- return PCIBIOS_SUCCESSFUL;
-}
-
-static int loongson3_pci_pcibios_read(struct pci_bus *bus, unsigned int devfn,
- int where, int size, u32 *val)
-{
- u32 data = 0;
- int ret = loongson3_pci_config_access(PCI_ACCESS_READ,
- bus, devfn, where, &data);
-
- if (ret != PCIBIOS_SUCCESSFUL)
- return ret;
-
- if (size == 1)
- *val = (data >> ((where & 3) << 3)) & 0xff;
- else if (size == 2)
- *val = (data >> ((where & 3) << 3)) & 0xffff;
- else
- *val = data;
-
- return PCIBIOS_SUCCESSFUL;
-}
-
-static int loongson3_pci_pcibios_write(struct pci_bus *bus, unsigned int devfn,
- int where, int size, u32 val)
-{
- u32 data = 0;
- int ret;
-
- if (size == 4)
- data = val;
- else {
- ret = loongson3_pci_config_access(PCI_ACCESS_READ,
- bus, devfn, where, &data);
- if (ret != PCIBIOS_SUCCESSFUL)
- return ret;
-
- if (size == 1)
- data = (data & ~(0xff << ((where & 3) << 3))) |
- (val << ((where & 3) << 3));
- else if (size == 2)
- data = (data & ~(0xffff << ((where & 3) << 3))) |
- (val << ((where & 3) << 3));
- }
-
- ret = loongson3_pci_config_access(PCI_ACCESS_WRITE,
- bus, devfn, where, &data);
-
- return ret;
-}
-
-struct pci_ops loongson_pci_ops = {
- .read = loongson3_pci_pcibios_read,
- .write = loongson3_pci_pcibios_write
-};
--
2.27.0.rc0
^ permalink raw reply related
* Re: [PATCH] dt-bindings: leds: fix macro names for pca955x
From: Pavel Machek @ 2020-05-26 9:22 UTC (permalink / raw)
To: Flavio Suligoi
Cc: Jacek Anaszewski, Dan Murphy, Rob Herring, linux-leds, devicetree,
linux-kernel
In-Reply-To: <20200526092052.24172-1-f.suligoi@asem.it>
[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]
On Tue 2020-05-26 11:20:52, Flavio Suligoi wrote:
> The documentation reports the wrong macro names
> related to the pca9532 instead of the pca955x
>
> Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
Nothing obviously wrong, but why did you send it twice within half an
hour?
Pavel
> Documentation/devicetree/bindings/leds/leds-pca955x.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-pca955x.txt b/Documentation/devicetree/bindings/leds/leds-pca955x.txt
> index 7984efb767b4..7a5830f8d5ab 100644
> --- a/Documentation/devicetree/bindings/leds/leds-pca955x.txt
> +++ b/Documentation/devicetree/bindings/leds/leds-pca955x.txt
> @@ -26,9 +26,9 @@ LED sub-node properties:
> from 0 to 15 for the pca9552
> from 0 to 3 for the pca9553
> - type: (optional) either
> - PCA9532_TYPE_NONE
> - PCA9532_TYPE_LED
> - PCA9532_TYPE_GPIO
> + PCA955X_TYPE_NONE
> + PCA955X_TYPE_LED
> + PCA955X_TYPE_GPIO
> see dt-bindings/leds/leds-pca955x.h (default to LED)
> - label : (optional)
> see Documentation/devicetree/bindings/leds/common.txt
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH v11 4/5] MIPS: DTS: Loongson64: Add PCI Controller Node
From: Jiaxun Yang @ 2020-05-26 9:21 UTC (permalink / raw)
To: linux-pci
Cc: Jiaxun Yang, Bjorn Helgaas, Rob Herring, Thomas Bogendoerfer,
Huacai Chen, Lorenzo Pieralisi, Paul Burton, devicetree,
linux-kernel, linux-mips
In-Reply-To: <20200526092130.145550-1-jiaxun.yang@flygoat.com>
Add PCI Host controller node for Loongson64 with RS780E PCH dts.
Note that PCI interrupts are probed via legacy way, as different
machine have different interrupt arrangement, we can't cover all
of them in dt.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
---
arch/mips/boot/dts/loongson/rs780e-pch.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/mips/boot/dts/loongson/rs780e-pch.dtsi b/arch/mips/boot/dts/loongson/rs780e-pch.dtsi
index 8687c4f7370a..d0d5d60a8697 100644
--- a/arch/mips/boot/dts/loongson/rs780e-pch.dtsi
+++ b/arch/mips/boot/dts/loongson/rs780e-pch.dtsi
@@ -9,6 +9,18 @@ bus@10000000 {
0 0x40000000 0 0x40000000 0 0x40000000
0xfd 0xfe000000 0xfd 0xfe000000 0 0x2000000 /* PCI Config Space */>;
+ pci@1a000000 {
+ compatible = "loongson,rs780e-pci";
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ reg = <0 0x1a000000 0 0x02000000>;
+
+ ranges = <0x01000000 0 0x00004000 0 0x18004000 0 0x00004000>,
+ <0x02000000 0 0x40000000 0 0x40000000 0 0x40000000>;
+ };
+
isa {
compatible = "isa";
#address-cells = <2>;
--
2.27.0.rc0
^ permalink raw reply related
* [PATCH v11 3/5] dt-bindings: Document Loongson PCI Host Controller
From: Jiaxun Yang @ 2020-05-26 9:21 UTC (permalink / raw)
To: linux-pci
Cc: Jiaxun Yang, Rob Herring, Bjorn Helgaas, Rob Herring,
Thomas Bogendoerfer, Huacai Chen, Lorenzo Pieralisi, Paul Burton,
devicetree, linux-kernel, linux-mips
In-Reply-To: <20200526092130.145550-1-jiaxun.yang@flygoat.com>
PCI host controller found on Loongson PCHs and SoCs.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/pci/loongson.yaml | 62 +++++++++++++++++++
1 file changed, 62 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/loongson.yaml
diff --git a/Documentation/devicetree/bindings/pci/loongson.yaml b/Documentation/devicetree/bindings/pci/loongson.yaml
new file mode 100644
index 000000000000..30e7cf1aeb87
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/loongson.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/loongson.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson PCI Host Controller
+
+maintainers:
+ - Jiaxun Yang <jiaxun.yang@flygoat.com>
+
+description: |+
+ PCI host controller found on Loongson PCHs and SoCs.
+
+allOf:
+ - $ref: /schemas/pci/pci-bus.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: loongson,ls2k-pci
+ - const: loongson,ls7a-pci
+ - const: loongson,rs780e-pci
+
+ reg:
+ minItems: 1
+ maxItems: 2
+ items:
+ - description: CFG0 standard config space register
+ - description: CFG1 extended config space register
+
+ ranges:
+ minItems: 1
+ maxItems: 3
+
+
+required:
+ - compatible
+ - reg
+ - ranges
+
+examples:
+ - |
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ pcie@1a000000 {
+ compatible = "loongson,rs780e-pci";
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ // CPU_PHYSICAL(2) SIZE(2)
+ reg = <0x0 0x1a000000 0x0 0x2000000>;
+
+ // BUS_ADDRESS(3) CPU_PHYSICAL(2) SIZE(2)
+ ranges = <0x01000000 0x0 0x00004000 0x0 0x00004000 0x0 0x00004000>,
+ <0x02000000 0x0 0x40000000 0x0 0x40000000 0x0 0x40000000>;
+ };
+ };
+...
--
2.27.0.rc0
^ permalink raw reply related
* [PATCH v11 2/5] PCI: Add Loongson PCI Controller support
From: Jiaxun Yang @ 2020-05-26 9:21 UTC (permalink / raw)
To: linux-pci
Cc: Jiaxun Yang, Rob Herring, Lorenzo Pieralisi, Bjorn Helgaas,
Rob Herring, Thomas Bogendoerfer, Huacai Chen, Paul Burton,
devicetree, linux-kernel, linux-mips
In-Reply-To: <20200526092130.145550-1-jiaxun.yang@flygoat.com>
This controller can be found on Loongson-2K SoC, Loongson-3
systems with RS780E/LS7A PCH.
The RS780E part of code was previously located at
arch/mips/pci/ops-loongson3.c and now it can use generic PCI
driver implementation.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
--
v2:
- Clean up according to rob's suggestions
- Claim that it can't work as a module
v3:
- Fix a typo
v4:
- More clean-ups: Drop flag check, use devfn
v7:
- Fix ordering according to huacai's suggestion
v8:
- Style clean and bugfix according to Bjorn's review
v9:
- Confirm with vendor about the details on system_bus BARs
- Further cleanups
- I think assume root_bus as 0 simplify our code a lot, as that's
always valid to the hardware, as we're not ecam or dwc, we can't
easily get host bus_nr via cfg, adding that will cause unnecessary
overhead.
v10:
- Enhance comments about system_bus quirk and host bus quirk.
v11:
- Add static for pci_loongson_map_bus
---
drivers/pci/controller/Kconfig | 10 ++
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pci-loongson.c | 247 ++++++++++++++++++++++++++
3 files changed, 258 insertions(+)
create mode 100644 drivers/pci/controller/pci-loongson.c
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 91bfdb784829..ae36edb1d7db 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -258,6 +258,16 @@ config PCI_HYPERV_INTERFACE
The Hyper-V PCI Interface is a helper driver allows other drivers to
have a common interface with the Hyper-V PCI frontend driver.
+config PCI_LOONGSON
+ bool "LOONGSON PCI Controller"
+ depends on MACH_LOONGSON64 || COMPILE_TEST
+ depends on OF
+ depends on PCI_QUIRKS
+ default MACH_LOONGSON64
+ help
+ Say Y here if you want to enable PCI controller support on
+ Loongson systems.
+
source "drivers/pci/controller/dwc/Kconfig"
source "drivers/pci/controller/mobiveil/Kconfig"
source "drivers/pci/controller/cadence/Kconfig"
diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
index 158c59771824..fbac4b0190a0 100644
--- a/drivers/pci/controller/Makefile
+++ b/drivers/pci/controller/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
obj-$(CONFIG_VMD) += vmd.o
obj-$(CONFIG_PCIE_BRCMSTB) += pcie-brcmstb.o
+obj-$(CONFIG_PCI_LOONGSON) += pci-loongson.o
# pcie-hisi.o quirks are needed even without CONFIG_PCIE_DW
obj-y += dwc/
obj-y += mobiveil/
diff --git a/drivers/pci/controller/pci-loongson.c b/drivers/pci/controller/pci-loongson.c
new file mode 100644
index 000000000000..b590f3746ed2
--- /dev/null
+++ b/drivers/pci/controller/pci-loongson.c
@@ -0,0 +1,247 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Loongson PCI Host Controller Driver
+ *
+ * Copyright (C) 2020 Jiaxun Yang <jiaxun.yang@flygoat.com>
+ */
+
+#include <linux/of_device.h>
+#include <linux/of_pci.h>
+#include <linux/pci.h>
+#include <linux/pci_ids.h>
+
+#include "../pci.h"
+
+/* Device IDs */
+#define DEV_PCIE_PORT_0 0x7a09
+#define DEV_PCIE_PORT_1 0x7a19
+#define DEV_PCIE_PORT_2 0x7a29
+
+#define DEV_LS2K_APB 0x7a02
+#define DEV_LS7A_CONF 0x7a10
+#define DEV_LS7A_LPC 0x7a0c
+
+#define FLAG_CFG0 BIT(0)
+#define FLAG_CFG1 BIT(1)
+#define FLAG_DEV_FIX BIT(2)
+
+struct loongson_pci {
+ void __iomem *cfg0_base;
+ void __iomem *cfg1_base;
+ struct platform_device *pdev;
+ u32 flags;
+};
+
+/* Fixup wrong class code in PCIe bridges */
+static void bridge_class_quirk(struct pci_dev *dev)
+{
+ dev->class = PCI_CLASS_BRIDGE_PCI << 8;
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LOONGSON,
+ DEV_PCIE_PORT_0, bridge_class_quirk);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LOONGSON,
+ DEV_PCIE_PORT_1, bridge_class_quirk);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LOONGSON,
+ DEV_PCIE_PORT_2, bridge_class_quirk);
+
+static void system_bus_quirk(struct pci_dev *pdev)
+{
+ /*
+ * The address space consumed by these devices is outside the
+ * resources of the host bridge.
+ */
+ pdev->mmio_always_on = 1;
+ pdev->non_compliant_bars = 1;
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON,
+ DEV_LS2K_APB, system_bus_quirk);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON,
+ DEV_LS7A_CONF, system_bus_quirk);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON,
+ DEV_LS7A_LPC, system_bus_quirk);
+
+static void loongson_mrrs_quirk(struct pci_dev *dev)
+{
+ struct pci_bus *bus = dev->bus;
+ struct pci_dev *bridge;
+ static const struct pci_device_id bridge_devids[] = {
+ { PCI_VDEVICE(LOONGSON, DEV_PCIE_PORT_0) },
+ { PCI_VDEVICE(LOONGSON, DEV_PCIE_PORT_1) },
+ { PCI_VDEVICE(LOONGSON, DEV_PCIE_PORT_2) },
+ { 0, },
+ };
+
+ /* look for the matching bridge */
+ while (!pci_is_root_bus(bus)) {
+ bridge = bus->self;
+ bus = bus->parent;
+ /*
+ * Some Loongson PCIe ports have a h/w limitation of
+ * 256 bytes maximum read request size. They can't handle
+ * anything larger than this. So force this limit on
+ * any devices attached under these ports.
+ */
+ if (pci_match_id(bridge_devids, bridge)) {
+ if (pcie_get_readrq(dev) > 256) {
+ pci_info(dev, "limiting MRRS to 256\n");
+ pcie_set_readrq(dev, 256);
+ }
+ break;
+ }
+ }
+}
+DECLARE_PCI_FIXUP_ENABLE(PCI_ANY_ID, PCI_ANY_ID, loongson_mrrs_quirk);
+
+static void __iomem *cfg1_map(struct loongson_pci *priv, int bus,
+ unsigned int devfn, int where)
+{
+ unsigned long addroff = 0x0;
+
+ if (bus != 0)
+ addroff |= BIT(28); /* Type 1 Access */
+ addroff |= (where & 0xff) | ((where & 0xf00) << 16);
+ addroff |= (bus << 16) | (devfn << 8);
+ return priv->cfg1_base + addroff;
+}
+
+static void __iomem *cfg0_map(struct loongson_pci *priv, int bus,
+ unsigned int devfn, int where)
+{
+ unsigned long addroff = 0x0;
+
+ if (bus != 0)
+ addroff |= BIT(24); /* Type 1 Access */
+ addroff |= (bus << 16) | (devfn << 8) | where;
+ return priv->cfg0_base + addroff;
+}
+
+static void __iomem *pci_loongson_map_bus(struct pci_bus *bus, unsigned int devfn,
+ int where)
+{
+ unsigned char busnum = bus->number;
+ struct pci_host_bridge *bridge = pci_find_host_bridge(bus);
+ struct loongson_pci *priv = pci_host_bridge_priv(bridge);
+
+ /*
+ * Do not read more than one device on the bus other than
+ * the host bus. For our hardware the root bus is always bus 0.
+ */
+ if (priv->flags & FLAG_DEV_FIX && busnum != 0 &&
+ PCI_SLOT(devfn) > 0)
+ return NULL;
+
+ /* CFG0 can only access standard space */
+ if (where < PCI_CFG_SPACE_SIZE && priv->cfg0_base)
+ return cfg0_map(priv, busnum, devfn, where);
+
+ /* CFG1 can access extended space */
+ if (where < PCI_CFG_SPACE_EXP_SIZE && priv->cfg1_base)
+ return cfg1_map(priv, busnum, devfn, where);
+
+ return NULL;
+}
+
+static int loongson_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+{
+ int irq;
+ u8 val;
+
+ irq = of_irq_parse_and_map_pci(dev, slot, pin);
+ if (irq > 0)
+ return irq;
+
+ /* Care i8259 legacy systems */
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &val);
+ /* i8259 only have 15 IRQs */
+ if (val > 15)
+ return 0;
+
+ return val;
+}
+
+/* H/w only accept 32-bit PCI operations */
+static struct pci_ops loongson_pci_ops = {
+ .map_bus = pci_loongson_map_bus,
+ .read = pci_generic_config_read32,
+ .write = pci_generic_config_write32,
+};
+
+static const struct of_device_id loongson_pci_of_match[] = {
+ { .compatible = "loongson,ls2k-pci",
+ .data = (void *)(FLAG_CFG0 | FLAG_CFG1 | FLAG_DEV_FIX), },
+ { .compatible = "loongson,ls7a-pci",
+ .data = (void *)(FLAG_CFG0 | FLAG_CFG1 | FLAG_DEV_FIX), },
+ { .compatible = "loongson,rs780e-pci",
+ .data = (void *)(FLAG_CFG0), },
+ {}
+};
+
+static int loongson_pci_probe(struct platform_device *pdev)
+{
+ struct loongson_pci *priv;
+ struct device *dev = &pdev->dev;
+ struct device_node *node = dev->of_node;
+ struct pci_host_bridge *bridge;
+ struct resource *regs;
+ int err;
+
+ if (!node)
+ return -ENODEV;
+
+ bridge = devm_pci_alloc_host_bridge(dev, sizeof(*priv));
+ if (!bridge)
+ return -ENODEV;
+
+ priv = pci_host_bridge_priv(bridge);
+ priv->pdev = pdev;
+ priv->flags = (unsigned long)of_device_get_match_data(dev);
+
+ regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!regs) {
+ dev_err(dev, "missing mem resources for cfg0\n");
+ return -EINVAL;
+ }
+
+ priv->cfg0_base = devm_pci_remap_cfg_resource(dev, regs);
+ if (IS_ERR(priv->cfg0_base))
+ return PTR_ERR(priv->cfg0_base);
+
+ /* CFG1 is optional */
+ if (priv->flags & FLAG_CFG1) {
+ regs = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!regs)
+ dev_info(dev, "missing mem resource for cfg1\n");
+ else {
+ priv->cfg1_base = devm_pci_remap_cfg_resource(dev, regs);
+ if (IS_ERR(priv->cfg1_base))
+ priv->cfg1_base = NULL;
+ }
+ }
+
+ err = pci_parse_request_of_pci_ranges(dev, &bridge->windows,
+ &bridge->dma_ranges, NULL);
+ if (err) {
+ dev_err(dev, "failed to get bridge resources\n");
+ return err;
+ }
+
+ bridge->dev.parent = dev;
+ bridge->sysdata = priv;
+ bridge->ops = &loongson_pci_ops;
+ bridge->map_irq = loongson_map_irq;
+
+ err = pci_host_probe(bridge);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static struct platform_driver loongson_pci_driver = {
+ .driver = {
+ .name = "loongson-pci",
+ .of_match_table = loongson_pci_of_match,
+ },
+ .probe = loongson_pci_probe,
+};
+builtin_platform_driver(loongson_pci_driver);
--
2.27.0.rc0
^ permalink raw reply related
* Re: [PATCH v6 3/5] dt-bindings: iio: magnetometer: ak8975: add gpio reset support
From: Linus Walleij @ 2020-05-26 9:22 UTC (permalink / raw)
To: Jonathan Albrieux
Cc: linux-kernel@vger.kernel.org, ~postmarketos/upstreaming,
Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Hartmut Knaack, Jonathan Cameron, Lars-Peter Clausen,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Jonathan Cameron, Rob Herring
In-Reply-To: <20200525151117.32540-4-jonathan.albrieux@gmail.com>
On Mon, May 25, 2020 at 5:13 PM Jonathan Albrieux
<jonathan.albrieux@gmail.com> wrote:
> Add reset-gpio support.
>
> Without reset's deassertion during ak8975_power_on(), driver's probe fails
> on ak8975_who_i_am() while checking for device identity for AK09911 chip.
>
> AK09911 has an active low reset gpio to handle register's reset.
> AK09911 datasheet says that, if not used, reset pin should be connected
> to VID. This patch emulates this situation.
>
> Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v11 1/5] PCI: Don't disable decoding when mmio_always_on is set
From: Jiaxun Yang @ 2020-05-26 9:21 UTC (permalink / raw)
To: linux-pci
Cc: Jiaxun Yang, Bjorn Helgaas, Bjorn Helgaas, Rob Herring,
Thomas Bogendoerfer, Huacai Chen, Lorenzo Pieralisi, Paul Burton,
devicetree, linux-kernel, linux-mips
In-Reply-To: <20200526092130.145550-1-jiaxun.yang@flygoat.com>
Don't disable MEM/IO decoding when a device have both non_compliant_bars
and mmio_always_on.
That would allow us quirk devices with junk in BARs but can't disable
their decoding.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Acked-by: Bjorn Helgaas <helgaas@kernel.org>
---
drivers/pci/probe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 77b8a145c39b..d9c2c3301a8a 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1822,7 +1822,7 @@ int pci_setup_device(struct pci_dev *dev)
/* Device class may be changed after fixup */
class = dev->class >> 8;
- if (dev->non_compliant_bars) {
+ if (dev->non_compliant_bars && !dev->mmio_always_on) {
pci_read_config_word(dev, PCI_COMMAND, &cmd);
if (cmd & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
pci_info(dev, "device has non-compliant BARs; disabling IO/MEM decoding\n");
--
2.27.0.rc0
^ permalink raw reply related
* [PATCH v11 0/5] Loongson Generic PCI v11
From: Jiaxun Yang @ 2020-05-26 9:21 UTC (permalink / raw)
To: linux-pci
Cc: Jiaxun Yang, Bjorn Helgaas, Rob Herring, Thomas Bogendoerfer,
Huacai Chen, Lorenzo Pieralisi, Paul Burton, devicetree,
linux-kernel, linux-mips
In-Reply-To: <20200427060551.1372591-1-jiaxun.yang@flygoat.com>
v11 fixes a minor style issue in patch 2.
Now it have got enough ack,
Thomas, cloud you please apply it to mips-next?
Thanks.
Jiaxun Yang (5):
PCI: Don't disable decoding when mmio_always_on is set
PCI: Add Loongson PCI Controller support
dt-bindings: Document Loongson PCI Host Controller
MIPS: DTS: Loongson64: Add PCI Controller Node
MIPS: Loongson64: Switch to generic PCI driver
.../devicetree/bindings/pci/loongson.yaml | 62 +++++
arch/mips/Kconfig | 1 +
arch/mips/boot/dts/loongson/rs780e-pch.dtsi | 12 +
arch/mips/loongson64/Makefile | 2 +-
arch/mips/loongson64/vbios_quirk.c | 29 ++
arch/mips/pci/Makefile | 1 -
arch/mips/pci/fixup-loongson3.c | 71 -----
arch/mips/pci/ops-loongson3.c | 116 --------
drivers/pci/controller/Kconfig | 10 +
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pci-loongson.c | 247 ++++++++++++++++++
drivers/pci/probe.c | 2 +-
12 files changed, 364 insertions(+), 190 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/loongson.yaml
create mode 100644 arch/mips/loongson64/vbios_quirk.c
delete mode 100644 arch/mips/pci/fixup-loongson3.c
delete mode 100644 arch/mips/pci/ops-loongson3.c
create mode 100644 drivers/pci/controller/pci-loongson.c
--
2.27.0.rc0
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: pinctrl: Add bindings for mscc,ocelot-sgpio
From: Linus Walleij @ 2020-05-26 9:20 UTC (permalink / raw)
To: Lars Povlsen
Cc: SoC Team, Rob Herring, Microchip Linux Driver Support,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, Linux ARM, linux-kernel@vger.kernel.org,
Alexandre Belloni
In-Reply-To: <87r1v8oz9f.fsf@soft-dev15.microsemi.net>
On Mon, May 25, 2020 at 4:38 PM Lars Povlsen <lars.povlsen@microchip.com> wrote:
> Yes, the problem is they're not in sequence. F.ex. you could have ports
> 0,1 enabled, skip 2,3,4 and have 5,6,7 enabled.
Just use disabled nodes.
That would look like this in my idea of a device tree:
pinctrl@nnn {
gpio0: gpio@0 {
compatible = "foo";
status = "ok";
....
};
gpio1: gpio@1 {
compatible = "foo";
status = "ok";
....
};
gpio2: gpio@2 {
compatible = "foo";
status = "disabled";
....
};
gpio3: gpio@3 {
compatible = "foo";
status = "disabled";
....
};
gpio4: gpio@4 {
compatible = "foo";
status = "disabled";
....
};
gpio5: gpio@5 {
compatible = "foo";
status = "ok";
....
};
gpio6: gpio@6 {
compatible = "foo";
status = "ok";
....
};
gpio7: gpio@7 {
compatible = "foo";
status = "ok";
....
};
};
It is common to use the status to enable/disable nodes like this.
In the Linux kernel is is possible to iterate over these subnodes and
check which ones are enabled and disabled while keeping the
index by using something like:
i = 0;
struct device_node *np, *child;
for_each_child_of_node(np, child) {
if (of_device_is_available(child)) {
pr_info("populating device %d\n", i);
}
i++;
}
Certainly you can use i in the above loop to populate your registers
etc from an indexed array.
This way the consumers can pick their GPIO from the right port
and everything just using e.g.
my-gpios = <&gpio6 4 GPIO_OUT_LOW>;
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] dt-bindings: leds: fix macro names for pca955x
From: Flavio Suligoi @ 2020-05-26 9:20 UTC (permalink / raw)
To: Jacek Anaszewski, Pavel Machek, Dan Murphy, Rob Herring
Cc: linux-leds, devicetree, linux-kernel, Flavio Suligoi
The documentation reports the wrong macro names
related to the pca9532 instead of the pca955x
Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
---
Documentation/devicetree/bindings/leds/leds-pca955x.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/leds-pca955x.txt b/Documentation/devicetree/bindings/leds/leds-pca955x.txt
index 7984efb767b4..7a5830f8d5ab 100644
--- a/Documentation/devicetree/bindings/leds/leds-pca955x.txt
+++ b/Documentation/devicetree/bindings/leds/leds-pca955x.txt
@@ -26,9 +26,9 @@ LED sub-node properties:
from 0 to 15 for the pca9552
from 0 to 3 for the pca9553
- type: (optional) either
- PCA9532_TYPE_NONE
- PCA9532_TYPE_LED
- PCA9532_TYPE_GPIO
+ PCA955X_TYPE_NONE
+ PCA955X_TYPE_LED
+ PCA955X_TYPE_GPIO
see dt-bindings/leds/leds-pca955x.h (default to LED)
- label : (optional)
see Documentation/devicetree/bindings/leds/common.txt
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v5 0/8] Enable ili9341 and l3gd20 on stm32f429-disco
From: Mark Brown @ 2020-05-26 9:19 UTC (permalink / raw)
To: dillon.minfei@gmail.com, linus.walleij
Cc: linux-stm32, linux-spi, linux-clk, linux-kernel, linux-arm-kernel,
devicetree, dri-devel
In-Reply-To: <1590378348-8115-1-git-send-email-dillon.minfei@gmail.com>
On Mon, 25 May 2020 11:45:40 +0800, dillon.minfei@gmail.com wrote:
> V5's update based on Mark Brown's suggestion, use 'SPI_MASTER_MUST_RX'
> for SPI_SIMPLEX_RX mode on stm32 spi controller.
>
> V5:
> 1 instead of add send dummy data out under SIMPLEX_RX mode,
> add flags 'SPI_CONTROLLER_MUST_TX' for stm32 spi driver
> 2 bypass 'SPI_CONTROLLER_MUST_TX' and 'SPI_CONTROLLER_MUST_RX' under
> 'SPI_3WIRE' mode
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/2] spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4
commit: 61367d0b8f5edf5146059ba8b79ce4e4485340b2
[2/2] spi: flags 'SPI_CONTROLLER_MUST_RX' and 'SPI_CONTROLLER_MUST_TX' can't be coexit with 'SPI_3WIRE' mode
commit: aee67fe879e5030a2f5e1d9af3cb5b2a1027e78a
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v3 08/10] media: i2c: imx290: Add support to enumerate all frame sizes
From: Sakari Ailus @ 2020-05-26 9:17 UTC (permalink / raw)
To: Andrey Konovalov
Cc: mchehab, manivannan.sadhasivam, linux-media, linux-kernel,
devicetree, linux-arm-kernel, c.barrett, a.brela, peter.griffin
In-Reply-To: <20200524192505.20682-9-andrey.konovalov@linaro.org>
Hi Andrey,
On Sun, May 24, 2020 at 10:25:03PM +0300, Andrey Konovalov wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>
> Add support to enumerate all frame sizes supported by IMX290. This is
> required for using with userspace tools such as libcamera.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
> ---
> drivers/media/i2c/imx290.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
> index 6e70ff22bc5f..88850f3b1427 100644
> --- a/drivers/media/i2c/imx290.c
> +++ b/drivers/media/i2c/imx290.c
> @@ -471,6 +471,25 @@ static int imx290_enum_mbus_code(struct v4l2_subdev *sd,
> return 0;
> }
>
> +static int imx290_enum_frame_size(struct v4l2_subdev *subdev,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_frame_size_enum *fse)
> +{
> + if ((fse->code != imx290_formats[0].code) &&
> + (fse->code != imx290_formats[1].code))
> + return -EINVAL;
Please skip the modes that do not have the code specified by the user. They
should not be enumerated here.
> +
> + if (fse->index >= ARRAY_SIZE(imx290_modes))
> + return -EINVAL;
> +
> + fse->min_width = imx290_modes[fse->index].width;
> + fse->max_width = imx290_modes[fse->index].width;
> + fse->min_height = imx290_modes[fse->index].height;
> + fse->max_height = imx290_modes[fse->index].height;
> +
> + return 0;
> +}
> +
> static int imx290_get_fmt(struct v4l2_subdev *sd,
> struct v4l2_subdev_pad_config *cfg,
> struct v4l2_subdev_format *fmt)
> @@ -850,6 +869,7 @@ static const struct v4l2_subdev_video_ops imx290_video_ops = {
> static const struct v4l2_subdev_pad_ops imx290_pad_ops = {
> .init_cfg = imx290_entity_init_cfg,
> .enum_mbus_code = imx290_enum_mbus_code,
> + .enum_frame_size = imx290_enum_frame_size,
> .get_fmt = imx290_get_fmt,
> .set_fmt = imx290_set_fmt,
> };
--
Regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v3 04/10] media: i2c: imx290: Add support for 2 data lanes
From: Sakari Ailus @ 2020-05-26 9:16 UTC (permalink / raw)
To: Andrey Konovalov
Cc: mchehab, manivannan.sadhasivam, linux-media, linux-kernel,
devicetree, linux-arm-kernel, c.barrett, a.brela, peter.griffin
In-Reply-To: <d68dda83-2911-be57-c5b9-b482fe1fa0ca@linaro.org>
Hi Andrey,
On Tue, May 26, 2020 at 12:14:33PM +0300, Andrey Konovalov wrote:
> Hi Sakari,
>
> Thank you for the review
>
> On 26.05.2020 12:01, Sakari Ailus wrote:
> > Hi Andrey,
> >
> > On Sun, May 24, 2020 at 10:24:59PM +0300, Andrey Konovalov wrote:
> > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > >
> > > The IMX290 sensor can output frames with 2/4 CSI2 data lanes. This commit
> > > adds support for 2 lane mode in addition to the 4 lane and also
> > > configuring the data lane settings in the driver based on system
> > > configuration.
> > >
> > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > > Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
> > > ---
> > > drivers/media/i2c/imx290.c | 133 ++++++++++++++++++++++++++++++++++---
> > > 1 file changed, 124 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
> > > index 7b1de1f0c8b7..a361c9ac8bd5 100644
> > > --- a/drivers/media/i2c/imx290.c
> > > +++ b/drivers/media/i2c/imx290.c
> > > @@ -25,7 +25,18 @@
> > > #define IMX290_STANDBY 0x3000
> > > #define IMX290_REGHOLD 0x3001
> > > #define IMX290_XMSTA 0x3002
> > > +#define IMX290_FR_FDG_SEL 0x3009
> > > #define IMX290_GAIN 0x3014
> > > +#define IMX290_HMAX_LOW 0x301c
> > > +#define IMX290_HMAX_HIGH 0x301d
> > > +#define IMX290_PHY_LANE_NUM 0x3407
> > > +#define IMX290_CSI_LANE_MODE 0x3443
> > > +
> > > +/* HMAX fields */
> > > +#define IMX290_HMAX_2_1920 0x1130
> > > +#define IMX290_HMAX_4_1920 0x0898
> > > +#define IMX290_HMAX_2_720 0x19C8
> > > +#define IMX290_HMAX_4_720 0x0CE4
> > > #define IMX290_DEFAULT_LINK_FREQ 445500000
> > > @@ -56,6 +67,7 @@ struct imx290 {
> > > struct device *dev;
> > > struct clk *xclk;
> > > struct regmap *regmap;
> > > + u8 nlanes;
> > > struct v4l2_subdev sd;
> > > struct v4l2_fwnode_endpoint ep;
> > > @@ -89,14 +101,11 @@ static const struct regmap_config imx290_regmap_config = {
> > > static const struct imx290_regval imx290_global_init_settings[] = {
> > > { 0x3007, 0x00 },
> > > - { 0x3009, 0x00 },
> > > { 0x3018, 0x65 },
> > > { 0x3019, 0x04 },
> > > { 0x301a, 0x00 },
> > > - { 0x3443, 0x03 },
> > > { 0x3444, 0x20 },
> > > { 0x3445, 0x25 },
> > > - { 0x3407, 0x03 },
> > > { 0x303a, 0x0c },
> > > { 0x3040, 0x00 },
> > > { 0x3041, 0x00 },
> > > @@ -169,7 +178,6 @@ static const struct imx290_regval imx290_1080p_settings[] = {
> > > { 0x3164, 0x1a },
> > > { 0x3480, 0x49 },
> > > /* data rate settings */
> > > - { 0x3009, 0x01 },
> > > { 0x3405, 0x10 },
> > > { 0x3446, 0x57 },
> > > { 0x3447, 0x00 },
> > > @@ -187,8 +195,6 @@ static const struct imx290_regval imx290_1080p_settings[] = {
> > > { 0x3453, 0x00 },
> > > { 0x3454, 0x17 },
> > > { 0x3455, 0x00 },
> > > - { 0x301c, 0x98 },
> > > - { 0x301d, 0x08 },
> > > };
> > > static const struct imx290_regval imx290_720p_settings[] = {
> > > @@ -210,7 +216,6 @@ static const struct imx290_regval imx290_720p_settings[] = {
> > > { 0x3164, 0x1a },
> > > { 0x3480, 0x49 },
> > > /* data rate settings */
> > > - { 0x3009, 0x01 },
> > > { 0x3405, 0x10 },
> > > { 0x3446, 0x4f },
> > > { 0x3447, 0x00 },
> > > @@ -228,8 +233,6 @@ static const struct imx290_regval imx290_720p_settings[] = {
> > > { 0x3453, 0x00 },
> > > { 0x3454, 0x17 },
> > > { 0x3455, 0x00 },
> > > - { 0x301c, 0xe4 },
> > > - { 0x301d, 0x0c },
> > > };
> > > static const struct imx290_regval imx290_10bit_settings[] = {
> > > @@ -522,6 +525,25 @@ static int imx290_write_current_format(struct imx290 *imx290,
> > > return 0;
> > > }
> > > +static int imx290_set_hmax(struct imx290 *imx290, u32 val)
> > > +{
> > > + int ret;
> > > +
> > > + ret = imx290_write_reg(imx290, IMX290_HMAX_LOW, (val & 0xff));
> > > + if (ret) {
> > > + dev_err(imx290->dev, "Error setting HMAX register\n");
> > > + return ret;
> > > + }
> > > +
> > > + ret = imx290_write_reg(imx290, IMX290_HMAX_HIGH, ((val >> 8) & 0xff));
> > > + if (ret) {
> > > + dev_err(imx290->dev, "Error setting HMAX register\n");
> > > + return ret;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > /* Start streaming */
> > > static int imx290_start_streaming(struct imx290 *imx290)
> > > {
> > > @@ -551,6 +573,40 @@ static int imx290_start_streaming(struct imx290 *imx290)
> > > return ret;
> > > }
> > > + switch (imx290->nlanes) {
> > > + case 2:
> > > + if (imx290->current_mode->width == 1920) {
> > > + ret = imx290_set_hmax(imx290, IMX290_HMAX_2_1920);
> > > + if (ret < 0)
> > > + return ret;
> > > + } else {
> > > + ret = imx290_set_hmax(imx290, IMX290_HMAX_2_720);
> > > + if (ret < 0)
> > > + return ret;
> > > + }
> > > +
> > > + break;
> > > + case 4:
> > > + if (imx290->current_mode->width == 1920) {
> > > + ret = imx290_set_hmax(imx290, IMX290_HMAX_4_1920);
> > > + if (ret < 0)
> > > + return ret;
> > > + } else {
> > > + ret = imx290_set_hmax(imx290, IMX290_HMAX_4_720);
> > > + if (ret < 0)
> > > + return ret;
> >
> > I think it'd be nicer to put this where the mode definitions are, to avoid
> > scattering the configuration around the driver.
>
> Would it be OK if I move this inside imx290_write_current_format()?
It'd still be separated from the mode there. My point was that it is
specific to the mode, and should be associated with it.
>
> > > + }
> > > +
> > > + break;
> > > + default:
> > > + /*
> > > + * We should never hit this since the data lane count is
> > > + * validated in probe itself
> > > + */
> > > + dev_err(imx290->dev, "Lane configuration not supported\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > /* Apply customized values from user */
> > > ret = v4l2_ctrl_handler_setup(imx290->sd.ctrl_handler);
> > > if (ret) {
> > > @@ -607,6 +663,49 @@ static int imx290_get_regulators(struct device *dev, struct imx290 *imx290)
> > > imx290->supplies);
> > > }
> > > +static int imx290_set_data_lanes(struct imx290 *imx290)
> > > +{
> > > + int ret = 0, laneval, frsel;
> > > +
> > > + switch (imx290->nlanes) {
> > > + case 2:
> > > + laneval = 0x01;
> > > + frsel = 0x02;
> > > + break;
> > > + case 4:
> > > + laneval = 0x03;
> > > + frsel = 0x01;
> > > + break;
> > > + default:
> > > + /*
> > > + * We should never hit this since the data lane count is
> > > + * validated in probe itself
> > > + */
> > > + dev_err(imx290->dev, "Lane configuration not supported\n");
> > > + ret = -EINVAL;
> > > + goto exit;
> > > + }
> > > +
> > > + ret = imx290_write_reg(imx290, IMX290_PHY_LANE_NUM, laneval);
> > > + if (ret) {
> > > + dev_err(imx290->dev, "Error setting Physical Lane number register\n");
> > > + goto exit;
> > > + }
> > > +
> > > + ret = imx290_write_reg(imx290, IMX290_CSI_LANE_MODE, laneval);
> > > + if (ret) {
> > > + dev_err(imx290->dev, "Error setting CSI Lane mode register\n");
> > > + goto exit;
> > > + }
> > > +
> > > + ret = imx290_write_reg(imx290, IMX290_FR_FDG_SEL, frsel);
> > > + if (ret)
> > > + dev_err(imx290->dev, "Error setting FR/FDG SEL register\n");
> > > +
> > > +exit:
> > > + return ret;
> > > +}
> > > +
> > > static int imx290_power_on(struct device *dev)
> > > {
> > > struct i2c_client *client = to_i2c_client(dev);
> > > @@ -631,6 +730,9 @@ static int imx290_power_on(struct device *dev)
> > > gpiod_set_value_cansleep(imx290->rst_gpio, 0);
> > > usleep_range(30000, 31000);
> > > + /* Set data lane count */
> > > + imx290_set_data_lanes(imx290);
> > > +
> > > return 0;
> > > }
> > > @@ -703,6 +805,16 @@ static int imx290_probe(struct i2c_client *client)
> > > goto free_err;
> > > }
> > > + /* Get number of data lanes */
> >
> > While at it, could you set the PHY type in the V4L2 fwnode endpoint before
> > parsing the data using v4l2_fwnode_endpoint_alloc_parse()?
>
> This is currently done in "[PATCH v3 10/10] media: i2c: imx290: set bus_type
> before calling v4l2_fwnode_endpoint_alloc_parse()" (along with some more
> clean-ups for the probe()). I can merge the PHY type in the V4L2 fwnode endpoint
> change into this patch.
Ack, I hadn't gotten that far yet. It's fine to keep it as-is.
--
Regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v10 5/5] MIPS: Loongson64: Switch to generic PCI driver
From: Jiaxun Yang @ 2020-05-26 9:14 UTC (permalink / raw)
To: Lorenzo Pieralisi, Thomas Bogendoerfer
Cc: linux-pci, Bjorn Helgaas, Rob Herring, Huacai Chen, Paul Burton,
devicetree, linux-kernel, linux-mips
In-Reply-To: <20200526091227.GB19547@e121166-lin.cambridge.arm.com>
于 2020年5月26日 GMT+08:00 下午5:12:27, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> 写到:
>On Sat, May 23, 2020 at 12:36:56AM +0200, Thomas Bogendoerfer wrote:
>> On Fri, May 22, 2020 at 04:22:11PM +0100, Lorenzo Pieralisi wrote:
>> > On Fri, May 22, 2020 at 04:25:50PM +0200, Thomas Bogendoerfer wrote:
>> > > On Thu, May 14, 2020 at 09:16:41PM +0800, Jiaxun Yang wrote:
>> > > > We can now enable generic PCI driver in Kconfig, and remove legacy
>> > > > PCI driver code.
>> > > >
>> > > > Radeon vbios quirk is moved to the platform folder to fit the
>> > > > new structure.
>> > > >
>> > > > Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
>> > > > --
>> > > > v9: Fix licenses tag
>> > > > ---
>> > > > arch/mips/Kconfig | 1 +
>> > > > arch/mips/loongson64/Makefile | 2 +-
>> > > > arch/mips/loongson64/vbios_quirk.c | 29 ++++++++
>> > > > arch/mips/pci/Makefile | 1 -
>> > > > arch/mips/pci/fixup-loongson3.c | 71 ------------------
>> > > > arch/mips/pci/ops-loongson3.c | 116 -----------------------------
>> > > > 6 files changed, 31 insertions(+), 189 deletions(-)
>> > > > create mode 100644 arch/mips/loongson64/vbios_quirk.c
>> > > > delete mode 100644 arch/mips/pci/fixup-loongson3.c
>> > > > delete mode 100644 arch/mips/pci/ops-loongson3.c
>> > >
>> > > Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
>> >
>> > This patch (so the series) does not apply to v5.7-rc1 which is our
>> > baseline. I reiterate the point, isn't it better to take the whole
>> > series through the MIPS tree ?
>>
>> sounds better then
>>
>> > Failing that, the series has to
>> > be rebased (or split differently so that it can be taken through
>> > different trees), just let me know.
>>
>> so let's take via mips-next. So can I add your Acked-by to the
>> first three patches ?
>
>I have acked patch 2, you have all required ACKs to get this series via
>the MIPS tree now, apologies for the delay.
I had received a regression report from test robot.
Will send v11 very soon.
Please take v11 into MIPS tree.
Thanks.
>
>Thanks,
>Lorenzo
--
Jiaxun Yang
^ permalink raw reply
* Re: [PATCH v3 04/10] media: i2c: imx290: Add support for 2 data lanes
From: Andrey Konovalov @ 2020-05-26 9:14 UTC (permalink / raw)
To: Sakari Ailus
Cc: mchehab, manivannan.sadhasivam, linux-media, linux-kernel,
devicetree, linux-arm-kernel, c.barrett, a.brela, peter.griffin
In-Reply-To: <20200526090127.GG8214@valkosipuli.retiisi.org.uk>
Hi Sakari,
Thank you for the review
On 26.05.2020 12:01, Sakari Ailus wrote:
> Hi Andrey,
>
> On Sun, May 24, 2020 at 10:24:59PM +0300, Andrey Konovalov wrote:
>> From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>>
>> The IMX290 sensor can output frames with 2/4 CSI2 data lanes. This commit
>> adds support for 2 lane mode in addition to the 4 lane and also
>> configuring the data lane settings in the driver based on system
>> configuration.
>>
>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
>> ---
>> drivers/media/i2c/imx290.c | 133 ++++++++++++++++++++++++++++++++++---
>> 1 file changed, 124 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
>> index 7b1de1f0c8b7..a361c9ac8bd5 100644
>> --- a/drivers/media/i2c/imx290.c
>> +++ b/drivers/media/i2c/imx290.c
>> @@ -25,7 +25,18 @@
>> #define IMX290_STANDBY 0x3000
>> #define IMX290_REGHOLD 0x3001
>> #define IMX290_XMSTA 0x3002
>> +#define IMX290_FR_FDG_SEL 0x3009
>> #define IMX290_GAIN 0x3014
>> +#define IMX290_HMAX_LOW 0x301c
>> +#define IMX290_HMAX_HIGH 0x301d
>> +#define IMX290_PHY_LANE_NUM 0x3407
>> +#define IMX290_CSI_LANE_MODE 0x3443
>> +
>> +/* HMAX fields */
>> +#define IMX290_HMAX_2_1920 0x1130
>> +#define IMX290_HMAX_4_1920 0x0898
>> +#define IMX290_HMAX_2_720 0x19C8
>> +#define IMX290_HMAX_4_720 0x0CE4
>>
>> #define IMX290_DEFAULT_LINK_FREQ 445500000
>>
>> @@ -56,6 +67,7 @@ struct imx290 {
>> struct device *dev;
>> struct clk *xclk;
>> struct regmap *regmap;
>> + u8 nlanes;
>>
>> struct v4l2_subdev sd;
>> struct v4l2_fwnode_endpoint ep;
>> @@ -89,14 +101,11 @@ static const struct regmap_config imx290_regmap_config = {
>>
>> static const struct imx290_regval imx290_global_init_settings[] = {
>> { 0x3007, 0x00 },
>> - { 0x3009, 0x00 },
>> { 0x3018, 0x65 },
>> { 0x3019, 0x04 },
>> { 0x301a, 0x00 },
>> - { 0x3443, 0x03 },
>> { 0x3444, 0x20 },
>> { 0x3445, 0x25 },
>> - { 0x3407, 0x03 },
>> { 0x303a, 0x0c },
>> { 0x3040, 0x00 },
>> { 0x3041, 0x00 },
>> @@ -169,7 +178,6 @@ static const struct imx290_regval imx290_1080p_settings[] = {
>> { 0x3164, 0x1a },
>> { 0x3480, 0x49 },
>> /* data rate settings */
>> - { 0x3009, 0x01 },
>> { 0x3405, 0x10 },
>> { 0x3446, 0x57 },
>> { 0x3447, 0x00 },
>> @@ -187,8 +195,6 @@ static const struct imx290_regval imx290_1080p_settings[] = {
>> { 0x3453, 0x00 },
>> { 0x3454, 0x17 },
>> { 0x3455, 0x00 },
>> - { 0x301c, 0x98 },
>> - { 0x301d, 0x08 },
>> };
>>
>> static const struct imx290_regval imx290_720p_settings[] = {
>> @@ -210,7 +216,6 @@ static const struct imx290_regval imx290_720p_settings[] = {
>> { 0x3164, 0x1a },
>> { 0x3480, 0x49 },
>> /* data rate settings */
>> - { 0x3009, 0x01 },
>> { 0x3405, 0x10 },
>> { 0x3446, 0x4f },
>> { 0x3447, 0x00 },
>> @@ -228,8 +233,6 @@ static const struct imx290_regval imx290_720p_settings[] = {
>> { 0x3453, 0x00 },
>> { 0x3454, 0x17 },
>> { 0x3455, 0x00 },
>> - { 0x301c, 0xe4 },
>> - { 0x301d, 0x0c },
>> };
>>
>> static const struct imx290_regval imx290_10bit_settings[] = {
>> @@ -522,6 +525,25 @@ static int imx290_write_current_format(struct imx290 *imx290,
>> return 0;
>> }
>>
>> +static int imx290_set_hmax(struct imx290 *imx290, u32 val)
>> +{
>> + int ret;
>> +
>> + ret = imx290_write_reg(imx290, IMX290_HMAX_LOW, (val & 0xff));
>> + if (ret) {
>> + dev_err(imx290->dev, "Error setting HMAX register\n");
>> + return ret;
>> + }
>> +
>> + ret = imx290_write_reg(imx290, IMX290_HMAX_HIGH, ((val >> 8) & 0xff));
>> + if (ret) {
>> + dev_err(imx290->dev, "Error setting HMAX register\n");
>> + return ret;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> /* Start streaming */
>> static int imx290_start_streaming(struct imx290 *imx290)
>> {
>> @@ -551,6 +573,40 @@ static int imx290_start_streaming(struct imx290 *imx290)
>> return ret;
>> }
>>
>> + switch (imx290->nlanes) {
>> + case 2:
>> + if (imx290->current_mode->width == 1920) {
>> + ret = imx290_set_hmax(imx290, IMX290_HMAX_2_1920);
>> + if (ret < 0)
>> + return ret;
>> + } else {
>> + ret = imx290_set_hmax(imx290, IMX290_HMAX_2_720);
>> + if (ret < 0)
>> + return ret;
>> + }
>> +
>> + break;
>> + case 4:
>> + if (imx290->current_mode->width == 1920) {
>> + ret = imx290_set_hmax(imx290, IMX290_HMAX_4_1920);
>> + if (ret < 0)
>> + return ret;
>> + } else {
>> + ret = imx290_set_hmax(imx290, IMX290_HMAX_4_720);
>> + if (ret < 0)
>> + return ret;
>
> I think it'd be nicer to put this where the mode definitions are, to avoid
> scattering the configuration around the driver.
Would it be OK if I move this inside imx290_write_current_format()?
>> + }
>> +
>> + break;
>> + default:
>> + /*
>> + * We should never hit this since the data lane count is
>> + * validated in probe itself
>> + */
>> + dev_err(imx290->dev, "Lane configuration not supported\n");
>> + return -EINVAL;
>> + }
>> +
>> /* Apply customized values from user */
>> ret = v4l2_ctrl_handler_setup(imx290->sd.ctrl_handler);
>> if (ret) {
>> @@ -607,6 +663,49 @@ static int imx290_get_regulators(struct device *dev, struct imx290 *imx290)
>> imx290->supplies);
>> }
>>
>> +static int imx290_set_data_lanes(struct imx290 *imx290)
>> +{
>> + int ret = 0, laneval, frsel;
>> +
>> + switch (imx290->nlanes) {
>> + case 2:
>> + laneval = 0x01;
>> + frsel = 0x02;
>> + break;
>> + case 4:
>> + laneval = 0x03;
>> + frsel = 0x01;
>> + break;
>> + default:
>> + /*
>> + * We should never hit this since the data lane count is
>> + * validated in probe itself
>> + */
>> + dev_err(imx290->dev, "Lane configuration not supported\n");
>> + ret = -EINVAL;
>> + goto exit;
>> + }
>> +
>> + ret = imx290_write_reg(imx290, IMX290_PHY_LANE_NUM, laneval);
>> + if (ret) {
>> + dev_err(imx290->dev, "Error setting Physical Lane number register\n");
>> + goto exit;
>> + }
>> +
>> + ret = imx290_write_reg(imx290, IMX290_CSI_LANE_MODE, laneval);
>> + if (ret) {
>> + dev_err(imx290->dev, "Error setting CSI Lane mode register\n");
>> + goto exit;
>> + }
>> +
>> + ret = imx290_write_reg(imx290, IMX290_FR_FDG_SEL, frsel);
>> + if (ret)
>> + dev_err(imx290->dev, "Error setting FR/FDG SEL register\n");
>> +
>> +exit:
>> + return ret;
>> +}
>> +
>> static int imx290_power_on(struct device *dev)
>> {
>> struct i2c_client *client = to_i2c_client(dev);
>> @@ -631,6 +730,9 @@ static int imx290_power_on(struct device *dev)
>> gpiod_set_value_cansleep(imx290->rst_gpio, 0);
>> usleep_range(30000, 31000);
>>
>> + /* Set data lane count */
>> + imx290_set_data_lanes(imx290);
>> +
>> return 0;
>> }
>>
>> @@ -703,6 +805,16 @@ static int imx290_probe(struct i2c_client *client)
>> goto free_err;
>> }
>>
>> + /* Get number of data lanes */
>
> While at it, could you set the PHY type in the V4L2 fwnode endpoint before
> parsing the data using v4l2_fwnode_endpoint_alloc_parse()?
This is currently done in "[PATCH v3 10/10] media: i2c: imx290: set bus_type
before calling v4l2_fwnode_endpoint_alloc_parse()" (along with some more
clean-ups for the probe()). I can merge the PHY type in the V4L2 fwnode endpoint
change into this patch.
Thanks,
Andrey
>> + imx290->nlanes = imx290->ep.bus.mipi_csi2.num_data_lanes;
>> + if (imx290->nlanes != 2 && imx290->nlanes != 4) {
>> + dev_err(dev, "Invalid data lanes: %d\n", imx290->nlanes);
>> + ret = -EINVAL;
>> + goto free_err;
>> + }
>> +
>> + dev_dbg(dev, "Using %u data lanes\n", imx290->nlanes);
>> +
>> if (!imx290->ep.nr_of_link_frequencies) {
>> dev_err(dev, "link-frequency property not found in DT\n");
>> ret = -EINVAL;
>> @@ -823,6 +935,9 @@ static int imx290_probe(struct i2c_client *client)
>> goto free_entity;
>> }
>>
>> + /* Set data lane count */
>> + imx290_set_data_lanes(imx290);
>> +
>> pm_runtime_set_active(dev);
>> pm_runtime_enable(dev);
>> pm_runtime_idle(dev);
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox