* [PATCH 5/8] pinctrl: aspeed: Enable capture of off-SCU pinmux state
From: Andrew Jeffery @ 2016-09-29 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8Xc7y3GtcJCVYYs-JKTqBZvqVeZaz5MUk=UX151SX1xEFw@mail.gmail.com>
On Thu, 2016-09-29 at 16:15 +0930, Joel Stanley wrote:
> On Wed, Sep 28, 2016 at 12:20 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> >
> > The System Control Unit IP in the Aspeed SoCs is typically where the
> > pinmux configuration is found.
> >
> > But not always.
> >
> > On the AST2400 and AST2500 a number of pins depend on state in one of
> > the SIO, LPC or GFX IP blocks, so add support to at least capture what
> > that state is. The pinctrl engine for the Aspeed SoCs doesn't try to
> > inspect or modify the state of the off-SCU IP blocks. Instead, it logs
> > the state requirement with the expectation that the platform
> > designer/maintainer arranges for the appropriate configuration to be
> > applied through the associated drivers.
> This is unfortunate.
>
> This patch kicks the can down the road, but doesn't solve the problem
> for a user who wants to configure some functionality that depends on
> the non-SCU bits. Because of this I'm not sure if we want to put it in
> the tree.
I agree that there's not much functionality from a user's perspective,
but the "kicking the can down the road" assessment might be a little
harsh. Given the lack of user functionality it becomes more difficult
to argue for the patch's inclusion given the additional complexity, but
it does mean that the g4/g5 drivers can completely specify their
dependencies and not have the aspeed pinctrl core do the wrong thing
when it encounters the non-SCU IP offsets. It gets us half-way to
having the pinctrl driver actually configure the state (knowing what it
needs to configure), which I feel is more than a kick-the-can-down-the-
road boondoggle.
>
> However, I'm not sure what a proper solution would look like.
So if we accept that a proper solution includes specifying the off-SCU
dependencies, the remaining question is how do we tastefully apply the
desired state on register-spaces the pinctrl driver doesn't own.
> Perhaps
> Linus can point out another SoC that has a similar problem?
Or failing that, an approach that is acceptable...
Cheers,
Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160929/31192dfd/attachment-0001.sig>
^ permalink raw reply
* drm/mediatek: fixed the calc method of data rate per lane
From: CK Hu @ 2016-09-29 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472191831-7150-1-git-send-email-jitao.shi@mediatek.com>
Hi, Jitao:
Sorry for late reply.
Some comments inline.
On Fri, 2016-08-26 at 14:10 +0800, Jitao Shi wrote:
> Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
> Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
> signal will cause h-time larger than normal and reduce FPS.
> Need to multiply a coefficient to offset the extra signal's effect.
> coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+Ths_trail+
> Ths_exit)/(htotal*bpp/lane_number))
>
> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 111 ++++++++++++++++++++++--------------
> 1 file changed, 67 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 28b2044..506aa22 100644
[snip...]
>
> -static void dsi_phy_timconfig(struct mtk_dsi *dsi)
> +static void dsi_phy_timconfig(struct mtk_dsi *dsi, u32 phy_timing0,
> + u32 phy_timing1, u32 phy_timing2,
> + u32 phy_timing3)
> {
> - u32 timcon0, timcon1, timcon2, timcon3;
> - unsigned int ui, cycle_time;
> - unsigned int lpx;
> -
> - ui = 1000 / dsi->data_rate + 0x01;
> - cycle_time = 8000 / dsi->data_rate + 0x01;
> - lpx = 5;
> -
> - timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
> - timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
> - (4 * lpx);
> - timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> - (NS_TO_CYCLE(0x150, cycle_time) << 16);
> - timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
> - NS_TO_CYCLE(0x40, cycle_time);
> -
> - writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
> - writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
> - writel(timcon2, dsi->regs + DSI_PHY_TIMECON2);
> - writel(timcon3, dsi->regs + DSI_PHY_TIMECON3);
> + writel(phy_timing0, dsi->regs + DSI_PHY_TIMECON0);
> + writel(phy_timing1, dsi->regs + DSI_PHY_TIMECON1);
> + writel(phy_timing2, dsi->regs + DSI_PHY_TIMECON2);
> + writel(phy_timing3, dsi->regs + DSI_PHY_TIMECON3);
> }
>
> static void mtk_dsi_enable(struct mtk_dsi *dsi)
> @@ -202,19 +186,57 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> {
> struct device *dev = dsi->dev;
> int ret;
> + u64 bit_clock, total_bits;
> + u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
> + u32 phy_timing0, phy_timing1, phy_timing2, phy_timing3;
>
> if (++dsi->refcount != 1)
> return 0;
>
> + phy_timing0 = LPX(5) | HS_PRPR(6) | HS_ZERO(10) | HS_TRAIL(8);
> + phy_timing1 = TA_GO(20) | TA_SURE(7) | TA_GET(25) | DA_HS_EXIT(7);
> + phy_timing2 = CLK_ZERO(38) | CLK_TRAIL(22);
> + phy_timing3 = CLK_HS_PRPR(8) | CLK_HS_POST(21) | CLK_HS_EXIT(10);
The original phy_timing2 and phy_timing3 is defined as
timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
(NS_TO_CYCLE(0x150, cycle_time) << 16);
timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8
|
NS_TO_CYCLE(0x40, cycle_time);
They are varied by cycle_time. I think you should not use a fixed value
for them.
> +
> + switch (dsi->format) {
> + case MIPI_DSI_FMT_RGB565:
> + bit_per_pixel = 16;
> + break;
> + case MIPI_DSI_FMT_RGB666_PACKED:
> + bit_per_pixel = 18;
> + break;
> + case MIPI_DSI_FMT_RGB666:
> + case MIPI_DSI_FMT_RGB888:
> + default:
> + bit_per_pixel = 24;
> + break;
> + }
> /**
> - * data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
> - * pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
> - * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
> - * we set mipi_ratio is 1.05.
> + * data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
> + * vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
> + * mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
> + * + Thstrail + Ths_exit + Ths_zero) /
> + * (htotal * byte_per_pixel /lane_number)
> */
> - dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
> + bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
> + htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
> + dsi->vm.hsync_len;
> + htotal_bits = htotal * bit_per_pixel;
> +
> + /**
> + * overhead = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
> + */
> + overhead_cycles = (phy_timing0 & 0xff) + (phy_timing0 >> 8 & 0xff) +
> + (phy_timing0 >> 16 & 0xff) +
> + (phy_timing0 >> 24 & 0xff) +
> + (phy_timing1 >> 24 & 0xff);
I think phy_timing0 and phy_timing1 is defined as
phy_timing0 = LPX(a) | HS_PRPR(b) | HS_ZERO(c) | HS_TRAIL(d);
phy_timing1 = TA_GO(e) | TA_SURE(f) | TA_GET(g) | DA_HS_EXIT(h);
So, it could be a more simple way to assign overhead_cycles like this
overhead_cycles = a + b + c + d + h;
Because these variable are constant, maybe you can define them as
symbols.
> + overhead_bits = overhead_cycles * dsi->lanes * 8;
> + total_bits = htotal_bits + overhead_bits;
> +
> + dsi->data_rate = DIV_ROUND_UP_ULL(bit_clock * total_bits,
> + htotal_bits * dsi->lanes);
>
> - ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
> + ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
> if (ret < 0) {
> dev_err(dev, "Failed to set data rate: %d\n", ret);
> goto err_refcount;
> @@ -236,7 +258,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>
> mtk_dsi_enable(dsi);
> mtk_dsi_reset(dsi);
> - dsi_phy_timconfig(dsi);
> + dsi_phy_timconfig(dsi, phy_timing0, phy_timing1, phy_timing2,
> + phy_timing3);
>
> return 0;
>
Regards,
CK
^ permalink raw reply
* [PATCH v6 0/3] arm64 kexec-tools patches
From: Simon Horman @ 2016-09-29 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923085840.GA22928@localhost.localdomain>
On Wed, Sep 28, 2016 at 06:05:14PM +0200, Matthias Brugger wrote:
>
>
> On 21/09/16 20:14, Geoff Levand wrote:
> >This series adds the core support for kexec re-boot on ARM64.
> >
>
> I also tested on seattle.
>
> Tested-By: Matthias Brugger <mbrugger@suse.com>
On Fri, Sep 23, 2016 at 02:28:40PM +0530, Pratyush Anand wrote:
> Hi Geoff,
>
> On 21/09/2016:06:14:25 PM, Geoff Levand wrote:
> > This series adds the core support for kexec re-boot on ARM64.
>
> I tested this series with mustang and seattle and they work.
>
> So you can use my "Tested-By: Pratyush Anand <panand@redhat.com>".
>
> Just one Nitpick: In patch 2/3 arm64_header_check_msb(),
> arm64_header_page_size() and arm64_header_placement() have been defined but they
> have not been used anywhere. So, may be they can be removed.
Thanks everyone, I have queued this up with the above tags.
Please consider a follow-up patch to remove the functions mentioned above.
FWIW I tested v5 of this patchset on Renesas Gen3 R-Car H3 and M3-W and
it seems to work fine.
^ permalink raw reply
* [PATCH] MAINTAINERS: update entry for atmel_serial driver
From: Nicolas Ferre @ 2016-09-29 7:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929063148.GA418@kroah.com>
Le 29/09/2016 ? 08:31, Greg Kroah-Hartman a ?crit :
> On Wed, Sep 28, 2016 at 05:47:35PM +0200, Nicolas Ferre wrote:
>> Change maintainer for the serial driver found on most of the
>> Microchip / Atmel MPUs and take advantage of the move to rename
>> and reorder the entry.
>> I'm happy that Richard is taking over the maintenance of this
>> driver.
>>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>> Acked-by: Richard Genoud <richard.genoud@gmail.com>
>> ---
>> MAINTAINERS | 11 ++++++-----
>> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> This doesn't apply to my tty-next tree at all, what did you make it
> against?
Yesterdays' linux-next (next-20160928 tag). I thought it would be the
best for easy pick-up by anybody, particularly on a highly shared file
like MAINTAINERS.
Tell me if you want me to collect all tags, rebase on tty-next and re-send.
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency
From: Jisheng Zhang @ 2016-09-29 7:34 UTC (permalink / raw)
To: linux-arm-kernel
On Marvell berlin arm64 platforms, I see the preemptoff tracer report
a max 26543 us latency at __purge_vmap_area_lazy, this latency is an
awfully bad for STB. And the ftrace log also shows __free_vmap_area
contributes most latency now. I noticed that Joel mentioned the same
issue[1] on x86 platform and gave two solutions, but it seems no patch
is sent out for this purpose.
This patch adopts Joel's first solution, but I use 16MB per core
rather than 8MB per core for the number of lazy_max_pages. After this
patch, the preemptoff tracer reports a max 6455us latency, reduced to
1/4 of original result.
[1] http://lkml.iu.edu/hypermail/linux/kernel/1603.2/04803.html
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
---
mm/vmalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 91f44e7..66f377a 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -596,7 +596,7 @@ static unsigned long lazy_max_pages(void)
log = fls(num_online_cpus());
- return log * (32UL * 1024 * 1024 / PAGE_SIZE);
+ return log * (16UL * 1024 * 1024 / PAGE_SIZE);
}
static atomic_t vmap_lazy_nr = ATOMIC_INIT(0);
--
2.9.3
^ permalink raw reply related
* [PATCH] arm64: set path to Image.gz in the mkspec to avoid rpm build issue
From: Michal Marek @ 2016-09-29 7:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160928094913.GD24658@arm.com>
On 2016-09-28 11:49, Will Deacon wrote:
> [Adding Michal Marek]
>
> On Tue, Sep 27, 2016 at 08:53:47AM -0700, Vadim Lomovtsev wrote:
>> In addition to http://www.spinics.net/lists/arm-kernel/msg527466.html
>>
>> While building rpm-pkg target it fails to copy kernel image
>> from default location to rpm buildroot directory.
>>
>> Since we have arch variable set to aarch64 while Image.gz
>> is located at arch/arm64/boot it's necessary to specify
>> correct path to cp command as it implemeted for ppc64 build.
The variable should point to the actual file. ppc64 should be fixed as well.
Michal
^ permalink raw reply
* [PATCH] MAINTAINERS: add myself as Marvell berlin SoC co-maintainers
From: Jisheng Zhang @ 2016-09-29 6:55 UTC (permalink / raw)
To: linux-arm-kernel
I would like to help maintaining Marvell berlin SoCs.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b003d0c..b1e5243 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1411,6 +1411,7 @@ F: arch/arm/configs/mvebu_*_defconfig
ARM/Marvell Berlin SoC support
M: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+M: Jisheng Zhang <jszhang@marvell.com>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-berlin/
--
2.9.3
^ permalink raw reply related
* [PATCH 5/8] pinctrl: aspeed: Enable capture of off-SCU pinmux state
From: Joel Stanley @ 2016-09-29 6:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a266046d34009e6e92c4c76699c550c2ba44bd5c.1474986045.git-series.andrew@aj.id.au>
On Wed, Sep 28, 2016 at 12:20 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> The System Control Unit IP in the Aspeed SoCs is typically where the
> pinmux configuration is found.
>
> But not always.
>
> On the AST2400 and AST2500 a number of pins depend on state in one of
> the SIO, LPC or GFX IP blocks, so add support to at least capture what
> that state is. The pinctrl engine for the Aspeed SoCs doesn't try to
> inspect or modify the state of the off-SCU IP blocks. Instead, it logs
> the state requirement with the expectation that the platform
> designer/maintainer arranges for the appropriate configuration to be
> applied through the associated drivers.
This is unfortunate.
This patch kicks the can down the road, but doesn't solve the problem
for a user who wants to configure some functionality that depends on
the non-SCU bits. Because of this I'm not sure if we want to put it in
the tree.
However, I'm not sure what a proper solution would look like. Perhaps
Linus can point out another SoC that has a similar problem?
Cheers,
Joel
>
> The IP block of interest is encoded in the reg member of struct
> aspeed_sig_desc. For compatibility with the existing code, the SCU is
> defined to have an IP value of 0.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> drivers/pinctrl/aspeed/pinctrl-aspeed.c | 53 +++++++++++++++++++++++---
> drivers/pinctrl/aspeed/pinctrl-aspeed.h | 16 +++++++-
> 2 files changed, 61 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.c b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> index 49aeba912531..21ef195d586f 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> @@ -14,6 +14,8 @@
> #include "../core.h"
> #include "pinctrl-aspeed.h"
>
> +const char *const aspeed_pinmux_ips[] = { "SCU", "SIO", "GFX", "LPC" };
> +
> int aspeed_pinctrl_get_groups_count(struct pinctrl_dev *pctldev)
> {
> struct aspeed_pinctrl_data *pdata = pinctrl_dev_get_drvdata(pctldev);
> @@ -78,7 +80,9 @@ int aspeed_pinmux_get_fn_groups(struct pinctrl_dev *pctldev,
> static inline void aspeed_sig_desc_print_val(
> const struct aspeed_sig_desc *desc, bool enable, u32 rv)
> {
> - pr_debug("SCU%x[0x%08x]=0x%x, got 0x%x from 0x%08x\n", desc->reg,
> + pr_debug("Want %s%lX[0x%08X]=0x%X, got 0x%X from 0x%08X\n",
> + aspeed_pinmux_ips[SIG_DESC_IP_FROM_REG(desc->reg)],
> + SIG_DESC_OFFSET_FROM_REG(desc->reg),
> desc->mask, enable ? desc->enable : desc->disable,
> (rv & desc->mask) >> __ffs(desc->mask), rv);
> }
> @@ -105,6 +109,8 @@ static bool aspeed_sig_desc_eval(const struct aspeed_sig_desc *desc,
> unsigned int raw;
> u32 want;
>
> + WARN_ON(SIG_DESC_IP_FROM_REG(desc->reg) != ASPEED_IP_SCU);
> +
> if (regmap_read(map, desc->reg, &raw) < 0)
> return false;
>
> @@ -142,9 +148,19 @@ static bool aspeed_sig_expr_eval(const struct aspeed_sig_expr *expr,
>
> for (i = 0; i < expr->ndescs; i++) {
> const struct aspeed_sig_desc *desc = &expr->descs[i];
> + size_t ip = SIG_DESC_IP_FROM_REG(desc->reg);
> +
> + if (ip == ASPEED_IP_SCU) {
> + if (!aspeed_sig_desc_eval(desc, enabled, map))
> + return false;
> + } else {
> + size_t offset = SIG_DESC_OFFSET_FROM_REG(desc->reg);
> + const char *ip_name = aspeed_pinmux_ips[ip];
> +
> + pr_debug("Ignoring configuration of field %s%X[0x%08X]\n",
> + ip_name, offset, desc->mask);
> + }
>
> - if (!aspeed_sig_desc_eval(desc, enabled, map))
> - return false;
> }
>
> return true;
> @@ -170,7 +186,14 @@ static bool aspeed_sig_expr_set(const struct aspeed_sig_expr *expr,
> for (i = 0; i < expr->ndescs; i++) {
> bool ret;
> const struct aspeed_sig_desc *desc = &expr->descs[i];
> +
> + size_t offset = SIG_DESC_OFFSET_FROM_REG(desc->reg);
> + size_t ip = SIG_DESC_IP_FROM_REG(desc->reg);
> + bool is_scu = (ip == ASPEED_IP_SCU);
> + const char *ip_name = aspeed_pinmux_ips[ip];
> +
> u32 pattern = enable ? desc->enable : desc->disable;
> + u32 val = (pattern << __ffs(desc->mask));
>
> /*
> * Strap registers are configured in hardware or by early-boot
> @@ -179,11 +202,27 @@ static bool aspeed_sig_expr_set(const struct aspeed_sig_expr *expr,
> * deconfigured and is the reason we re-evaluate after writing
> * all descriptor bits.
> */
> - if (desc->reg == HW_STRAP1 || desc->reg == HW_STRAP2)
> + if (is_scu && (offset == HW_STRAP1 || offset == HW_STRAP2))
> continue;
>
> - ret = regmap_update_bits(map, desc->reg, desc->mask,
> - pattern << __ffs(desc->mask)) == 0;
> + /*
> + * Sometimes we need help from IP outside the SCU to activate a
> + * mux request. Report that we need its cooperation.
> + */
> + if (enable && !is_scu) {
> + pr_debug("Pinmux request for %s requires cooperation of %s IP: Need (%s%X[0x%08X] = 0x%08X\n",
> + expr->function, ip_name, ip_name, offset,
> + desc->mask, val);
> + }
> +
> + /* And only read/write SCU registers */
> + if (!is_scu) {
> + pr_debug("Skipping configuration of field %s%X[0x%08X]\n",
> + ip_name, offset, desc->mask);
> + continue;
> + }
> +
> + ret = regmap_update_bits(map, desc->reg, desc->mask, val) == 0;
>
> if (!ret)
> return ret;
> @@ -343,6 +382,8 @@ int aspeed_pinmux_set_mux(struct pinctrl_dev *pctldev, unsigned int function,
> const struct aspeed_sig_expr **funcs;
> const struct aspeed_sig_expr ***prios;
>
> + pr_debug("Muxing pin %d for %s\n", pin, pfunc->name);
> +
> if (!pdesc)
> return -EINVAL;
>
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.h b/drivers/pinctrl/aspeed/pinctrl-aspeed.h
> index 3e72ef8c54bf..4384407d77fb 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed.h
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.h
> @@ -232,6 +232,15 @@
> * group.
> */
>
> +#define ASPEED_IP_SCU 0
> +#define ASPEED_IP_SIO 1
> +#define ASPEED_IP_GFX 2
> +#define ASPEED_IP_LPC 3
> +
> +#define SIG_DESC_TO_REG(ip, offset) (((ip) << 24) | (offset))
> +#define SIG_DESC_IP_FROM_REG(reg) (((reg) >> 24) & GENMASK(7, 0))
> +#define SIG_DESC_OFFSET_FROM_REG(reg) ((reg) & GENMASK(11, 0))
> +
> /*
> * The "Multi-function Pins Mapping and Control" table in the SoC datasheet
> * references registers by the device/offset mnemonic. The register macros
> @@ -261,7 +270,10 @@
> * A signal descriptor, which describes the register, bits and the
> * enable/disable values that should be compared or written.
> *
> - * @reg: The register offset from base in bytes
> + * @reg: Split into three fields:
> + * 31:24: IP selector
> + * 23:12: Reserved
> + * 11:0: Register offset
> * @mask: The mask to apply to the register. The lowest set bit of the mask is
> * used to derive the shift value.
> * @enable: The value that enables the function. Value should be in the LSBs,
> @@ -270,7 +282,7 @@
> * LSBs, not at the position of the mask.
> */
> struct aspeed_sig_desc {
> - unsigned int reg;
> + u32 reg;
> u32 mask;
> u32 enable;
> u32 disable;
> --
> git-series 0.8.10
^ permalink raw reply
* [PATCH RFC 6/8] ARM: dts: r8a7743: add SYS-DMAC support
From: Geert Uytterhoeven @ 2016-09-29 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <be7575a5-e9a0-05a6-5b2d-803632c7edac@cogentembedded.com>
Hi Sergei,
On Wed, Sep 28, 2016 at 10:09 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> On 09/19/2016 11:19 AM, Geert Uytterhoeven wrote:
>>> --- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
>>> +++ renesas/arch/arm/boot/dts/r8a7743.dtsi
>>> @@ -90,6 +90,70 @@
>>> #power-domain-cells = <1>;
>>> };
>>>
>>> + dmac0: dma-controller at e6700000 {
>>> + compatible = "renesas,dmac-r8a7743",
>>
>>
>> To be documented.
>
> The R-Car DMAC binding has "renesas,dmac-<soctype>" documented.
> I can add the mention of RZ/G and new examples though...
Just adding a line for RZ/G1M should be sufficient. Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] MAINTAINERS: update entry for atmel_serial driver
From: Greg Kroah-Hartman @ 2016-09-29 6:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160928154735.25265-1-nicolas.ferre@atmel.com>
On Wed, Sep 28, 2016 at 05:47:35PM +0200, Nicolas Ferre wrote:
> Change maintainer for the serial driver found on most of the
> Microchip / Atmel MPUs and take advantage of the move to rename
> and reorder the entry.
> I'm happy that Richard is taking over the maintenance of this
> driver.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> Acked-by: Richard Genoud <richard.genoud@gmail.com>
> ---
> MAINTAINERS | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
This doesn't apply to my tty-next tree at all, what did you make it
against?
thanks,
greg k-h
^ permalink raw reply
* [PATCH] MAINTAINERS: update entry for atmel_serial driver
From: Richard Genoud @ 2016-09-29 6:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475078653.2685.1.camel@perches.com>
2016-09-28 18:04 GMT+02:00 Joe Perches <joe@perches.com>:
> On Wed, 2016-09-28 at 17:47 +0200, Nicolas Ferre wrote:
>> Change maintainer for the serial driver found on most of the
>> Microchip / Atmel MPUs and take advantage of the move to rename
>> and reorder the entry.
> []
>> diff --git a/MAINTAINERS b/MAINTAINERS
> []
>> +MICROCHIP / ATMEL AT91 / AT32 SERIAL DRIVER
>> +M: Richard Genoud <richard.genoud@gmail.com>
>> +S: Maintained
>> +F: drivers/tty/serial/atmel_serial.c
>> +F: include/linux/atmel_serial.h
>
> Thanks Richard.
>
> include/linux is pretty cluttered with random files.
>
> atmel_serial.h is #include exactly once.
>
> Please move it out of include/linux and into
> drivers/tty/serial/ one day.
No problem, I'll add that to my TBD list !
Richard.
^ permalink raw reply
* [PATCH 0/3] [v2] Add basic ACPI support to the Qualcomm Technologies EMAC driver
From: David Miller @ 2016-09-29 5:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475081924-12362-1-git-send-email-timur@codeaurora.org>
From: Timur Tabi <timur@codeaurora.org>
Date: Wed, 28 Sep 2016 11:58:41 -0500
> This patch series adds support to the EMAC driver for extracting addresses,
> interrupts, and some _DSDs (properties) from ACPI. The first two patches
> clean up the code, and the third patch adds ACPI-specific functionality.
>
> The first patch fixes a bug with handling the platform_device for the
> internal PHY. This phy is treated as a separate device in both DT and
> ACPI, but since the platform is not released automatically when the
> driver unloads, managed functions like devm_ioremap_resource cannot be
> used.
>
> The second patch replaces of_get_mac_address with its platform-independent
> equivalent device_get_mac_address.
>
> The third patch parses the ACPI tables to obtain the platform_device for
> the primary EMAC node ("QCOM8070") and the internal phy node ("QCOM8071").
Series applied, thanks.
^ permalink raw reply
* [PATCH 2/2] drm/mediatek: clear IRQ status before enable OVL interrupt
From: CK Hu @ 2016-09-29 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475119789-64619-3-git-send-email-bibby.hsieh@mediatek.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
On Thu, 2016-09-29 at 11:29 +0800, Bibby Hsieh wrote:
> To make sure that the first vblank IRQ after enabling
> vblank isn't too short or immediate, we have to clear
> the IRQ status before enable OVL interrupt.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 019b7ca..f75c5b5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -80,6 +80,7 @@ static void mtk_ovl_enable_vblank(struct mtk_ddp_comp *comp,
> ddp_comp);
>
> priv->crtc = crtc;
> + writel(0x0, comp->regs + DISP_REG_OVL_INTSTA);
> writel_relaxed(OVL_FME_CPL_INT, comp->regs + DISP_REG_OVL_INTEN);
> }
>
^ permalink raw reply
* [PATCH v3 2/7] i2c: bcm2835: Protect against unexpected TXW/RXR interrupts
From: Stefan Wahren @ 2016-09-29 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d93a0590-1783-b913-9362-007628cb17d6@tronnes.org>
> Noralf Tr?nnes <noralf@tronnes.org> hat am 29. September 2016 um 00:22
> geschrieben:
>
>
>
> Den 29.09.2016 00:00, skrev Eric Anholt:
> > Noralf Tr?nnes <noralf@tronnes.org> writes:
> >
> >> If an unexpected TXW or RXR interrupt occurs (msg_buf_remaining == 0),
> >> the driver has no way to fill/drain the FIFO to stop the interrupts.
> >> In this case the controller has to be disabled and the transfer
> >> completed to avoid hang.
> >>
> >> (CLKT | ERR) and DONE interrupts are completed in their own paths, and
> >> the controller is disabled in the transfer function after completion.
> >> Unite the code paths and do disabling inside the interrupt routine.
> >>
> >> Clear interrupt status bits in the united completion path instead of
> >> trying to do it on every interrupt which isn't necessary.
> >> Only CLKT, ERR and DONE can be cleared that way.
> >>
> >> Add the status value to the error value in case of TXW/RXR errors to
> >> distinguish them from the other S_LEN error.
> > I was surprised that not writing the TXW/RXR bits on handling their
> > interrupts was OK, given that we were doing so before, but it's a level
> > interrupt and those bits are basically ignored on write.
> >
> > This patch and 3, 4, and 6 are:
> >
> > Reviewed-by: Eric Anholt <eric@anholt.net>
> >
> > Patch 5 is:
> >
> > Acked-by: Eric Anholt <eric@anholt.net>
> >
> > Note for future debug: The I2C_C_CLEAR on errors will take some time to
> > resolve -- if you were in non-idle state and I2C_C_READ, it sets an
> > abort_rx flag and runs through the state machine to send a NACK and a
> > STOP, I think. Since we're setting CLEAR without I2CEN, that NACK will
> > be hanging around queued up for next time we start the engine.
>
> Maybe you're able to explain the issues I had with reset:
> https://github.com/raspberrypi/linux/issues/1653
>
> Should we put your note into the commit message?
> It will most likely be lost if it just stays in this email.
I prefer to have this kind of information as a code comment.
>
> Noralf.
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] drm/mediatek: set vblank_disable_allowed to true
From: CK Hu @ 2016-09-29 5:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475119789-64619-2-git-send-email-bibby.hsieh@mediatek.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
On Thu, 2016-09-29 at 11:29 +0800, Bibby Hsieh wrote:
> MTK DRM driver didn't set the vblank_disable_allowed to
> true, it cause that the irq_handler is called every
> 16.6 ms (every vblank) when the display didn't be updated.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index eebb7d8..941ec5f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -200,6 +200,7 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> if (ret < 0)
> goto err_component_unbind;
>
> + drm->vblank_disable_allowed = true;
> drm_kms_helper_poll_init(drm);
> drm_mode_config_reset(drm);
>
^ permalink raw reply
* [PATCH v19 05/12] fpga-mgr: add fpga image information struct
From: Alan Tull @ 2016-09-29 4:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAtXAHcdSsVUE4hQ6isCp7_35ZKb60EAKAgtGwBR41apwPpe=g@mail.gmail.com>
On Wed, Sep 28, 2016 at 6:41 PM, Moritz Fischer
<moritz.fischer@ettus.com> wrote:
Hi Moritz,
> Hi Alan,
>
> generally ok with the change.
Cool!
>
> On Wed, Sep 28, 2016 at 11:21 AM, Alan Tull <atull@opensource.altera.com> wrote:
>
>> -int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf,
>> - size_t count)
>> +int fpga_mgr_buf_load(struct fpga_manager *mgr, struct fpga_image_info *info,
>> + const char *buf, size_t count)
>
> Doesn't this break the both socfpga and zynq if [6/12] and [7/12] are
> not part of this commit?
> i.e shouldn't 5,6 and 7 be a single commit?
Yeah, squashing those would improve bisectability.
Alan
aka atull
>
> Cheers,
> Moritz
^ permalink raw reply
* [PATCH] drm/mediatek: fix a typo
From: CK Hu @ 2016-09-29 4:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475119322-58657-1-git-send-email-bibby.hsieh@mediatek.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
On Thu, 2016-09-29 at 11:22 +0800, Bibby Hsieh wrote:
> Fix the typo: OD_RELAYMODE->OD_CFG
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index df33b3c..aa5f20f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -123,7 +123,7 @@ static void mtk_od_config(struct mtk_ddp_comp *comp, unsigned int w,
> unsigned int bpc)
> {
> writel(w << 16 | h, comp->regs + DISP_OD_SIZE);
> - writel(OD_RELAYMODE, comp->regs + OD_RELAYMODE);
> + writel(OD_RELAYMODE, comp->regs + OD_CFG);
> mtk_dither_set(comp, bpc, DISP_OD_CFG);
> }
>
^ permalink raw reply
* [PATCH 2/2] drm/mediatek: clear IRQ status before enable OVL interrupt
From: Bibby Hsieh @ 2016-09-29 3:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475119789-64619-1-git-send-email-bibby.hsieh@mediatek.com>
To make sure that the first vblank IRQ after enabling
vblank isn't too short or immediate, we have to clear
the IRQ status before enable OVL interrupt.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 019b7ca..f75c5b5 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -80,6 +80,7 @@ static void mtk_ovl_enable_vblank(struct mtk_ddp_comp *comp,
ddp_comp);
priv->crtc = crtc;
+ writel(0x0, comp->regs + DISP_REG_OVL_INTSTA);
writel_relaxed(OVL_FME_CPL_INT, comp->regs + DISP_REG_OVL_INTEN);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] drm/mediatek: set vblank_disable_allowed to true
From: Bibby Hsieh @ 2016-09-29 3:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475119789-64619-1-git-send-email-bibby.hsieh@mediatek.com>
MTK DRM driver didn't set the vblank_disable_allowed to
true, it cause that the irq_handler is called every
16.6 ms (every vblank) when the display didn't be updated.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index eebb7d8..941ec5f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -200,6 +200,7 @@ static int mtk_drm_kms_init(struct drm_device *drm)
if (ret < 0)
goto err_component_unbind;
+ drm->vblank_disable_allowed = true;
drm_kms_helper_poll_init(drm);
drm_mode_config_reset(drm);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/2] fix issue: vblank interrupts are never disabled
From: Bibby Hsieh @ 2016-09-29 3:29 UTC (permalink / raw)
To: linux-arm-kernel
Clean the interrupt status before enable interrupt
and set the vblank_disable_allowed to fix the issue.
Bibby Hsieh (2):
drm/mediatek: set vblank_disable_allowed to true
drm/mediatek: clear IRQ status before enable OVL interrupt
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 1 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
2 files changed, 2 insertions(+)
--
1.7.9.5
^ permalink raw reply
* [PATCH] drm/mediatek: fix a typo
From: Bibby Hsieh @ 2016-09-29 3:22 UTC (permalink / raw)
To: linux-arm-kernel
Fix the typo: OD_RELAYMODE->OD_CFG
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index df33b3c..aa5f20f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -123,7 +123,7 @@ static void mtk_od_config(struct mtk_ddp_comp *comp, unsigned int w,
unsigned int bpc)
{
writel(w << 16 | h, comp->regs + DISP_OD_SIZE);
- writel(OD_RELAYMODE, comp->regs + OD_RELAYMODE);
+ writel(OD_RELAYMODE, comp->regs + OD_CFG);
mtk_dither_set(comp, bpc, DISP_OD_CFG);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 3/3] drm/mediatek: modify the factor to make the pll_rate set in the 1G-2G range
From: Bibby Hsieh @ 2016-09-29 3:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475118135-56780-1-git-send-email-bibby.hsieh@mediatek.com>
From: Junzhi Zhao <junzhi.zhao@mediatek.com>
Currently, the code sets the "pll" to the desired multiple
of the pixel clock manully(4*3m 8*3,etc). The valid range
of the pll is 1G-2G, however, when the pixel clock is bigger
than 167MHz, the "pll" will be set to a invalid value( > 2G),
then the "pll" will be 2GHz, thus the pixel clock will be in
correct. Change the factor to make the "pll" be set in the
(1G, 2G) range.
Signed-off-by: Junzhi Zhao <junzhi.zhao@mediatek.com>
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 0186e50..90fb831 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -432,11 +432,16 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
unsigned long pll_rate;
unsigned int factor;
+ /* let pll_rate can fix the valid range of tvdpll (1G~2GHz) */
pix_rate = 1000UL * mode->clock;
- if (mode->clock <= 74000)
+ if (mode->clock <= 27000)
+ factor = 16 * 3;
+ else if (mode->clock <= 84000)
factor = 8 * 3;
- else
+ else if (mode->clock <= 167000)
factor = 4 * 3;
+ else
+ factor = 2 * 3;
pll_rate = pix_rate * factor;
dev_dbg(dpi->dev, "Want PLL %lu Hz, pixel clock %lu Hz\n",
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 2/3] drm/mediatek: enhance the HDMI driving current
From: Bibby Hsieh @ 2016-09-29 3:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475118135-56780-1-git-send-email-bibby.hsieh@mediatek.com>
From: Junzhi Zhao <junzhi.zhao@mediatek.com>
In order to improve 4K resolution performance,
we have to enhance the HDMI driving current
when clock rate is greater than 165MHz.
Signed-off-by: Junzhi Zhao <junzhi.zhao@mediatek.com>
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 42 +++++++++++++++++-------
1 file changed, 30 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index 8a24754..51cb9cf 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -265,6 +265,9 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, unsigned long rate,
struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
unsigned int pre_div;
unsigned int div;
+ unsigned int pre_ibias;
+ unsigned int hdmi_ibias;
+ unsigned int imp_en;
dev_dbg(hdmi_phy->dev, "%s: %lu Hz, parent: %lu Hz\n", __func__,
rate, parent_rate);
@@ -298,18 +301,31 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, unsigned long rate,
(0x1 << PLL_BR_SHIFT),
RG_HDMITX_PLL_BP | RG_HDMITX_PLL_BC |
RG_HDMITX_PLL_BR);
- mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON3, RG_HDMITX_PRD_IMP_EN);
+ if (rate < 165000000) {
+ mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON3,
+ RG_HDMITX_PRD_IMP_EN);
+ pre_ibias = 0x3;
+ imp_en = 0x0;
+ hdmi_ibias = hdmi_phy->ibias;
+ } else {
+ mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON3,
+ RG_HDMITX_PRD_IMP_EN);
+ pre_ibias = 0x6;
+ imp_en = 0xf;
+ hdmi_ibias = hdmi_phy->ibias_up;
+ }
mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON4,
- (0x3 << PRD_IBIAS_CLK_SHIFT) |
- (0x3 << PRD_IBIAS_D2_SHIFT) |
- (0x3 << PRD_IBIAS_D1_SHIFT) |
- (0x3 << PRD_IBIAS_D0_SHIFT),
+ (pre_ibias << PRD_IBIAS_CLK_SHIFT) |
+ (pre_ibias << PRD_IBIAS_D2_SHIFT) |
+ (pre_ibias << PRD_IBIAS_D1_SHIFT) |
+ (pre_ibias << PRD_IBIAS_D0_SHIFT),
RG_HDMITX_PRD_IBIAS_CLK |
RG_HDMITX_PRD_IBIAS_D2 |
RG_HDMITX_PRD_IBIAS_D1 |
RG_HDMITX_PRD_IBIAS_D0);
mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON3,
- (0x0 << DRV_IMP_EN_SHIFT), RG_HDMITX_DRV_IMP_EN);
+ (imp_en << DRV_IMP_EN_SHIFT),
+ RG_HDMITX_DRV_IMP_EN);
mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6,
(hdmi_phy->drv_imp_clk << DRV_IMP_CLK_SHIFT) |
(hdmi_phy->drv_imp_d2 << DRV_IMP_D2_SHIFT) |
@@ -318,12 +334,14 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, unsigned long rate,
RG_HDMITX_DRV_IMP_CLK | RG_HDMITX_DRV_IMP_D2 |
RG_HDMITX_DRV_IMP_D1 | RG_HDMITX_DRV_IMP_D0);
mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON5,
- (hdmi_phy->ibias << DRV_IBIAS_CLK_SHIFT) |
- (hdmi_phy->ibias << DRV_IBIAS_D2_SHIFT) |
- (hdmi_phy->ibias << DRV_IBIAS_D1_SHIFT) |
- (hdmi_phy->ibias << DRV_IBIAS_D0_SHIFT),
- RG_HDMITX_DRV_IBIAS_CLK | RG_HDMITX_DRV_IBIAS_D2 |
- RG_HDMITX_DRV_IBIAS_D1 | RG_HDMITX_DRV_IBIAS_D0);
+ (hdmi_ibias << DRV_IBIAS_CLK_SHIFT) |
+ (hdmi_ibias << DRV_IBIAS_D2_SHIFT) |
+ (hdmi_ibias << DRV_IBIAS_D1_SHIFT) |
+ (hdmi_ibias << DRV_IBIAS_D0_SHIFT),
+ RG_HDMITX_DRV_IBIAS_CLK |
+ RG_HDMITX_DRV_IBIAS_D2 |
+ RG_HDMITX_DRV_IBIAS_D1 |
+ RG_HDMITX_DRV_IBIAS_D0);
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 1/3] drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock enable
From: Bibby Hsieh @ 2016-09-29 3:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475118135-56780-1-git-send-email-bibby.hsieh@mediatek.com>
From: Junzhi Zhao <junzhi.zhao@mediatek.com>
The mtk_hdmi_send_infoframe have to
be run after PLL and PIXEL clock of HDMI enable.
Make sure that HDMI inforframes can be sent
successfully.
Signed-off-by: Junzhi Zhao <junzhi.zhao@mediatek.com>
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 334562d..875b045 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1133,12 +1133,6 @@ static int mtk_hdmi_output_set_display_mode(struct mtk_hdmi *hdmi,
phy_power_on(hdmi->phy);
mtk_hdmi_aud_output_config(hdmi, mode);
- mtk_hdmi_setup_audio_infoframe(hdmi);
- mtk_hdmi_setup_avi_infoframe(hdmi, mode);
- mtk_hdmi_setup_spd_infoframe(hdmi, "mediatek", "On-chip HDMI");
- if (mode->flags & DRM_MODE_FLAG_3D_MASK)
- mtk_hdmi_setup_vendor_specific_infoframe(hdmi, mode);
-
mtk_hdmi_hw_vid_black(hdmi, false);
mtk_hdmi_hw_aud_unmute(hdmi);
mtk_hdmi_hw_send_av_unmute(hdmi);
@@ -1401,6 +1395,16 @@ static void mtk_hdmi_bridge_pre_enable(struct drm_bridge *bridge)
hdmi->powered = true;
}
+static void mtk_hdmi_send_infoframe(struct mtk_hdmi *hdmi,
+ struct drm_display_mode *mode)
+{
+ mtk_hdmi_setup_audio_infoframe(hdmi);
+ mtk_hdmi_setup_avi_infoframe(hdmi, mode);
+ mtk_hdmi_setup_spd_infoframe(hdmi, "mediatek", "On-chip HDMI");
+ if (mode->flags & DRM_MODE_FLAG_3D_MASK)
+ mtk_hdmi_setup_vendor_specific_infoframe(hdmi, mode);
+}
+
static void mtk_hdmi_bridge_enable(struct drm_bridge *bridge)
{
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
@@ -1409,6 +1413,7 @@ static void mtk_hdmi_bridge_enable(struct drm_bridge *bridge)
clk_prepare_enable(hdmi->clk[MTK_HDMI_CLK_HDMI_PLL]);
clk_prepare_enable(hdmi->clk[MTK_HDMI_CLK_HDMI_PIXEL]);
phy_power_on(hdmi->phy);
+ mtk_hdmi_send_infoframe(hdmi, &hdmi->mode);
hdmi->enabled = true;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 0/3] MT8173 HDMI 4K support
From: Bibby Hsieh @ 2016-09-29 3:02 UTC (permalink / raw)
To: linux-arm-kernel
This is MT8173 HDMI 4K support PATCH v5, based on 4.8-rc1.
In order to support HDMI 4K on MT8173,
we have to make some modifications.
1) Make sure that mtk_hdmi_send_infoframe is sent successfully.
2) Enhance the HDMI driving current to improve performance.
3) Make sure that pixel clock is 297MHz when resolution is 4K.
Changes since v4:
- Update commit message and patch title.
Changes since v3:
- Rebase to 4.8-rc1.
- The valid range of tvdpll is 1G to 2G Hz, so, we Change the
if statement of mode->clock to fit that and add a comment.
Changes since v2:
- Remove the change about preparation for MT2701 support.
Changes since v1:
- According to the suggestion from philipp, We use the new
dpi0_sel rate set method.
- calls clk_set_rate to set the dpi0_sel according to the
pixel clock.
- Remove the direct access to all the intermediate clock part.
- Remove the intermediate tvdpll_d* clocks in dts.
- According to suggestion from CK, we rename the clock parse
function and remove it from mtk_dpi_conf struct.
- Merges the hdmi Pll set rate for pixel clock greater than
165MHz and smaller parts.
The PATCH depends on the following patch:
https://patchwork.kernel.org/patch/9262575/
(arm64: dts: mt8173: add mmsel clocks for 4K support)
Junzhi Zhao (3):
drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock enable
drm/mediatek: enhance the HDMI driving current
drm/mediatek: modify the factor to make the pll_rate set in the 1G-2G
range
drivers/gpu/drm/mediatek/mtk_dpi.c | 9 +++--
drivers/gpu/drm/mediatek/mtk_hdmi.c | 17 ++++++----
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 42 +++++++++++++++++-------
3 files changed, 48 insertions(+), 20 deletions(-)
--
1.7.9.5
^ 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