* Re: [PATCH v3 0/2] regmap: provide simple bitops and use them in a driver
From: Mark Brown @ 2020-05-29 16:51 UTC (permalink / raw)
To: Bartosz Golaszewski, Sean Wang, John Crispin, Matthias Brugger,
Mark Lee, Jakub Kicinski, David S . Miller
Cc: Stephane Le Provost, Fabien Parent, Pedro Tsai, linux-kernel,
Bartosz Golaszewski, linux-mediatek, Andrew Perepech, netdev,
linux-arm-kernel
In-Reply-To: <20200528154503.26304-1-brgl@bgdev.pl>
On Thu, 28 May 2020 17:45:01 +0200, Bartosz Golaszewski wrote:
> I noticed that oftentimes I use regmap_update_bits() for simple bit
> setting or clearing. In this case the fourth argument is superfluous as
> it's always 0 or equal to the mask argument.
>
> This series proposes to add simple bit operations for setting, clearing
> and testing specific bits with regmap.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-next
Thanks!
[1/1] regmap: provide helpers for simple bit operations
commit: aa2ff9dbaeddabb5ad166db5f9f1a0580a8bbba8
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
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtkuart: Improve exception handling in btmtuart_probe()
From: Markus Elfring @ 2020-05-28 17:09 UTC (permalink / raw)
To: Chuhong Yuan, linux-arm-kernel, linux-bluetooth, linux-mediatek
Cc: Johan Hedberg, Marcel Holtmann, Sean Wang, kernel-janitors,
linux-kernel, Matthias Brugger
> btmtuart_probe() misses several function calls in its error paths,
> including hci_free_dev() and clk_disable_unprepare().
> Refactor the code and call correct undo functions to fix the error
> paths.
How do you think about a wording variant like the following?
Change description:
Calls of the functions “clk_disable_unprepare” and “hci_free_dev”
were missing for the exception handling.
Thus add the missed function calls together with corresponding
jump targets.
Would you like to add the tag “Fixes” to the commit message?
Regards,
Markus
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH v8 0/8] Add support for devices in the Energy Model
From: Rafael J. Wysocki @ 2020-05-29 16:18 UTC (permalink / raw)
To: Lukasz Luba
Cc: Nishanth Menon, Juri Lelli, Peter Zijlstra, Viresh Kumar,
Liviu Dudau, dri-devel, Bjorn Andersson, Benjamin Segall,
alyssa.rosenzweig, Fabio Estevam, Matthias Kaehlcke, Rob Herring,
Amit Kucheria, Lorenzo Pieralisi, Vincent Guittot, Kevin Hilman,
Andy Gross, Daniel Lezcano, steven.price, Chanwoo Choi,
Ingo Molnar, dl-linux-imx, Zhang, Rui, Mel Gorman, orjan.eide,
Daniel Vetter, Linux PM, linux-arm-msm, Sascha Hauer,
Steven Rostedt, moderated list:ARM/Mediatek SoC...,
Matthias Brugger, Linux OMAP Mailing List, Dietmar Eggemann,
Linux ARM, David Airlie, Tomeu Vizoso, Quentin Perret,
Stephen Boyd, Randy Dunlap, Rafael J. Wysocki,
Linux Kernel Mailing List, Bartlomiej Zolnierkiewicz,
Sascha Hauer, Sudeep Holla, patrick.bellasi, Shawn Guo
In-Reply-To: <8fca24a1-93f7-f859-bd1f-b7bf484737f4@arm.com>
On Fri, May 29, 2020 at 5:01 PM Lukasz Luba <lukasz.luba@arm.com> wrote:
>
> Hi Rafael,
>
>
> On 5/27/20 10:58 AM, Lukasz Luba wrote:
> > Hi all,
> >
> > Background of this version:
> > This is the v8 of the patch set and is has smaller scope. I had to split
> > the series into two: EM changes and thermal changes due to devfreq
> > dependencies. The patches from v7 9-14 which change devfreq cooling are
> > going to be sent in separate patch series, just after this set get merged
> > into mainline. These patches related to EM got acks and hopefully can go
> > through linux-pm tree. The later thermal patches will go through thermal
> > tree.
> >
> > The idea and purpose of the Energy Model framework changes:
> > This patch set introduces support for devices in the Energy Model (EM)
> > framework. It will unify the power model for thermal subsystem. It will
> > make simpler to add support for new devices willing to use more
> > advanced features (like Intelligent Power Allocation). Now it should
> > require less knowledge and effort for driver developer to add e.g.
> > GPU driver with simple energy model. A more sophisticated energy model
> > in the thermal framework is also possible, driver needs to provide
> > a dedicated callback function. More information can be found in the
> > updated documentation file.
> >
> > First 7 patches are refactoring Energy Model framework to add support
> > of other devices that CPUs. They change:
> > - naming convention from 'capacity' to 'performance' state,
> > - API arguments adding device pointer and not rely only on cpumask,
> > - change naming when 'cpu' was used, now it's a 'device'
> > - internal structure to maintain registered devices
> > - update users to the new API
> > Patch 8 updates OPP framework helper function to be more generic, not
> > CPU specific.
> >
> > The patch set is based on linux-pm branch linux-next 813946019dfd.
> >
>
> Could you take the patch set via your linux-pm?
I can do that, but I didn't realize that it was targeted at me, so I
need some more time to review the patches.
Thanks!
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* [PATCH v1] Bluetooth: btmtkuart: Use serdev_device_write_buf() instead of serdev_device_write()
From: Zijun Hu @ 2020-05-29 15:58 UTC (permalink / raw)
To: sean.wang, marcel, johan.hedberg, matthias.bgg
Cc: linux-kernel, linux-bluetooth, mka, linux-mediatek, zijuhu,
linux-arm-kernel
serdev_device_write() is not appropriate at here because
serdev_device_write_wakeup() is not used to release completion hold
by the former at @write_wakeup member of struct serdev_device_ops.
Fix by using serdev_device_write_buf() instead of serdev_device_write().
Signed-off-by: Zijun Hu <zijuhu@codeaurora.org>
---
drivers/bluetooth/btmtkuart.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/bluetooth/btmtkuart.c b/drivers/bluetooth/btmtkuart.c
index 8a81fbca5c9d..6c40bc75fb5b 100644
--- a/drivers/bluetooth/btmtkuart.c
+++ b/drivers/bluetooth/btmtkuart.c
@@ -695,8 +695,7 @@ static int btmtkuart_change_baudrate(struct hci_dev *hdev)
/* Send a dummy byte 0xff to activate the new baudrate */
param = 0xff;
- err = serdev_device_write(bdev->serdev, ¶m, sizeof(param),
- MAX_SCHEDULE_TIMEOUT);
+ err = serdev_device_write_buf(bdev->serdev, ¶m, sizeof(param));
if (err < 0 || err < sizeof(param))
return err;
--
2.7.4
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* Re: [PATCH v8 0/8] Add support for devices in the Energy Model
From: Lukasz Luba @ 2020-05-29 15:00 UTC (permalink / raw)
To: rjw
Cc: nm, juri.lelli, peterz, viresh.kumar, liviu.dudau, dri-devel,
bjorn.andersson, bsegall, alyssa.rosenzweig, festevam, mka, robh,
amit.kucheria, lorenzo.pieralisi, vincent.guittot, khilman,
agross, daniel.lezcano, steven.price, cw00.choi, mingo, linux-imx,
rui.zhang, mgorman, orjan.eide, daniel, linux-pm, linux-arm-msm,
s.hauer, rostedt, linux-mediatek, matthias.bgg, linux-omap,
Dietmar.Eggemann, linux-arm-kernel, airlied, tomeu.vizoso,
qperret, sboyd, rdunlap, linux-kernel, b.zolnierkie, kernel,
sudeep.holla, patrick.bellasi, shawnguo
In-Reply-To: <20200527095854.21714-1-lukasz.luba@arm.com>
Hi Rafael,
On 5/27/20 10:58 AM, Lukasz Luba wrote:
> Hi all,
>
> Background of this version:
> This is the v8 of the patch set and is has smaller scope. I had to split
> the series into two: EM changes and thermal changes due to devfreq
> dependencies. The patches from v7 9-14 which change devfreq cooling are
> going to be sent in separate patch series, just after this set get merged
> into mainline. These patches related to EM got acks and hopefully can go
> through linux-pm tree. The later thermal patches will go through thermal
> tree.
>
> The idea and purpose of the Energy Model framework changes:
> This patch set introduces support for devices in the Energy Model (EM)
> framework. It will unify the power model for thermal subsystem. It will
> make simpler to add support for new devices willing to use more
> advanced features (like Intelligent Power Allocation). Now it should
> require less knowledge and effort for driver developer to add e.g.
> GPU driver with simple energy model. A more sophisticated energy model
> in the thermal framework is also possible, driver needs to provide
> a dedicated callback function. More information can be found in the
> updated documentation file.
>
> First 7 patches are refactoring Energy Model framework to add support
> of other devices that CPUs. They change:
> - naming convention from 'capacity' to 'performance' state,
> - API arguments adding device pointer and not rely only on cpumask,
> - change naming when 'cpu' was used, now it's a 'device'
> - internal structure to maintain registered devices
> - update users to the new API
> Patch 8 updates OPP framework helper function to be more generic, not
> CPU specific.
>
> The patch set is based on linux-pm branch linux-next 813946019dfd.
>
Could you take the patch set via your linux-pm?
Regards,
Lukasz
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Tomasz Figa @ 2020-05-29 13:43 UTC (permalink / raw)
To: Dongchun Zhu
Cc: Mark Rutland, Rob Herring, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男), Louis Kuo,
Bartosz Golaszewski, Sj Huang, Nicolas Boichat,
moderated list:ARM/Mediatek SoC support, Sakari Ailus,
Matthias Brugger, Cao Bing Bu, Mauro Carvalho Chehab,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Linux Media Mailing List
In-Reply-To: <1590653082.8804.517.camel@mhfsdcap03>
On Thu, May 28, 2020 at 10:06 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
>
> Hi Sakari,
>
> On Thu, 2020-05-28 at 10:23 +0300, Sakari Ailus wrote:
> > Hi Dongchun,
> >
> > On Thu, May 28, 2020 at 11:34:42AM +0800, Dongchun Zhu wrote:
> > > Hi Sakari, Rob,
> > >
> > > On Thu, 2020-05-28 at 00:16 +0300, Sakari Ailus wrote:
> > > > Hi Rob, Dongchun,
> > > >
> > > > On Wed, May 27, 2020 at 09:27:22AM -0600, Rob Herring wrote:
> > > > > > > > + properties:
> > > > > > > > + endpoint:
> > > > > > > > + type: object
> > > > > > > > + additionalProperties: false
> > > > > > > > +
> > > > > > > > + properties:
> > > > > >
> > > > > > Actually I wonder whether we need to declare 'clock-lanes' here?
> > > > >
> > > > > Yes, if you are using it.
> > > >
> > > > Dongchun, can you confirm the chip has a single data and a single clock
> > > > lane and that it does not support lane reordering?
> > > >
> > >
> > > From the datasheet, 'MIPI inside the OV02A10 provides one single
> > > uni-directional clock lane and one bi-directional data lane solution for
> > > communication links between components inside a mobile device.
> > > The data lane has full support for HS(uni-directional) and
> > > LP(bi-directional) data transfer mode.'
> > >
> > > The sensor doesn't support lane reordering, so 'clock-lanes' property
> > > would not be added in next release.
> > >
> > > > So if there's nothing to convey to the driver, also the data-lanes should
> > > > be removed IMO.
> > > >
> > >
> > > However, 'data-lanes' property may still be required.
> > > It is known that either data-lanes or clock-lanes is an array of
> > > physical data lane indexes. Position of an entry determines the logical
> > > lane number, while the value of an entry indicates physical lane, e.g.,
> > > for 1-lane MIPI CSI-2 bus we could have "data-lanes = <1>;", assuming
> > > the clock lane is on hardware lane 0.
> > >
> > > As mentioned earlier, the OV02A10 sensor supports only 1C1D and does not
> > > support lane reordering, so here we shall use 'data-lanes = <1>' as
> > > there is only a clock lane for OV02A10.
> > >
> > > Reminder:
> > > If 'data-lanes' property is not present, the driver would assume
> > > four-lane operation. This means for one-lane or two-lane operation, this
> > > property must be present and set to the right physical lane indexes.
> > > If the hardware does not support lane reordering, monotonically
> > > incremented values shall be used from 0 or 1 onwards, depending on
> > > whether or not there is also a clock lane.
> >
> > How can the driver use four lanes, considering the device only supports a
> > single lane??
> >
>
> I understood your meaning.
> If we omit the property 'data-lanes', the sensor should work still.
> But then what's the meaning of the existence of 'data-lanes'?
> If this property 'data-lanes' is always optional, then why dt-bindings
> provide the interface?
>
> In the meantime, if omitting 'data-lanes' for one sensor(transmitter)
> that has only one physical data lane, MIPI receiver(e.g., MIPI CSI-2)
> shall enable four-lane configuration, which may increase consumption of
> both power and resource in the process of IIC communication.
Wouldn't the receiver still have the data-lanes property under its
endpoint node, telling it how many lanes and in which order should be
used?
Best regards,
Tomasz
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH] ASoC: mediatek: mt6358: support DMIC one-wire mode
From: Mark Brown @ 2020-05-29 13:05 UTC (permalink / raw)
To: Tzung-Bi Shih
Cc: Hariprasad Kelam, Linux Kernel Mailing List, howie.huang,
Takashi Iwai, ALSA development, Jiaxin Yu, Liam Girdwood,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <CA+Px+wVSwJK-=75chKLjSEe3bPRtV2wD95W5D_pdR0Pw0G470A@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 548 bytes --]
On Fri, May 29, 2020 at 07:22:43PM +0800, Tzung-Bi Shih wrote:
> On Fri, May 29, 2020 at 7:09 PM Mark Brown <broonie@kernel.org> wrote:
> > What is DMIC one wire mode? This doesn't sound like something I'd
> > expect to vary at runtime.
> It means: 1 PDM data wire carries 2 channel data (rising edge for left
> and falling edge for right).
I thought that was normal for DMICs - is this selecting between left and
right or something?
> The setting shouldn't and won't change at runtime. Would you suggest
> putting it into DTS binding?
Yes.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [RFC PATCH V4 4/4] platform: mtk-isp: Add Mediatek FD driver
From: Tomasz Figa @ 2020-05-29 12:59 UTC (permalink / raw)
To: Jerry-ch Chen
Cc: linux-devicetree, Sean Cheng (鄭昇弘),
Laurent Pinchart, zwisler, srv_heupstream,
Christie Yu (游雅惠), Hans Verkuil,
Jungo Lin (林明俊), Sj Huang, yuzhao,
Hans Verkuil, Pi-Hsun Shih,
Frederic Chen (陳俊元), Matthias Brugger,
moderated list:ARM/Mediatek SoC support, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
In-Reply-To: <1590755163.23156.24.camel@mtksdccf07>
On Fri, May 29, 2020 at 2:26 PM Jerry-ch Chen
<Jerry-ch.Chen@mediatek.com> wrote:
>
> Hi Tomasz,
>
> I Appreciate your review comments, here's the reply.
>
> On Mon, 2020-05-25 at 14:24 +0200, Tomasz Figa wrote:
> > r
> >
> > On Fri, May 22, 2020 at 4:11 PM Jerry-ch Chen
> > <Jerry-ch.Chen@mediatek.com> wrote:
> > >
> > > Hi Tomasz,
> > >
> > > On Thu, 2020-05-21 at 18:28 +0000, Tomasz Figa wrote:
> > > > Hi Jerry,
> > > >
> > > > On Wed, Dec 04, 2019 at 08:47:32PM +0800, Jerry-ch Chen wrote:
[snip]
> > Isn't still a need to clamp() width and height to min/max, though?
> Yes, I'll add them back.
>
> This function will be refined as :
>
> static void mtk_fd_fill_pixfmt_mp(struct v4l2_pix_format_mplane *dfmt,
> u32 pixfmt)
> {
> v4l2_fill_pixfmt_mp(dfmt, pixfmt, dfmt->width, dfmt->height);
>
> dfmt->field = V4L2_FIELD_NONE;
> dfmt->colorspace = V4L2_COLORSPACE_BT2020;
> dfmt->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
> dfmt->quantization = V4L2_QUANTIZATION_DEFAULT;
> dfmt->xfer_func = V4L2_MAP_XFER_FUNC_DEFAULT(dfmt->colorspace);
>
> /* Keep user setting as possible */
> dfmt->width = clamp(dfmt->width,
> MTK_FD_OUTPUT_MIN_WIDTH,
> MTK_FD_OUTPUT_MAX_WIDTH);
> dfmt->height = clamp(dfmt->height,
> MTK_FD_OUTPUT_MIN_HEIGHT,
> MTK_FD_OUTPUT_MAX_HEIGHT);
Note that this would cause the other fields of dfmt to be inconsistent
with width and height. The correct way to do this would be to first
clamp and then call v4l2_fill_pixfmt_mp().
Best regards,
Tomasz
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
From: Christoph Hellwig @ 2020-05-29 12:45 UTC (permalink / raw)
To: Logan Gunthorpe
Cc: kvm, David Airlie, Joonas Lahtinen, dri-devel, Bjorn Andersson,
linux-tegra, Julien Grall, Thierry Reding, Will Deacon,
Marek Szyprowski, Jean-Philippe Brucker, linux-samsung-soc,
Marc Zyngier, Krzysztof Kozlowski, Jonathan Hunter,
linux-rockchip, Andy Gross, linux-arm-kernel, linux-s390,
linux-arm-msm, intel-gfx, Jani Nikula, Alex Williamson,
linux-mediatek, Rodrigo Vivi, Matthias Brugger, Thomas Gleixner,
virtualization, Gerald Schaefer, David Woodhouse, Cornelia Huck,
linux-kernel, Tom Murphy, iommu, Kukjin Kim, Robin Murphy
In-Reply-To: <465815ae-9292-f37a-59b9-03949cb68460@deltatee.com>
On Thu, May 28, 2020 at 06:00:44PM -0600, Logan Gunthorpe wrote:
> > This issue is most likely in the i915 driver and is most likely caused by the driver not respecting the return value of the dma_map_ops::map_sg function. You can see the driver ignoring the return value here:
> > https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51
> >
> > Previously this didn’t cause issues because the intel map_sg always returned the same number of elements as the input scatter gather list but with the change to this dma-iommu api this is no longer the case. I wasn’t able to track the bug down to a specific line of code unfortunately.
Mark did a big audit into the map_sg API abuse and initially had
some i915 patches, but then gave up on them with this comment:
"The biggest TODO is DRM/i915 driver and I don't feel brave enough to fix
it fully. The driver creatively uses sg_table->orig_nents to store the
size of the allocate scatterlist and ignores the number of the entries
returned by dma_map_sg function. In this patchset I only fixed the
sg_table objects exported by dmabuf related functions. I hope that I
didn't break anything there."
it would be really nice if the i915 maintainers could help with sorting
that API abuse out.
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [RFC PATCH V4 4/4] platform: mtk-isp: Add Mediatek FD driver
From: Jerry-ch Chen @ 2020-05-29 12:26 UTC (permalink / raw)
To: Tomasz Figa
Cc: linux-devicetree, Sean Cheng (鄭昇弘),
Laurent Pinchart, zwisler, srv_heupstream,
Christie Yu (游雅惠), jerry-ch.chen,
Hans Verkuil, Jungo Lin (林明俊), Sj Huang,
yuzhao, Hans Verkuil, Pi-Hsun Shih,
Frederic Chen (陳俊元), Matthias Brugger,
moderated list:ARM/Mediatek SoC support, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
In-Reply-To: <CAAFQd5DodDfWsHkhQZP-M70k9_2sUwwb4zHtWfTx5EDyEKkwow@mail.gmail.com>
Hi Tomasz,
I Appreciate your review comments, here's the reply.
On Mon, 2020-05-25 at 14:24 +0200, Tomasz Figa wrote:
> r
>
> On Fri, May 22, 2020 at 4:11 PM Jerry-ch Chen
> <Jerry-ch.Chen@mediatek.com> wrote:
> >
> > Hi Tomasz,
> >
> > On Thu, 2020-05-21 at 18:28 +0000, Tomasz Figa wrote:
> > > Hi Jerry,
> > >
> > > On Wed, Dec 04, 2019 at 08:47:32PM +0800, Jerry-ch Chen wrote:
> [snip]
> > > > +
> > > > +enum face_angle {
> > > > + MTK_FD_FACE_FRONT,
> > > > + MTK_FD_FACE_RIGHT_50,
> > > > + MTK_FD_FACE_LEFT_50,
> > > > + MTK_FD_FACE_RIGHT_90,
> > > > + MTK_FD_FACE_LEFT_90,
> > > > + MTK_FD_FACE_ANGLE_NUM,
> > > > +};
> > >
> > > This enum seems to define values for the V4L2_CID_MTK_FD_DETECT_POSE
> > > control. Considering that this is an enumeration and the values are
> > > actually integers (-90, -50, 0, 50, 90), perhaps this should be an
> > > INTEGER_MENU control instead?
> > >
> >
> > this ioctl let user select multiple face positions(combination of angles
> > and directions) to be detected. so I thought I am not able to use the
> > INTEGER_MENU for this purpose.
>
> Ah, okay, I thought there is only one selection possible.
>
> >
> > A bit-field as following should be used by user.
> > I consider adding it to uapi.
> >
> > struct face_direction_def {
> > __u16 MTK_FD_FACE_DIR_0 : 1,
> > MTK_FD_FACE_DIR_30 : 1,
> > MTK_FD_FACE_DIR_60 : 1,
> > MTK_FD_FACE_DIR_90 : 1,
> > MTK_FD_FACE_DIR_120 : 1,
> > MTK_FD_FACE_DIR_150 : 1,
> > MTK_FD_FACE_DIR_180 : 1,
> > MTK_FD_FACE_DIR_210 : 1,
> > MTK_FD_FACE_DIR_240 : 1,
> > MTK_FD_FACE_DIR_270 : 1,
> > MTK_FD_FACE_DIR_300 : 1,
> > MTK_FD_FACE_DIR_330 : 1,
> > : 4;
> > };
>
> Note that bit fields are not recommended in UAPI because of not being
> well specified by the language. Instead bits should be defined using
> macros with explicit masks or sometimes enums.
>
Ok, I'll define them in macro with masks.
> >
> > User can also select some face directions of each face angle in one
> > ioctl, for example:
> >
> > /*
> > * u16 face_directions[MTK_FD_FACE_ANGLE_NUM] = {0};
> > *
> > * face_directions[MTK_FD_FACE_FRONT] = 0x7; //angle:0, dir:0,30,60
> > * face_directions[MTK_FACE_RIGHT_50] = 0x2; //angle:50, dir:30
> > *
> > */
>
> Makes sense, thanks.
>
> >
> > > > +
> > > > +struct fd_buffer {
> > > > + __u32 scp_addr; /* used by SCP */
> > > > + __u32 dma_addr; /* used by DMA HW */
> > > > +} __packed;
> > fd buffer is used for scp ipi
> >
> > > > +
> > > > +struct fd_face_result {
> > > > + char data[16];
> > > > +};
> > fd_face_result is used for user, so it should be moved to
> > include/uapi/linux.
> > In fact, it has bit-field definition for user, so I would like to define
> > it in include/uapi/linux as following:
> >
> > struct fd_face_result {
> > __u64 face_idx : 12,
> > type : 1,
> > x0 : 10,
> > y0 : 10,
> > x1 : 10,
> > y1 : 10,
> > fcv1 : 11;
> > __u64 fcv2 : 7,
> > rip_dir : 4,
> > rop_dir : 3,
> > det_size : 5;
> > };
> >
>
> Indeed this should be defined, but as per my comment above, please
> avoid using the bitfield construct and define shifts and masks
> instead.
>
Ok, I'll fix it.
> >
> > > > +
> > > > +struct fd_user_output {
> > > > + struct fd_face_result results[MTK_FD_MAX_RESULT_NUM];
> > > > + __u16 number;
> > >
> > > Is this perhaps the number of results? If so, would num_results be a better
> > > name?
> > >
> > yes, fixed.
> > > > +};
> > >
> > > Since this struct is the meta buffer format, it is a part of the userspace
> > > interface and should be defined in a header under include/uapi/linux/.
> > >
> > Ok, I will create include/uapi/linux/mtk_fd_40.h
> > which suppose to include structures that userspace will use.
> > should the private IOCTLs be placed in it together?
> >
>
> Sorry, what private IOCTLs are you referring to? If you mean private
> control IDs, then yes, they should go to that header.
yes, the IDs, sorry for the wrong expression.
>
> [snip]
> > > > +static int mtk_fd_vb2_queue_setup(struct vb2_queue *vq,
> > > > + unsigned int *num_buffers,
> > > > + unsigned int *num_planes,
> > > > + unsigned int sizes[],
> > > > + struct device *alloc_devs[])
> > > > +{
> > > > + struct mtk_fd_ctx *ctx = vb2_get_drv_priv(vq);
> > > > + unsigned int size[2];
> > > > + unsigned int plane;
> > > > +
> > > > + switch (vq->type) {
> > > > + case V4L2_BUF_TYPE_META_CAPTURE:
> > > > + size[0] = ctx->dst_fmt.buffersize;
> > > > + break;
> > > > + case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
> > > > + size[0] = ctx->src_fmt.plane_fmt[0].sizeimage;
> > > > + if (*num_planes == 2)
> > > > + size[1] = ctx->src_fmt.plane_fmt[1].sizeimage;
> > > > + break;
> > > > + }
> > >
> > > Is this code above needed? The code below sets sizes[] and it uses a for loop,
> > > without opencoded assignment for the second plane.
> > >
> >
> > Looks like not really useful here,
> > it should check sizes and num_planes if num_plane not zero,
> > and for V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE, it will at most have 2
> > planes, maybe no need for loop as well.
>
> Loops generally make the code cleaner and there might be some desire
> to add support for more formats in the future, e.g. in case a next
> generation of the hardware shows up.
>
Ok, got it.
> > I will refine this function as following:
> > mtk_fd_vb2_queue_setup(...)
> > {
> > struct mtk_fd_ctx *ctx = vb2_get_drv_priv(vq);
> >
> > if (*num_planes == 0) {
> > if (vq->type == V4L2_BUF_TYPE_META_CAPTURE) {
> > sizes[0] = ctx->dst_fmt.buffersize;
> > *num_planes = 1;
> > return 0;
> > } else if (vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> > *num_planes = ctx->src_fmt.num_planes;
> > sizes[0] = ctx->src_fmt.plane_fmt[0].sizeimage;
> > if (*num_planes == 2)
> > sizes[1] = ctx->src_fmt.plane_fmt[1].sizeimage;
> > return 0;
> > }
> > return -EINVAL;
> > }
> >
> > /* If num_plane not zero, check the num_plane and sizes*/
> > if (vq->type == V4L2_BUF_TYPE_META_CAPTURE) {
> > if ((*num_planes == 1) &&
> > (sizes[0] <= ctx->dst_fmt.buffersize))
> > return 0;
>
> nit: The typical convention is to check for problems and return the
> error code earlier, with the success handled at the end of the block.
>
Got it.
> > else
> > return -EINVAL;
> > }
> > if (vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> > if ((*num_planes == 1) &&
> > (sizes[0] <= ctx->src_fmt.plane_fmt[0].sizeimage))
> > return 0;
> > else if ((*num_planes == 2) &&
> > (sizes[0] <= ctx->src_fmt.plane_fmt[0].sizeimage) &&
> > (sizes[1] <= ctx->src_fmt.plane_fmt[1].sizeimage))
> > return 0;
>
> Wouldn't a loop eliminate the need to if/else if through the various
> supported cases and duplicate the size checks?
>
> > else
> > return -EINVAL;
> >
> > }
> > return 0;
> > }
>
> How about the following?
>
> mtk_fd_vb2_queue_setup(...)
> {
> struct mtk_fd_ctx *ctx = vb2_get_drv_priv(vq);
>
> if (vq->type == V4L2_BUF_TYPE_META_CAPTURE) {
> if (*num_planes == 0) {
> *num_planes = 1;
> sizes[0] = ctx->dst_fmt.buffersize;
> return 0;
> }
>
> if (*num_planes != 1 || sizes[0] < ctx->dst_fmt.buffersize)
> return -EINVAL;
>
> return 0;
> }
>
> /* V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE */
> if (*num_planes == 0) {
> *num_planes = ctx->src_fmt.num_planes;
> for (i = 0; i < ctx->src_fmt.num_planes; ++i)
> sizes[i] = ctx->src_fmt.plane_fmt[i].sizeimage;
> return 0;
> }
>
> if (*num_planes < ctx->src_fmt.num_planes)
> return -EINVAL;
>
> for (i = 0; i < ctx->src_fmt.num_planes; ++i)
> if (sizes[i] < ctx->src_fmt.plane_fmt[i].sizeimage)
> return -EINVAL;
>
> return 0;
> }
>
> Note that it fully separates the code dealing with each queue and thus
> improves the readability.
>
> In this case, it could actually be beneficial to split the vb2_ops
> implementation into one that deals only with video_output_mplane and
> one only with meta_capture. This would allow eliminating the special
> casing based on vq->type and thus further simplify the code. Not sure
> if it applies to the other vb2 callbacks, though.
>
Got it, thanks for the comments.
> [snip]
> > > > +static void mtk_fd_fill_pixfmt_mp(struct v4l2_pix_format_mplane *dfmt,
> > > > + const struct v4l2_pix_format_mplane *sfmt)
> > > > +{
> > > > + dfmt->field = V4L2_FIELD_NONE;
> > > > + dfmt->colorspace = V4L2_COLORSPACE_BT2020;
> > > > + dfmt->num_planes = sfmt->num_planes;
> > > > + dfmt->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
> > > > + dfmt->quantization = V4L2_QUANTIZATION_DEFAULT;
> > > > + dfmt->xfer_func =
> > > > + V4L2_MAP_XFER_FUNC_DEFAULT(dfmt->colorspace);
> > > > +
> > > > + /* Keep user setting as possible */
> > > > + dfmt->width = clamp(dfmt->width,
> > > > + MTK_FD_OUTPUT_MIN_WIDTH,
> > > > + MTK_FD_OUTPUT_MAX_WIDTH);
> > > > + dfmt->height = clamp(dfmt->height,
> > > > + MTK_FD_OUTPUT_MIN_HEIGHT,
> > > > + MTK_FD_OUTPUT_MAX_HEIGHT);
> > > > +
> > > > + if (sfmt->num_planes == 2) {
> > > > + /* NV16M and NV61M has 1 byte per pixel */
> > > > + dfmt->plane_fmt[0].bytesperline = dfmt->width;
> > > > + dfmt->plane_fmt[1].bytesperline = dfmt->width;
> > > > + } else {
> > > > + /* 2 bytes per pixel */
> > > > + dfmt->plane_fmt[0].bytesperline = dfmt->width * 2;
> > > > + }
> > > > +
> > > > + dfmt->plane_fmt[0].sizeimage =
> > > > + dfmt->height * dfmt->plane_fmt[0].bytesperline;
> > >
> > > Could some of the code above be replaced with v4l2_fill_pixfmt_mp()?
> > >
> > I would like to refine as following
> >
> > mtk_fd_fill_pixfmt_mp(...){
> > v4l2_fill_pixfmt_mp(dfmt, sfmt->pixelformat, dfmt->width,
> > dfmt->height);
> >
> > dfmt->field = V4L2_FIELD_NONE;
> > dfmt->colorspace = V4L2_COLORSPACE_BT2020;
> > dfmt->num_planes = sfmt->num_planes;
>
> num_planes should be already filled in by the helper. That actually
> raises a question on whether there is any need to have sfmt passed to
> this function at all. Perhaps all we need is the value of pixelformat?
>
Yes, I'll replace sfmt with u32 pixfmt.
> > dfmt->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
> > dfmt->quantization = V4L2_QUANTIZATION_DEFAULT;
> > dfmt->xfer_func =
> > V4L2_MAP_XFER_FUNC_DEFAULT(dfmt->colorspace);
> > }
> >
>
> Isn't still a need to clamp() width and height to min/max, though?
Yes, I'll add them back.
This function will be refined as :
static void mtk_fd_fill_pixfmt_mp(struct v4l2_pix_format_mplane *dfmt,
u32 pixfmt)
{
v4l2_fill_pixfmt_mp(dfmt, pixfmt, dfmt->width, dfmt->height);
dfmt->field = V4L2_FIELD_NONE;
dfmt->colorspace = V4L2_COLORSPACE_BT2020;
dfmt->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
dfmt->quantization = V4L2_QUANTIZATION_DEFAULT;
dfmt->xfer_func = V4L2_MAP_XFER_FUNC_DEFAULT(dfmt->colorspace);
/* Keep user setting as possible */
dfmt->width = clamp(dfmt->width,
MTK_FD_OUTPUT_MIN_WIDTH,
MTK_FD_OUTPUT_MAX_WIDTH);
dfmt->height = clamp(dfmt->height,
MTK_FD_OUTPUT_MIN_HEIGHT,
MTK_FD_OUTPUT_MAX_HEIGHT);
}
>
> [snip]
> > > > + fd_param.user_param.src_img_fmt =
> > > > + get_fd_img_fmt(ctx->src_fmt.pixelformat);
> > > > + if (ctx->src_fmt.num_planes == 2)
> > > > + fd_param.src_img[1].dma_addr =
> > > > + vb2_dma_contig_plane_dma_addr(&src_buf->vb2_buf, 1);
> > >
> > > nit: Could this be moved above, to be just below src_img[0] initialization,
> > > for readability reasons?
> > >
> > Ok, this function will be refined as
> >
> > static void mtk_fd_device_run(void *priv)
> > {
> > struct mtk_fd_ctx *ctx = priv;
> > struct mtk_fd_dev *fd = ctx->fd_dev;
> > struct vb2_v4l2_buffer *src_buf, *dst_buf;
> > struct fd_enq_param fd_param;
> >
> > src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> >
> > fd_param.src_img[0].dma_addr =
> > vb2_dma_contig_plane_dma_addr(&src_buf->vb2_buf, 0);
> > if (ctx->src_fmt.num_planes == 2)
> > fd_param.src_img[1].dma_addr =
> > vb2_dma_contig_plane_dma_addr(&src_buf->vb2_buf, 1);
>
> How about making this a loop in terms of ctx->src_fmt.num_planes?
>
yes, it will be refined as following, I use the src_vb2_buf to reduce
the length for fitting 80 columns
src_vb2_buf = &src_buf->vb2_buf;
dst_vb2_buf = &dst_buf->vb2_buf;
for (i = 0; i < ctx->src_fmt.num_planes; i++)
fd_param.src_img[i].dma_addr =
vb2_dma_contig_plane_dma_addr(src_vb2_buf,i);
fd_param.user_result.dma_addr =
vb2_dma_contig_plane_dma_addr(dst_vb2_buf, 0);
> > fd_param.user_result.dma_addr =
> > vb2_dma_contig_plane_dma_addr(&dst_buf->vb2_buf, 0);
> > fd_param.user_param.src_img_fmt =
> > get_fd_img_fmt(fd->dev, ctx->src_fmt.pixelformat);
> >
> > mtk_fd_fill_user_param(&fd_param.user_param, &ctx->hdl);
> >
> > /* Complete request controls if any */
> > v4l2_ctrl_request_complete(src_buf->vb2_buf.req_obj.req, &ctx->hdl);
> >
> > fd->output = vb2_plane_vaddr(&dst_buf->vb2_buf, 0);
> > mtk_fd_hw_job_exec(fd, &fd_param);
> > }
>
> Best regards,
> Tomasz
Thanks and Best regards,
Jerry
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH 4/5] iio: light: lm3533-als: remove explicit parent assignment
From: Ardelean, Alexandru @ 2020-05-29 11:08 UTC (permalink / raw)
To: johan@kernel.org
Cc: milo.kim@ti.com, tomislav.denis@avl.com, dan@dlrobertson.com,
heiko@sntech.de, linux-aspeed@lists.ozlabs.org,
linux-iio@vger.kernel.org, linus.walleij@linaro.org,
eajames@linux.ibm.com, platform-driver-x86@vger.kernel.org,
paul@crapouillou.net, lorenzo.bianconi83@gmail.com,
fabrice.gasnier@st.com, srinivas.pandruvada@linux.intel.com,
linux-stm32@st-md-mailman.stormreply.com,
devel@driverdev.osuosl.org, linux-samsung-soc@vger.kernel.org,
zhang.lyra@gmail.com, tduszyns@gmail.com, krzk@kernel.org,
linux-rockchip@lists.infradead.org, wens@csie.org,
kgene@kernel.org, bcm-kernel-feedback-list@broadcom.com,
agross@kernel.org, slemieux.tyco@gmail.com, orsonzhai@gmail.com,
linux-arm-msm@vger.kernel.org, linux-input@vger.kernel.org,
alexandre.torgue@st.com, linux-pm@vger.kernel.org,
rjui@broadcom.com, s.hauer@pengutronix.de, jikos@kernel.org,
vilhelm.gray@gmail.com, mripard@kernel.org, vz@mleia.com,
rmfrfs@gmail.com, linux-mediatek@lists.infradead.org,
ak@it-klinger.de, matthias.bgg@gmail.com,
linux-amlogic@lists.infradead.org, coproscefalo@gmail.com,
linux-arm-kernel@lists.infradead.org, sbranden@broadcom.com,
hdegoede@redhat.com, syednwaris@gmail.com,
dmitry.torokhov@gmail.com, linux-kernel@vger.kernel.org,
songqiang1304521@gmail.com, bjorn.andersson@linaro.org,
mcoquelin.stm32@gmail.com, khilman@baylibre.com,
baolin.wang7@gmail.com, ktsai@capellamicro.com,
shawnguo@kernel.org, peda@axentia.se, jic23@kernel.org
In-Reply-To: <20200529101608.GC19480@localhost>
On Fri, 2020-05-29 at 12:16 +0200, Johan Hovold wrote:
> [External]
>
> On Fri, May 22, 2020 at 11:22:07AM +0300, Alexandru Ardelean wrote:
> > This assignment is the more peculiar of the bunch as it assigns the parent
> > of the platform-device's device (i.e. pdev->dev.parent) as the IIO device's
> > parent.
> >
> > It's unclear whether this is intentional or not.
> > Hence it is in it's own patch.
>
> Yeah, we have a few mfd drivers whose child drivers registers their
> class devices directly under the parent mfd device rather than the
> corresponding child platform device.
>
> Since it's done consistently I think you need to update them all if you
> really want to change this.
>
> And it may not be worth it since at least in theory someone could now be
> relying on this topology.
Thanks for the feedback.
I guess, it could make sense to do here:
devm_iio_device_alloc(pdev->dev.parent, ...)
Currently it's:
devm_iio_device_alloc(&pdev->dev, ...)
That would make it slightly more consistent.
i.e. the life-time of the object would be attached to the parent of the platform
device, versus the platform-device.
Currently, as it is, the allocation [of the IIO device] is tied the platform-
device, and the IIO registration to the parent (of the platform-device).
I'm not super-familiar with the internals here, but does this sound a bit wrong?
Is there a chance where the IIO device could be de-allocated, while registered?
>
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > ---
> > drivers/iio/light/lm3533-als.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/iio/light/lm3533-als.c b/drivers/iio/light/lm3533-als.c
> > index bc196c212881..0f380ec8d30c 100644
> > --- a/drivers/iio/light/lm3533-als.c
> > +++ b/drivers/iio/light/lm3533-als.c
> > @@ -852,7 +852,6 @@ static int lm3533_als_probe(struct platform_device
> > *pdev)
> > indio_dev->channels = lm3533_als_channels;
> > indio_dev->num_channels = ARRAY_SIZE(lm3533_als_channels);
> > indio_dev->name = dev_name(&pdev->dev);
> > - indio_dev->dev.parent = pdev->dev.parent;
> > indio_dev->modes = INDIO_DIRECT_MODE;
> >
> > als = iio_priv(indio_dev);
>
> Johan
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: btmtkuart: Improve exception handling in btmtuart_probe()
From: Marcel Holtmann @ 2020-05-29 11:41 UTC (permalink / raw)
To: Chuhong Yuan
Cc: Johan Hedberg, Sean Wang, linux-kernel,
open list:BLUETOOTH DRIVERS, Markus Elfring, Matthias Brugger,
linux-mediatek, linux-arm-kernel
In-Reply-To: <20200529022726.917826-1-hslester96@gmail.com>
Hi Chuhong,
> Calls of the functions clk_disable_unprepare() and hci_free_dev()
> were missing for the exception handling.
> Thus add the missed function calls together with corresponding
> jump targets.
>
> Fixes: 055825614c6b ("Bluetooth: btmtkuart: add an implementation for clock osc property")
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
> ---
> Changes in v2:
> - Modify description.
> - Add fixes tag.
>
> drivers/bluetooth/btmtkuart.c | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH] ASoC: mediatek: mt6358: support DMIC one-wire mode
From: Tzung-Bi Shih @ 2020-05-29 11:22 UTC (permalink / raw)
To: Mark Brown
Cc: Hariprasad Kelam, Linux Kernel Mailing List, howie.huang,
Takashi Iwai, ALSA development, Jiaxin Yu, Liam Girdwood,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <20200529110915.GH4610@sirena.org.uk>
On Fri, May 29, 2020 at 7:09 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Fri, May 29, 2020 at 07:04:53PM +0800, Jiaxin Yu wrote:
> > Supports DMIC one-wire mode. Adds a mixer control to enable and disable.
>
> What is DMIC one wire mode? This doesn't sound like something I'd
> expect to vary at runtime.
It means: 1 PDM data wire carries 2 channel data (rising edge for left
and falling edge for right).
The setting shouldn't and won't change at runtime. Would you suggest
putting it into DTS binding?
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH] ASoC: mediatek: mt6358: support DMIC one-wire mode
From: Mark Brown @ 2020-05-29 11:09 UTC (permalink / raw)
To: Jiaxin Yu
Cc: hariprasad.kelam, alsa-devel, linux-kernel, howie.huang,
lgirdwood, tiwai, tzungbi, linux-mediatek, matthias.bgg,
linux-arm-kernel
In-Reply-To: <1590750293-12769-1-git-send-email-jiaxin.yu@mediatek.com>
[-- Attachment #1.1: Type: text/plain, Size: 229 bytes --]
On Fri, May 29, 2020 at 07:04:53PM +0800, Jiaxin Yu wrote:
> Supports DMIC one-wire mode. Adds a mixer control to enable and disable.
What is DMIC one wire mode? This doesn't sound like something I'd
expect to vary at runtime.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* [PATCH] ASoC: mediatek: mt6358: support DMIC one-wire mode
From: Jiaxin Yu @ 2020-05-29 11:04 UTC (permalink / raw)
To: lgirdwood, broonie, tiwai, matthias.bgg, hariprasad.kelam
Cc: alsa-devel, howie.huang, linux-kernel, Jiaxin Yu, tzungbi,
linux-mediatek, linux-arm-kernel
Supports DMIC one-wire mode. Adds a mixer control to enable and disable.
Signed-off-by: Jiaxin Yu <jiaxin.yu@mediatek.com>
Reviewed-by: Tzung-Bi Shih <tzungbi@google.com>
---
sound/soc/codecs/mt6358.c | 33 ++++++++++++++++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/mt6358.c b/sound/soc/codecs/mt6358.c
index 1b830ea..ca7628d 100644
--- a/sound/soc/codecs/mt6358.c
+++ b/sound/soc/codecs/mt6358.c
@@ -95,6 +95,8 @@ struct mt6358_priv {
struct regulator *avdd_reg;
int wov_enabled;
+
+ int dmic_one_wire_mode;
};
int mt6358_set_mtkaif_protocol(struct snd_soc_component *cmpnt,
@@ -566,6 +568,28 @@ static int mt6358_put_wov(struct snd_kcontrol *kcontrol,
return 0;
}
+static int mt6358_dmic_one_wire_mode_get(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_component *cmpnt = snd_soc_kcontrol_component(kcontrol);
+ struct mt6358_priv *priv = snd_soc_component_get_drvdata(cmpnt);
+
+ ucontrol->value.integer.value[0] = priv->dmic_one_wire_mode;
+
+ return 0;
+}
+
+static int mt6358_dmic_one_wire_mode_set(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_component *cmpnt = snd_soc_kcontrol_component(kcontrol);
+ struct mt6358_priv *priv = snd_soc_component_get_drvdata(cmpnt);
+
+ priv->dmic_one_wire_mode = ucontrol->value.integer.value[0];
+
+ return 0;
+}
+
static const DECLARE_TLV_DB_SCALE(playback_tlv, -1000, 100, 0);
static const DECLARE_TLV_DB_SCALE(pga_tlv, 0, 600, 0);
@@ -588,6 +612,10 @@ static int mt6358_put_wov(struct snd_kcontrol *kcontrol,
SOC_SINGLE_BOOL_EXT("Wake-on-Voice Phase2 Switch", 0,
mt6358_get_wov, mt6358_put_wov),
+
+ SOC_SINGLE_BOOL_EXT("Dmic One Wire Mode", 0,
+ mt6358_dmic_one_wire_mode_get,
+ mt6358_dmic_one_wire_mode_set),
};
/* MUX */
@@ -1740,7 +1768,10 @@ static int mt6358_amic_enable(struct mt6358_priv *priv)
mt6358_mtkaif_tx_enable(priv);
/* UL dmic setting off */
- regmap_write(priv->regmap, MT6358_AFE_UL_SRC_CON0_H, 0x0000);
+ if (priv->dmic_one_wire_mode)
+ regmap_write(priv->regmap, MT6358_AFE_UL_SRC_CON0_H, 0x0400);
+ else
+ regmap_write(priv->regmap, MT6358_AFE_UL_SRC_CON0_H, 0x0080);
/* UL turn on */
regmap_write(priv->regmap, MT6358_AFE_UL_SRC_CON0_L, 0x0001);
--
1.8.1.1.dirty
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* Re: [PATCH v12 2/3] drivers: input: keyboard: Add mtk keypad driver
From: Andy Shevchenko @ 2020-05-29 10:58 UTC (permalink / raw)
To: Fengping Yu
Cc: Dmitry Torokhov, Marco Felsch, linux-mediatek, linux-input,
Yingjoe Chen, linux-arm-kernel
In-Reply-To: <20200529015618.128283-3-fengping.yu@mediatek.com>
On Fri, May 29, 2020 at 09:56:20AM +0800, Fengping Yu wrote:
> From: "fengping.yu" <fengping.yu@mediatek.com>
>
> This adds matrix keypad support for Mediatek SoCs.
FWIW,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
One comment to the code below, up to Dmitry to decide.
P.S. If you ignore tags given you, people will be discouraged to review your
contribution. Yes, I'm talking about Marco's ones.
> Signed-off-by: fengping.yu <fengping.yu@mediatek.com>
> ---
> drivers/input/keyboard/Kconfig | 11 ++
> drivers/input/keyboard/Makefile | 1 +
> drivers/input/keyboard/mtk-kpd.c | 205 +++++++++++++++++++++++++++++++
> 3 files changed, 217 insertions(+)
> create mode 100644 drivers/input/keyboard/mtk-kpd.c
>
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index 28de965a08d5..0803668bfa36 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -782,6 +782,17 @@ config KEYBOARD_BCM
> To compile this driver as a module, choose M here: the
> module will be called bcm-keypad.
>
> +config KEYBOARD_MTK_KPD
> + tristate "MediaTek Keypad Support"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + select REGMAP_MMIO
> + select INPUT_MATRIXKMAP
> + help
> + Say Y here if you want to use the keypad on MediaTek SoCs.
> + If unsure, say N.
> + To compile this driver as a module, choose M here: the
> + module will be called mtk-kpd.
> +
> config KEYBOARD_MTK_PMIC
> tristate "MediaTek PMIC keys support"
> depends on MFD_MT6397
> diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> index 1d689fdd5c00..6c9d852c377e 100644
> --- a/drivers/input/keyboard/Makefile
> +++ b/drivers/input/keyboard/Makefile
> @@ -43,6 +43,7 @@ obj-$(CONFIG_KEYBOARD_MATRIX) += matrix_keypad.o
> obj-$(CONFIG_KEYBOARD_MAX7359) += max7359_keypad.o
> obj-$(CONFIG_KEYBOARD_MCS) += mcs_touchkey.o
> obj-$(CONFIG_KEYBOARD_MPR121) += mpr121_touchkey.o
> +obj-$(CONFIG_KEYBOARD_MTK_KPD) += mtk-kpd.o
> obj-$(CONFIG_KEYBOARD_MTK_PMIC) += mtk-pmic-keys.o
> obj-$(CONFIG_KEYBOARD_NEWTON) += newtonkbd.o
> obj-$(CONFIG_KEYBOARD_NOMADIK) += nomadik-ske-keypad.o
> diff --git a/drivers/input/keyboard/mtk-kpd.c b/drivers/input/keyboard/mtk-kpd.c
> new file mode 100644
> index 000000000000..0a6b8e2530bc
> --- /dev/null
> +++ b/drivers/input/keyboard/mtk-kpd.c
> @@ -0,0 +1,205 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 MediaTek Inc.
> + * Author Terry Chang <terry.chang@mediatek.com>
> + */
> +#include <linux/bitops.h>
> +#include <linux/clk.h>
> +#include <linux/input/matrix_keypad.h>
> +#include <linux/interrupt.h>
> +#include <linux/module.h>
> +#include <linux/property.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +
> +#define MTK_KPD_NAME "mtk-kpd"
> +#define MTK_KPD_MEM 0x0004
> +#define MTK_KPD_DEBOUNCE 0x0018
> +#define MTK_KPD_DEBOUNCE_MASK GENMASK(13, 0)
> +#define MTK_KPD_DEBOUNCE_MAX_US 256000
> +#define MTK_KPD_NUM_MEMS 5
> +#define MTK_KPD_NUM_BITS 136 /* 4*32+8 MEM5 only use 8 BITS */
> +
> +struct mtk_keypad {
> + struct regmap *regmap;
> + struct input_dev *input_dev;
> + struct clk *clk;
> + void __iomem *base;
> + u32 n_rows;
> + u32 n_cols;
> + DECLARE_BITMAP(keymap_state, MTK_KPD_NUM_BITS);
> +};
> +
> +static const struct regmap_config keypad_regmap_cfg = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = sizeof(u32),
> + .max_register = 36,
> +};
> +
> +static irqreturn_t kpd_irq_handler(int irq, void *dev_id)
> +{
> + struct mtk_keypad *keypad = dev_id;
> + unsigned short *keycode = keypad->input_dev->keycode;
> + DECLARE_BITMAP(new_state, MTK_KPD_NUM_BITS);
> + DECLARE_BITMAP(change, MTK_KPD_NUM_BITS);
> + int bit_nr;
> + int pressed;
> + unsigned short code;
> +
> + regmap_raw_read(keypad->regmap, MTK_KPD_MEM,
> + new_state, MTK_KPD_NUM_MEMS);
> +
> + bitmap_xor(change, new_state, keypad->keymap_state, MTK_KPD_NUM_BITS);
> +
> + for_each_set_bit(bit_nr, change, MTK_KPD_NUM_BITS) {
> + /* 1: not pressed, 0: pressed */
> + pressed = !test_bit(bit_nr, new_state);
> + dev_dbg(&keypad->input_dev->dev, "%s",
> + pressed ? "pressed" : "released");
> +
> + /* 32bit register only use low 16bit as keypad mem register */
> + code = keycode[bit_nr - 16 * (BITS_TO_U32(bit_nr) - 1)];
> +
> + input_report_key(keypad->input_dev, code, pressed);
> + input_sync(keypad->input_dev);
> +
> + dev_dbg(&keypad->input_dev->dev,
> + "report Linux keycode = %d\n", code);
> + }
> +
> + bitmap_copy(keypad->keymap_state, new_state, MTK_KPD_NUM_BITS);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static void kpd_clk_disable(void *data)
> +{
> + clk_disable_unprepare(data);
> +}
> +
> +static int kpd_pdrv_probe(struct platform_device *pdev)
> +{
> + struct mtk_keypad *keypad;
> + unsigned int irq;
> + u32 debounce;
> + bool wakeup;
> + int ret;
> +
> + keypad = devm_kzalloc(&pdev->dev, sizeof(*keypad), GFP_KERNEL);
> + if (!keypad)
> + return -ENOMEM;
> +
> + keypad->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(keypad->base))
> + return PTR_ERR(keypad->base);
> +
> + keypad->regmap = devm_regmap_init_mmio(&pdev->dev,
> + keypad->base,
> + &keypad_regmap_cfg);
> + if (IS_ERR(keypad->regmap)) {
> + dev_err(&pdev->dev,
> + "regmap init failed:%ld\n", PTR_ERR(keypad->regmap));
> + return PTR_ERR(keypad->regmap);
> + }
> +
> + bitmap_fill(keypad->keymap_state, MTK_KPD_NUM_BITS);
> +
> + keypad->input_dev = devm_input_allocate_device(&pdev->dev);
> + if (!keypad->input_dev) {
> + dev_err(&pdev->dev, "Failed to allocate input dev\n");
> + return -ENOMEM;
> + }
> +
> + keypad->input_dev->name = MTK_KPD_NAME;
> + keypad->input_dev->id.bustype = BUS_HOST;
> +
> + ret = matrix_keypad_parse_properties(&pdev->dev, &keypad->n_rows,
> + &keypad->n_cols);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to parse keypad params\n");
> + return ret;
> + }
> +
> + if (device_property_read_u32(&pdev->dev, "mediatek,debounce-us",
> + &debounce))
> + debounce = 16000;
> +
> + if (debounce > MTK_KPD_DEBOUNCE_MAX_US) {
> + dev_err(&pdev->dev, "Debounce time exceeds the maximum allowed time %dus\n",
> + MTK_KPD_DEBOUNCE_MAX_US);
> + return -EINVAL;
> + }
> +
> + wakeup = device_property_read_bool(&pdev->dev, "wakeup-source");
> +
> + dev_dbg(&pdev->dev, "n_row=%d n_col=%d debounce=%d\n",
> + keypad->n_rows, keypad->n_cols, debounce);
> +
> + ret = matrix_keypad_build_keymap(NULL, NULL,
> + keypad->n_rows,
> + keypad->n_cols,
> + NULL,
> + keypad->input_dev);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to build keymap\n");
> + return ret;
> + }
> +
> + regmap_write(keypad->regmap, MTK_KPD_DEBOUNCE,
> + debounce * 32 / 1000 & MTK_KPD_DEBOUNCE_MASK);
> +
> + keypad->clk = devm_clk_get(&pdev->dev, "kpd");
> + if (IS_ERR(keypad->clk))
> + return keypad->clk;
> +
> + ret = clk_prepare_enable(keypad->clk);
> + if (ret) {
> + dev_err(&pdev->dev, "cannot prepare/enable keypad clock\n");
> + return ret;
> + }
> +
> + ret = devm_add_action_or_reset(&pdev->dev, kpd_clk_disable, keypad->clk);
> + if (ret)
> + return ret;
> +
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0)
> + return irq;
> +
> + ret = devm_request_threaded_irq(&pdev->dev, irq,
> + NULL, kpd_irq_handler, 0,
> + MTK_KPD_NAME, keypad);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to request IRQ#%d:%d\n",
> + irq, ret);
> + return ret;
> + }
> +
> + ret = input_register_device(keypad->input_dev);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to register device\n");
> + return ret;
> + }
> +
> + return device_init_wakeup(&pdev->dev, wakeup);
I'm not sure that it's good idea to fail the probe if we can't register wake up
source. Keypad is still working, right? Perhaps simple warning?
> +}
> +
> +static const struct of_device_id kpd_of_match[] = {
> + { .compatible = "mediatek,mt6779-keypad" },
> + { .compatible = "mediatek,mt6873-keypad" },
> + { /* sentinel */ }
> +};
> +
> +static struct platform_driver kpd_pdrv = {
> + .probe = kpd_pdrv_probe,
> + .driver = {
> + .name = MTK_KPD_NAME,
> + .of_match_table = kpd_of_match,
> + },
> +};
> +module_platform_driver(kpd_pdrv);
> +
> +MODULE_AUTHOR("Mediatek Corporation");
> +MODULE_DESCRIPTION("MTK Keypad (KPD) Driver");
> +MODULE_LICENSE("GPL");
> --
> 2.18.0
--
With Best Regards,
Andy Shevchenko
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH 4/5] iio: light: lm3533-als: remove explicit parent assignment
From: Johan Hovold @ 2020-05-29 10:16 UTC (permalink / raw)
To: Alexandru Ardelean
Cc: milo.kim, tomislav.denis, dan, heiko, linux-aspeed, linux-iio,
linus.walleij, eajames, platform-driver-x86, paul,
lorenzo.bianconi83, songqiang1304521, srinivas.pandruvada,
linux-stm32, devel, linux-samsung-soc, khilman, tduszyns, krzk,
linux-rockchip, wens, kgene, bcm-kernel-feedback-list, agross,
linux-input, orsonzhai, alexandre.torgue, linux-pm, linux-arm-msm,
s.hauer, jikos, vilhelm.gray, mripard, vz, hdegoede,
linux-mediatek, ak, matthias.bgg, linux-amlogic, fabrice.gasnier,
linux-arm-kernel, sbranden, rmfrfs, shawnguo, dmitry.torokhov,
coproscefalo, linux-kernel, rjui, slemieux.tyco, bjorn.andersson,
mcoquelin.stm32, zhang.lyra, baolin.wang7, ktsai, syednwaris,
peda, jic23
In-Reply-To: <20200522082208.383631-4-alexandru.ardelean@analog.com>
On Fri, May 22, 2020 at 11:22:07AM +0300, Alexandru Ardelean wrote:
> This assignment is the more peculiar of the bunch as it assigns the parent
> of the platform-device's device (i.e. pdev->dev.parent) as the IIO device's
> parent.
>
> It's unclear whether this is intentional or not.
> Hence it is in it's own patch.
Yeah, we have a few mfd drivers whose child drivers registers their
class devices directly under the parent mfd device rather than the
corresponding child platform device.
Since it's done consistently I think you need to update them all if you
really want to change this.
And it may not be worth it since at least in theory someone could now be
relying on this topology.
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> ---
> drivers/iio/light/lm3533-als.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/iio/light/lm3533-als.c b/drivers/iio/light/lm3533-als.c
> index bc196c212881..0f380ec8d30c 100644
> --- a/drivers/iio/light/lm3533-als.c
> +++ b/drivers/iio/light/lm3533-als.c
> @@ -852,7 +852,6 @@ static int lm3533_als_probe(struct platform_device *pdev)
> indio_dev->channels = lm3533_als_channels;
> indio_dev->num_channels = ARRAY_SIZE(lm3533_als_channels);
> indio_dev->name = dev_name(&pdev->dev);
> - indio_dev->dev.parent = pdev->dev.parent;
> indio_dev->modes = INDIO_DIRECT_MODE;
>
> als = iio_priv(indio_dev);
Johan
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* [PATCH v2 4/5] scsi: ufs-mediatek: Fix unbalanced clock on/off
From: Stanley Chu @ 2020-05-29 9:23 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: pengshun.zhao, Stanley Chu, bvanassche, andy.teng, cc.chou,
chun-hung.wu, kuohong.wang, linux-kernel, cang, linux-mediatek,
peter.wang, matthias.bgg, beanhuo, chaotian.jing,
linux-arm-kernel, asutoshd
In-Reply-To: <20200529092310.1106-1-stanley.chu@mediatek.com>
MediaTek UFS clocks are separated to two parts and controlled
by different modules: ufs-mediatek and phy-ufs-mediatek.
If both Auto-Hibern8 and clk-gating feature are enabled, mphy
power control is not balanced thus unbalanced control also
happens to the clocks probed by phy-ufs-mediatek module.
Fix this issue by
- Promise usage of phy_power_on/off balanced
- Remove phy_power_on/off control in suspend/resume vops since
both can be handled in setup_clock vops only
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
---
drivers/scsi/ufs/ufs-mediatek.c | 56 +++++++++++++++++++--------------
1 file changed, 32 insertions(+), 24 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 5f41b7b7db8f..de9e643fb8dd 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -205,6 +205,23 @@ int ufs_mtk_wait_link_state(struct ufs_hba *hba, u32 state,
return -ETIMEDOUT;
}
+static void ufs_mtk_mphy_power_on(struct ufs_hba *hba, bool on)
+{
+ struct ufs_mtk_host *host = ufshcd_get_variant(hba);
+ struct phy *mphy = host->mphy;
+
+ if (!mphy)
+ return;
+
+ if (on && !host->mphy_powered_on)
+ phy_power_on(mphy);
+ else if (!on && host->mphy_powered_on)
+ phy_power_off(mphy);
+ else
+ return;
+ host->mphy_powered_on = on;
+}
+
/**
* ufs_mtk_setup_clocks - enables/disable clocks
* @hba: host controller instance
@@ -228,25 +245,24 @@ static int ufs_mtk_setup_clocks(struct ufs_hba *hba, bool on,
return 0;
if (!on && status == PRE_CHANGE) {
- if (!ufshcd_is_link_active(hba)) {
- ufs_mtk_setup_ref_clk(hba, on);
- ret = phy_power_off(host->mphy);
- } else {
- /*
- * Gate ref-clk if link state is in Hibern8
- * triggered by Auto-Hibern8.
- */
- if (!ufshcd_can_hibern8_during_gating(hba) &&
- ufshcd_is_auto_hibern8_enabled(hba)) {
- ret = ufs_mtk_wait_link_state(hba,
- VS_LINK_HIBERN8,
- 15);
- if (!ret)
- ufs_mtk_setup_ref_clk(hba, on);
+ /*
+ * Gate ref-clk and poweroff mphy if link state is in OFF
+ * or Hibern8 by either ufshcd_link_state_transition() or
+ * Auto-Hibern8.
+ */
+ if (!ufshcd_is_link_active(hba) ||
+ (!ufshcd_can_hibern8_during_gating(hba) &&
+ ufshcd_is_auto_hibern8_enabled(hba))) {
+ ret = ufs_mtk_wait_link_state(hba,
+ VS_LINK_HIBERN8,
+ 15);
+ if (!ret) {
+ ufs_mtk_setup_ref_clk(hba, on);
+ ufs_mtk_mphy_power_on(hba, on);
}
}
} else if (on && status == POST_CHANGE) {
- ret = phy_power_on(host->mphy);
+ ufs_mtk_mphy_power_on(hba, on);
ufs_mtk_setup_ref_clk(hba, on);
}
@@ -538,7 +554,6 @@ static void ufs_mtk_vreg_set_lpm(struct ufs_hba *hba, bool lpm)
static int ufs_mtk_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
{
int err;
- struct ufs_mtk_host *host = ufshcd_get_variant(hba);
if (ufshcd_is_link_hibern8(hba)) {
err = ufs_mtk_link_set_lpm(hba);
@@ -559,20 +574,13 @@ static int ufs_mtk_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
ufs_mtk_vreg_set_lpm(hba, true);
}
- if (!ufshcd_is_link_active(hba))
- phy_power_off(host->mphy);
-
return 0;
}
static int ufs_mtk_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
{
- struct ufs_mtk_host *host = ufshcd_get_variant(hba);
int err;
- if (!ufshcd_is_link_active(hba))
- phy_power_on(host->mphy);
-
if (ufshcd_is_link_hibern8(hba)) {
ufs_mtk_vreg_set_lpm(hba, false);
err = ufs_mtk_link_set_hpm(hba);
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* [PATCH v2 1/5] scsi: ufs-mediatek: Fix imprecise waiting time for ref-clk control
From: Stanley Chu @ 2020-05-29 9:23 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: pengshun.zhao, Stanley Chu, bvanassche, andy.teng, cc.chou,
chun-hung.wu, kuohong.wang, linux-kernel, cang, linux-mediatek,
peter.wang, matthias.bgg, beanhuo, chaotian.jing,
linux-arm-kernel, asutoshd
In-Reply-To: <20200529092310.1106-1-stanley.chu@mediatek.com>
Currently ref-clk control timeout is implemented by Jiffies. However
jiffies is not accurate enough thus "false timeout" may happen.
Use more accurate delay mechanism instead, for example, ktime.
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Andy Teng <andy.teng@mediatek.com>
---
drivers/scsi/ufs/ufs-mediatek.c | 7 ++++---
drivers/scsi/ufs/ufs-mediatek.h | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index d56ce8d97d4e..523ee5573921 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -120,7 +120,7 @@ static int ufs_mtk_setup_ref_clk(struct ufs_hba *hba, bool on)
{
struct ufs_mtk_host *host = ufshcd_get_variant(hba);
struct arm_smccc_res res;
- unsigned long timeout;
+ ktime_t timeout, time_checked;
u32 value;
if (host->ref_clk_enabled == on)
@@ -135,8 +135,9 @@ static int ufs_mtk_setup_ref_clk(struct ufs_hba *hba, bool on)
}
/* Wait for ack */
- timeout = jiffies + msecs_to_jiffies(REFCLK_REQ_TIMEOUT_MS);
+ timeout = ktime_add_us(ktime_get(), REFCLK_REQ_TIMEOUT_US);
do {
+ time_checked = ktime_get();
value = ufshcd_readl(hba, REG_UFS_REFCLK_CTRL);
/* Wait until ack bit equals to req bit */
@@ -144,7 +145,7 @@ static int ufs_mtk_setup_ref_clk(struct ufs_hba *hba, bool on)
goto out;
usleep_range(100, 200);
- } while (time_before(jiffies, timeout));
+ } while (ktime_before(time_checked, timeout));
dev_err(hba->dev, "missing ack of refclk req, reg: 0x%x\n", value);
diff --git a/drivers/scsi/ufs/ufs-mediatek.h b/drivers/scsi/ufs/ufs-mediatek.h
index 5bbd3e9cbae2..fc42dcbfd800 100644
--- a/drivers/scsi/ufs/ufs-mediatek.h
+++ b/drivers/scsi/ufs/ufs-mediatek.h
@@ -28,7 +28,7 @@
#define REFCLK_REQUEST BIT(0)
#define REFCLK_ACK BIT(1)
-#define REFCLK_REQ_TIMEOUT_MS 3
+#define REFCLK_REQ_TIMEOUT_US 3000
/*
* Vendor specific pre-defined parameters
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* [PATCH v2 2/5] scsi: ufs-mediatek: Do not gate clocks if auto-hibern8 is not entered yet
From: Stanley Chu @ 2020-05-29 9:23 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: pengshun.zhao, Stanley Chu, bvanassche, andy.teng, cc.chou,
chun-hung.wu, kuohong.wang, linux-kernel, cang, linux-mediatek,
peter.wang, matthias.bgg, beanhuo, chaotian.jing,
linux-arm-kernel, asutoshd
In-Reply-To: <20200529092310.1106-1-stanley.chu@mediatek.com>
There are some chances that link enters hibern8 lately by auto-hibern8
scheme during the clock-gating flow. Clocks shall not be gated if link
is still active otherwise host or device may hang.
Fix this by returning error code to the caller __ufshcd_setup_clocks()
to skip gating clocks there if link is not confirmed in hibern8
state yet.
Also allow some waiting time for the hibern8 state transition.
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Andy Teng <andy.teng@mediatek.com>
---
drivers/scsi/ufs/ufs-mediatek.c | 36 ++++++++++++++++++++++++---------
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 523ee5573921..3c85f5e97dea 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -178,15 +178,30 @@ static void ufs_mtk_setup_ref_clk_wait_us(struct ufs_hba *hba,
host->ref_clk_ungating_wait_us = ungating_us;
}
-static u32 ufs_mtk_link_get_state(struct ufs_hba *hba)
+int ufs_mtk_wait_link_state(struct ufs_hba *hba, u32 state,
+ unsigned long max_wait_ms)
{
+ ktime_t timeout, time_checked;
u32 val;
- ufshcd_writel(hba, 0x20, REG_UFS_DEBUG_SEL);
- val = ufshcd_readl(hba, REG_UFS_PROBE);
- val = val >> 28;
+ timeout = ktime_add_us(ktime_get(), ms_to_ktime(max_wait_ms));
+ do {
+ time_checked = ktime_get();
+ ufshcd_writel(hba, 0x20, REG_UFS_DEBUG_SEL);
+ val = ufshcd_readl(hba, REG_UFS_PROBE);
+ val = val >> 28;
+
+ if (val == state)
+ return 0;
- return val;
+ /* Sleep for max. 200us */
+ usleep_range(100, 200);
+ } while (ktime_before(time_checked, timeout));
+
+ if (val == state)
+ return 0;
+
+ return -ETIMEDOUT;
}
/**
@@ -221,10 +236,13 @@ static int ufs_mtk_setup_clocks(struct ufs_hba *hba, bool on,
* triggered by Auto-Hibern8.
*/
if (!ufshcd_can_hibern8_during_gating(hba) &&
- ufshcd_is_auto_hibern8_enabled(hba) &&
- ufs_mtk_link_get_state(hba) ==
- VS_LINK_HIBERN8)
- ufs_mtk_setup_ref_clk(hba, on);
+ ufshcd_is_auto_hibern8_enabled(hba)) {
+ ret = ufs_mtk_wait_link_state(hba,
+ VS_LINK_HIBERN8,
+ 15);
+ if (!ret)
+ ufs_mtk_setup_ref_clk(hba, on);
+ }
}
} else if (on && status == POST_CHANGE) {
ret = phy_power_on(host->mphy);
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* [PATCH v2 5/5] scsi: ufs-mediatek: Allow unbound mphy
From: Stanley Chu @ 2020-05-29 9:23 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: pengshun.zhao, Stanley Chu, bvanassche, andy.teng, cc.chou,
chun-hung.wu, kuohong.wang, linux-kernel, cang, linux-mediatek,
peter.wang, matthias.bgg, beanhuo, chaotian.jing,
linux-arm-kernel, asutoshd
In-Reply-To: <20200529092310.1106-1-stanley.chu@mediatek.com>
Allow unbound MPHY module since not every MediaTek UFS platform
needs specific MPHY control.
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
---
drivers/scsi/ufs/ufs-mediatek.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index de9e643fb8dd..d587b3276aa8 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -113,6 +113,12 @@ static int ufs_mtk_bind_mphy(struct ufs_hba *hba)
if (err)
host->mphy = NULL;
+ /*
+ * Allow unbound mphy because not every platform needs specific
+ * mphy control.
+ */
+ if (err == -ENODEV)
+ err = 0;
return err;
}
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* [PATCH v2 0/5] scsi: ufs-mediatek: Fix clk-gating and introduce low-power mode for vccq2
From: Stanley Chu @ 2020-05-29 9:23 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: pengshun.zhao, Stanley Chu, bvanassche, andy.teng, cc.chou,
chun-hung.wu, kuohong.wang, linux-kernel, cang, linux-mediatek,
peter.wang, matthias.bgg, beanhuo, chaotian.jing,
linux-arm-kernel, asutoshd
Hi,
This series fixes clk-gating issues and introduces low-power mode for vccq2 in MediaTek platforms.
v1 -> v2:
- Add patch [4] and [5]
Stanley Chu (5):
scsi: ufs-mediatek: Fix imprecise waiting time for ref-clk control
scsi: ufs-mediatek: Do not gate clocks if auto-hibern8 is not entered
yet
scsi: ufs-mediatek: Introduce low-power mode for device power supply
scsi: ufs-mediatek: Fix unbalanced clock on/off
scsi: ufs-mediatek: Allow unbound mphy
drivers/scsi/ufs/ufs-mediatek.c | 112 +++++++++++++++++++++++---------
drivers/scsi/ufs/ufs-mediatek.h | 2 +-
2 files changed, 84 insertions(+), 30 deletions(-)
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* [PATCH v2 3/5] scsi: ufs-mediatek: Introduce low-power mode for device power supply
From: Stanley Chu @ 2020-05-29 9:23 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: pengshun.zhao, Stanley Chu, bvanassche, andy.teng, cc.chou,
chun-hung.wu, kuohong.wang, linux-kernel, cang, linux-mediatek,
peter.wang, matthias.bgg, beanhuo, chaotian.jing,
linux-arm-kernel, asutoshd
In-Reply-To: <20200529092310.1106-1-stanley.chu@mediatek.com>
Allow device power supply to enter low-power mode if device will
do nothing to save more power.
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Pengshun Zhao <pengshun.zhao@mediatek.com>
---
drivers/scsi/ufs/ufs-mediatek.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 3c85f5e97dea..5f41b7b7db8f 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -12,6 +12,7 @@
#include <linux/of_address.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
#include <linux/soc/mediatek/mtk_sip_svc.h>
#include "ufshcd.h"
@@ -521,6 +522,19 @@ static int ufs_mtk_link_set_lpm(struct ufs_hba *hba)
return 0;
}
+static void ufs_mtk_vreg_set_lpm(struct ufs_hba *hba, bool lpm)
+{
+ if (!hba->vreg_info.vccq2)
+ return;
+
+ if (lpm & !hba->vreg_info.vcc->enabled)
+ regulator_set_mode(hba->vreg_info.vccq2->reg,
+ REGULATOR_MODE_IDLE);
+ else if (!lpm)
+ regulator_set_mode(hba->vreg_info.vccq2->reg,
+ REGULATOR_MODE_NORMAL);
+}
+
static int ufs_mtk_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
{
int err;
@@ -537,6 +551,12 @@ static int ufs_mtk_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
ufshcd_set_link_off(hba);
return -EAGAIN;
}
+ /*
+ * Make sure no error will be returned to prevent
+ * ufshcd_suspend() re-enabling regulators while vreg is still
+ * in low-power mode.
+ */
+ ufs_mtk_vreg_set_lpm(hba, true);
}
if (!ufshcd_is_link_active(hba))
@@ -554,6 +574,7 @@ static int ufs_mtk_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
phy_power_on(host->mphy);
if (ufshcd_is_link_hibern8(hba)) {
+ ufs_mtk_vreg_set_lpm(hba, false);
err = ufs_mtk_link_set_hpm(hba);
if (err) {
err = ufshcd_link_recovery(hba);
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* Re: [PATCH] net: ethernet: mtk-star-emac: remove unused variable
From: Bartosz Golaszewski @ 2020-05-29 8:27 UTC (permalink / raw)
To: John Crispin, Sean Wang, Mark Lee, David S . Miller,
Jakub Kicinski, Matthias Brugger
Cc: kbuild test robot, Stephane Le Provost, Bartosz Golaszewski,
netdev, Linux Kernel Mailing List, Fabien Parent,
moderated list:ARM/Mediatek SoC..., Andrew Perepech, Pedro Tsai,
Linux ARM
In-Reply-To: <20200529082648.19677-1-brgl@bgdev.pl>
pt., 29 maj 2020 o 10:26 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
>
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> The desc pointer is set but not used. Remove it.
>
> Reported-by: kbuild test robot <lkp@intel.com>
> Fixes: 8c7bd5a454ff ("net: ethernet: mtk-star-emac: new driver")
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> drivers/net/ethernet/mediatek/mtk_star_emac.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_star_emac.c b/drivers/net/ethernet/mediatek/mtk_star_emac.c
> index 8596ca0e60eb..7df35872c107 100644
> --- a/drivers/net/ethernet/mediatek/mtk_star_emac.c
> +++ b/drivers/net/ethernet/mediatek/mtk_star_emac.c
> @@ -746,15 +746,12 @@ mtk_star_ring_free_skbs(struct mtk_star_priv *priv, struct mtk_star_ring *ring,
> struct mtk_star_ring_desc_data *))
> {
> struct mtk_star_ring_desc_data desc_data;
> - struct mtk_star_ring_desc *desc;
> int i;
>
> for (i = 0; i < MTK_STAR_RING_NUM_DESCS; i++) {
> if (!ring->dma_addrs[i])
> continue;
>
> - desc = &ring->descs[i];
> -
> desc_data.dma_addr = ring->dma_addrs[i];
> desc_data.skb = ring->skbs[i];
>
> --
> 2.26.1
>
Cr*p I forgot to tag it for net-next. David let me know if you want me
to resend it.
Bartosz
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* [PATCH] net: ethernet: mtk-star-emac: remove unused variable
From: Bartosz Golaszewski @ 2020-05-29 8:26 UTC (permalink / raw)
To: John Crispin, Sean Wang, Mark Lee, David S . Miller,
Jakub Kicinski, Matthias Brugger
Cc: kbuild test robot, Stephane Le Provost, Bartosz Golaszewski,
netdev, linux-kernel, Fabien Parent, linux-mediatek,
Andrew Perepech, Pedro Tsai, linux-arm-kernel
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
The desc pointer is set but not used. Remove it.
Reported-by: kbuild test robot <lkp@intel.com>
Fixes: 8c7bd5a454ff ("net: ethernet: mtk-star-emac: new driver")
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/net/ethernet/mediatek/mtk_star_emac.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_star_emac.c b/drivers/net/ethernet/mediatek/mtk_star_emac.c
index 8596ca0e60eb..7df35872c107 100644
--- a/drivers/net/ethernet/mediatek/mtk_star_emac.c
+++ b/drivers/net/ethernet/mediatek/mtk_star_emac.c
@@ -746,15 +746,12 @@ mtk_star_ring_free_skbs(struct mtk_star_priv *priv, struct mtk_star_ring *ring,
struct mtk_star_ring_desc_data *))
{
struct mtk_star_ring_desc_data desc_data;
- struct mtk_star_ring_desc *desc;
int i;
for (i = 0; i < MTK_STAR_RING_NUM_DESCS; i++) {
if (!ring->dma_addrs[i])
continue;
- desc = &ring->descs[i];
-
desc_data.dma_addr = ring->dma_addrs[i];
desc_data.skb = ring->skbs[i];
--
2.26.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ 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